You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Whenever talking about versioning, different things may come to the surface that may be somehow related.

To what versioning are you referring to exactly? Requirements versioning, test versioning?

Are you talking about tracking changes on your artifacts or on having explicit versions each time you change an artifact?

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, so you know who changed what and when.


So, if you have a requirement (e.g. a story) for version 1.0 and you wish to change it somehow in another posterior version (e.g. v2.0), normally you will have to create another requirement issue to specify the new behaviour.

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 a issue, it gets tracked in the History changes; however, there is no increment in the version (not in any other field) of the requirement because it is used for another purpose: to tell for which version you're delivering it. 

How does Xray handle "versioning" of Test cases

Versioning of Tests work in the same way as 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.


In other words, this means:

  • if you wa


Xray support this feature in this way, which we think is way more advanced:

  • whenever you schedule a Test for execution in a Test Execution, Xray creates an instance of the Test that we call Test Run; that Test Run contains the "version" of the Test specification at that moment.
  • you can go to an already recorded Test Run and reset the specification to the last/actual specification on the Test issue... or you can even merge it; the later means that only changed steps will be updated and other step results are not changed 
  • normaly you work with the "last version" of the Test (as you do for a user story, etc); however, if you really want to manage different versions of Tests at same time, you can create different Tests, one per "version"
  • No labels