The test plan answers "what and how we will check" — before the work starts. It has a mirror document at the other end of the cycle: the test result report answers "what we checked and how it went." Planning and reporting are linked in a ring: without a clear plan nobody knows who does what; without an honest report on what was done, the next plan can't be built. Break one link — and the whole process starts to crumble.

"Everything's fine" is not a report

Imagine the customer asks how testing is going. The answer "overall it's fine" says nothing: it's a subjective feeling that can be arbitrarily far from reality. Compare: "79% of requirements are implemented, including 94% of the important ones; over the last three iterations coverage grew from 63% to 71%, and the case pass rate from 85% to 89%. We're on plan." The second version is facts and numbers you can base decisions on.

The numbers for such answers come from metrics — numeric characteristics of quality and progress. The most common ones are simple to compute:

  • Test case pass rate — what percentage of executed cases passed.
  • Test case execution rate — what percentage of planned cases were executed at all.
  • Requirements coverage — what percentage of requirements are checked by at least one case.
  • Defect fix rate — what percentage of found bugs are fixed (usually viewed by severity: for critical ones at the final stage, 100% is expected).

Much of this is computed automatically by trackers and test management systems, along with the trend over time — and the trend often matters more than the current value: coverage of 71% "grown from 63%" and coverage of 71% "dropped from 80%" are very different news.

One trap: metrics for metrics' sake. A tool collects piles of data and draws dozens of charts — and nobody knows how to interpret them. Every metric the team uses needs a short guide: what the number means and at what value it's time to worry.

What a report consists of

There is no single standard — report forms come in dozens. The universal skeleton:

  • Summary. The main achievements, problems, conclusions, and recommendations — written so that a very busy person gets the full picture from one paragraph. Don't confuse it with a bug report's summary: same name, different content and principles.
  • Process description — what was done during the reporting period: which builds, which testing types, what was manual and what automated.
  • Defect statistics — new and cumulative, broken down by status and severity; usually a table plus a chart.
  • Recommendations — what you propose to do.
  • Appendixes — metric values and their dynamics.

The logic: conclusions → recommendations → justification → facts

The most valuable part of a report is the conclusions and recommendations, and they follow a strict logic: conclusions are built from the goals stated in the plan, complemented by recommendations, both are rigorously justified, and the justification rests on facts.

Conclusions must be brief, informative, and useful:

  • Bad: "The results of processing files with multiple encodings leave much to be desired." Good: "Serious problems found with the encoding-detection library (see BR-834)."
  • Statements like "some tests passed surprisingly well" or "part of the team was on vacation, but we managed" don't belong in a report at all: no decision follows from them.

Recommendations must be brief, actually feasible, and leave room for decisions. "Use a word-processing mechanism similar to Google's" is not a recommendation: it cannot be acted on. "Replace the problematic library with an analog (needs investigation) or write our own solution (reliable but slow)" is one: the options and their costs are clear.

Justification answers "why we think so." Compare: "requirements coverage is sufficient" versus "coverage reached a sufficient level: 63% against the declared minimum of 60% for the current project stage." The second raises no "says who?" question.

Where this applies

Even if the formal report is written by the lead, everyone has to report in words and numbers: at stand-ups, in chat, in a release comment. The difference between "seems okay" and "92% of cases executed, two critical bugs in progress, we'll make it by Friday" is the difference between a feeling and information. The second person can be trusted with a decision; the first cannot.

Where beginners stumble:

  • They report feelings — "all good," "a few issues." Build your answer on the numbers already in the tracker.
  • They bring numbers without interpretation. Is "78% pass rate" good or bad? Without a threshold and a trend, the number is useless.
  • They write wish-recommendations ("quality needs more attention") that can't be acted on. A recommendation is a set of options with their costs.

What to learn next. A report leans on a plan — if you haven't yet, start with the test plan article. Defect statistics come from the tracker, and case numbers from test management systems. How to estimate the work before it starts — in the effort estimation article.