Reporting quality to executives on one page

A QA lead sends leadership a monthly report: 412 test cases executed, 89% pass rate, 47 bugs found, 31 fixed. Nobody replies. Next quarter, the QA budget is flat again.

The report was accurate and useless. Executives cannot act on test case counts, because those numbers answer a question nobody upstairs is asking. The questions upstairs are: are we getting better or worse, what might blow up, and what do you need from me?

A quality report that answers those three questions fits on one page — and gets read.

Short version

• Report trends, not totals. "Escaped bugs down 40% this quarter" beats any raw count.
• Lead with risk: the three things most likely to hurt, in plain words.
• Translate to money and customers where you honestly can.
• End with one ask. Reports without an ask change nothing.
• One page. The second page is where reports go to be unread.

What executives actually read

In order:

1. The headline. One sentence: is quality improving, stable, or slipping?
2. The risk list. What could go wrong soon, and how badly.
3. The trend charts. Two or three lines going up or down over months.
4. The ask. What you need, with a cost and a consequence.

What they skip: activity numbers. Tests run, cases written, hours spent — these describe effort, not outcome. Including them is not just neutral; it signals that QA measures itself by busyness, which is exactly the impression that keeps QA underfunded.

The one-page layout

QUALITY REPORT — Q2 2026                    Prepared by: QA Lead, 03 May

HEADLINE
Product quality improved this quarter: bugs reaching customers
fell 40% (23 → 14), while release frequency stayed unchanged.

TOP RISKS
1. Payments provider migration (June) — highest-risk change of
   the year; test environment still not available. HIGH
2. iOS Safari coverage remains manual-only; 18% of revenue
   comes through it. MEDIUM
3. Flaky checkout tests being skipped in CI for 3 weeks —
   regression cover there is currently partial. MEDIUM

TRENDS (charts)
- Escaped bugs per month (12-month line, trending down)
- Time from bug report to fix, P1/P2 (trending down)
- % of releases needing an emergency hotfix (flat)

CUSTOMER IMPACT
- 2 incidents this quarter (vs 5 last): ~3h checkout degradation
  in April (est. $12k delayed revenue), export outage in May.
- Support tickets tagged "bug": down 22%.

THE ASK
A staging environment for the payments migration by 20 May
(~$800/mo infra). Without it, the June cutover ships tested
against mocks only — our highest-severity gap this year.

Every section is skimmable in ten seconds. The whole page reads in ninety.

Choosing the three metrics

You need two or three trend lines, reported the same way every period. The strongest candidates:

Escaped bugs — bugs found by customers rather than by the team. The single most honest quality outcome number. Count them from support tickets and production incident reports, not from your own tracker's guesses.

Time to fix by severity — how long a P1 or P2 lives between report and resolution. Leadership understands response time instinctively.

Hotfix rate — the share of releases needing an emergency follow-up. A proxy for "how often do we ship something we regret", which is precisely what executives fear.

Metrics to keep out of the executive page (fine for internal use): test case counts, pass rates, coverage percentages, bugs-per-tester. Each is either gameable, meaningless without context, or an invitation to a wrong conclusion. A 95% pass rate sounds reassuring and says nothing — it depends entirely on what the failing 5% touches.

One rule above all: never change how a metric is calculated without saying so on the page. The first time leadership catches a silently redefined number, every future report is discounted.

Writing the risk section

This is the section that makes the report worth sending, and the one QA leads most often soften. Three rules:

Name real things, not categories. "Technical debt in testing" is wallpaper. "Checkout regression tests have been skipped in CI for three weeks" is information.

Attach each risk to a consequence. Not "iOS coverage is limited" but "iOS Safari carries 18% of revenue and is tested manually only — a checkout break there would likely be found by customers first."

Keep severity words honest. If everything is HIGH, nothing is. One or two HIGHs per quarter, used only when you mean it, buys you the credibility to be believed when it matters.

The risk section is also your protection. When a named risk later becomes an incident, the report shows it was flagged, dated, and costed. The uncomfortable conversation happens once, in advance, on your terms — instead of afterwards, on worse ones.

The ask

A report without an ask is a weather forecast. Executives are allocators; give them an allocation decision.

The formula: what, by when, what it costs, what happens without it.

A staging environment for the payments migration by 20 May (~$800/month). Without it, the June cutover ships tested against mocks only.

One ask per report. Two at most. A list of five asks is a list of zero, because it delegates the prioritisation you were supposed to do.

And when you have no ask? Say so explicitly — "No requests this quarter" — which spends nothing and builds the credibility your next ask will draw on.

Where the numbers come from

A one-page report should take an hour to write, not a day of spreadsheet archaeology. That is only true if the underlying data is captured as work happens: bugs consistently tagged with severity and source, incidents logged with duration, fixes timestamped.

Most of this falls out of a disciplined bug workflow automatically. Reports filed with full evidence and consistent fields — the kind tools like Crosscheck produce by default — make "escaped vs internal" and "time to fix" queries you run, not judgments you reconstruct at quarter end.

Frequently asked questions

How often should this report go out? Monthly or quarterly, matching whatever rhythm leadership already reads. More often than monthly and trends are noise; less than quarterly and QA disappears from the conversation.

What if the trends are bad? Report them plainly, with the reason and the plan. A bad trend honestly reported builds more trust than a good one massaged — and a bad trend is itself the strongest possible support for your ask.

Should I include what QA accomplished? One line, at most, and framed as outcome ("regression suite now covers refunds — the source of two incidents last year"). The report is about the product's quality, not the team's activity.

What if leadership only wants a dashboard? Give them the dashboard and attach the headline, risks, and ask as the summary on top. Numbers without narrative get misread; the narrative is the part only you can write.

How do I count escaped bugs without perfect data? Start rough: support tickets tagged "bug" plus incident count. Consistency matters more than precision — a slightly wrong number measured the same way every month still shows the trend truthfully.