QUICK ANSWER
What should a software test report template include?
A software test report should name the exact plan, strategy, case, build, environment, and reporting-window revisions; count unique cases separately from attempts; preserve passed, failed, blocked, not-run, and inconclusive outcomes; link sanitized evidence, defects, deviations, coverage, and reruns; disclose residual risks; and record a human recommendation without turning the report into acceptance or release approval.
A software test report should synthesize one bounded execution window without erasing failed, blocked, inconclusive, or not-run cases. It should identify the exact plan, strategy, case, build, and environment revisions used, then reconcile unique cases, repeated attempts, evidence, coverage, deviations, defects, reruns, residual risks, and a human recommendation.
This downloadable pack includes an editable Markdown worksheet, JSON starter, completed fictional JSON example, closed Draft 2020-12 schema, dependency-free validator, mutation tests, deterministic builder, and README. It reports results after execution. It does not plan tests, own raw evidence, approve acceptance or release, publish release notes, report general project health, or certify quality, security, accessibility, or compliance.
Build one report from a frozen execution boundary
Freeze the exact source revisions first, index every expected case once, preserve every attempt, and derive the summary from the detailed rows. Keep the report as a synthesis of existing evidence rather than a substitute for the systems that own planning, execution, defects, or release decisions.
Freeze the source and reporting boundary
Name the exact test plan, test strategy, requirement set, build digest, environments, and UTC reporting window. The report must not silently mix results from a later build, revised case, different environment, or execution outside that window.
Sources: [test-report-pack], [nasa-swe-065], [nasa-testing-analysis]
Index each expected case and every attempt
List each expected case exactly once. Keep attempts in time order, preserve their individual verdicts, and derive the final verdict from the latest attempt. A case never run remains an explicit not-run row with no fabricated attempt or evidence.
Sources: [test-report-pack], [nasa-testing-analysis]
Link sanitized evidence, deviations, defects, and reruns
Use stable references rather than copying raw logs or defect descriptions into the report. Each result links only the evidence needed to support the observation, marks it sanitized, and uses reserved fictional hosts in the example. Failed and blocked states retain their required rationale or reference.
Sources: [test-report-pack], [rfc-2606], [ico-data-minimisation]
Reconcile summary and coverage arithmetic
Count unique cases separately from attempt references so reruns cannot inflate coverage. Derive requirement coverage from the case rows and preserve failed, blocked, not-run, and inconclusive gaps instead of collapsing them into an overall success percentage.
Sources: [test-report-pack], [nasa-swe-065], [nasa-testing-analysis], [json-schema-2020-12]
Record residual risks and a human recommendation
Describe the remaining uncertainty with source references and let an accountable human choose continue testing, rerun required, review required, or no recommendation. The report does not make business acceptance, release, launch, or specialist assurance decisions.
Sources: [test-report-pack], [nasa-swe-065], [nist-ssdf]
One post-execution synthesis, with adjacent owners intact
Use this report after a bounded software-test execution window. It aggregates evidence references and results for an audience without taking control of the work that produced or acts on them.
Included
- Exact plan, strategy, requirement, case, build, environment, and reporting-window revisions.
- One result-index row per expected case, ordered attempt references, and the latest derived verdict.
- Passed, failed, blocked, not-run, and inconclusive states without hidden exclusions.
- Sanitized evidence, deviation, defect, rerun, coverage, residual-risk, and recommendation references.
- Derived unique-case, attempt, outcome, and requirement-coverage totals with revision history.
Not included
- Test planning, strategy, case design, execution scheduling, raw evidence ownership, and defect reproduction.
- User acceptance testing, business acceptance, release or launch approval, and release-note publishing.
- General project status, schedule forecasting, implementation priority, remediation ownership, or product certification.
- Security, accessibility, privacy, compliance, reliability, or universal quality assurance.
DOWNLOADABLE RESOURCE
Download the deterministic test report pack
Use the Markdown worksheet for review, the JSON files for structured exchange, the closed schema for portable shape checks, and the dependency-free validator for cross-record rules. The builder creates the same versioned ZIP from the exact eight-file allowlist.
Software test report template and validator pack
An eight-file fictional resource pack for one post-execution synthesis with exact revisions, multiple outcomes, attempt-aware arithmetic, coverage, evidence, defects, deviations, reruns, residual risks, and human recommendation boundaries.
Format: Markdown, JSON, JSON Schema, validator, mutation tests, builder, and README in one ZIP
Locally reproduced August 1, 2026. SHA-256: 883f06c49efc41dd77f1ed239be7f96587750c4a5fb6a561029ba06ffde81da6
Included
- Editable Markdown worksheet plus a minimal valid JSON starter.
- Completed fictional JSON with pass, fail, blocked, not-run, inconclusive, and rerun states.
- Closed Draft 2020-12 JSON Schema for the portable record shape.
- Dependency-free validator and mutation tests for cross-record, privacy, arithmetic, and boundary rules.
- Deterministic builder and README with the exact eight-file allowlist and verification commands.
Verification boundary
Built from the page-local source allowlist with fixed timestamps and ZIP metadata removed, extracted cleanly, compared byte-for-byte with public files, rebuilt across time zones, and checked with the packaged validator and tests.
Three ways to use the report without crossing its boundary
These patterns show how the same report structure preserves visible uncertainty. They do not decide what to test, whether a defect is valid, or whether a build may ship.
Bounded regression window with mixed outcomes
Use when: A reviewed regression run is complete for one named build and environment set, but failures, blockers, or gaps remain.
Index every expected case once, retain all attempts, link the existing evidence and defect references, and derive the multiple-state summary before a human records the recommendation.
Structure
- Freeze build, plan, strategy, case, environment, and reporting-window revisions.
- Reconcile unique cases, attempts, verdicts, coverage gaps, defects, deviations, reruns, and residual risks.
Watch for: Do not turn a favorable result count into release approval or omit not-run and inconclusive work from the denominator.
Sources: [test-report-pack], [nasa-swe-065], [nasa-testing-analysis]
Rerun after an earlier failed attempt
Use when: The same case revision was executed again within the frozen window and both the earlier and later attempt must remain visible.
Preserve both executions, link them with one rerun reference, derive the final verdict from the latest attempt, and still count the case once in the unique-case totals.
Structure
- Keep adjacent execution references and their distinct evidence or defect links.
- Count two attempts, one expected case, one final verdict, and no invented coverage gain.
Watch for: A later pass does not erase the earlier failure, authenticate either evidence set, or prove regression safety outside the named case and environment.
Sources: [test-report-pack], [nasa-testing-analysis]
Window closed with blocked and not-run work
Use when: The reporting deadline arrives before every expected case can produce a conclusive executed result.
Keep missing execution as not-run, attach blocker evidence to blocked attempts, derive the affected requirement gaps, and record the residual risk and human recommendation without inventing completion.
Structure
- Represent not-run with no attempt and blocked with a resolvable blocker-evidence reference.
- Carry those states into summary, coverage, residual risks, and the next review decision.
Watch for: Do not convert blocked, not-run, or inconclusive states into passed work or claim that structural validation proves the reason is authentic.
Sources: [test-report-pack], [nasa-swe-065]
Decide whether a report is ready for review
A structurally valid file is reviewable, not authoritative. Use these rules before presenting it as the synthesis for a frozen window.
The report mixes builds, environment revisions, case revisions, or executions outside one declared reporting window.
Choose: Split the synthesis or update the source boundary explicitly, then revalidate every result and summary row against the revised identity.
Tradeoff: Readers may receive more than one report, but each conclusion remains tied to a traceable execution boundary.
Unique-case totals, attempt totals, outcome counts, coverage rows, reruns, or detailed results do not reconcile.
Choose: Treat the report as draft, correct the detailed references first, and regenerate every derived total instead of editing the summary by hand.
Tradeoff: Publication waits, but reruns and missing cases cannot silently distort the audience-facing result.
A passed, failed, blocked, or inconclusive attempt lacks required sanitized evidence, or a failure lacks a defect reference or explicit no-defect rationale.
Choose: Return the record to the evidence or defect owner for a safe resolvable reference; do not manufacture the missing observation inside the report.
Tradeoff: The report stays incomplete, but evidence custody and defect judgment remain with their proper owners.
Someone asks the report author to certify quality, compliance, security, accessibility, acceptance, or release readiness.
Choose: Keep the relevant boundary flags false and route the decision to the qualified business, release, or specialist owner with the report as one input.
Tradeoff: The report cannot offer a universal seal, but the accountable decision remains separate from a limited evidence synthesis.
PRESERVE EVERY OUTCOME
Download the test report template and validator
Open the Markdown or JSON starter, inspect the completed fictional multiple-state example, review the closed schema, and run the dependency-free validator before adapting the report to one execution window.
Download the test report packThe ZIP is reproduced locally. Public availability and the accuracy, safety, authenticity, and completeness of adapted evidence require separate verification.
Plan the execution before reporting itThe plan owns release scope, environments, suites, gates, and raw execution evidence. This report owns only the post-execution synthesis.
What a test report cannot prove
A reconciled report makes missing, conflicting, and repeated evidence visible. Its conclusion is still limited by the frozen scope, source systems, execution quality, evidence safety, and human judgment.
- A passed case proves only the recorded result for the named case revision, build, environment, input, and execution; it does not prove universal correctness.
- A hash and sanitized flag make a reference reviewable but do not authenticate its origin, completeness, custody, redaction quality, or observation.
- Coverage arithmetic shows mapped requirement and case states; it does not prove that the requirements, cases, risks, or environments were complete or well designed.
- A failed result can reference a defect without proving root cause, severity, priority, ownership, remediation, or business impact.
- A later passed rerun does not erase an earlier failure or prove that related areas, integrations, data, permissions, locales, devices, or load conditions are safe.
- Blocked, not-run, and inconclusive results preserve uncertainty; the template cannot decide whether the residual risk is acceptable.
- The closed schema checks portable shape, while the validator checks bundled cross-record rules; neither establishes the truth of external evidence or source revisions.
- The pack does not replace a test plan, test strategy, test cases, UAT record, project status report, bug report, release notes, launch review, or specialist assessment.
- This ordinary informational article is not an AI entry page and does not grant AI signup credits.
Sources and verification record
The same-release pack directly supports the artifact claims. The external primary sources support bounded reporting, traceability, secure-development context, portable schema shape, reserved fictional domains, and data minimisation, without certifying this template or any real report.
[test-report-pack] Playcode:Software test report fictional resource pack
Checked August 1, 2026. Supports: The same-release fictional multiple-state report, exact eight-file allowlist, closed schema, validator behavior, mutation tests, deterministic archive, and owner-boundary flags. Public availability remains unverified until deployment.
[nasa-swe-065] NASA Software Engineering Handbook:SWE-065 Test Plan, Procedures, Reports
Checked August 1, 2026. Supports: Primary guidance distinguishing test plans, procedures, and reports, with executed outcomes, traceability, deviations, and retained records. NASA mission and safety obligations do not transfer to ordinary software teams or this pack.
[nasa-testing-analysis] NASA Software Engineering Handbook:Testing Analysis
Checked August 1, 2026. Supports: Primary discussion of analyzing test results, pass and fail outcomes, discrepancies, deviations, traceability, and reporting. It does not validate this fictional data or prescribe its JSON model.
[nist-ssdf] National Institute of Standards and Technology:Secure Software Development Framework 1.1
Checked August 1, 2026. Supports: A primary secure-development framework relevant to the boundary around security verification and qualified ownership. It does not certify generic QA results or this report.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The released Draft 2020-12 vocabulary declared by the bundled closed schema. Schema conformance checks data shape, not evidence truth or operational fitness.
[rfc-2606] RFC Editor:Reserved Top Level DNS Names
Checked August 1, 2026. Supports: The reservation of .test for testing examples, used by the fictional evidence references to avoid real customer, internal, or production hosts. Reservation alone does not make a URL safe or private.
[ico-data-minimisation] UK Information Commissioner's Office:Principle (c): Data minimisation
Checked August 1, 2026. Supports: UK GDPR context for limiting personal data to what is adequate, relevant, and necessary. It does not establish global compliance or prove that a sanitized evidence reference contains no personal data.
Software test report template questions
What is the difference between a test plan and a test report?
A test plan defines the release scope, environments, responsibilities, suites, gates, and evidence to produce before execution. A test report synthesizes the results after one bounded execution window. Link the exact plan revision in the report, but do not rewrite the plan, schedule new work, or make the report responsible for raw execution evidence.
How should reruns appear in a software test report?
Keep every attempt in chronological order, link adjacent repeated executions with a rerun reference, and derive the case final verdict from the latest attempt. Count the case once in unique-case and outcome totals while counting every attempt separately. Preserve the earlier failure, defect, deviation, and evidence links even if the later attempt passes.
How should not-run and blocked tests be reported?
Give every expected but unexecuted case an explicit not-run row with no attempt. A blocked case has an executed blocked attempt, sanitized evidence, and a resolvable blocker-evidence reference. Carry both states into the summary, coverage gaps, residual risks, and human recommendation rather than excluding them or presenting them as passes.
Should a failed test always link to a bug?
A failure should reference an existing defect record when one is already owned by the defect process. If no defect is created, preserve an explicit no-defect rationale such as a known environment issue or duplicate reference decision. The test report should not reproduce, triage, prioritize, or close the defect itself.
Does the JSON Schema validate the whole test report?
The closed Draft 2020-12 schema validates the portable field shape and rejects unknown keys. The dependency-free validator adds chronological, reference, arithmetic, rerun, privacy, and owner-boundary rules. Neither confirms evidence authenticity, source-system truth, coverage quality, defect validity, acceptance, or release readiness.
Can a passing test report approve a software release?
No. The report can provide one traceable input to a release owner, but it does not own business acceptance, launch approval, production readiness, or specialist assurance. Keep all approval and certification flags false, disclose residual risks and gaps, and let the accountable human apply the organization’s release criteria.
How should test evidence be shared safely?
Reference only the evidence needed for review, sanitize it before publication, use stable HTTPS locations with controlled access, and avoid names, emails, credentials, tokens, personal data, customer records, and private internal URLs. A sanitized flag and hash do not replace access control, retention, privacy review, or evidence-custody procedures.
Can Playcode turn this template into a reporting workflow?
Playcode can help build a bounded workflow around reviewed report fields and state rules. Before operational use, verify authentication, authorization, evidence storage, sanitization, retention, audit, concurrency, source-system integrations, notifications, exports, monitoring, backup, recovery, and the human owners for planning, defects, acceptance, release, and specialist assurance.
BUILD A BOUNDED REPORTING WORKFLOW
Turn the reviewed report model into an app
Give Playcode the reviewed fields, source revisions, states, validation rules, and owner boundaries. Verify access, evidence storage, privacy, retention, audit, integrations, concurrency, monitoring, backup, recovery, and human decisions before operational use.
Start building with PlaycodeThis ordinary informational article is not an AI entry page and does not grant AI signup credits. No evidence authenticity, coverage completeness, acceptance, release, security, accessibility, compliance, reliability, quality, or business outcome is guaranteed.