--- title: "Tips for Implementing Test Versioning" canonical: "https://docs.getxray.app/space/XRAYCLOUD/44565095/Tips%20for%20Implementing%20Test%20Versioning" format: markdown --- > Macro (rw-ui-expands-macro) > > > Macro (rw-expand) > > > Macro (toc) # Introduction 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, and how that approach is feasible also for managing versions of Tests, at least up to some level. Then we'll see how [Xray Enterprise](https://www.getxray.app/xray-enterprise) enables proper Test Case Versioning, allowing users to manage multiple versions at the same time for each one of your Tests. # How Jira Handles Versioning in General When we talk about versions in Jira, we're usually referring to Space releases. Jira issues are assigned to a given Space version by specifying the "Fix Versions" field. Additionally, the "Affects version" can be used to identify that a given issue impacts the mentioned Space version/release. At each Work Item level, Jira ensures that changes are tracked under the History section available in the corresponding Work Item screen, so you know who changed what and when. Even though changes are tracked for history and auditing purposes, there is no version management at the Work Item level, where users would be able to manage multiple versions of the Work Item content, including all its fields. So, how do teams deal with this need whenever they want to have multiple versions of the same Work Item? Usually, these versions are tied to a new iteration, a new enhancement. As an example, if you have a Requirement (e.g., a story) for version v1.0 and you want to change it somehow in a future version (e.g., v2.0), normally, you will have to create another Requirement Work Item to specify the new behavior. This will lead to the creation of additional Work Items. 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 ensure it is handled properly. If you make changes in some of the attributes of a Work Item, 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. # Test Versioning with Xray Standard Xray can handle the versioning of Tests in the same way as Jira handles the versioning of other Work Item types. Since Xray's Tests are Jira issues, Xray Standard allows the same approach, so your users work the same way 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 Work Item for each version. This is also not ideal, as you end up with multiple Work Items for the same entity, which complicates their management. Using the Jira way for addressing Test versioning, even though feasible and sufficient for most teams, has many limitations if you aim to have a thorough test versioning system in place.  ## Tip Avoid cloning Tests;  implementing Test versions by cloning Tests and changing their content will lead to many issues that will be hard to manage. ## Limitations - There is no way to create multiple versions, as such, for each Test (i.e., each one holding a specific copy of the Test specification details): - No way to revert to a previous "version" of a Test, as there is no notion of version. - No way to create different variants of a Test (e.g., a version with the manual test steps and another version with the [Gherkin](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565320) specification used by automation). - There is no way to manage the lifecycle of Tests independently of the Space lifecycle. Jira versions are created at the Space level. Hence, all Work Items within the Space are affected by the same version numbers. However, Test cases can have a different lifecycle than other Work Items in the same Space, such as Requirements or bugs. For instance, we can have multiple versions of a Test case for the same Space version (e.g., the Test has evolved with the changes in the Requirement; they have different types). > ℹ️ Although your Tests may live across many versions of your Space, 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). To overcome these limitations, Xray Enterprise introduced an explicit way of versioning Tests. # Test Versioning with Xray Enterprise With Test Case Versioning, available only for [Xray Enterprise](https://marketplace.atlassian.com/apps/1229688/xray-enterprise?hosting=cloud&tab=overview), it is now possible to create new versions within the same Test Work Item. You can revert back to a specific version and view all versions of a Test case easily. > ℹ️ Please check the [Test Case Versioning](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565571) page to see how to use this feature. ## Test Versions A Test Version is like a different branch or “variant” of a Test that has its own specification, Test type, and history. A Test Version is not like an incremental revision or “snapshot of the Test at a given moment”, even though users can create a new version of a Test using the latest contents of another version. ### Main Characteristics - A Test always has one default version; the default version is the one that is considered whenever adding a Test to a [Test Execution](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565117). - A Test Version has: - A “name” attribute, that acts as a description and is the common name for referring to the Test Version itself. - An internal attribute “version” (incremental); this is like a revision, useful if we wish to mention a specific change made within the Test Version. - Dataset, if any is associated with it. - Coverage information, i.e., the list of covered Requirements, is not part of the version; in other words, the link between the Test and Requirements is independent of the version; it’s like saying that “all versions cover” exactly the same Requirements. - A Test Version can be archived/unarchived. An archived Test version: - Cannot be added to a new Test Execution. - Can still be executed if it’s already part of a Test Execution. ## Possible Use Cases for Adopting Test Case Versioning ### Simultaneously Manage Multiple Variants of the Same Test A Requirement has a manual scripted Test, and we want to implement an automated variant of it, and we wish to have both at the same time and clearly track results independently. ### Simultaneously Manage Multiple Versions of the Same Test, with Different Content - A Requirement can have some slight differences, for example, localization-related; a different Test version can be created to have the specifics of those (e.g., for a different language). - A Requirement may be evolving while it’s being developed, and the Test needs to evolve also; different versions may be used as “milestones”, allowing the team to easily roll back or go to a specific “milestone” of that Requirement and Test. ## Test Versions and Other Entities ### Preconditions - [Preconditions](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565159) don’t have versions. - A Test in a given version can require some Precondition(s); another version of that Test may require different preconditions, if any. ### Test Sets The [Test Sets](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565163) only contain a list of Tests, and not a specific version of each Test. ### Test Plans - The Test Plans only contain a list of Tests, and not a specific version of each Test. - Versions are assigned to the Tests within the Test Execution whenever it is created from the Test Plan. ### Test Executions A Test Execution contains a specific version of each Test; the version is assigned at the moment each Test is added to the Test Execution; the default one is picked unless otherwise specified. ## Tips - Avoid cloning Tests; assess if Test Versions can be used to fulfil your needs. - Avoid having many versions of a Test, as it can complicate its management. - Don’t use Test Versions as a way to deal with different requirement versions; a different requirement version, usually in Jira, is handled as a separate Requirement Work Item, with its own specifics, its own development lifecycle, and its own Tests. - Test Versions provide the ability to manage multiple versions for each one of your Tests. This may be quite useful, but it also adds some complexity; therefore, we recommend discussing the usage of this feature with your teams. ## Limitations Test Case Versioning with Xray Enterprise provides real management capabilities for Test versions. However, there are some limitations (some by design and others that can be overcome in the future): - A specific Test Version cannot be linked to a “Requirement”; the coverage is always between the Test and the Requirement Work Items, and there are no additional variables considered. - You can’t select the versions to use for each Test, whenever creating Test Executions from within the Test Repository or from the Test Plan Board; it’s also not possible to do so from the Requirement Work Item screen. - Each Test can have a set of Test Versions, with user-defined names; there is no convention across different Tests, therefore a Test may name a version “v1” and another Test may name a version “myinitial-version-1”. - Even though changes are tracked individually, comparing versions overall (i.e., seeing the differences between different Test versions) is not yet possible. - Restoring to a specific “version in time” (i.e., like a snapshot) or to a specific change is not possible because the chosen approach for Test versions follows a different concept. - It’s not possible to say that version X of the system/Space uses a specific version of Test cases, as each Test version is part of each Test. # Test Runs and Test versions No matter the approach you're choosing for managing Test versions (the Jira/Xray Standard way or the Xray Enterprise way), 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](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565109) and reset the specification to the current specification on the Test version that originated the Test Run. Or, you can merge it, which means that only the changed steps will be updated, and the other step results are not changed. More info can be found on the [Execute Tests](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565122) page. By persisting the Test specification on the [Test Runs](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565109),  Xray ensures data consistency. The version of the Test 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). > ℹ️ Check [Test Runs](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44565109) for more information on the fields that are persisted at the Test Run level.
Support/Troubleshooting If you have questions or technical issues, please [contact the Support team via the Customer Portal (Jira service management)](https://jira.getxray.app/servicedesk/customer/portal/2/user/login?destination=portal%2F2%2Fcreate%2F28) or [send us a message using the in-app chat](https://getxraydocs.atlassian.net/wiki/spaces/XRAYCLOUD/pages/44577312).