What it does
Identifies product (quality) and project risks, scores each likelihood × impact for a 1–25 risk level, assigns a Low/Medium/High/Critical tier from fixed bands, and derives test depth and technique per tier. It assigns owners (required at risk level ≥13) and outputs a sorted register with tier summary.
When to use it
At the start of a release, or whenever you need to prioritize where to test deeply (Principle 4). Drives plan scope, estimate depth, and exit-criteria thinking.
Prerequisites
qa.config.yml (run /qa:qa-init first) — paths, risk_areas tiers, tooling toggles, gates, team (for owners).
Output
ISO/IEC/IEEE 29119-3 Product Risk Register -> <paths.docs_dir>/risk-register-<scope>.md.
Mechanics
How it works
- Config guard; resolve scope to args or default to risk_areas.critical
- Load the risk-register template
- Identify product (quality) and project risks, seeded from risk_areas and features in scope
- Score each likelihood(1–5) × impact(1–5) = risk level(1–25); assign a tier from the fixed bands
- Derive test response by tier (deeper/earlier/more independent for higher risk)
- Assign owners (required at level ≥13) and mitigation triggers
- Write the sorted register with a tier summary; reconcile with config risk_areas
Why it works
The theory behind it
Risk-based testing (CTFL §5.2; CTAL-TM). It operationalizes Principle 2 (exhaustive testing is impossible) and Principle 4 (defects cluster) — depth follows risk so finite effort lands where failure hurts most; the register is the 29119-3 work product that the plan, exit evaluation, and completion report's residual-risk statement consume.
CTFL v4.0 §5.2 · CTAL-TM
Example
See it in use
> /qa:risk-assessment R2.4✓ Correct when Each risk has a likelihood×impact score and payments/checkout/auth land in the top tier with a heavier test response.
Used by