2.2 How to Use CertiHeal™ Self-Healing & Visual Triage Patches

How self-healing automatically recovers broken CSS/XPath selectors during execution and how to review and apply 1-click remediation patches.

When a Selector Breaks, But the Feature Doesn’t

Frontend releases change generated CSS class hashes, dynamic element ids, and DOM nesting constantly – often without changing what a user actually sees or does. A test authored against .css-a8f2x or a coordinate-shaped XPath is exactly as brittle as it looks: the next deploy can silently break that selector without breaking anything a real user would notice, and a QA team spending most of a sprint just re-pointing broken locators is a well-known failure mode of traditional Selenium and Cypress suites. CertiHeal exists for that specific class of failure – not by asking you to author more resilient selectors up front, but by recovering automatically the moment one stops resolving.

The Five-Level Recovery Cascade

When a step’s original locator doesn’t resolve, CertiHeal tries a strict, ordered cascade and stops at the first tier that finds a visible, relevant match – it doesn’t run every tier every time. The first four tiers run locally and cost nothing; the fifth is the only one that calls out to a model, and only when everything local has already missed.

Tier	Strategy	What It Looks For
1	DATA_TESTID	A dedicated automation attribute, e.g. [data-testid=“submit”] – untouched by a CSS refactor.
2	ARIA_ROLE	The semantic accessibility tree, e.g. role=button[name=“Submit”] – survives most visual redesigns.
3	TEXT_MATCH	A stable, visible text anchor, e.g. text=“Complete Order” – works even when the surrounding markup shifts.
4	DOM_PROXIMITY	Hierarchical distance from nearby stable elements, falling back to the legacy selector as a last local option.
5	AI_VISUAL_MATCHER	A vision-capable model compares a fresh screenshot and DOM snapshot against what the step originally targeted – tried last, and only if tiers 1-4 all miss.

In practice this means the steps that already have a stable data-testid never reach tier 5 at all – only the harder cases, where the local heuristics genuinely can’t tell, pay for a model call.

Triaging a Healed Run

From a Green Run to an Applied Fix

• 1. Open Run Reports after any execution and look for the “HEALED” badge on a case – it means every step passed, but at least one of them didn’t resolve the way it was originally authored.
• 2. Open the case to reach the Triage Drawer, which lists each Self-Heal Event alongside the cascade tier that produced it – a tier-1 recovery is a much smaller signal than a tier-5 one.
• 3. Review the side-by-side diff: the original locator on the left, the healed proposal on the right, so you can judge whether the healer actually found the element you meant.
• 4. Click “Apply Remediation Patch” to write the healed locator into the case definition permanently – until you do, the same step keeps healing fresh on every single run instead of the fix being remembered.

Two Reasons Not to Apply a Patch on Autopilot

• A deliberate redesign that removed or relocated the element your test was checking for is not something self-healing should paper over – if the proposal points at a different element that happens to satisfy the old assertion, fix the test’s intent instead of applying the patch.
• Self-healing accuracy is only as good as the semantics your frontend actually exposes – meaningful data-testid attributes and ARIA roles keep recovery in the cheap, local tier 1-2 range; markup with neither pushes every recovery down to the AI visual matcher.