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 as relabeling a button or layout adjustments, are minor. A person might not even notice these changes, but they can easily break automated tests.
mabl's auto-healing functionality helps mabl adapt to such changes so your tests keep on working through these inevitable changes.
Every time mabl runs a test and interacts with an element, it collects element attributes that it uses to find the element next time and track changes over time. mabl tracks over thirty distinct attributes, like text, CSS classes, data-test-id, and other information like location and size on the page.
Sometimes the best way to find an element is to look for related elements that have particular text or other attributes. In these cases, mabl also collects information about the element's ancestor elements to help find the specific element it will interact with.
The general process of identifying and potentially healing an element starts with looking for element candidates by matches to the tracked attributes and then choosing the best match based on which combination of attributes matches for each candidate 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 it identifies candidates for the target element within the ancestor and again chooses the best match.
If there is not a clear match based on previous runs, it also dynamically increases waiting time before choosing a match, first attempting to identify when the page has stopped changing significantly and then using additional waiting and double-checking of results when the best match is uncertain due to similar elements on the page or only matching less identifying attributes.
If there is a strong match based on the element history, then mabl will just update its information about the new version of the element. If not, but there are potential candidates that match some information about the element, then mabl will attempt an auto-heal.
We write "attempt" because the auto-heal process is incomplete until the test completes in a passing state. When an element has changed enough that mabl is not confident it has found the right one, it will attempt to run the test step using the best candidate element. If the test completes without errors, mabl will update its description of the element and record an auto-heal insight. If the test ultimately fails, mabl will note the attempted auto-heals in the run's output log, but will not record them.
Any test step that interacts with an element on the page can be auto-healed, except those using a custom (CSS/XPath) find. 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. Otherwise mabl will attempt to auto-heal the step if there is not a strong match to what mabl knows about the expected element. You can also configure finds to give mabl more information about how to find the right element, while still enabling auto-healing after a specified timeout.
A test step's element's attributes are 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 will track element attributes separately for those two environments.
This means that any changes in QA resulting in auto-heals will not affect the behavior of the same test running against production.
Updated 6 days ago