Recently, I was attending a session on best practices in test automation. One of hot-button topic between the attendees was Object Management. There were lots of inputs about how to identify run time objects, objects changing properties, etc. there were answers coming all around. To my surprise, the topic did not extend further. For majority of them this is what Object Management means!
Test automation predominantly revolves around GUI, objects i.e. various UI controls. Ability of an automation tool to deal with objects is certainly important when selecting an automation tool for your Application-Under-Test (AUT). At the same time, how you look at using it for Object Management is just as important.
Object Management is not mere object identification, but a lot more than that. The following list will throw some light on what I mean:
- Object Identification – Tool algorithm used to identify objects – Name, ID, Link, XPath, etc. that will work across browsers. Do I need technical skills to identify objects?
- Object Repository – Let me know when objects are added by other users to avoid relearning and improve reusability
- Object Maintenance: Let me know when objects are added or removed within AUT for me understand the impact of object change
In the context of Selenium (
http://seleniumhq.org), there is no out-of-the box solution for Object Management – identification and repository. This furthermore increases the relevance and importance of needing a test automation solution that works in conjunction with Selenium to provide a comprehensive Object Management functionality.
Let us discuss the Object Management points mentioned above in detail.
Object Identification:
Object identification, to be more precise, objects being identified accurately demands certain steps to be followed and is certainly not a straight forward experience in Se-RC or Se-WD.
Se-WD offers a range of locators to point to a specific object in AUT. To name a few – ID, Name, Xpath, CSS, etc. Many a times user has to make use of Selenium IDE on Firefox to identify objects which is not a full proof solution. Even in that case, there are limitations such as:
1. User wants to verify text and not performing any other action
2. Se-IDE frequently generates index-based Xpath, which is not the right approach as maintainability becomes an issue
3. Se-IDE locators work only on single html reference at a time. Whereas web technology allows nested html structure with frames. If you want your Se-WD to act on an object which belongs to frame/iframe, you must select the frame first.
Then there are tools such as Firebug that can provide a much deeper understanding of the objects. The drawback here is that it demands understanding of HTML DOM to help you decide how to deal with objects to derive the best object identification locator.
While I explain this, I am getting more technical and your automation will demand even more technical depth to deal with objects using Se-WD. This is where a more integrated object identification capability combined with intelligent locator algorithm within an automation tool would be most ideal.
Object Repository:
Having a centralized Object Repository is an absolute necessity for any test automation initiative to be sustainable. In a multi-user environment, Object Repository reduces duplication of effort involved in learning objects if another user has already defined those objects. Only new or changed objects need to be dealt with. Most automation tools would provide for some form of Object Repository.
What is more important is the depth of functionality offered within the automation tool for Object Repository. These would include:
- Do you know which objects are used in which test cases?
- Can you bulk-add objects on a page vs. a one-by-one adding of objects?
- Can you identify objects in the Object Repository that are no longer available in the AUT?
- How easily can you navigate the thousands of objects that reside in the Object Repository?
Furthermore, in an Agile development environment, can you add object place holders so that as development is happening, even automation can begin in parallel. You can easily update the object definitions as the AUT is being released to QA for testing and automation.
An automation tool that provides more than just a centralized Object Repository, would help achieve the bigger goal of Object Management.
Object Maintenance:
How do we manage objects that are learnt so that we can adapt any change in future in a very efficient manner?
A change in application can be introduction of new UI or change in existing UI. In either of the case one must know which objects are already present in the repository and which objects in AUT have undergone a change and require update in Object Repository. Many are lost in this phase, ending up with relearning the objects / making changes to object without knowing the impacted test cases. As a result you have to maintain duplicate objects or you get unnecessary failures during execution.
As mentioned earlier, the first step to help with Object Maintenance is Object Identification. Smarter object identification helps ensure that you only have to deal with object maintenance, if an object has truly undergone a change.
An automation tool that can help you understand the impact of any object change would go a long way in addressing the headaches associated with Object Management. For e.g.:
- Functionality that provides you a list of test cases that will be impacted by an object change instantly will help faster decision-making and changes.
- Ability to update an object once and all test cases using that object are automatically updated
Most currently available tools provide this information post an execution failure – basically, you will be reactive vs. proactive in maintaining objects. What a productivity drain and time lost!
Impact of Object Management on Automation ROI
Object management that looks beyond the basics of object identification will have a much larger impact on ROI from a test automation exercise. Incomplete and under-utilized Object Management will have adverse consequences such as:
- Productivity slows down
- Maintenance efforts increase
- Overall cost is increased as against anticipated savings
- Above all, readiness of automation suite is not guaranteed when required
Suffice to say that Object Management needs a deeper thought and hence, it is fair to conclude that Object Management mechanism cannot be taken lightly when using Se as your automation technology.
