What it does
Aggregates per-release metrics into leadership-facing trends, mapping each KPI to its ISTQB term and ISO/IEC 25010 characteristic. It gathers only from enabled tooling, marks disabled/absent sources rather than fabricating, applies RAG thresholds (overridden by gates), and gives a top-3-concerns narrative for executives.
When to use it
For management/stakeholder quality reporting across releases. Distinct from status-report (one in-flight release) and release-report (end-of-test completion).
Prerequisites
qa.config.yml — paths, tooling toggles, gates, risk_areas (degrades gracefully if missing). Reads results history, coverage, prior STATUS/RELEASE reports.
Output
Cross-release management quality report (aggregates 29119-3 Test Status / Completion Reports; not itself a 29119-3 work product) -> <paths.docs_dir>/QUALITY-REPORT-<period>.md.
Mechanics
How it works
- Config guard; resolve the period from args or default to the last 3 releases
- Confirm the KPI set with a metric -> ISTQB-term -> ISO 25010 mapping table
- Gather each enabled metric over the period; mark disabled/absent sources, never fabricate
- Trend each metric with direction vs prior period; apply RAG thresholds (overridden by gates)
- Interpret for executives: top-3 concerns tied to metric, trend, and risk_areas
- Write the scorecard, mapping table, narrative, and residual-risk note
Why it works
The theory behind it
Test measurement & reporting at management level (CTAL-TM; CTFL §5.3). It summarizes the 29119-3 per-release reports over time without replacing them; each KPI maps to an ISO/IEC 25010 characteristic so quality is measurable, and uncovered KPIs are named (Principle 1).
CTAL-TM · CTFL v4.0 §5.3
Example
See it in use
> /qa:quality-report "Q2-2026"✓ Correct when It trends escaped defects, coverage, pass rate, MTTR, automation %, and flaky rate across releases with RAG status.
Used by