It is the end of the day, and the testing team is packing up and heading home. As the last person out traditionally shuts off the lights, there is one additional task to complete. On the way, out one of the team members needs to trigger the nightly test run as part of their regression testing for mobile devices. The next morning, however, to the shock and dismay of the team, they discover that many of their tests have failed due to a locator change within the application.

These types of changes happen often and go unnoticed for a variety of reasons. A quick example would be that the Development team made a change that was so small that it was seen as insignificant and, therefore, not communicated to the QA Team.

The time and effort needed to review failed scripts, update locators, and rerun tests can quickly derail a sprint, increasing the risk of shipping defects into production.

In a world where AI is increasingly central to the SDLC, developers now receive assistance with contextual suggestions, code optimization, and even unit test generation. While this accelerates development, it can create downstream challenges for QA teams as they struggle to keep up with the increase in code created.

Minor UI changes like the one above often impact automated end-to-end tests. However, with the integration of AI Self-Healing, scripts can adapt on the fly, repairing broken locators mid-execution without disrupting the testing flow. This capability will help QA teams keep pace with rapid development cycles, significantly reduce test maintenance time, and provide faster feedback—all while increasing test resilience.

This blog will explore how AI-powered Self-Healing autonomously addresses element mismatches at runtime without human intervention.

Prerequisites: This feature is only available to Pro & Premium SaaS customers

To help you better understand AI Self-Healing and how it behaves on our platform, we will look at Digital.ai’s Banking Application built for Android and walk through a simple test for the Login Page where a change will be detected.

We will have two versions of the same Application, one unmodified (a build that is expected to work) and one modified (where one of the locators has been changed).

In the unmodified version of the Application, we see the ID “usernameTextField” identify the username locator:

This locator will be referenced in the automation script as shown below. The following lines validate and interact with the username field after the automated Appium tests are triggered:

```

wait.until(ExpectedConditions.elementToBeClickable(By.id("com.experitest.ExperiBank:id/usernameTextField")));

driver.findElement(By.id("com.experitest.ExperiBank:id/usernameTextField")).sendKeys("tester01");

```

Under normal circumstances, where locators are not modified, the script would pass without issues.

However, let’s consider a scenario where the locator for the username field has changed. Instead of “UsernameTextField,” it is now identified as “UserTextField” in this modified build:

In this case, the script would fail immediately with a ”NoSuchElementException”.

How Can We Address This Issue?

It is as simple as adding one line to your Test Setup within the Desired Capabilities. Let’s look at a simple Test Script Setup to install and launch an Application on Digital.ai’s Continuous Testing platform:

```
DesiredCapabilities caps = new DesiredCapabilities();

caps.setCapability("testName", "login_scenario_test”);
caps.setCapability("accessKey", ACCESS_KEY);
caps.setCapability("deviceQuery", "@os='android'"); //
https://docs.digital.ai/bundle/TE/page/device_queries.html
caps.setCapability("app", "cloud: com.experitest.ExperiBank/.LoginActivity");
caps.setCapability("appPackage", "com.experitest.ExperiBank");
caps.setCapability("appActivity", ".LoginActivity");

desiredCapabilities.set(caps);
driver.set(new AndroidDriver(new URL("https://<your_cloud_url>/wd/hub"), caps));

```

Now, just adding the following line within your capabilities will tell the script it should run in a Self-Healing mode:

``` 
caps.setCapability("selfHealing", true);

```

You can now run the automated scripts as usual. No additional changes are required, whether from your IDE (such as Eclipse / IntelliJ) or a CICD pipeline (E.g., Azure DevOps).

Does Enabling AI Self-Healing Impact Regular Test Execution Time?

Enabling Self-Healing can potentially increase test execution time, as the Self-Healing module continuously scans pages for changes during the test run. To provide flexibility, we’ve included the option to pause and resume Self-Healing within your script. For instance, if the login page is stable and unlikely to cause failures, disabling Self-Healing for this section could help reduce test execution time. With a one-liner added to the test script, you can pause the Self-Healing mode:

```

driver.executeScript("seetest:client.stopHealing");

```

And when you want to resume, simply invoke another one-liner:

```

driver.executeScript("seetest:client.startHealing");

```

Is Self-Healing Customizable?

AI-powered Self-Healing is configurable to suit the needs of the applications being tested, particularly when dealing with varying levels of complexity.

  1. Recovery Tries: Defines the total number of attempts the algorithm will make to discover a matching locator.
    By default, Self-Healing tries to identify locator changes once per element. For example, if the algorithm fails to find a replacement locator for the username field, it will only attempt it once before moving on.
  2. Score-Cap: Sets a matching score threshold based on the probability of a successful match. The default score is set to 0.6 on a scale of 0.1 to 1.0.
    A score of 0.6 indicates that Self-Healing will be triggered for newly identified locators only when the probability of a match is greater than 60%.

The Digital.ai Support Team can modify both of these properties upon request.

Does AI Self-Healing Work on All Types of Mobile Applications?

Currently, AI Self-Healing is supported for mobile native and web tests on Android, as well as web tests on iOS. Support for mobile native applications on iOS is not yet available—but stay tuned for future updates.

What Happens if Multiple Locator Changes Occur During a Single Test Script Execution?

Whether it’s a single locator change or multiple changes, when AI Self-Healing is enabled, the Self-Healing mechanism will activate and automatically update all affected locators during a single test execution—without any manual intervention.

My Tests Healed: Do I Continue Running My Tests as Is, or Do I Need to Modify My Scripts?

You can continue to run your automated tests, and they will work as expected. The Digital.ai platform will continue to detect the changes and ensure the scripts run as expected. However, this does not fully resolve the issue. While the test heals during runtime, it doesn’t modify the actual script, regardless of whether you trigger it from an IDE like IntelliJ or a CI/CD pipeline such as Azure DevOps. You will need to modify the original automation scripts and make the necessary changes.

Why Heal if I Need to Make the Changes Anyway?

The benefit of using Self-Healing is that locator changes do not disrupt the test execution. After the run, you can review the reports at your convenience to identify which locators were healed and then update your script accordingly. Differentiating between genuine test failures and automation issues helps improve focus on higher-priority tasks that could have a much larger impact on the end users. As a result, you can release new updates without the constant worry of flaky tests derailing the progress.

How Do I Know If Something Healed?

That’s simple! Let’s look at an example. You can navigate to your Reporter Page from your browser (Works best on Chrome):

``` 
https://<your_cloud_url>/reporter/reporter/tests 
```

Alternatively, on the main platform, click on your initials in the upper right corner and select “Go to Reporter”:

 

And go to the “Tests” tab: 

 

This view will display all the executed tests for your project, including the percentage of tests that were healed:

 

Clicking on the Healed status in the pie chart will filter the results to display only the tests that were healed:

 

You can also click on each report to view detailed information about what was healed:

Final Thoughts

AI-Powered Self-Healing represents a leap forward in test automation. It makes the maintenance of Appium scripts more efficient and reduces the manual efforts required to keep up with rapid development cycles. While Self-Healing may not replace the need to update scripts altogether, it offers a seamless experience by preventing test interruptions and providing valuable insights for script maintenance. This makes it a powerful tool and enhances test reliability. If you’re ready to explore how AI Self-Healing can transform your test automation strategy and learn more about our AI innovations, reach out to us!
favicon cropped white

Author

Rahee Khan

See Digital.ai Continuous Testing in Action

Explore

What's New In The World of Digital.ai

October 24, 2024

Cross-Browser Testing for Mobile Devices

Enhance your mobile app’s performance with our guide to cross-browser testing. Understand the challenges, tools, and best practices for proper UX.

Learn More
October 22, 2024

Make Appium Script Maintenance Effortless with AI-Powered Self-Healing

AI-powered Self-Healing enhances mobile testing by autonomously fixing locator changes during execution, ensuring seamless test automation & reliability.

Learn More
October 22, 2024

Testing and Evaluating Accessibility for Websites

Learn the essentials of web accessibility testing, including legal standards, benefits, and practical tools to enhance user experience for individuals.

Learn More