Three types of self-healing: selector, timing and intent-based

"Self-healing" sounds like one feature. It's really three: selector healing, timing healing and intent-based resolution, with a big difference in what they actually solve.

In practice, the term hides three fundamentally different techniques, and vendors are rarely clear about which of the three their product actually offers.

Selector healing: the best-known form

An element ID changes from submit-btn to checkout-submit. The system recognises the element via alternative attributes (text content, position, surrounding structure) and automatically updates the locator. This is what most tools mean when they claim "self-healing", and it's also the simplest form.

Timing healing: the underrated majority

A test expects a confirmation banner after a click, but the API response takes 900 ms instead of 300 ms. That's often wrongly attributed to "a broken selector", when in reality the problem is timing. A good system tries to understand the cause of the timing failure and adjusts synchronisation, waits or retries based on runtime information.

Intent-based resolution: the heaviest category

With a full redesign, it's not one element that changes, but the entire structure of a page. Intent-based healing tries to understand what a test step is trying to achieve, for example "log in with this user", and searches semantically for the right element, even if the underlying structure is completely different. This is the technically most advanced form, and also the one where quality between tools varies most.

Self-healing is no substitute for good test automation. A test with clear intent, stable locators and correct synchronisation remains the best protection against maintenance costs. AI mainly works as a safety net for changes you can't predict in advance.

How to evaluate a tool fairly

• Run a proof of concept on 20 to 30 of your own tests, not on the vendor's demo application.
• Deliberately break them (rename classes, shift elements, slow down an API call) and measure what percentage repairs automatically.
• Look at what a repaired change produces. Can your team review it, or does the change disappear invisibly into a black box?
• Never compare benchmarks directly between vendors. They're measured on different applications, under different conditions.

The best approach is often a combination: stable, meaningful locators (ARIA roles, data-testid) as the first line of defence, with AI-driven fallback for whatever still changes.

An example from practice

While evaluating a self-healing tool for a client, we deliberately broke thirty tests in three ways: renaming a class, moving an element to a different spot in the DOM, and artificially delaying an API call by 800ms.

The vendor claimed "95% self-healing" based on their own demo application. On our own suite, with our own mix of breaking points, the tool fell well short of that marketing claim for timing-related issues. That 4 out of 30 was exactly the information that settled the decision: the tool was adopted for selector healing, backed by the team's own explicit-wait logic for timing.

How we set up this kind of test in practice

• Always use your own suite as the test environment, never the vendor's demo application.
• Break things in proportion to what actually happens in production. If your team rarely restructures the DOM but renames classes often, weight that scenario more heavily.
• Measure separately per healing type. A single overall score hides exactly the difference that should drive the purchasing decision.