A client receives a fifteen-page QA report, reads the first page, and never opens the rest. That’s not a sign they don’t care about quality. It’s a sign the report answered the wrong question. They didn’t ask “what are all the things you checked,” they asked one thing: is this ready to ship? Everything else in the report, useful as it is, only matters to the people who need to act on that answer.

We rebuilt our own reporting around answering that question first. This post walks through the full structure of that report, chapter by chapter, and the verdict logic that makes it possible. For the platform-specific how-to, see our Learning Centre guide, Building QA Reports Clients Actually Care About, which covers the exact export workflow inside Evaficy Smart Test.

The one number that actually matters

A pass rate on its own doesn’t tell a client much. A 90% pass rate on a run that skipped a third of the test cases means something very different from a 90% pass rate on full coverage, and most clients have no easy way to tell which one they’re looking at from the number alone. What they actually need is a verdict that already accounts for that: a single, computed label they can act on without doing the analysis themselves.

Anatomy of a report that leads with the answer

A well-structured QA report should be organized in the order a reader actually needs, verdict first, evidence last, not the other way around. In practice, that structure looks like this:

• Cover page: project, environment, and build details, plus the headline numbers up front: a pass-rate figure, a colour-coded verdict, and a quick breakdown of passed, failed, blocked, and skipped cases.
• Introduction: the test run overview, the environment it ran against, and the dates of execution.
• Executive summary: the full stat breakdown alongside the computed quality verdict and a plain-English assessment of each result category.
• Test case results: every test case in the run and its final status, in one scannable table.
• Detailed execution: steps, actual results, evidence, and reviewer comments per test case, for whoever needs to go deeper.
• Defects and issues: failed and blocked tests grouped into their own tables, with severity, priority, and reasons attached.
• Conclusion: the verdict restated, a short list of concrete recommendations, and a sign-off record.

A reader who only opens page one gets the verdict. A reader who needs to act on a specific failure can go straight to the relevant chapter. Nobody has to read fifteen pages to find the one line they actually needed.

How the verdict is actually calculated

The verdict isn’t a subjective call. It’s computed the same way every time, based directly on the pass rate:

Verdict	Condition	What it tells the client
Excellent	≥ 95% pass rate, 0 failed	All tests passed with no failures. Ready for release.
Acceptable	≥ 80% pass rate	Most tests passed. Minor issues should be addressed.
Needs Attention	≥ 60% pass rate	Significant failures detected. Investigation required.
Critical Issues	Below 60% pass rate	High failure rate. Release is not recommended.

Because the verdict is calculated the same way every time, a client who sees three consecutive “Acceptable” reports is looking at a genuine trend, not a shift in how thorough the QA process happened to be that particular week. It also removes an awkward conversation from the process: nobody has to decide in the moment whether a given run “feels” ready enough to ship, since the number already answered that before anyone opened the document.

Severity and priority aren’t the same thing

A failed test case is worth almost nothing to report without knowing how bad the failure actually is, and that’s where severity and priority get confused. Severity describes how badly something breaks. Priority describes how urgently it needs fixing. They are not the same axis, and treating them as one collapses two useful signals into one confusing label.

Those two don’t always move together. A cosmetic bug on a high-visibility page can be low severity but high priority: it barely affects functionality, but it’s the first thing an executive sees during a demo. A rare edge case that corrupts data can be high severity but lower priority if almost nobody actually hits it. Collapse both into one “severity” label and one of those two bugs gets fixed at the wrong time. Reporting them as separate columns is what lets a client and their team make that call deliberately instead of guessing.

One report, one test run

Worth being upfront about: a report covers a single test run, not an entire release. If a release spans five scenarios, that’s five separate reports, not one combined document summarizing all of them at once.

Planning your delivery cadence around that, sending a report after each completed run rather than waiting to bundle everything into one release-end summary, keeps clients seeing real progress throughout the engagement instead of only finding out how things went at the very end. It also means a failing run doesn’t get buried inside a five-scenario bundle where it’s easy to skim past. It shows up on its own, with its own verdict, the same day it happened.

The line most reports forget

A report that ends with numbers and nothing else misses the part that actually closes the loop: a sign-off record. Naming who executed the testing and who’s accountable for the verdict, with a place for a name, a date, and a signature, turns the report from a data dump into a formal handoff document.

It’s a small addition, and it answers a question clients often ask anyway once they’ve read the summary: who actually signed off on this? Having that answer already sitting in the document, rather than needing a follow-up email to track it down, is often what makes a report feel finished instead of provisional.

Common questions

Does one report have to be a PDF?

In our own workflow, yes, PDF is the format we standardized on for anything client-facing. A formatted PDF preserves the verdict, the layout, and the severity/priority columns exactly as intended, in a way a spreadsheet export doesn’t.

Can this be scheduled or sent automatically?

We treat report generation as a deliberate, manual step tied to a completed test run, not an automated recurring job. That keeps a human in the loop before anything reaches a client’s inbox.

Is there a link clients can open without logging in?

No. Reports are files you generate and send yourself, the same way you’d send any other attachment, rather than a public link into a live system.

Does one report cover a whole release?

No, and this is worth repeating: scope your reporting per test run. For a release spanning several scenarios, that means multiple reports, referenced together in your own delivery message.

Takeaways

• A computed, consistent verdict answers the only question a client actually asks: is this ready to ship?
• Structure the report verdict-first, evidence-last, so a reader gets the answer on page one.
• Severity and priority are different axes. Treating them as the same thing leads to the wrong bugs getting fixed first.
• Report per test run, not per release, and plan your delivery cadence around that.
• A sign-off record turns a report into a real handoff document, not just a page of numbers.

None of this depends on a client trusting your judgment call in the moment. The verdict is computed the same way every time, severity and priority are separated on purpose, and the sign-off record is already there when someone asks. A report built that way holds up on its own, whether the reader gets through all fifteen pages or just the first one.

If you want the exact, step-by-step version of this workflow inside a real QA platform, including plan limits and the full export process, we cover it in detail in Building QA Reports Clients Actually Care About.