How To Enable Reusability With Object Repositories In Automation Testing
As an automation developer, don’t we feel a sense of satisfaction when we hear from the manual testing team, or the client on how they have benefitted by using the automation that we built? For this, we vouch for a high-quality automation suite which is not only robust, but also easily adaptable to updates required as per any business/technical requirement changes. Maintenance should be easy—is what we keep reminding ourselves. What are the ways to ensure this?
Amongst the several ways that we can ensure high quality of a Test Automation suite, one way is ensuring reusability—not just by re-using commonly used test steps, but also re-using commonly used UI objects. In this article, I will explain how we can use object repositories to enhance the reusability aspect by re-using objects in a UI test automation project.
- What Is Object Repository in Automation Testing?
- Why Is It Important?
- Best Practices To Follow When Using Object Repositories
- How To Create Object Repositories (Examples)
What Is Object Repository in Automation Testing?
When you first start off with designing the test automation suite, most of us ensure that we are not re-writing blocks of code. For this, we build re-usable functions, make the re-usable blocks of code available in code libraries. However, have you re-used commonly used UI objects? If not, let me explain how you can do so by having an object repository as your base.
Object repository is a collection of UI objects that are commonly associated together. Not only does this enhance the reusability, but also ensures reliability and management of the UI elements in the automation suite.
While building the test automation scripts, you would have associated test script steps with each of these UI objects. Example, by –
- Typing into a text box UI object
- Retrieving the text from a Label UI object
- Clicking on the hyperlink object .. and so on.
Now, how can you enhance re-usability by re-using the UI objects that your scripts work on?
Well, if the test automation tool that you are using has an “object repository”, it's easy. Using an object repository, you could collate the UI objects and add, delete, manage, or update the UI objects from that repository in an organized way. You can eventually re-use the objects by referencing them.
Let us analyze a situation when you have not used an OR in your test automation suite. In such a case, for separate test automation scripts that use the same UI widget, you would add multiple copies of the same UI-object into each of the test scripts to perform activities on it.
Now, let us take a situation where we do use an OR. In such a case, you would have a single location/repository where you would store the UI objects. With that, in every test script that requires to act on the same UI object/widget, it would associate it to the same UI object stored in the OR. There is just one copy of the UI object in the test suite, with multiple test scripts referencing/calling the same UI object. And here is where re-usability comes into play!
Why Is It Important?
My first experience of having used an OR was when I used it in the IBM Rational Functional Test Automation tool. Since then, whenever I learn a new tool, I look forward to checking if that tool has the OR feature or not.
The first time I used an OR was when our team was automating a vast administrative Web UI console with several pages. We had 100+ test cases to automate. If we hadn’t used the OR, it would have been a massive challenge to automate. We analysed and came to the conclusion that the test automation suite that we were aiming to build was the ideal case to use an OR.
The reasons?
1. Each of the test cases that we were automating had several sub-flows in common, and hence had associated UI widgets in common.
Since there were common-subflows, there were obvious common UI objects in scenarios. We didn’t want to add copies of the same UI objects over and over so we decided to re-use the UI objects.
For example, a set of test cases would have to navigate through the same navigation menu links before acting on a set of steps. Hence, we planned that we would have a repository named to just store and manage all the navigation links. Then we were able to re-use the navigation menu links in an OR file.
2. We were informed that in the future, there could be situations of UI updates—in terms of hyperlinks, labels etc.
Hence, we wanted to ensure that when such a UI update happens, the test automation suite would be adaptable to change easily and any maintenance effort should be quick and easy.
Here is where the OR came to our rescue: we didn’t have to make changes to the UI object repositories in each copy of the same UI object. Whenever there was a change, we just had to update the one associated object in the OR, and the test scripts would run as per the updated UI object.
3. We had to build a test automation suite of 100+ scripts within a month!
Here is where another advantage of using an OR came in: by taking the approach of building an OR and all of us not having to re-add the same UI objects, we saved time. We built a well-organized OR, and all we had to do was build our code around the objects that we had organized in the OR.
We focused on the test case’s goal and the business logic of the test cases instead of wasting time re-inventing the wheel of adding objects for each test script. We saved time, and eventually delivered the test automation suite in the targeted time of a month!
Best Practices To Follow When Using Object Repositories
Now that you know situations where a UI Object repository would help, don’t you want to know what makes it click?
1. As a team, build a common goal of reusability. Together, understand why it can help your automation team, the manual testing team, and the client eventually.
2. While developing the test automation suite, as a team, always be in sync and be informed about the objects that you are building. Have a set of grouping rules and naming conventions that you all will abide by. When you get started, you could come up with a plan on how you plan to organize and store each of the OR files. Example, navigation menu objects in an OR file, a login page UI objects in another OR file, etc. Also, you could decide on the naming conventions for the objects so that they are easy to find.
3. Be sure to name the UI objects in such a way that it is readable, and easy to find and relate with. Name the UI objects in such a way that anyone else who scans through the UI repository in the intention of updating it should be able to find the UI object easily. In the example below, I will show one such situation.
How To Create Object Repositories (Examples)
Let’s now get hands on seeing how you can quickly get started with object repositories. Tools like UFT, IBM RFT, UiPath Test Automation Suite, and Power Automate have object repositories in them. So, why wait? Believe me, it is super easy!
Here is an example where I have created an OR with regards to the QAL website:
Observe the above UI – I grouped all the widgets associated with taking actions on the login UI widgets together as they would be common across several test cases. Next, I grouped the navigation links together. If we are to record these objects in a group, then when all test scripts will be definitely using this group of UI link objects in the beginning of each test case, these objects can be reused instead of re-adding them to the repository
Example Of Using The Object Repository In UiPath
Here is how the object repository looks in the UiPath tool:
In this example of the object repository, I have organized the “Login page” objects into one set and the “Main Navigation Links” in another set. With this, if I were to build several test scripts to—let’s say—test the Login Page, I would have all the test scripts “calling” the same objects that I had placed in the “Login Page”.
Example Of Using The Object Repository In PowerAutomate
Here is how the object repository looks in the PowerAutomate tool:
Like I mentioned earlier, the key to re-usability is also ensuring that you name the objects that you can find easily later. Observe the “meprmath_quiz” UI object. Unlike the other fields, we can’t really identify which UI object it refers to easily. Hence, in a case such as the above, though when I added the UI object for the “quiz” text box it showed the field name as “meprmath_quiz”, we could perhaps name it as “login_add” or so to make the object easy to locate while automating and maintaining the OR.
Wrapping Up
So, how are you using the OR in your favorite test automation tool? We would love to know.
I hope this article helps you understand how OR helps the team in the long run. We are lucky that we are in an era where most test automation tools have the OR feature available in them. Hence, all you have to do is just explore how it works in your favorite tool!
Learned something new in this article? If you are keen for more articles like this, don’t forget to subscribe to The QA Lead Newsletter!
Related Reads:
Related List of Tools: PERFORMANCE TESTING SOFTWARE FOR QA TEAMS
Also Worth Checking Out: