A release owner receives a report showing a high pass rate. The failed refund check is still open, several tests never ran, and nobody can tell whether the totals describe the candidate being released. The percentage gives the meeting a starting point, but it cannot support the decision on its own.
A Jira test summary report should preserve the outcome of a defined testing effort: the release scope, evidence reviewed, results, unresolved exposure, and status of agreed exit criteria. A dashboard can continue changing as work progresses. A completion report needs a dated evidence boundary and an accountable recommendation, even when testing ends with gaps or a recommendation to hold the release.
Begin with the release being assessed, not the chart you want to reproduce. Identify the Jira project or space, Fix Version, candidate build, environment, and reporting cutoff with a time zone. Record the selected test baseline and the specific run or cycle identifiers that supplied the results. If multiple candidates were tested, explain which results qualify for the final assessment.
Jira Cloud supports searching work items by fixVersion. A saved filter can therefore help describe release-associated work, but its current results do not freeze the historical scope. Preserve the JQL, filter reference, returned issue keys, retrieval time, and relevant exclusions. Reopening the filter later may show a different set because membership or the query changed.
Keep three evidence layers separate. Jira work items describe requirements, delivery scope, defects, and configured fields. The installed test-management app or external execution system supplies its own case, cycle, run, and result records. The report combines those inputs with a human assessment. A Jira issue moving to Done does not establish that every required test passed.
Also distinguish the reusable case from the instructions used in a particular run. Record a recoverable baseline or specification reference alongside the build and execution identity. The guidance on test case versioning and run snapshots explains why a release version alone cannot identify the test content that produced an earlier result.
Copy the following four sections into your release record and replace each instruction with actual evidence. Keep identifiers as references to the real records; add controlled links in your team's copy where readers have permission to use them. Unknown values should remain explicitly missing, with an owner and next action. Do not fill an approval field merely to make the report look complete.
Report title: Enter the product, release, and candidate. Report ID and revision: Enter a unique reference and revision. Prepared by: Enter the author and role. Evidence cutoff: Enter date, time, and time zone. Review meeting or decision deadline: Enter the agreed review point.
Release context:
Counting unit: State whether a row represents a unique case, a case-environment pair, or an app-specific execution object. Qualifying result rule: Define the candidate, environment, cutoff, and method for selecting the reported outcome. Status mapping: Explain how the source system's statuses map to the report without silently discarding unsupported states.
Report Entry | Value and Evidence to Supply |
|---|---|
Selected baseline | Total selected units, selection revision, and case-list reference |
Latest qualifying outcomes | Pass, Fail, Blocked, Not Run, and any additional applicable states |
Completed verdicts | Count with a qualifying Pass or Fail under this report's convention |
Pass rate among completed verdicts | Pass divided by Pass plus Fail; show numerator and denominator |
Passed share of selected scope | Pass divided by selected units; keep separate from the completed-verdict rate |
Attempts and retests | Attempt count, retry selection rule, earlier failure references, and retest evidence |
Evidence gaps | Missing logs, unavailable results, mismatched builds, or incomplete environment coverage |
For every source, record its system, product/edition where applicable, report or query name, run identifiers, retrieval time, included filters, and retained snapshot or export reference. Identify who reconciled the totals. Where a required result lacks usable evidence, mark the limitation instead of treating the absence as a pass.
Defect summary: Enter deduplicated defect totals by the team's severity definitions and current treatment. Distinguish all defects found during the effort from defects still unresolved at the cutoff. Do not equate failed-test counts with defect counts.
Repeat the following risk record for each material exposure:
Include risks caused by missing testing as well as known defects. An unavailable dependency can leave a serious behavior unassessed without producing a confirmed product bug.
For each criterion, record its ID, original condition, observed evidence, and one of Met, Unmet, or Waived. These are proposed report labels, not universal Jira statuses. Use Waived only when an authorized person has made a documented exception under the team's process. A requested exception remains Unmet with waiver pending.
Recommendation: Enter Proceed, Proceed With Conditions, or Hold, and explain the evidence behind it. List required fixes, retests, missing evidence, or containment checks. Name the owner and due point for each condition. If evidence is insufficient to recommend proceeding, say so directly.
Decision record: Enter the actual decision, decision-maker's name and organizational authority, timestamp, accepted residual risks, conditions, and reference to the recorded decision. If the meeting has not occurred, write Decision Pending. Separate the QA evidence review from the business or release authorization. Add sign-off entries only for people who actually reviewed or decided, identifying what each entry covers.
Agree on the counting policy before interpreting a pass percentage. The template uses completed verdicts to mean Pass plus Fail. Blocked and Not Run remain visible in the selected scope but do not enter that denominator. This is an explicit reporting convention, not a promise that every app uses the same definition of Executed or Completion.
Report both the pass rate among completed verdicts and the passed share of selected scope. The first describes the completed verdicts; the second shows how much selected work has affirmative passing evidence. Neither establishes requirements coverage, code coverage, or release readiness. If there are no completed verdicts, report the rate as not applicable rather than inventing a percentage.
Map In Progress, Aborted, Inconclusive, or custom statuses explicitly if the source uses them. Do not force an inconclusive result into Pass or remove it from the selected total. If a blocked test has no execution attempt in the source system, document that too. Status and attempt count answer different questions.
Retesting must preserve the earlier outcome. A useful policy selects the latest qualifying result for each reporting unit on the assessed candidate before the cutoff, while retaining previous attempts and their evidence. Do not use a later pass from another environment or a newer build to replace an unresolved result on the candidate under review. Changed test expectations also need an identifiable specification and review, not a silent rewrite of an old failure.
When several environments are required, decide whether the denominator is unique cases or case-environment pairs. One case passing in two browsers can represent two required execution units, but it is still one reusable case. Keep those counts separate and avoid adding cycle totals that contain the same selected units twice.
The following release, identifiers, people, results, and commitments are fictional. They illustrate the template; no Jira project or test system was used to produce these outcomes.
The fictional scope is Checkout 4.2, candidate build checkout-4.2-rc2, tested in staging-eu with the refund-retry flag enabled. The evidence cutoff is 18 October 2026 at 16:00 UTC. Baseline REF-B7 selects 40 unique cases for this single target environment. Runs REF-R101 and REF-R102 partition those cases without overlap; later attempts remain attached to their original case. Captured scope list SCOPE-42 and evidence index EV-42 identify the inputs.
At the cutoff, the latest qualifying outcomes are 32 Pass, 3 Fail, 2 Blocked, and 3 Not Run. Those categories reconcile to 40 selected cases. In this example, both blocked cases have recorded attempts, so 37 cases have at least one attempt. Five additional retry attempts produce 42 attempts in total. Retrying does not increase the selected-case denominator.
There are 35 completed Pass/Fail verdicts. Completion under that convention is 35 divided by 40, or 87.5%. The pass rate among completed verdicts is 32 divided by 35, or 91.4% rounded to one decimal place. The passed share of selected scope is 32 divided by 40, or 80%. Reporting only 91.4% would leave the blocked and untested work outside the reader's immediate view.
Three distinct unresolved defects remain: one High, one Medium, and one Low under this fictional team's impact rubric. They are counted by defect identity, not by failed checks. The High defect, CHK-81, permits a duplicate refund after a timeout; the three failed cases collectively link to these three defects, without assuming a universal one-test-to-one-defect relationship.
Maya, the fictional engineering owner, must investigate CHK-81 and provide a corrected candidate. Leo, the fictional QA owner, will rerun the reproducer and selected adjacent checks once that build is available. The blocked checks depend on a payment-sandbox callback; Nia owns restoring that dependency and obtaining evidence. Three selected accessibility checks were not run before the cutoff and remain a disclosed coverage gap.
Agreed Exit Criterion | Evidence at Cutoff | Assessment and Next Action |
|---|---|---|
Scope and baseline are identifiable | SCOPE-42, REF-B7, REF-R101, and REF-R102 reconcile to 40 cases | Met; Leo retains the evidence index |
No unresolved High refund defect | CHK-81 remains open on rc2 | Unmet; Maya supplies a corrected candidate, then Leo verifies |
Every selected case has a completed verdict | 35 of 40 have Pass/Fail verdicts; 2 Blocked and 3 Not Run remain | Unmet; Nia restores the dependency and Leo completes the missing checks |
Low defect may remain only with documented acceptance | Exception requested for CHK-83; no acceptance recorded | Unmet, waiver pending; Priya reviews the request under her fictional release authority |
The QA recommendation is Hold because the refund defect breaches an agreed condition and selected testing remains incomplete. Priya is the fictional release decision-maker, but the decision record is Pending; the example does not invent her approval. The next review is proposed for 19 October at 10:00 UTC, contingent on a corrected candidate and the missing evidence. If either is unavailable, the owners must report that limitation rather than mark the conditions complete.
Use the template as a reconciliation task before presenting it for a decision:
Choose the evidence source deliberately. Native Jira Cloud gadgets summarize work-item data, and its search exports can retain fields such as status, priority, and descriptions. Those records do not automatically contain the complete test-execution evidence held by an app. Tymola's Jira Cloud test-summary template names Smart Export to Word, PDF & Excel as its export app; that PDF workflow should not be presented as native Jira reporting. Likewise, the current Zephyr Cloud report table lists Excel for Test execution results (summary). Verify the exact installed product, hosting context, report, and supported format rather than borrowing another tool's export claim.
Where the team uses Sherlock Test Management, its current product description provides a relevant set of inputs: reviewed versioned baselines, release-specific runs, recorded Pass/Fail/Blocked outcomes, linked Jira defects, and release reports. Use the actual baseline and run references to populate the template, then check the counts and missing evidence against your report's definitions. The product description does not replace the human residual-risk assessment or establish that a release has been authorized.
Before the release meeting, ask a reviewer to follow one failed or missing test from the summary back to its scope, candidate, evidence, risk owner, and next action. If that path breaks, repair the record or disclose the gap before asking anyone to rely on the recommendation.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
