What it does
Investigates a failing test or reported bug, classifies its root location (test/env/product), assigns severity and priority independently, flags release blockers, and writes a 29119-3 Incident (Defect) Report with a unique ID. Read-only on product code.
When to use it
When a test fails for a real reason, or a bug is reported and needs to be filed properly.
Prerequisites
qa.config.yml (paths.reports_dir, gates.block_on_severity, risk_areas); the failure, trace, or bug description.
Output
ISO/IEC/IEEE 29119-3 Incident (Defect) Report -> reports/defects/DEF-<item>-<nnn>.md.
Mechanics
How it works
- Investigate the failure and classify root location (test/env/product)
- Assign severity from impact thresholds (S1-S4)
- Assign priority independently from the affected risk tier and timing
- Flag a release blocker if severity is in gates.block_on_severity
- Assign a unique defect ID and write the Incident Report
- Recommend the follow-up (regression test, add-test, flaky-hunt)
Why it works
The theory behind it
Defect management following the incident lifecycle; the non-negotiable separation of severity (technical impact) from priority (business urgency) is the heart of the technique.
CTFL v4.0 §5.5
Example
See it in use
> /qa:triage "checkout returns HTTP 500 when applying an expired coupon"✓ Correct when Separates severity from priority and gives clear repro/expected/actual.
Related commands
Used by