What it does
Targets the suite's reliability: statically scans for flakiness anti-patterns, confirms non-determinism by measuring a flake rate over N runs, quarantines flaky tests against an SLA, fixes the root cause (web-first waits, stable locators, isolated data, mocked time/network), and verifies at 0% flake over N. Product-defect intermittency goes to /qa:triage; deep cases route on. Never masks with retries.
When to use it
When tests intermittently fail or the user mentions flakiness.
Prerequisites
qa.config.yml for tooling.e2e/unit, tooling.language, paths.tests_dir/reports_dir, gates/process.* SLA, risk_areas; a test path or run count N.
Output
Flaky-Hunt report (test-maintenance work product feeding the 29119-3 Test Execution Log) -> reports_dir/FLAKY-HUNT-<date>.md, with quarantine changes reflected in the affected Test Procedures.
Mechanics
How it works
- Read config; resolve scope (default risk_areas.critical suites when empty)
- Static scan for flakiness anti-patterns (hard sleeps, brittle selectors, order/shared state, unmocked time/network)
- Confirm non-determinism: measure flake rate over N runs; classify deterministic/flaky/consistently-failing
- Triage each flaky test as test/env vs product defect
- Quarantine, fix the root cause, and verify at 0% flake over N
- Apply the quarantine SLA (thresholds, owner, fix SLA) and write the report
Why it works
The theory behind it
Test-automation maintenance & reliability (CT-TAE) targeting the suite's ISO 25010 reliability, countering the pesticide paradox (Principle 5). A false alarm destroys the signal that a failure means a defect.
CT-TAE (Specialist) · CTFL v4.0 §6 · ISO/IEC 25010 reliability · Principle 5
Example
See it in use
> /qa:flaky-hunt "tests/e2e/checkout.spec.ts"✓ Correct when It stabilizes the root cause (waits/data/order) rather than adding blind retries.
Related commands
Used by