What it does
Maintains the automated test suite: detects broken locators after UI/DOM changes, classifies each failure (locator drift / product defect / flaky / intentional removal), heals drift with the most stable available locator strategy (centralized in Page Objects), prunes/refactors obsolete tests, updates approved baselines, and re-runs to confirm. Never loosens an assertion to force green; product defects go to /qa:triage.
When to use it
When tests break due to UI/DOM changes, or for routine suite maintenance.
Prerequisites
qa.config.yml for tooling.e2e, tooling.visual, paths.tests_dir/reports_dir, stack.base_url_web, risk_areas; a test path/failing area or recent UI-change signals.
Output
Updated 29119-3 Test Procedure Specifications / scripts in place under tests_dir, a maintenance change log, and a Test Execution Log under reports_dir.
Mechanics
How it works
- Read config and suite signals; resolve scope (failing/UI-impacted tests, or asked target)
- Run in-scope tests to surface locator failures
- Classify each failure (locator drift / product defect / flaky / intentional removal)
- Heal drift via the highest stable locator tier; confirm a single-element match in the Page Object
- Maintain: prune/refactor obsolete tests, update approved baselines, review quarantine
- Re-run healed/affected tests locally; report counts; escalate defects to triage, flake to flaky-hunt
Why it works
The theory behind it
Test-automation maintenance (CT-TAE); maintainability is an ISO 25010 property of the testware. Counters the pesticide paradox without weakening assertions.
CT-TAE (Specialist) · CTFL v4.0 §1.3 Principle 5 · ISO/IEC 25010 maintainability
Example
See it in use
> /qa:self-heal "tests/pages/CheckoutPage.ts"✓ Correct when It heals how we locate (stable locator tiers in the Page Object), not what we verify, and escalates real product defects instead of silencing them.
Used by