Self-healing tests: can AI repair a failed test by itself?
Self-healing testing describes a feature that looks for a replacement element or suggests a new selector after the interface changes. It can reduce the time spent on routine maintenance. If it approves the change without review, however, it can redirect the test to the wrong behaviour and create a false sense of confidence.
What is the problem?
Test maintenance is a real cost. A suite that nobody repairs after application changes may gradually lose its value. Self-healing primarily addresses cases in which an element’s name or location changes while the expected behaviour remains the same.
The tool may not be able to determine the reason for the change reliably from the similarity of elements. A button may have been legitimately renamed, but it may also have disappeared because of a defect. Automatically accepting a replacement in the latter case may hide the very problem the test was supposed to highlight.
When it can help and when it is risky
It works best for a small, understandable change where the element’s purpose has remained the same. A change to the user journey, business rule or result needs human assessment.
If an element’s identifier changes, a suggested replacement can save the time needed to find it. Self-healing may not distinguish an approved change from a form defect, however, so it is important to see both the difference and the reason for the change.
Risky situations include the following:
- The Submit button disappears because of a defect. Self-healing finds another button on the page with similar text—Cancel, for example—and redirects the test to it. The test “passes”, but the order is never submitted.
- A field is renamed because the form logic has changed. The tool finds another field with a similar name, the test enters data into it and finishes green—even though it checked something entirely different.
- The result check is attached to an element that happens to exist on the page but means something else. The test is green and protects nothing.
Each of these cases can create false confidence: the test passes even though it has not checked its original objective. It is therefore important to distinguish an automatically suggested repair from an automatically approved repair.
How we address it
We use AI for maintenance, but not as a black box that silently rewrites tests for you.
When the interface changes and a test fails, AI can suggest a repair together with the difference between the original and the new element. A tester then decides whether this is an approved application change or a defect the test correctly detected. The change is accepted only after the expected result has been checked.
At the same time, we reduce the need for repairs by using stable selectors and, depending on the size of the project, a suitable layer of page or component objects. A change to one element can then be made in a shared location instead of in many tests.
What you gain
- A faster repair proposal without having to find every selector from the beginning.
- An audit trail and deliberate approval of changes to tests.
- A lower risk that an automatic repair will hide an application defect.
Next step
For each self-healing change, start by recording the original selector, the proposed change and the result of the review. If you would like to assess where self-healing is safe in your suite, use a no-obligation consultation.