What should a self-healing browser test prove?

A layout change can break a target while leaving the user journey intact. Finding that target again, which is what self-healing means, saves maintenance work. The risk is accepting a different control, or a weaker outcome, just to keep the test passing.

So the useful question isn't whether a tool heals. It's what happens in cases like these:

What changed	What you'd want
"Save" moved from the footer into a menu	Find it, carry on, and show that it moved
"Save" was renamed "Save and publish"	Stop. It may do something different, and a person should decide
Two "Save" buttons now appear on the page	Don't guess. Fail and ask for a more specific step
"Save" is disabled	Fail. Don't click something else with a similar name
"Save" works, but the confirmation no longer appears	Fail. The target was fine and the outcome wasn't

Try those on any tool you're evaluating, and test a harmless layout change separately from a real product regression. Ask to see the original target, the replacement and the reason.

How Zerocheck handles them

Zerocheck checks whether a remembered target is still the same control, using things like its role, name and surrounding context. A moved control can be found again from the step's description, and a renamed control isn't treated as the same target. The run shows the old and new target in its healing history.

The heal is kept only when the whole test passes and the run shows that the intended action and outcome really happened. Otherwise it stays pending, and a failed test rejects it. There's no second full run to confirm the repair. The results documentation has the details.

Your team still owns what the test is checking. Healing can't make an irrelevant assertion useful.