Illustration: a QaCockpit Cloud Campaign Run Report. The copyable template below is a separate review aid that you can use with your existing tools.
A release readiness report should let someone answer three questions: which version did we review, what evidence supports it, and what still needs a decision?
Start with the template below. Copy it into a document, a release work item, or your team’s existing review system. No account or email is required. The filled example shows how to use it when a passing test report belongs to the wrong version and another required report is missing.
This is a review of test evidence for a release decision. Your team may also require security, migration, rollback, operational, or other checks. Record those separate gates instead of assuming that a complete test report proves every aspect of release readiness.
Copy the release readiness report template
Use one record per candidate and review. Repeat the source and risk sections as
needed. Write Unknown when the evidence does not establish an answer; leave no
unexplained blank that another reader could interpret as a pass.
RELEASE READINESS REVIEW
Release / candidate:
Product and scope:
Review time (include time zone):
Reviewer / decision owner:
Review record version:
TARGET VERSION
Component -> exact artifact/package version or digest:
Source commit(s), where relevant:
Target environment and relevant configuration:
Required test sources and accepted scope baseline:
Evidence freshness rule for this decision:
Other required release gates and their records:
REQUIRED SOURCE (repeat for each source)
Source / project / pipeline:
Exact run and attempt, with link:
Test suite revision:
Actual application version tested, with proof:
Environment tested and completion time:
Passed / failed / skipped / unknown counts:
Report availability: complete / partial / missing / unknown
Expected tests or shards: matched / missing / unknown
Version and environment match: yes / no / unknown
Evidence age acceptable: yes / no / unknown
Failure details and artifact links:
Missing evidence, next action, owner, and due time:
RISK OR EXCEPTION (repeat for each item)
Issue / missing evidence:
Affected behavior and release scope:
Impact and supporting evidence:
Action owner and next step:
Exception requested: yes / no
Accepted by, reason, limits, and expiry (if accepted):
Recheck or withdrawal condition:
DECISION
Go / no-go / pending:
Reason and unresolved conditions:
Decision owner and decision time:
Next review time or trigger:
Selected evidence retained until:
Retention location and access check owner:A timestamp needs a time zone. An evidence link needs to identify one execution, not a page whose meaning changes whenever a new run finishes. If a release combines several services, record the version of each service. Their repositories do not need to share a commit SHA.
Filled example: a release with incomplete evidence
The following product, run numbers, people, and times are fictional. They illustrate a review method, not customer results or a recommended industry threshold.
Candidate: Shop release R42, comprising orders-api 4.2.0 and web 7.8.0.
In this example, both package versions identify immutable artifacts in the team’s
registry. Their exact registry and build references belong in the real record.
Review: 16 September 2026, 09:00 UTC. Decision owner: Maya, release lead.
Required evidence: API regression, browser regression, and deployment smoke in
release-test. The team’s rule for this release is evidence from the preceding
24 hours, collected against the candidate versions and agreed configuration.
| Required source | Selected execution | Evidence at the review |
|---|---|---|
| API regression | Run 481, attempt 1; completed 07:20 UTC | 240 passed, 0 failed, 0 skipped, 0 unknown. All 240 baseline tests reported against orders-api 4.2.0 in release-test. |
| Browser regression | Run 732, attempt 1; completed 07:40 UTC | 118 passed, 0 failed, 2 skipped, 0 unknown. All 120 baseline test identities are present, but the deployment record shows web 7.7.0. |
| Deployment smoke | Run 915, attempt 1; completed 08:10 UTC | Pipeline succeeded. No usable test report is available. The expected 20 checks cannot be verified. |
Each run number in a real report should link to the exact execution in its project. Attach the deployment record that establishes the tested versions, the baseline used for comparison, and the relevant result or diagnostic artifacts.
The browser report is complete as a file and accounts for its expected test
identities. It still does not validate web 7.8.0. The two skipped checks also need
an explanation; their presence in the report does not mean they executed.
The smoke pipeline’s successful conclusion establishes neither its test counts nor the outcome of the required checks. Do not enter zero failures for this source. Its outcome remains unknown until the report or another accepted form of evidence is available.
Turn each gap into an owned action
The release record now has three concrete follow-ups:
| Gap | Action and owner | Completion condition |
|---|---|---|
| Browser results cover the previous web version | Alex, frontend engineer, deploys web 7.8.0 to release-test and runs the browser regression again. |
New exact run, deployment version proof, and results for the agreed browser scope. |
| Two browser checks were skipped | Sam, QA lead, investigates the exclusions before the next review. | Checks execute, or the release lead records a reasoned, limited exception with an owner and expiry. |
| Smoke report is missing | Jordan, platform engineer, checks test execution and report publication. | Recover usable evidence from run 915 if it exists and is valid; otherwise run the missing checks and record the new execution. |
Recorded decision: no-go at 09:00 UTC. Required evidence for the candidate is incomplete. No exception has been accepted. The next review is at 11:00 UTC, or after the three completion conditions are met if that takes longer.
The API result can remain in the next review only if its version, environment, freshness, and relevant dependencies still satisfy the team’s rules. Preserve the first review and record the new evidence selection as another version of the decision record. Do not silently replace its run numbers.
The example team’s retention requirement is 90 days after the decision. That is a chosen requirement for this example, not a universal minimum. The record names an owner to check that result files, diagnostic artifacts, and links remain accessible for that period.
Keep completeness, outcomes, and decisions separate
Three distinctions prevent a concise report from becoming misleading:
- A received report is not proof of complete test scope. Compare it with the required sources and accepted test or shard baseline. If no baseline exists, describe the observed results and mark scope completeness as unknown.
- A complete result set is not proof of the right version. Trace each result to the application artifact and environment that were actually tested.
- An accepted exception is not a passed test. Keep the failure or gap visible, together with who accepted it, why, and under which limits.
For the questions behind those checks, use the existing seven-question release readiness checklist. The release readiness dashboard guide explains how to keep the same distinctions visible during ongoing quality work.
Use the template with your reporting system
The template captures the reviewer’s reasoning and decision. Prefer links and counts from the original evidence over repeatedly copying numbers between reports. When you must transcribe a value, identify its source and the time it was reviewed.
QaCockpit Cloud can build versioned stakeholder reports from stored executions and campaign runs, including result and completeness evidence. The report-sharing guide describes its previews and delivery options. Your team’s release decision and additional gates still need their own agreed process.
For an Azure DevOps-only setup, see the separate QaCockpit for Azure DevOps edition and its extension documentation. Its private campaign reports and provider-retained evidence have different sharing and retention boundaries from Cloud.
If gathering the fields in this template is difficult, take the Release Visibility Check. It identifies gaps in how your team finds and uses evidence, with practical next steps and no email required. Its score assesses those practices; the release decision remains yours.