In my new project, we have 4 automation testers working together on four different modules of an application . Its a web application and we work on windows platform. The automation tool being used is QTP and we are following a hybrid framework using Object repository and DP as required. I would like to know the best approach here to take. As all four of us are working on different modules and finally we have to integrate them together into the test machine, where all our scripts will run together. We are not planning to remove OR as scripts with OR is running much faster than those with DP in our application. The problem we are facing is that , as each of us have our on local OR , each time we add new code to test machine, we also put our respective OR after making it .tsr into the shared repository and associate them to the script. This creates a lot of object redundancy in the shared repository . What we are planning to do is make those shared repo as local in the test machine and delete all those duplicate objects each time and update the repo from application. Please suggest me the best approach to this problem , so that we can maintain a robust test frame work for our application , which will also be easy to handle and maintain.
Having a robust framework is always a challenge for an Automation Engineer. I had worked on a project in which, we added every single object into the repository and finally found the maintenance activity as a Herculean task. Also, maintaining a local OR for every script will add to more chaos. (I hope you agree to this)
With the help of an Automation Engineer we arrived at a reasonably good framework and I will share some of the features that we follow here. (Ours is a Desktop application and you may correlate it to a web application)
Adding only the parent dialog to the OR. The controls that you want to access should be done through a function that identifies the child by its parent & classname/title etc This will avert the cumbersome activity that might come up if you had added every single control to the OR. Since the parent is known, finding the appropriate child would be quick. Additionally, it won't eat up your time had you used DP.
Maintain an include file in which you will be writing functions to define your parent objects (that you added to the OR). Different parents of the same class could be written in a same function and selected using SELECT CASE based on the parameter that you pass through the function. This will not only reduce the length of your code, but also help in the easy maintenance of OR.
We maintain our repository on network. So if one person is modifying a file, it will be opened as a Read-only file for others. Also, if you have followed the approach mentioned in (1) & (2), OR will be just a one-time investment !