Self-healing tests
Self-healing test automation
A renamed button should not cost a morning. Klarent re-resolves the element, repairs the step mid-run, and shows you exactly what changed so you can accept or reject it.
The maintenance tax
Where automation effort really goes
Repairing, not writing
Most automation effort goes into test maintenance, repairing broken locators instead of writing new coverage.
One refactor, many failures
A single UI change or refactor can break a large share of the suite at once, before a single real bug is found.
A queue for the author
Repairs need the engineer who wrote the test, so broken tests wait in a queue behind everything else.
Deleted, not fixed
Tests that break too often get deleted rather than repaired, and coverage falls release by release.
Flaky tests lose trust
When red runs are usually broken locators, teams stop believing them, and real failures get ignored too.
Slower releases
Every release waits on test suite upkeep before anyone can trust the regression suite again.
How it works
How self-healing works in Klarent
Step 1 - Detect
The expected element is no longer where it was, or no longer what it was.
Step 2 - Re-resolve
The agent identifies the element by intent and context, not by a stored selector.
Step 3 - Repair and report
The step is repaired, and the change is shown step by step for your review.
Platform capabilities
Self-healing automation you can see into
Intent-based element identification
Element identification by what the element is for, not by a stored XPath or CSS selector.
Mid-run repair
Broken steps are repaired mid-run, so a single UI change does not take the whole suite down.
Before and after on every heal
See exactly what changed in each healed step, side by side, before anything is applied.
Accept or reject
Every heal is yours to accept or reject, so the team stays in control of the suite.
One heal, every browser
A test is defined once, so one repair fixes it for every browser and viewport it runs on.
What self-healing handles, and what it does not
A UI change is not a bug
Self-healing repairs how a step finds its element. It never changes what the step is meant to achieve. If the intended outcome is still reachable, the step is healed. If it is not, the test fails and reports it.
| Change | What happens | Why |
|---|---|---|
| Renamed element | Healed | Same element and purpose, new label or ID |
| Moved element | Healed | Same element, found in its new position |
| Restyled component | Healed | Appearance changed, behaviour did not |
| DOM restructuring | Healed | Broken locators re-resolved against the new structure |
| Genuine functional regression | Fails and reports | The expected outcome no longer happens, which is a real bug |
| Removed feature | Fails and reports | There is nothing left to heal towards |
| Changed business logic | Fails and reports | The test needs updating to the new behaviour, by a person |
Why review matters
Transparency is the safeguard
A silent heal can hide a bug
A tool that quietly rewrites tests until they pass can turn a real failure into a false green.
Approval on every heal
Healed steps are shown for review, and nothing is applied until someone accepts it.
Audit trail
Healing events are recorded in the activities feed, alongside role-based access and audit logs.
Point Klarent at a suite that keeps breaking.
Bring the flows that break after every release, and see Klarent build them, heal them through UI changes, and show you every change it made.
FAQs
Self-healing test automation repairs tests when the application changes underneath them. When an element is renamed, moved or restyled, the test re-resolves it and keeps working, instead of failing on a broken locator and waiting for someone to fix it by hand.
Klarent identifies elements by intent and context, what the element is for and where it sits in the flow, rather than by a stored selector. When the stored path no longer works, the agent finds the element that serves the same purpose in the current version of the page.
A silent heal could, which is why Klarent never heals silently. Self-healing only changes how a step finds its element, never what the step is meant to achieve, and every healed step is shown with a before and after view so the team can accept or reject it.
Every heal is shown for review before it is applied, and your team decides whether to accept it. Reviewing the diff takes seconds, because it shows exactly which step changed and how.
Genuine functional regressions, removed features and changed business logic. In each case the intended outcome is no longer reachable, so the test fails and reports it. That is the point: those are the changes a person needs to look at.
It depends on how often your UI changes and how large the suite is. The time saved is the time your team spends repairing broken locators today. The ROI calculator estimates it for your own suite.
Yes. Because elements are identified by intent rather than generated IDs or fixed positions, content that changes between sessions, users or page loads does not break the test the way it breaks selector-based scripts.
Smart locators store several fallback attributes per element and try them in turn, which still breaks when all of them change. Klarent re-resolves the element from the live page by its purpose in the flow, and shows you exactly what it changed instead of switching attributes silently.