5 Steps to Implementing an Effective Locator Strategy for Seamless Automation Testing

5 min readSep 4, 2023

Unlock the Full Potential of Automation Testing: Streamline Your Locator Strategy Today! #AutomationTesting #LocatorStrategy #SoftwareTesting

Introduction

In the world of web automation testing, the term “locator” refers to the way we identify elements on a web page that our automation scripts interact with. The constant evolution of modern web development poses a unique set of challenges for automation testers, particularly in reliably locating these web elements. This article aims to lay down a comprehensive locator strategy that serves as a blueprint for finding web elements during automated tests. It’s an essential read for testers dealing with flaky test scripts and inconsistent locator methods.

Examples of different types of locators used in automation testing. From XPath to IDs, this variety often leads to inconsistency and flakiness in automated tests if not managed properly.

Why Care About Locator Strategy?

You may ask, why even bother with a locator strategy? Well, consider the pains of debugging failed tests, only to find out the issue lies in flimsy locators. A minor change in an element’s attribute, a tiny modification in the hierarchy, can lead to broken test scripts. It’s akin to going on a trip with a poorly drawn map — time-consuming, frustrating, and leading to unexpected detours.

The headache of dealing with fragile locators can be avoided with a robust strategy. Image credit: Canva

Take the example of Google Maps. Imagine you’re on your way to a destination, faithfully following the GPS directions. Suddenly, you hit an unexpected detour — maybe a road closure or a new one-way street. Your map didn’t account for this change, and now you’re scrambling to find an alternative route in unfamiliar territory. Similarly, without a robust locator strategy, any change in the application can lead to your automation scripts going off course, resulting in wasted time and resources.

My Journey in Implementing Locator Strategies

When I first started focusing on automation testing for a specific project in my company, I faced the challenge of dealing with flaky locators. For instance, we were using locators like these:

Flaky Xpath: //div//div/span[2]

Flaky accessible ID: Sign in

Flaky Class: btn_class_v2

These kinds of locators would often break with even the smallest changes in the UI, leading to test failures and script maintenance headaches.

Recognizing the need for change, I embarked on a journey to create a more robust locator strategy. With trial and error, and in collaboration with developers, we created a standardized locator schema:

Schema Format: screenName_widget_widget
NameFor example: login_button_loginBtn, home_text_welcomeMsg

This schema was designed to make our locators both descriptive and stable. We implemented this strategy within a single project initially and observed the following benefits:

Reduced script maintenance
Fewer failed tests due to unstable locators

The positive outcomes caught the attention of higher management, leading to the incorporation of this locator strategy into our standard development and testing cycles. Today, this schema is an integral part of all ongoing and future projects, ensuring a consistent, efficient, and maintainable automation test suite.

Setting Up a Locator Strategy

To make your test automation as robust as possible, it’s essential to have a well-thought-out locator strategy. Below is a step-by-step guide to setting one up:

1. Define a Locator Strategy

The first step is to decide what types of locators you will use. Your options generally include IDs, Classes, Names, XPath, and CSS Selectors. Our team chose to use IDs primarily because of their stability and uniqueness.

Example Naming Convention

screenName_widget_widgetName

Concrete Example

login_button_loginBtn

Use Unique Keys for Elements

If you’re working on mobile apps, use unique keys for elements that serve as the ‘Accessibility ID’. This unique key should also be an attribute like ‘content-desc’ or ‘text’.

Example:

For a login button, the unique key could be login_button_loginBtn.
This unique key then becomes the ‘Accessibility ID’.

Create Unique XPaths

To further solidify our locator strategy, we also decided to create unique XPaths using attributes like ‘content-desc’ or ‘text’ when dealing with mobile elements.

Example:

XPath Format: //element_type[contains(@attribute, 'unique_key')]

Concrete Example:

//android.view.View[contains(@content-desc, 'login_button_loginBtn')]

By adopting this two-pronged strategy — utilizing IDs and generating unique XPaths based on those IDs — we were able to greatly stabilize our test scripts. They became less susceptible to breaks due to UI changes, thereby saving us significant time and resources in script maintenance.

2. Prototype in a Feature:

Rather than implementing custom IDs, our team took a slightly different approach. We designated unique keys for each element on the development end. For instance, in Android, we used the setContentDescription method to set these keys:

yourButton.setContentDescription("login_button_loginBtn");

These keys served as accessible IDs and were integrated into one of the element’s attributes, such as content description or text. We began this process by focusing on the login page of our application. This method allowed us to validate the effectiveness of using unique keys as locators in a controlled environment before rolling it out to other features.

3. Collaborate with Dev Team

This is the most crucial step in the entire process, as it requires close collaboration with the development team. Initially, I faced resistance when proposing these unique keys as element identifiers. However, I arranged a quick demonstration to showcase how this strategy would significantly reduce script failure due to fragile locators.

For instance, consider a button that frequently changed positions in the app. By using a stable unique key, we were able to keep our tests running smoothly regardless of any UI changes. The demonstration was convincing enough to secure the development team’s support.

Now, our developers actively participate in ensuring that each new feature is built with these locators in mind, making our automation scripts more resilient and efficient.

4. Iterate and Extend

Once the strategy has been successfully validated in one feature — our login page, in this case — it’s time to extend it throughout the application. We created a roadmap and started implementing our locator strategy module by module. For example, after tackling the login page, we moved on to user profile settings, payment gateways, and eventually covered all features of the application. This incremental approach allowed us to continually test and refine our locator strategy, making adjustments as needed.

5. Include in Dev Cycle

Finally, make it a part of your development and testing cycle so that all future elements are consistent with this locator strategy. Importantly, this shouldn’t be a one-time effort. Instead, make it an integral part of the development cycle. Our team has incorporated this locator strategy into our Definition of Done, ensuring that no feature is marked as complete until it conforms to our locator strategy. This guarantees that all new elements are created with automation in mind, leading to less brittle and more maintainable test scripts.

Conclusion

By systematically defining, prototyping, and refining your web locator strategy — while collaborating closely with your development team — you pave the way for more efficient, maintainable, and robust automation testing.

Acknowledgment

Special thanks to Top industry expert James Bach the Founder of Rapid Software Testing Methodology. An internationally known teacher, author, and consultant, James’ invaluable insights and feedback have been instrumental in enriching this article.

#AutomationTesting #LocatorStrategy #Testing #SoftwareQuality #Collaboration