Turn your manual testers into automation experts Request a DemoStart testRigor Free

AI-Based Self-Healing for Test Automation

Automated tests, however well-written, can fail sometimes for reasons other than the bugs. Some reasons are not related to the test case itself, like 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 to do it for a user. 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.

For example, instead of relying on locators like so:
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");
  }
}
You can write a simple statement like:
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 open-source Selenium Java library to enable locators auto-healing based on testRigor as described here.

It works as follows: you can wrap your driver reference into testRigor wrapper. testRigor on the first successful run will internally record the end-user’s way of explaining your locator, and when the locator will no longer work – 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 the changes in the specification. Like, for example, the button renamed from “Contacts” to “Prospects”. You might argue that this is a hard specification change, and, therefore, the test must 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 similar 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 use of AI.

AI-based self-healing

AI-based features in Setting/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 to do as opposed to failing. This will allow you to very quickly adapt to breaking changes in your application.

Of course, some of the way 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 a diff in the UI and rollback to the previous version if necessary.

Request a Demo
Ready to move your software testing into the next stage of scale and efficiency? After submitting this form, our team will reach out to you to schedule a demo where they can also answer your technical questions.

Loading…

The connection to the server timed out!

Thank you for your request. Please select date and time for a demo.

“We spent so much time on maintenance when using Selenium, and we spend nearly 0 time with maintenance using testRigor”
Keith Powe
VP Of Engineering -
“The manual team does not need to be sidelined and I don't need to hire separate experts for automating scenarios.”
Sagar Bhute
Director of QA -