Minimize Automation maintenance through the self-healing ML way

Automation has advanced a lot, compared to earlier decades. This has to liberate our people from tedious tasks and boost their efficiency. Especially in the digital transformation world, where we deal mostly with webpages, we have to take the competitive advantage of these capabilities we discuss below, and build such capabilities to our automation frameworks whereever possible, and accelerate test automation in the ways that were not possible earlier.

Target Audience: Webui Automation Developers, Automation Architects, Test Managers, other Automation enthusiasts.

The moment we see the title, most of Automation engineers might have related to the problem statement, in terms of what the Webui Automation Developers would face on day-to-day challenges in terms of script maintenance, locator issues, flakiness in the scripts causing huge turn-around time in maintenance of the same, where that time ideally might have been spent on some beneficial/innovative work.

Before we jump, a small caution: This work is more fun and more dangerous.

Manual Maintenance of locators: For small projects like say, 100–150 tests, these are little manageable. But when we go large scale and have common framework across the projects, the maintenance is next to impossible or the efficiency of automation will degrade due to these flaky tests/huge maintenance manual efforts. Changes in application UI (till at least one PSI) can’t be avoided. So we have to figure out a way to reduce these efforts of maintenance when UI failures are seen on locator issues.

Test Automation is felt more costlier than more beneficial when manual maintenance takes time away from testing. Here this self-healing approach will provide us the relief in automatically identifying the fixes for object changes.

Here we discuss about two approaches (one without ML, one with ML).

Design:

First Approach:

Prerequisites: Firstly, when we write the locators for the first time and we run out tests, ideally all locators would work. That is the pre-requisite here. Once we design all the locators (say xpath/csspaths),

• Capturing the Web Element attributes

The model has to go and extract all the attributes of web element, parent, sibling counts, child counts, if any. Basically, we are trying to get all the possible details of the web element. (Try to relate web element with a human being, like we are capturing the details of person, face, thumb prints, color, parent details, family details, etc. to uniquely identify the person). Post this, register these details in the framework external files for all the web elements we come across. Say, id, text, name, class, class-index, etc.

• Building the locator at runtime

Now say, for the next build of the application while we run the automation, and any locator details are changed or added/updated attributes, the scripts mostly fails to identify the web element on the page. Now our self-healing model has to be triggered which will try to build the xpath with the remaining attributes of the webelement that we have already recorded. Say level1: with single attribute and followed by level2: with combination of the attributes parent+sibling count+element attributes to identify the element. Once we capture the webelement, we need to backup our ObjectRepository and update the xpath/csspath accordingly, so that it is self-healed.

• Validating & updating the records: Post validating these at runtime, we have updated our object repository accordingly.

Second Approach:

At times, say we create a locator (runtime/manual), and we get multiple webelements with given xpath/csspath, that time, to identify the webelement uniquely, we can build the scoring algorithm using Machine Learning concepts. Also this algo, on the basis of the score, will help us to decide which is the nearing match of the expected webelement. All this process is at runtime and automated, such that we can avoid the manual errors and manual maintenance. Snippet of the outcome below:

Coming to how we achieved this on ML, we took element attributes first copy given in Approach 1 (say, a json in my case) and the second copy at runtime (extracting the element attributes again) and compare similarities match, in both the copies of json files and come up with the score, whichever has more score is my web element. Which means, we are comparing apple to apple match % for each and every web element attributes, its parent, sibling counts, child counts, etc.

Sample json file below:

Conclusion:

We need to train the ML model built as per our application, locators, attributes that the application uses and ensure we are building it right. Hence I mentioned it as dangerous if we pick/implement something wrong, it changes the existing copies of locators which is the heart of any UI Automation. Unless we make the model matured and maintain consistency, we can’t replace this 100%.