If the result of testing exists only in the tester’s head, as far as the rest of the project is concerned, testing has not happened.

A report is not a ritual email to the lead. It brings information about progress, quality and risk to the people who need to make decisions. The reader might be a Test Lead, Project Manager, Product Owner, developer, customer or operations team; each needs a different level of detail.

Progress report

A progress report answers: where are we compared with the plan?

A short report usually includes:

For example:

Checkout regression — build rc.3

- Executed: 42/60 tests
- Result: 35 passed, 5 failed, 2 blocked
- Blocker: payment sandbox timeout, PAY-184
- Risk: refund and duplicate callback not tested yet
- Next: retest 3 fixes and continue the remaining 18 tests when the sandbox is stable

Don’t report 80% complete without saying 80% of what. A payment case taking two hours and a label check taking two minutes do not carry the same weight, so a percentage is a signal, not a truth machine.

Report frequency depends on the project rhythm. If the team already sees a real-time dashboard and discusses it in Daily Scrum, there may be no point making everyone send an identical email at the end of the day. Reports exist to reduce information blindness, not increase the number of channels to update.

Test completion report

When a test level, sprint, milestone or release reaches its endpoint, the report needs to answer the larger question:

With the evidence we have, what state is the product in and what risks remain if we continue?

It usually includes:

  1. Scope and test basis: which features, requirements, build and environment are covered.
  2. Period and effort: when testing happened and who or what participated.
  3. Coverage: which requirements, risks, platforms or configurations were and were not covered.
  4. Execution result: planned, executed, passed, failed, blocked and skipped tests.
  5. Defects: open defects by severity/priority, fixed defects and retests.
  6. Deviation: what differed from the Test Plan and why.
  7. Residual risk: what was not tested, which failures were accepted and what limitations remain.
  8. Conclusion or recommendation: release, delay, conditional release or more evidence needed.

Don’t call execution rate coverage

These two numbers are often mixed up:

Execution rate = executed tests / planned tests
Pass rate      = passed tests / executed tests

They are useful, but 60/60 executed does not automatically mean 100% requirement coverage. The team may have written too few tests for a business rule from the beginning.

Coverage must say what it covers: requirements, risks, branches, browsers, devices or test conditions. Pass rate is not a direct measure of quality either; 99 cosmetic cases passing and one payment case failing still makes a build seriously worrying.

Automation reports

For automation, look beyond pass/fail:

A green dashboard after three retries should not be described as a clean pass. Hide instability in the report and, when the pipeline really turns red, nobody will trust it anymore.

Write for the person reading it

The lead needs detail for coordination. The Product Owner needs risk and business impact. Leadership may need only a release recommendation and a few numbers with context.

A good report often has two layers:

Don’t paste a 200-line tool export into an email and call it a summary. Link to the dashboard or detailed file, then explain what matters in the report itself.

Wrap-up

A report does not directly improve the product. It makes product decisions less dependent on feelings.

If the reader still does not know what was tested, what was not tested and what risk exists in releasing now, the report is missing its most important part no matter how pretty the tables are.

The last article in Manual Testing Foundation takes a quick look at the tool groups testers commonly meet and how to choose tools for the work instead of memorising a list of logos.

References