Write a client-facing test summary
A client summary connects the test results to a business question, with enough context to explain the findings and their limits.
From report to summary
The report guide explains session counts, failures and timings. The template below can be used in your own client document to describe the workload, results and performance targets.
A reusable seven-part summary
| Section | What to include |
|---|---|
| Purpose | The question or release decision the test supports. |
| Scope | Environment, release, scenario boundaries, timestamp and exclusions. |
| Configuration and results | Sessions, arrival window, traffic pattern, location and recorded outcomes. Exact session starts and delays require evidence beyond the report. |
| Findings | Session counts, failures and timings, compared with a baseline where available. |
| Decision | How the results compare with the agreed performance targets. |
| Limitations | Untested paths, incomplete work, lab conditions and environmental differences. |
| Next actions | Specific investigation or retest, responsible owner and agreed timing. |
Example summary (fictional data)
The test assessed whether release B met the performance targets for the campaign’s catalogue-to-product scenario. Both runs used the same scenario, location and traffic pattern in an authorised staging environment, with each run testing a different release. Each requested 600 sessions over ten minutes and recorded 600 completed sessions, including failures. Checkout, payment and real-user performance were outside the test’s scope.
Failures increased from 2 of 600 sessions (0.33%) to 40 of 600 (6.67%), while average page-load time rose from 1.8 to 3.1 seconds. Failed-step durations are excluded from those timing averages. Release B therefore exceeded both agreed limits: a 1% session failure rate and a two-second average page-load time.
The report does not confirm exact session start times or explain the cause of the slowdown, and these staging results do not establish production capacity. The application engineer will investigate the failed product step using the corresponding service logs. The test owner will then repeat the workload after the fix and update the release recommendation.
Limits of a conclusion
A conclusion applies to the scenario and workload that were tested. A browsing test does not establish whether checkout or payment works, and a run with fewer session starts than requested leaves readiness at the intended load uncertain. Missing measurements can also affect comparisons; without sample counts, the extent of that effect may be unknown.
Absolute counts help make these qualifications clear. For example, “2 failures became 40” describes the scale of a change more directly than a percentage increase alone, while the corresponding session totals explain how much work each run recorded.
Show a badge on the site
A “Load tested by UserLimit” badge can go on the tested site, for example in its footer. It links to UserLimit and doesn’t need a public report. The Share dialog of a run shows it in Light and Dark with the code to paste:
<a href="https://userlimit.com/"><img src="https://userlimit.com/badge.svg" alt="Load tested by UserLimit" width="131" height="44"></a>
On a dark page, use https://userlimit.com/badge.svg?theme=dark as the image address.