Recommended resources
The freely available resources this lesson will direct you to.
Hello. Last lesson, you made cross-project work traceable with issue links and release versions. The same discipline applies to QA: a release manager needs to know not just that a story is Done or that a bug is open, but which requirement was checked, what happened when it was checked, and whether a defect still affects the release.
This lesson designs that workflow for both an older Jira Server installation and current Jira Cloud. It starts with a process you can maintain using ordinary Jira issues and links, then shows what a test-management app can add. You do not need administrator access—or an app installation—to follow the design.
Start with the evidence you want to retrieve
Suppose a story, WEB-42, requires a customer to be able to reset a password. Its acceptance criteria say that a valid reset link allows a new password and an expired link does not. A useful release review should be able to retrieve four distinct things:
- Requirement:
WEB-42and the acceptance criterion being checked. - Test case: the planned check, including its expected result.
- Execution: the result of running that case on a particular build and environment.
- Defect: a Jira Bug, if a confirmed product problem needs investigation and a fix.
These are not interchangeable. Linking a test case to WEB-42 establishes planned coverage; it does not show that anyone ran the test. A passing execution shows what happened under its recorded conditions; it does not prove the feature will pass in every environment. A failed execution is an observation, while a Bug is a work item the team can triage, assign, fix, and verify.
Read the “Introduction” in Xray’s Requirements and Defects to see how one test-management app defines the requirement and defect ends of this record.
Xray’s documentation explains the associations it uses between requirements, tests, and defects. Read it for the relationship design, not as a list of link types you should expect in every Jira installation.
In “Introduction,” begin with the paragraph describing a requirement and continue through the explanation that organizations can map these concepts to different issue types: core definitions. Still in “Introduction,” read from the paragraph beginning “Requirements and Defect issues can be associated” through the explanation of the “tests” and “tested by” link descriptions: link relationships. Focus on what each association means. Those particular link names are configured by Xray; they are not standard Jira issue types or links.
For WEB-42, two test cases might check valid and expired links separately. One test can also cover more than one requirement, and one confirmed defect can affect several cases. Do not force these relationships into a single parent–child chain. Keep the story as the source of the requirement, record the relevant test associations, and make the Bug’s impact navigable from the affected story and test evidence.
Preserve the result of each run
A test case describes an intended check: preconditions, actions or test data, and expected behavior. An execution record describes one attempt to perform it. To interpret a result later, record the case and requirement keys, outcome, date, tester, build or revision, environment, and any evidence needed to reproduce an unexpected result. Keep the release or test cycle identifiable too. The exact fields depend on your Jira configuration and any installed app.
Consider the expired-link case. It passes in one build, but fails in the next because the link still permits a password change. Both outcomes matter. Replacing the earlier result with “Fail” loses the history; retaining only “Pass” conceals a current release risk. A later successful retest should likewise be a new result tied to the fixed build, not an unexplained change to the original failure.
Watch the execution portion of “Jira Xray Tutorial #10 - How to Execute Test Cases in Jira Xray” by Software Testing Mentor. The interface is app-specific, but the distinction between a test, its run, evidence, and a defect is broadly useful.
Jira Xray Tutorial #10 - How to Execute Test Cases in Jira Xray
Watch an Xray test execution move from a finding to a recorded result, then see how a step-based test records more precise evidence.
Watch finding and failure for the findings area, attached evidence, creation or association of a Bug, and the failed run status. Then watch step results to see how preconditions, individual steps, comments, and evidence help locate a failure. Focus on which information belongs to the run rather than to the reusable test case.
A run can also be blocked because the environment is unavailable, or remain unexecuted. Neither should be counted as a pass. This matters when a release dashboard compresses several outcomes into a single “tests complete” figure.
Turn a failure into a controlled defect
A failed check deserves investigation, but not every failure is immediately a product Bug. The test data might be wrong, the environment might be unavailable, or the result might expose an ambiguous requirement. If investigation confirms that the product behaves incorrectly, create or associate a Bug rather than leaving the problem solely in a test-run note. That gives the team a work item with an owner and a triage decision.
Xray’s Reporting and Tracking Defects makes this distinction explicit and explains why a Bug with no connection to its testing context leaves a traceability gap.
Reporting and Tracking Defects
This Xray Cloud guide distinguishes test failures from defects and shows what context a defect reported during execution can retain. Its screens and automatic associations depend on Xray Cloud; use the reasoning even if your Jira Server instance has no test-management app.
Under “Concepts,” read “Could We Simply Report Test Failures?” from the explanation of a failed run to why a reported defect complements it: failure versus defect. Under “Defect Reporting,” read “Where Basic Defect Reporting Falls Short,” starting at the traceability concern and ending with escaped defects: missing context. Finally, under “Defects in Xray,” read “Finding Defects” and the opening of “Reporting Defects Using Xray,” from the two discovery scenarios through the explanation of the test and execution context: execution context. Notice that a production-reported defect may have no existing test run.
For the failed expired-link check, a useful Bug states the expected and actual behavior, steps and data needed to reproduce it, affected build and environment, impact or severity, and relevant evidence. Link it to WEB-42 and to the test or failed run where your tools permit. Set the Fix Version/s to the release in which the fix is planned; use Affects Version/s to identify affected released versions or builds if that field and the team’s convention support it. Do not treat the planned fix version as evidence that the fix has shipped.
A workable defect workflow is:
- Report and triage: decide whether the finding is a confirmed defect, a duplicate, a test problem, or an accepted behavior. Preserve the failed result and record the decision.
- Prioritize and fix: give a confirmed Bug an owner and release decision. If it cannot be fixed for the target release, document the accepted risk or move its planned fix to the appropriate version rather than letting it disappear from review.
- Verify: run the relevant case again against the fixed build. Record a new result and its environment; add focused regression checks if the change could affect nearby behavior.
- Close or reopen: close the Bug according to the team’s workflow only when its verification and disposition are clear. Reopen it if the expected behavior still fails.
For a production-reported Bug, there may be no failed run to link. Associate it with the affected story or requirement if one exists, record where it was discovered, and add a regression test when the behavior has been clarified. This keeps escaped defects visible without inventing a prior test execution.
Implement it with the access and tools you have
Without a test-management app, Jira can still hold a defensible traceability record. Keep acceptance criteria on the story. Store test cases in an agreed, accessible place—such as permitted Jira test issues or an external case repository—and record their stable identifiers on or alongside the story. Use a Jira Bug for confirmed defects, link it to the affected story with an available relationship such as “relates to,” and include the case identifier and execution evidence in the Bug or a linked record. If you can create a separate test issue, link that too. Use consistent names and check that both directions are easy to navigate.
This baseline needs deliberate maintenance. Standard Jira does not automatically provide test runs, coverage reports, or a requirement-to-defect matrix. Nor should you assume Xray’s “tests” link type exists on your older Server instance. If you cannot create a needed issue type, link, or shared convention, agree the recording approach with a project administrator rather than presenting an improvised label as complete coverage.
With an installed test-management app, use its native case, execution, and traceability features where available. Xray’s run-based defect reporting can retain the test and execution context; its direct issue links and settings still need to be checked in the actual installation. Other apps implement similar goals differently. The matrix below illustrates the kind of management view an app and reporting layer can assemble—it is not a standard Jira report.
Read a row across rather than judging it by one green cell. A requirement with a linked test but no executions has planned coverage, not verified coverage. A row showing both passes and failures can reflect multiple executions; inspect which build, environment, and time produced the relevant result. Even a requirement marked Done can have unresolved defects. Also note that the pictured columns say Zephyr Squad: do not assume this exact report or its fields will appear in Zephyr Scale, Xray, or an unmodified Jira project.
For your manager-level release review, maintain a small view or register with columns for requirement, associated cases, latest relevant run and context, open defects, and release decision. Existing saved Jira filters can supply the Bug portion—for example, a filter for open Bugs planned for the release—but ordinary JQL should not be assumed to traverse every test and link automatically. Reconcile the filter with case and execution records before reporting coverage. Check with the relevant owner before placing sensitive logs or account data in attachments or comments, particularly if a service project offers customer-visible comments.
Conclusion
A traceable testing workflow keeps requirements, reusable test cases, individual executions, and defects distinct, while preserving the associations between them. Report failures with their build and environment, triage confirmed problems as Bugs, and verify fixes with new run evidence. In older Jira Server, a consistent linked-record convention is a viable baseline; where a compatible test-management app is installed, its execution and coverage views can reduce manual reconciliation.
This completes the first module’s project-control foundation. The next module moves into advanced JQL, reporting, and process governance—tools you can use to inspect and improve the workflows you have now designed.