Before a release, review both requirement coverage and execution results. First check whether the release’s Jira work items have suitable Test Cases. Then check whether the planned testing is complete and whether failures still need attention.
A requirement with linked cases is not necessarily fully tested. A completed test can also be Failed or N/A, so completion alone is not a pass decision.
Choose the report for the question
Question | Use |
Which release work items have no matching Test Cases? | Requirements Traceability Summary, with the work item totals and details. Start without additional testing filters. |
Which cases cover each requirement, and what execution supports the result? | Requirements Traceability Matrix. |
Is the release’s planned testing finished? | The selected Test Plan iteration’s Insights and Test Summary Report. |
How are several plans progressing? | Test Plan Traceability Summary. Check which iteration each report uses. |
For setup instructions, see Work Item Traceability Summary, Requirements Traceability Matrix, and Test Plan Reports.
Before you begin
Use a Jira dashboard you can edit and an account with access to the relevant Jira spaces, work items, and Vansah testing information.
Agree which requirements belong to the release. Use a reviewed Jira saved filter, a work item list, or JQL to select them.
Decide whether child work items and Jira-linked work items belong in the review. These options can expand the report beyond the items you selected directly.
1. Confirm the release requirements
Configure the traceability gadget and select the appropriate Jira spaces.
Under Work Item(s) selection, choose List, Filter, or JQL and supply your release’s selection. For example, a small review could use DEMO-123 and DEMO-124.
Review Include Child Work items and Include Linked Work items. Include them only when they belong to the testing scope.
Start without extra Test Case or Test Run filters. Select Save and confirm that the expected requirements appear.
Keep the two release selections separate: a Jira filter selects which work items belong to the release. A Vansah Releases testing filter narrows execution data by the selected Test Run property. Selecting that property does not define the release’s requirement list.
2. Find missing or unsuitable coverage
In the summary, inspect the work item total and its details for items without matching Test Cases. In the matrix, look for requirements with an empty test area.
Open each apparent gap and check whether suitable Test Cases are actually linked. If you previously added filters, clear them before concluding that the requirement has no tests.
Review the linked scripts against the requirement’s acceptance criteria. A link confirms a relationship; it does not prove that every important scenario has been checked.
Link an appropriate existing Test Case or create a missing one, then refresh the report. Review the version linked to the requirement.
Follow Link Test Cases to a Jira Work Item when you need to add coverage.
3. Review execution in the intended scope
In the matrix, open the relevant cases and execution details. Confirm the requirement, Test Case version, test conditions, and date behind the result.
If reviewing a particular environment or release execution, apply the supported testing filters and check the saved values. Keep the unfiltered coverage review separate so you can still see gaps.
In the summary configuration, review Report by Latest/Last result. Enabling it can use a case’s latest result from another testing context in the selected Jira spaces.
For a release Test Plan, open Insights and select the intended iteration. Review completion, outstanding work, failures, and blocked tests together.
Test Case filters can remove cases from the report. Run filters change the executions considered, and a tested-date filter can exclude cases without a matching execution. An empty filtered result is not proof that no Test Case is linked.
If summary and matrix results differ, compare their settings and open the underlying Test Runs before using the result in a release decision. Do not assume the two views select an identical execution.
4. Turn findings into follow-up work
Finding | Follow-up |
No suitable linked Test Cases | Add or link coverage for the acceptance criteria and important failure scenarios. |
Linked cases are Untested | Assign and execute them in the intended testing context. |
Testing is In Progress | Review unfinished steps and complete the execution. |
A case is blocked | Resolve or explain the blocker and identify who will follow it up. |
A completed case failed | Review its logs and linked work items, investigate the problem, and record a separate retest after a fix. |
A case is marked N/A | Confirm that it is appropriate to exclude that check from this release’s testing decision. |
For example, DEMO-123 might have one completed Passed case and one Untested case, while DEMO-124 has no linked cases. The first requirement needs execution follow-up; the second needs coverage review. A pass result on the first case does not resolve either gap.
See Retest Failed Test Cases and Preserve Earlier Results for recording follow-up executions.
5. Share the review with its context
Confirm the report’s requirement selection, child and linked work item options, testing filters, and plan iteration. Clear any temporary table search before exporting the complete intended view.
Export the relevant report from its options menu using XLSX or HTML, where available.
Share the scope, testing context, outstanding gaps, unresolved failures, and agreed follow-up owners with the release team.
Use your team’s release criteria to decide whether the evidence is sufficient. Traceability and completion figures support that review; they do not automatically approve a release or measure application code coverage.