The button is still there. Your locator just cannot find it anymore.
When the application works but the test fails because an ID, XPath, CSS, role or accessibility attribute changed, self-healing can reduce maintenance noise.
Common causes of broken locators
Refactoring, new components, dynamic IDs, changed labels or a different DOM/view hierarchy can turn valid user flows red.
Web locators
Stabilize Selenium and Playwright when IDs, CSS, XPath, roles, labels and text change.
Mobile locators
Support Appium when accessibility IDs, resource IDs and mobile UI hierarchies change.
Do not replace blindly
Candidates are evaluated from multiple signals; if confidence is too low, the failure remains.
Turn “element not found” into controlled healing
Detect the failure
The test reports that the original locator no longer returns the expected element.
Reconstruct the target
TestZombie uses existing context to evaluate potential target elements.
Document healing
A robust replacement can be used and stored for review or source-code update.
Broken locator FAQ
Is a broken locator automatically a flaky test?
Not necessarily. A locator can become deterministically broken after a UI change, while self-healing still addresses the same maintenance problem.
Which frameworks does TestZombie cover?
The public product experience presents self-healing for Selenium, Playwright and Appium.
What happens with an uncertain candidate?
If no sufficiently confident replacement exists, the test should fail rather than use the wrong element.
Your tests should survive change.
Add healing, analysis and actionable fix recommendations to existing Selenium, Playwright and Appium tests.