Building QA Reports Clients Actually Care About
Stop sending walls of technical data. Here's the report structure clients actually understand — built from the exact test run report Evaficy Smart Test generates for you.
For agency founders, account managers, and QA Engineers who need to hand a client something they'll actually read.
Why Standard QA Reports Fail
A client receives a 15-page QA report, reads the first page, and never opens the rest. It's not that they don't care about quality — it's that the report answers the wrong question. They didn't ask "what are all 500 things you checked?" They asked one thing: is this ready to ship?
A report that leads with a defect-by-defect data dump forces the reader to do the analysis themselves. A report that leads with a verdict and lets them drill into evidence only if they want to respects their time — and gets read.
Anatomy of an Evaficy Test Run Report
Every completed test run can be exported as a single PDF — the Export PDF button sits on the test run screen once execution is complete. The report is built in the order a reader actually needs: verdict first, evidence last.
Branded cover page
Project name, environment, browser/OS, build version, who ran it, and when — plus the headline numbers up front: a pass-rate circle, a colour-coded verdict pill, and five stat cards (Passed / Failed / Blocked / Skipped / Not Run). A reader gets the answer before turning the page.
Introduction
Test run overview, the test environment it ran against, and the dates and schedule of execution — context for everything that follows.
Executive Summary
Eight stat cards (Total, Passed, Failed, Blocked, Skipped, Not Run, In Progress, Pass Rate), the Quality Verdict box, and a Result Breakdown table that pairs each status with a plain-English assessment — "Defect detected — requires investigation," not just a number.
Test Case Results
Every test case in the run and its final status, in one table — the scannable middle layer between the summary and the full detail.
Detailed Execution
Per test case: the steps executed, the actual result recorded, any evidence links attached, and reviewer comments. This is the chapter a developer opens; a client rarely needs to.
Defects & Issues
Failed tests grouped into their own table (severity, priority, defect description), and blocked tests grouped into another (with the block reason) — exactly the "defects by severity" view a client wants, generated automatically from what was logged during execution.
Conclusion
The verdict restated, a list of auto-generated recommendations ("Investigate and resolve the 3 failed test case(s) before release," "Quality is excellent — this build is a strong candidate for release"), and a Sign-Off table with rows for Test Lead, QA Engineer, and Product Owner — built for exactly the handoff moment a client-facing report needs.
The Quality Verdict, Explained
The verdict on the cover and in the Conclusion isn't a subjective label — it's calculated directly from 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 computed the same way every time, a client who sees three consecutive "Acceptable" reports is looking at a genuine trend, not a QA engineer's changing mood.
Reading Severity and Priority in the Report
The Failed Tests table in Chapter 5 shows a Severity and a Priority column for each failure — set at the moment the QA Engineer marked that test case failed during the run. Severity here is Critical / Major / Minor / Trivial and priority is Critical / High / Medium / Low.
A subtle but real distinction
This run-level severity scale is separate from the severity scale used when logging a standalone defect in Evaficy's dedicated Defect tracker, which uses Critical/High/Medium/Low/Trivial. Both describe how bad a defect is — they just come from two different places in the product, so don't expect the wording to match exactly between the two when you cross-reference them. See the Defect Reporting Guide for the full defect severity taxonomy.
One Report Covers One Test Run
Worth being precise about: the exportable report is scoped to a single test run, not a whole project or an entire release spanning several scenarios. If a release involves testing five scenarios, you get five reports — one per completed run — not one combined document.
For a release that spans multiple scenarios, the practical approach is to export a report for each completed run and reference all of them in your own delivery message, or use each scenario's test run history inside the platform to confirm everything relevant has actually been executed before you start exporting.
Who Can Generate a Report, and How Many
The Export PDF button lives on the test run screen — which means generating a report requires a completed test run, and test runs are an Enterprise-plan feature. Export usage itself is also capped by plan:
| Limit | Basic | Advanced | Enterprise |
|---|---|---|---|
| Test Runs & execution | — | — | ✓ |
| PDF report export | 5 total | 10 / mo | Unlimited |
| AI Defect Prediction (Risk Insights) | — | — | ✓ |
In practice, generating a client report at all requires Enterprise — Basic and Advanced don't have test runs to export from yet. See the full breakdown on the Pricing page.
Delivering the Report to a Client
There's no built-in scheduled report, automated email delivery, or public shareable link — the PDF is a file you download and send yourself, the same way you'd send any attachment.
The Sign-Off table is the handoff point
Chapter 6's Sign-Off table — blank Name, Date, and Signature rows for Test Lead, QA Engineer, and Product Owner — is designed for exactly this moment: attach the PDF to your delivery email, and the report itself carries the formal record of who tested it and who's accountable for the verdict.
A practical cadence most agencies use: export and send a report after each completed run during active testing, then a final report once the release-scoped runs are all done and the client is ready to make a ship decision.
Pairing the Report With Risk Insights
Before you even get to a final test run, Evaficy's AI Defect Prediction (Risk Insights) feature gives you an earlier read: a 0–100 risk score per scenario, labelled Low/Medium/High and colour-coded green/amber/red, calculated from historical fail rate and recent trend. It also generates a short plain-English narrative summarising your project's current risk profile.
Use it before the report, not instead of it
Risk Insights (Enterprise) is a pre-release signal for your own team and for a Product Owner or Tech Lead deciding what to prioritise — it's not exportable and doesn't replace the test run report a client sees. Think of it as the thing you check before deciding which scenario needs one more test run before you generate the report you'll actually send. More detail: AI-Powered QA Features.
Common Questions
Can I export the report as Word or Excel instead of PDF?
No — PDF is the only client-facing report format. There is no Word export, and there is no exportable spreadsheet format for a formatted report today.
Can reports be scheduled or emailed automatically to a client?
No. Report generation is a manual action — you click Export PDF on a completed run and deliver the file yourself. There’s no automated or recurring report feature.
Is there a link I can send a client to view results without a login?
No. Everything in the platform, including the export action itself, requires an authenticated project member. What you share with a client is the exported PDF file, not a link into the app.
Does one report cover a whole release with multiple scenarios?
No — a report is scoped to one test run. For a release spanning several scenarios, export one report per completed run.
Key Takeaways
- Lead with the verdict, not the data — Evaficy’s report puts a computed Quality Verdict on the cover page before any detail, because that’s the question clients actually ask.
- The verdict is calculated, not subjective: Excellent (≥95%, 0 failed), Acceptable (≥80%), Needs Attention (≥60%), Critical Issues (below 60%).
- A report covers one test run, not a whole release — export one per completed run for multi-scenario releases.
- Failed-test severity/priority in the report (Critical/Major/Minor/Trivial, Critical/High/Medium/Low) is set during execution and is distinct from the standalone Defect tracker’s severity scale.
- PDF export requires Enterprise in practice, since test runs themselves are Enterprise-only.
- Delivery is manual — there’s no scheduled report or shareable client link — so the Sign-Off table in the Conclusion chapter is your handoff record.
Related guides
Test Run Execution: A Step-by-Step Guide
Executing steps, marking pass/fail, logging defects with evidence, and reading run results.Defect Reporting Best Practices
The real severity taxonomy, severity vs. priority, and how to log defects that get fixed.Managing Multiple Client QA Projects
Project structure, roles, and plan limits for agencies running several client engagements.AI-Powered QA Features
How Risk Insights, regression selection, and test maintenance work.Free Resource
This topic is covered in the QA Leader’s Handbook
A free 10-chapter PDF guide for Tech Leads and Product Owners.
See the report on your own test run
Create your free account, run a structured test execution, and export your first client-ready PDF report.
Create your free account