How auto-heal works

You are probably testing software that changes on a regular basis. Some changes are major and require old tests to be rewritten. But many changes, such as relabeling a button or layout adjustments, are minor. A person might not even notice these changes, but they can easily break automated tests.

Auto-heal helps mabl adapt to such changes so your browser tests keep on working through these inevitable changes.

How it works

When you record a test step that interacts with an element on the page, mabl collects attributes and uses them to find the element and track changes over time. This information forms the basis of the step's element history. When the test runs in the cloud, if there is not a strong match to what mabl knows about the expected element, mabl attempts to auto-heal the step.

📘

Steps that don't auto-heal

There are two types of steps that interact with elements on the page and do not use auto-heal:
(1) Custom find steps: When you provide a CSS selector or XPath query for finding an element, it tells mabl exactly how you want to identify the desired element, so auto-healing is not available.
(2) Configure Find steps marked "Disable auto-heal"

The general process of identifying and potentially healing an element starts with:

1. Looking for element candidates
2. Finding a strong match
3. Attempting to auto-heal if a strong match isn't found

Looking for element candidates

Mabl looks for elements that match the tracked attributes and the history of finds for that element and similar elements.

• If an ancestor is recorded for the element, this process happens first for the ancestor. Then mabl identifies candidates for the target element within the ancestor and chooses the best match.
• If the step uses Configure Find, mabl only considers elements that match the specified criteria.

Finding a strong match

Mabl uses data from past runs to determine when the element should appear on the page and be in an actionable state. Then mabl looks for a strong match to the model of the element learned from past runs:

• If there is a strong match, mabl executes the step action (completes the step) on the target element.
• If a strong match is not found after the element is expected to have appeared and been actionable, mabl attempts an auto-heal.

📘

Determining wait times in Unified runs

• If the step is newer and hasn't run a few times successfully in plan runs, mabl uses page interaction speed to determine how long to wait for an exact or strong match for an element in your application.
• After a few successful plan runs, mabl uses Intelligent Wait to determine how long to wait for an exact or strong match.

The process of finding a strong match for steps that use Configure Find works a bit differently. First, mabl looks for a strong match using the specific criteria until the chosen timeout.

• If there is a strong match, mabl executes the step action (completes the step) on the target element and makes small updates to the element if needed.
• If a strong match is not found before the chosen timeout, the next phase depends on which option was selected for the step:
  • "Auto-heal": mabl attempts to auto-heal.
  • "Disable auto-heal": mabl fails the step and indicates that it was unable to find the correct element.

Attempting an auto-heal

When an element has changed enough that mabl is not confident it has found the right one, mabl attempts to auto-heal and runs the test step using the best candidate element. The auto-heal process results in one of two outcomes:

1. If the test ultimately passes and is part of a plan run, then mabl updates its description in the element history and records an auto-heal insight.
2. If the test ultimately fails or is part of an ad-hoc run, then mabl notes the attempted auto-heal in the mabl Activity log but does not update the element history or record an insight.

📘

Auto-heal is per environment

A test step's element history is tracked and updated for each environment the test is run against.

For example, if you have a test in two plans - one that runs the test against your QA environment and one against your production environment - mabl tracks element attributes separately for those two environments.

Any changes in the QA environment that result in auto-heals do not affect the behavior of the same test running against the production environment.

Ad-hoc runs and auto-heal

Ad-hoc runs, which use the same execution environment as tests run in plans or deployment events, are intended to provide a way to validate test edits without impacting overall stats, metrics, and insights. For this reason, while ad-hoc runs use the same find strategies as tests run in a plan or deployment event, any successful adaptation in an ad-hoc run is not saved as an auto-heal in the element history.