A software test report should identify the product and build tested, environment, objectives, scope, execution summary, coverage, defects, deviations, blocked or untested work, residual risks, and release recommendation. Use counts only with their denominator and context. The report should let a decision-maker understand what evidence exists, what remains unknown, and who accepted any remaining risk.
Copy-and-paste software test report template
Complete this report at the end of a defined test activity, release, or milestone. Keep live progress updates in a separate progress report. The completion report should summarize the final evidence without hiding changed scope or unfinished work.
Write for the decision audience. An executive may need the recommendation, major risks, and exceptions first; a delivery team also needs defect links, environment details, and reusable test assets. Both views must refer to the same underlying results.
- Report header: product, version, build, environment, period, author, and approval status
- Objective and decision: what the testing was intended to establish
- Scope: features, integrations, platforms, test levels, and explicit exclusions
- Execution: planned, passed, failed, blocked, and not-run tests with definitions
- Coverage: requirements or risks exercised, with evidence links
- Defects: open and closed counts by agreed severity plus critical summaries
- Deviations: changes to plan, environment, schedule, data, or technique
- Residual risk: unresolved defects, untested areas, likelihood, impact, and owner
- Recommendation: release, release with accepted risk, retest, or do not release
- Approvals and attachments: decision owner, date, reports, logs, and reusable assets
Illustrative completed example for an appointment reminder release
The following build identifiers, dates, counts, defects, and recommendation are fictional and provided only to show how a completed report reads. Build and environment: Reminder Web 1.4.0, commit 7f2a91, production-like staging, Chrome and Safari current supported versions, synthetic clinic and patient records, SMS provider sandbox. Test period: 8 to 10 September. Objective: determine whether staff can schedule and cancel reminders safely across clinic and timezone boundaries.
Scope completed: booking edit flow, consent validation, scheduling, cancellation, delivery-status display, clinic isolation, timezone conversion, and provider failure recovery. Excluded: two-way replies and recurring campaigns because they are outside this release. Execution: 46 planned, 41 passed, 2 failed, 1 blocked, and 2 not run. The blocked item depended on a provider sandbox outage.
Open defects: one high-severity defect allows a daylight-saving transition to show the wrong local send time; one medium defect truncates a long clinic name. Recommendation: do not release until the timezone defect is fixed and the critical scheduling regression set passes. The medium visual defect may be accepted by the product owner if documented.
This recommendation follows from the product risk, not from the 89 percent pass rate. One high-risk failure can outweigh dozens of passing low-risk checks.
Report counts without losing meaning
Define each status. Passed means the expected observable result occurred on the identified build and environment. Failed means it did not. Blocked means execution could not reach a result because a prerequisite failed. Not run means no execution occurred. Never merge blocked or not-run tests into passed results.
State the denominator and selection method for coverage claims. A requirement coverage percentage should point to the requirement set and show which high-priority items remain. Defect counts should state severity definitions and whether duplicates, deferred issues, and accepted issues are included.
- Link summary numbers to the source test run or evidence repository
- Separate retest results from the first execution when trends matter
- Explain skipped platforms or reduced scope and name the approver
- Call out flaky or unreliable evidence instead of averaging it into success
- Preserve the final report with the build and test assets it describes
Make residual risk explicit
Residual risk includes open defects, untested conditions, fragile dependencies, uncertain data, and known limits that remain after testing. For each material item, state the affected user or operation, likely consequence, available mitigation, monitoring, owner, and review date.
A release-with-risk recommendation is not the same as a pass. Record who has authority to accept the risk and the evidence they reviewed. If a risk cannot be described clearly enough for that decision, the report is not complete.
Connect the report to the product journey
A report is easier to review when stakeholders recognize the tested journey. Teams using SayCraft can preserve a replay of the product conversation and the evolving working preview. That shared context can help explain why particular flows and risks were prioritized.
Do not cite the prototype as evidence that the released system passed. The test report must refer to the actual identified build, environment, and observations. Use the prototype and meeting replay only as linked product context.