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.
There are two types of steps that interact with elements on the page and do not use auto-heal:
- 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.
- Configure Find steps marked "Disable auto-heal"
The general process of identifying and potentially healing an element starts with:
- Looking for element candidates
- Finding a strong match
- 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.
- 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:
- Standard auto-heal: Mabl looks for the best available match to the element model. This process includes comparing partial matches to the model across the available elements on the page.
- Advanced auto-heal: If standard auto-healing strategies do not find a good match, mabl attempts advanced auto-healing. Advanced auto-heal uses generative AI to identify semantic similarities with new text and meaningful attribute values to find a good match. If the best match is low confidence, the test step fails instead of auto-healing to an element that is a poor match.
If the step auto-heals, one of the following outcomes occurs:
- If the test ultimately passes and is part of a plan run, then mabl updates its description in the element history and records and auto-heal insight.
- If the test ultimately fails or is part of an ad-hoc run, then mabl notes the attempted auto-heal in the output logs but does not update the element history or record an insight.
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.
Local runs and auto-heal
For local runs, mabl uses models from the most recent cloud runs to find the correct element. If a strong match isn't found during a local run, mabl uses standard auto-healing strategies. Any attempted auto-heals in local runs are not saved as auto-heal insights and do not impact the element history, even if the test run passes.
Advanced auto-heal is a cloud-only feature.
Ad hoc cloud runs and auto-heal
Ad-hoc cloud 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.