A refund test passed on the previous release candidate. Since then, someone has changed its expected result to require a permission check before every retry. When a reviewer opens the old result beside today's case, which behavior does that pass establish?
The answer depends on what the test-management app retained. Jira issue history, a release version, an app-managed test version, and a run's copied specification answer different questions. Reliable test case versioning in Jira requires a recoverable connection between the approved content, the candidate tested, and the recorded outcome.
Start by identifying the record you need rather than looking for a field called Version. A team may need to explain an edit, select a specification for a supported release, or recover the exact instructions used in a failed execution. One identifier rarely answers all three questions.
Record | Question It Answers | Boundary to Check |
|---|---|---|
Jira issue history | What changed on this work item? | A sequence of changes is not automatically a selectable complete test specification |
Jira release version | Which delivery release is this work associated with? | Release association does not freeze test steps or expected outcomes |
App-managed case version | Which reusable specification or variant should be selected? | Included fields, editability and execution selection depend on the app |
Run specification and results | What instructions and outcomes belong to this execution? | A run may copy only selected fields and may permit deliberate updates |
Treat a case version and a run copy as separate references. A named version can remain editable, while a run retains an earlier copy of its supported fields. Conversely, a result linked to a version label is incomplete evidence if the content behind that label cannot be recovered.
In Jira Cloud, the Activity section includes History, which records updates such as field edits and workflow movement. It helps investigate when a work item changed. It does not, by itself, establish that a particular test specification was approved or that an older execution used the content now displayed.
Fix versions has another purpose. Atlassian's company-managed Jira Cloud documentation describes it as the version in which the work is released; setting it associates the work item with that release. Affects versions identifies product versions affected by an issue, such as a bug, and does not add that issue to the release.
For example, a defect might affect release 4.1 and be fixed in release 4.2. Neither value says which revision of a refund test was executed. Updating an expected outcome also does not increment a test-specification version through the Fix versions mechanism. Any separate test-version model must come from the team's controlled content process or the installed app.
A release association is also different from a deployed candidate. RC1 and RC2 can both belong to release 4.2 while containing different code. Retain an identifiable build or revision alongside the selected specification; a release name alone cannot distinguish the failed candidate from its corrected successor.
These are Jira Cloud semantics, not a universal screen recipe. Current Atlassian documentation may call projects spaces and issues work items. Confirm the deployment, project type and app before translating the model into local configuration.
Ask two questions before introducing labels such as v1 and v2: what content belongs to each version, and how does an execution select it? App documentation can use version to mean a maintained variant, a revision, or a copied execution definition. Those models have different retention limits.
Xray's current Cloud documentation distinguishes the history-based approach available with Standard from explicit Test Case Versioning described for Enterprise. The latter supports multiple versions within the same Test. A Test Version is a named branch or variant with its own specification, rather than an automatic snapshot of every edit at every timestamp.
The version model includes test specification fields, test type, dataset and precondition associations. It can support concurrently maintained variants, including different test types. Returning to a maintained version should not be confused with restoring any arbitrary earlier change: the Cloud tips explicitly says restoration to a particular point in time or individual change is not supported by this model.
Selection deserves a separate check. A Test has a default version, which Xray uses when a run is created without an explicitly specified version. Test Plans and Test Sets contain Test identities rather than a pinned version of every Test. Do not assume that adding a Test to a plan establishes the specification that a later execution will use. Inspect the actual selection when the execution is created, especially through a route that relies on the default.
Requirement links have a further limit. The Cloud tips says coverage connects the Test and requirement work items, not a particular Test Version and requirement. A coverage relationship therefore cannot independently prove that the chosen variant checks the current requirement. Record that review explicitly when behavior differs between variants.
Xray also persists a copy of the supported specification when the Test is scheduled in a Test Execution. Its Test Runs guide describes a run as an internal Xray entity, not a Jira issue. Subsequent edits to the reusable Test do not automatically replace an existing run's copy.
The copy is not the whole Jira issue. The guide explicitly excludes the Test's summary, description and general custom fields from replication. Manual steps and supported precondition content belong to the copied specification. Put execution-critical instructions in supported fields, and retain controlled references for additional context that the copy excludes.
Preservation is conditional, not immutable. Xray documents merging a current specification into a run and resetting a run by copying the current specification while discarding recorded results. Its versioning feature guide also warns that deleting a Test Version deletes the runs executed for that version. Access controls and retention procedures must address those operations separately from ordinary case editing.
QMetry Test Management for Jira Cloud provides an independent example of an app-managed version model. Its documentation describes maintaining different case versions at the same time, viewing version-wise details, and comparing versions for audit purposes. The latest version is displayed by default on the case detail page, and versions can be edited or deleted.
That display default does not tell you which version is linked to an existing cycle. QMetry's execution guide describes an indicator for a newer version and an operation to sync the linked case to it. Review the linked version instead of assuming that today's case detail view represents yesterday's execution.
The documented Sync Latest Test Case Version operation has significant consequences. It cannot be reverted and resets case and step statuses to Not Run across current and previous executions in that test cycle. Previously linked defects are not carried forward and are unlinked from older executions. Actual time, actual outcome, comments, attachments and other custom execution-field values are erased.
Treat that warning as a retention decision, not routine housekeeping. Before authorizing the operation, identify the affected executions and preserve the evidence your process requires. The warning concerns this specific QMetry Jira Cloud operation; it is not a claim that all case edits, all sync actions, or other vendors behave identically.
Consider a fictional manual case, REF-12. Its v1 specification checks that a finance user can initiate a refund and that an unauthorized user is rejected on initial submission. Run A records a pass for v1 on RC1 of release 4.2.
The requirement then changes: after a gateway timeout, the system must check authorization again before retrying the refund. The maintainer prepares v2 with a timeout setup, a change to the user's permissions, and an expected rejection before the retry proceeds. A reviewer approves that changed specification for a new execution on RC2.
Run A's pass does not establish the retry behavior in v2. The earlier case did not ask the tester to create that condition. Keep Run A associated with its original specification and candidate, and create Run B for the changed specification on RC2. These names and outcomes are illustrative, not a report of testing performed in Jira or either app.
In the documented Xray Cloud model, a v1 manual-step copy in Run A remains unchanged by an ordinary edit to the reusable Test. The new retry step belongs in the supported specification used for Run B. If the authorization rule had existed only in Jira Description or a general custom field, the run copy would not preserve that text. Retain a controlled requirement reference or other recoverable context instead of assuming an old result screen freezes it.
For the same reason, a maintained version name is insufficient on its own. If someone edits v1 after Run A, the run's copied specification may be the better evidence of what was executed. Check the copied content, not merely whether both screens show v1.
In QMetry Jira Cloud, applying the documented latest-version sync to an old cycle could reset historical statuses and erase associated execution detail. Do not use that operation to make an earlier pass appear current. Plan a distinct new execution record for the changed candidate, verify its linked version, and preserve the old evidence before any authorized maintenance of the earlier cycle.
A release-to-specification contract is a recommended team record, not a native Jira feature. It states which reviewed content each execution is meant to use and how another person can recover it. Use the app's documented model where it supplies the necessary references; retain controlled supporting content where it does not.
A changed expected outcome needs a content-specific review decision. Keeping the same case key or an Approved status does not make the earlier approval apply to the new behavior. The guidance on test case approval and re-review develops reviewer responsibilities and change-control decisions when the versioning mechanism alone is insufficient.
Sherlock Test Management offers a relevant baseline-and-run model. Its current product description says each approval creates a baseline version and finished runs stay attached to the version they executed. It also describes proposed release scope based on Jira Fix Version for human review. For the refund change, the team could review the new expected behavior separately from the earlier run's executed baseline. The Sherlock baseline and release-run workflow describes that separation; it does not establish immutable storage, complete field-level snapshots, or integration with Xray or QMetry.
Before relying on a versioning policy, have the QA lead and app administrator validate it in an authorized safe context. Use a disposable case and execution, not a production record required for an audit. The following are proposed checks, not actions performed here:
Check archive behavior separately. Xray's current Cloud tips says an archived version already in an execution can still be executed, while its versioning feature guide says archived versions cannot be executed. That documentation discrepancy requires tenant-specific verification; do not build a retention or execution rule around an assumed interpretation.
Choose one old failed test and ask a teammate to recover its executed specification, build, expected outcome, actual outcome and subsequent retest without relying on memory. If the result leads only to today's editable case, repair that connection before using historical passes to support the next release decision.
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.
