What it does
Decides what to regression-test for a change: runs impact analysis to map affected areas to risk tiers, picks a regression strategy by rule (retest-all / risk-based selective / prioritized), builds an include/defer/retire selection matrix, and recommends CI placement (PR smoke vs nightly) with counts. Scopes regression only — confirmation re-testing of the fix is separate. Reads source files only.
When to use it
When deciding what to regression-test for a change, or to keep the regression suite lean.
Prerequisites
qa.config.yml for paths.docs_dir, risk_areas, gates, tooling.* toggles; git history or a named change/area/release.
Output
Regression Test Selection report (tailored ISO/IEC/IEEE 29119-3 Test Design Specification fragment) -> docs_dir/REGRESSION-SELECTION-<scope>.md.
Mechanics
How it works
- Read config and recent change signals; resolve the change scope
- Run impact analysis; map each affected area to a risk_areas tier in a table
- Select a regression strategy by explicit rule (retest-all / selective / prioritized)
- Build the selection matrix: include / defer / retire per candidate test
- Recommend CI placement (PR smoke vs nightly) with counts
- State residual risk for what the selected set does not cover
Why it works
The theory behind it
Change-related regression testing (CTFL v4.0 §2.2.2) — re-running passing tests to detect new breakage, explicitly distinct from confirmation testing. Risk-based selection (CTAL-TM) keeps it affordable (Principle 2).
CTFL v4.0 §2.2.2 (regression testing) · CTAL-TM (risk-based selection) · Principle 2
Example
See it in use
> /qa:regression "saved-cards change"✓ Correct when It uses impact analysis to include affected areas and trims unrelated tests (pesticide paradox).