Your Locator Healed, but Is Your Test Still Testing the Right Thing?

Miscellaneous
1

Self-healing automation can help a test recover when a locator changes. But recovering a click is not the same as preserving the purpose of the test.

A recent Ministry of Testing discussion highlights two separate review questions: “Does this code work?” and “Does this test still verify the intended user outcome?”

Try a small audit of your next healed test:
• Write down the user outcome it is meant to protect.
• Inspect the original target and its replacement. Do they perform the same action in the same context?
• Check the assertion: does it verify the outcome, or only that a page or element appeared?
• In a safe test environment, deliberately break that outcome and confirm the test fails.
• Keep the before/after locator and the reviewer’s reasoning with the result.

For example, if “Save” moves into a menu, a healed click is useful, but the test should still confirm that the change persists after reopening the record, not merely that the menu closes.

Treat healing as a proposed repair to review, not automatic evidence that coverage survived.

Have you seen a healed test stay green while losing its original purpose? What check caught it?

Is agentic AI testing real?

2

yes, seen it. a “delete” button moved into a kebab menu, the healed locator landed on the “duplicate” item next to it, and the test stayed green for two sprints because the assertion only checked that the row count changed. it did change, it went up.

the check that caught it was boring: the assertion was rewritten to verify the specific record is gone, not that “something happened”. since then my rule for healed steps is that the assertion has to name the outcome (record x absent, status equals y), and a healed step gets a manual look at the before and after locator in the report before anyone approves the heal. self-healing is a repair suggestion, treating it as a pass is where it goes wrong.