When talking about versioning, different things may come to the surface that may somehow be related.
Is it requirements versioning? Test versioning? Are you talking about tracking changes to your artifacts or having explicit versions each time you change an artifact?
Let's see first how Jira handles changes and versions in general.
How Jira handles versioning
As preliminary information, Jira issues are assigned to a given version by specifying the "Fix Version" field.
Besides this, Jira ensures that changes are tracked under the History section available in the corresponding issue screen, so you know who changed what and when.
If you have a requirement (e.g., a story) for version 1.0 and you want to change it somehow in a future version (e.g., v2.0), normally, you will have to create another requirement issue to specify the new behavior.
However, if you are changing the specification during the development lifecycle of that requirement, you can simply update its description and use Jira workflows to guarantee that is being handled properly.
If you make changes in some of the attributes of an issue, it gets tracked in the History changes; however, the version is not incremented because it is used for another purpose: to tell for which version you're delivering it.
How does Xray handle "versioning" of Test cases
Test case versioning is only available in Xray Enterprise.
We can handle the versioning of Tests in the same way as the versioning of other issue types in Jira. Since Xray's Tests are Jira issues, we follow the same approach so your users work in the same manner they already do.
However, even though you can see all the changes of a Test case using the Jira History tab, it is not easy to revert or view a previous Test version easily unless you create a new Test issue for each version. This is also not ideal as you end up with multiple issues for the same entity.
Another downside of using Jira versions to manage Test versions is related with the lifecycle of a Test. Jira versions are created at the project level. Hence, all issues within the project are affected by the same version numbers.
Test cases can have a different lifecycle than other issues in the same project, such as requirements or bugs. For instance, we can have multiple versions of a Test case for the same project version (e.g., the test has evolved with the changes in the requirement; they have different types).
This is why Xray has introduced a new way of versioning Tests in v7.0. Starting from this version, it is possible to create new versions within the same Test issue. You can revert back to a specific version and view all versions of a Test case easily.
However, this doesn't mean that you can't use Jira versions. In fact, you can use both. Although your tests may live across many versions of your project, they're made in the context of some version, most probably for the version of the requirement they aim to validate. Thus, assigning them to a Fix Version serves the purpose of tracking the specification+implementation of the test case, the first time they have been used. This way, you can also track it in the Release as one artifact that needs to be "done" (i.e., specified/reviewed/approved).
It is still important to note that Xray makes a copy of the Test specification whenever you schedule a Test for execution in a Test Execution.
- A Test Run effectively contains the Test specification of the Test version chosen when the Test Run was created (at that moment).
- You can go to an already recorded Test Run and reset the specification to the current specification on the Test version which originated the Test Run. Or, you can merge it, which means that only changed steps will be updated and the other step results are not changed. More info can be found on the Execute Tests page.
By persisting the Test specification on the Test Runs, Xray ensures data consistency. The "version" of the Test that was executed in a Test Run, is persisted in the Test Run itself. That means that if you change a Test specification today, that won't affect your already recorded runs for that Test (unless you want to).
Please have a look at Test Runs for more information on the fields that are persisted at the Test Run level.