We Can Do Better Than Fragile Locators

Test automation is of significant importance for companies searching to accelerate. Non-regression tests enable us to deliver changes with more confidence while their implementation represents concrete challenges.

The ecosystem is continuously evolving to improve our capacity to interact automatically with systems. Interfaces, drivers, and even off-the-shelf tools are available, such as Selenium with its IDE or the Appium library.

These toolboxes are valuable when used correctly to support our business drivers and test automation efforts. We must balance the “right automation” with getting the “automation right”.

This article shares why we need a locator strategy while giving perspectives on future developments.

Why we need a locator strategy

Test automation requires a repeatable execution process. Our test cases are usually composed of actions and controls on particular elements. We need identifiers to interact with these elements, also known as locators.

Concretely, we cannot automate tests for web, mobile, or even API without locators. The various technologies incorporate ways to identify our elements like XPATH within HTML; similar locators are available for XML and JSON.

We can navigate the element path in various ways, using ids, CSS, or hierarchical approaches. These possibilities create a whole set of options being free to use any of them. Therefore, a locator strategy will support the reliability of our test automation.

Let’s see what happens without a locator strategy.

No strategy leads to using accidental techniques

A new software application is already on its way to production. Facing a set of regression issues, the project team asks for automated tests. It seems a fair challenge having web and mobile tests to implement.

The first step is to discover the application and identify valuable automated tests to include in the scope. If you are lucky, a test automation framework is available to accelerate the initial setup. You can start implementing automated tests.

You record the tests actions and controls with their associated locators. The good part of having a test recorder is simplifying this task; you don’t even have to care about the locators. The test suite rapidly grows using modular testing.

You see that the locators are sometimes dynamic due to the front-end framework not finding any proper id. The project team starts to use your automated test suite for their non-regression tests. After a few executions, they are so unstable that the team discards them, letting you fix the issues.

At that point, you may try to use an alternative solution such as visual recognition. While it can work, image recognition is suitable for individual verifications and test techniques. Using “the right tool for the right job” is also valid for test automation.

Sticking to using locators, we can try to optimize them.

We then iterate to optimize the locators

While not being reliable, our test suite is hardly maintainable with the various locators strategies in use. We identify that starting to pay the interests of our technical debt is necessary to get value from our previous effort.

We can start by addressing coherency, harmonizing our various locators into a limited set of options. For example, we can choose to use only id and name locators, removing all relative paths that are unstable. This approach is the first step, assuming that we have id and name elements available.

After various iterations, we can hopefully have more stable tests. Unfortunately, the mobile test framework generates dynamic locators at each rendering; our locator strategy falls short here. In both cases, we reflect on tackling the root cause to have an efficient and robust system finally.

Including stable locators by design feels like a good idea.

Stable locators was a testability requirement

Our stable locator strategy means that fixed locators must be embedded inside the code in the first place. We understand that the inclusion of developers is necessary to move forward. We have in fact to shift-left.

Our sharing with the development team focuses on defining the stable core locators aligned with the regression test suite. A set of standard identifiers are defined, for instance, with ids starting with “autotest-<name>” to identify them correctly. 

This practice enables us to achieve a significant improvement in the reliability of our automated test suites. The project team is now using it back again. A shared understanding was also beneficial, increasing the collaboration and value of our tests.

In a retrospective, we identify failing at including testability by design.

Shift-left Testability by design, before more AI

Non-functional requirements are structuring in software engineering. They are usually the world of architects, not being a reflex of the core team. A QA team with the practice of Question Asker can be valuable here, to include testability as a requirement.

The particular subject of locators strategy is one of the hell’s in detail for test automation. A “No strategy” approach leads to ineffective, throwable, and accelerated technical debt. We need to define a locator strategy.

A stable locator strategy is an excellent way to include testability by design, providing more reliability and shared understanding. Alternatives techniques of image recognition can be helpful if making sense for our test techniques. 

Our locator strategy will be gradually improved with self-healing capabilities.

Antoine Craske, Cerberus Testing.

Data science, AI, and more intelligence in test automation are key trends for software quality. Our locator strategy is going to improve with such techniques, providing features like self-healing. One priority for us at Cerberus Testing to improve your test automation journey with these capabilities.

Follow Cerberus Testing to stay updated on these evolutions.