Self-Healing should not make a real bug disappear.
The value of healing is not turning every red test green. It is separating technical locator drift, uncertain matches and real product failures clearly.
Four principles for trustworthy self-healing.
Automation only remains useful when healing is transparent, bounded and reviewable.
Separate locator problems from product failures
Healing addresses technical element mapping — not business assertions or real application defects.
Keep uncertainty visible
If no reliable candidate exists, a red test is better than a false green test.
Make healing traceable
Original locator, replacement and context should remain visible to the team and reviewers.
Control durable fixes
Automatic Code Update should fit normal Git and review processes instead of hiding changes.
What healing should solve — and what it should not.
A clear boundary helps teams use TestZombie as maintenance automation rather than failure suppression.
- ID, CSS, XPath, role or accessibility identifier changed
- Element moved after a UI refactor
- Technical locator is stale while the business flow is unchanged
- Assertion or expected business result is wrong
- Target element no longer exists by design
- Several candidates are too similar to identify safely
Safe Self-Healing FAQ
Should self-healing repair every test failure?
No. Self-healing is best suited to technical locator and UI drift. Business assertions and real product failures should remain visible.
What happens when several elements are plausible matches?
If the mapping is not sufficiently reliable, the test should fail or enter review rather than continue with an arbitrary element.
Why is Automatic Code Update part of the trust story?
Because successful healings do not have to stay hidden forever in a runtime layer. The fix can become visible, reviewable and maintainable test code.