AI-Based Self-Healing for Test Automation

Automated tests, however well-written, can fail sometimes for reasons other than bugs. Some reasons are not related to the test case itself, such as issues with the test environment, however most are related to the changes of the product.

This is where self-healing comes in.

It is very important to understand that there are two distinct types of self-healing for tests:

1. Locator healing
2. Adapting to specification changes

Locator healing

This is where you would use locators like XPaths or CSS Selectors to locate elements in frameworks like Selenium or Appium. The problem with those locators is that they describe how to find an element in the internal HTML/XML structure of the screen as opposed to how an actual user would find it. This basically means that you are relying on details of implementation, how engineers wrote the code yesterday to describe how the test should work.

Therefore, the best way to deal with those locators is avoid using them altogether. This is how tools like testRigor work. There are no locators, you are describing how to deal with elements from the end-user’s perspective.

package tests;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.Test;

public class TestSample {
  @Test
  public void login() {
    System.setProperty("webdriver.chrome.driver", "path of driver");
    WebDriver driver = new ChromeDriver();
    driver.manage().window().maximize();
    driver.get("https://www.browserstack.com/users/sign_in");
    WebElement username = driver.findElement(By.id("user_email_Login"));
    WebElement password = driver.findElement(By.id("user_password"));
    WebElement login = driver.findElement(By.name("commit"));
    username.sendKeys("[email protected]");
    password.sendKeys("your_password");
    login.click();

    WebElement welcomeXpath = driver.findElement(
        By.xpath("//*@id='wbwodx-content']/div[2]/header[2]/div/nav/ul/li[5]/a/span"));
    String welcomeXpathText = welcomeXpath.getText();
    Assert.assertEquals(welcomeXpathText, "Welcome Peter");
  }
}

login
check that page contains "Welcome Peter"

This way, it doesn’t matter how the implementation changes over time. If you can still login with the same credentials it will continue to work requiring no overhead on the test maintenance.

testRigor allows you to convert your Selenium tests to plain English for test execution to avoid test maintenance overhead. Or, you could use an open-source Selenium Java library to enable locator auto-healing based on testRigor as described here.

It works as follows:

You can wrap your driver reference into testRigor wrapper. On the first successful run, testRigor will internally record the end-user’s way of explaining your locator, and when the locator no longer works, it will use that explanation to find the element on the screen and fix your locator.

Adapting to specification changes

Another type of test failure can be related to changes in the specification. For example, a button was renamed from “Contacts” to “Prospects”. You might argue that this is a hard specification change, and, therefore, the test should break since the test represents the specification in code, which would be formally correct. However, in an application that is being rapidly developed those changes might be frequent.

To deal with those changes more easily, testRigor has several features:

1. Synonyms support
2. AI-based self-healing

Synonyms Support

testRigor will allow you to automatically adapt to synonyms in several ways:

1. You can write commands that support multiple variants out of the box like: click “Contacts” or “Prospects”. In this case, testRigor will try to first find “Contacts” on the screen and if not successful will attempt to find “Prospects”.
2. You can enable the “Search for synonyms if element not found” setting (enabled by default) in the Settings/Advanced section. Here testRigor will work similarly to the above with the exception that it will list all possible synonyms known to it.

Both of these ways will work very fast without requiring the use of AI.

AI-based self-healing

AI-based features in the Settings/Test Generation section:

If you enable Vision AI and enable Auto-Healing for rules and single commands, testRigor will be able to look on the screen for the alternative way of doing what was intended as opposed to failing. This will allow you to very quickly adapt to breaking changes in your application.

Of course, some of the ways AI adapts will not be what you want, so testRigor will allow you to see which test cases were self-healed using the “fixed-by-ai” label and the steps that were self-healed will have a warning on them describing what exactly was changed.

Also, you can always see the differences in the UI and rollback to the previous version if necessary.