Table of Contents
An object repository is the backbone of any UI test automation framework in UFT/QTP. Whether local or shared, it enables UFT to uniquely identify and interact with objects in the application under test.
Choosing the right object repository strategy can have significant impacts on test maintenance effort, reuse, script resilience and overall automation ROI. This comprehensive guide examines local vs shared repositories in depth – their strengths and weaknesses, use cases, best practices, and even hybrid approaches.
Local Object Repositories
Local object repositories are attached directly to each action, storing objects and their properties that were recorded or added for that specific test.
Pros
-
Simplicity – Easy to create and maintain without any admin overhead. Just start recording and local repositories are automatically generated.
-
Encapsulation – Changes to the local repository only impact that particular action.
-
Portability – Can be copied and moved easily between actions.
Cons
-
No reuse – Local object repositories cannot be shared across multiple actions or tests. Object and property details need to be re-learnt for every test.
-
Testing overhead – Changes to the application UI may break many tests using local repositories, requiring effort to diagnose and update each action.
-
Script fragility – Edits to the local repository for one action can inadvertently affect other actions if not encapsulated properly.
When to use
Local repositories work best for small, stable applications where tests do not share many objects and test maintenance effort needs to be minimal.
As per recent surveys on test automation challenges, applications changing frequently causes over 30% of scripts to fail. Local repositories would prove inefficient for rapidly evolving UIs.
Shared Object Repositories
Shared object repositories consolidate objects and their properties into a common, external storage that can be accessed by multiple tests across the framework.
Pros
-
Reuse – Objects and properties learned once can be leveraged across actions, reducing replay effort. As per testing best practices, maximizing reuse improves ROI.
-
Centralized – UI changes only need updates in one central repository rather than each test individually.
-
Robust – Enables dynamic object recognition using multiple properties rather than just screen location, improving script resilience.
Cons
-
Maintenance – Shared repositories require tools for versioning, merge management etc. – adding to admin effort.
-
Dependency – Tests depend directly on the shared repository – changes risk breaking multiple scripts.
-
Access – Can create challenges for distributed teams with remote access rights, parallel development etc.
When to use
Shared object repositories are preferable for enterprise test automation addressing large, frequently changing applications – especially where multiple tests validate the same flows.
Research shows that nearly 60% of test automation projects face challenges from frequent application changes. Shared object repositories equipped with version control and dynamic object recognition better withstand UI changes.
As per recent Capgemini test automation benchmarks, maximizeing test asset reuse can improve execution efficiency by over 15% and accelerate time-to-market by nearly 25% over siloed test automation.
Recommended Practices
Repository Administration
Employ an Object Repository Administrator role focused solely on shared asset maintenance. Specialized competencies and clear accountability improves reliability and uptime.
Leverage source control tools like GIT or SVN providing versioning, branching, merging etc for shared repositories – especially with distributed teams. Connect UFT to TFS or VSTS for built-in features.
Change Management
To minimize dependency risk, introduce EC (Engineering Change) processes ensuring repository changes are assessed for downstream impact and communicated proactively.
Design automated "canary" regression suites specifically targeting shared objects to alert breakages. Promote shared repository KPIs like usage levels and uptime alongside other QA metrics.
Object Recognition
Employ advanced object identification techniques like dynamic descriptive programming rather than just using screen co-ordinates for resilience against UI changes.
Combine partial descriptions, regular expressions, context references etc when creating shared objects to maximize recognition probability even when application controls move or alter.
Making the Choice
Hopefully this guide has revealed some key considerations when weighing local versus shared object repository approaches. Like most quality assurance decisions, analyze your specific solution landscape across these factors:
Application Factors
- UI Volatility – frequency and complexity of UI changes
- Integrations variability – impacts on application workflows
- Test case diversity – overlap in test coverage
Automation Factors
- Framework maturity – developer skills, enablement levels
- Execution distribution – sharing test cases across tools, environments
- Release velocity – continuous delivery pipeline stages
QTP Tooling Factors
- Object identification methods utilized
- Descriptive programming skills & adoption
- Integrations with CI/CD and test management tools
This decision matrix can help indicate where shared repositories make sense over local ones for optimal reuse and resilience:
Additionally, consider potential hybrid models maximizing pros while minimizing cons of both approaches:
- Maintain a shared baseline repository with commonly accessed objects
- Extend tests with local repositories for action-specific needs
- Employ a shared repository solely for dynamic descriptive objects
Hopefully this guide has provided a comprehensive strategy evaluation of local versus shared techniques for managing object repositories in UFT/QTP. Choose the approach aligned closest to your test automation environment complexity, maturity and UI volatility patterns.