Self-healing and the heal-review queue

Why a queue and not silent repair

A test that silently re-targets itself to the wrong element passes while the product is broken. That is worse than a failing test, because it looks like a pass. So every heal is a proposal with a diff: the locator that failed, the locator that matched, a screenshot of the matched element, and the strategy that found it. Approving takes seconds; the alternative is trusting a machine with your release gate.

How a proposal is built

• The recorder stored many locators per element at record time: test IDs, ARIA roles and names, text, CSS, XPath variants, relative position to stable neighbours, and more.
• On failure, strategies are tried in order of stability, and the candidates are scored against the original element's captured attributes and screenshot.
• The top candidate becomes the proposal. Candidates below a confidence floor are not proposed at all; the step fails and says so.

Reviewing

1. Open Heal Review. Each item shows the test, the step, the failed locator and the proposal side by side with screenshots.
2. Approve to update the element repository. Every recording that references that element picks up the fix; you do not edit tests one by one.
3. Reject if the match is wrong. The step stays failed, and the rejected strategy is down-weighted for that element.

Limits

• A heal cannot repair a step whose element no longer exists at all. That is a product change, and the queue says so instead of guessing.
• Confidence scores are heuristics over captured attributes. They are shown so you can judge them; they are not a promise.
• We do not publish a "maintenance reduced by X%" figure because we have not measured it across customers yet. When we have, it will appear here with the method.