What it does
Classifies the maintenance trigger, runs impact analysis on direct and indirect effects, then specifies and runs confirmation testing of the change plus regression of impacted areas.
When to use it
When testing patches, upgrades, data migrations, or decommissioning of a deployed system.
Prerequisites
qa.config.yml; paths.*; tooling.* toggles; gates (entry/exit criteria); risk_areas; recent git diff helps infer empty scope.
Output
Maintenance Test Plan (ISO/IEC/IEEE 29119-3, scoped to a maintenance release) -> paths.docs_dir/MAINTENANCE-<scope>.md.
Mechanics
How it works
- Guard config, then resolve the maintenance scope (or infer from the recent-changes diff)
- Classify the trigger: Modification, Migration, or Retirement
- Run impact analysis on direct and indirect effects, mapping each to risk_areas
- Delegate regression selection/prioritization to /qa:regression
- Specify and run confirmation testing of the change plus the selected regression set (add data/rollback tests for migration)
- Set entry/exit from gates, state residual risk, write the plan and hand to /qa:release-report
Why it works
The theory behind it
Maintenance testing + impact analysis (CTFL §2.3) driving the two change-related test types — confirmation and regression (§2.2.2). Impact analysis is what makes regression scoping evidence-based, not run-everything.
CTFL v4.0 §2.3 · §2.2.2
Example
See it in use
> /qa:maintenance-test "migrate payments to Stripe API v2"✓ Correct when It includes impact analysis plus a confirmation/regression scope for the change.
Related commands
Used by