(Jira Cloud implementation)
I may have a different understanding to releases as everyone else, but I would expect to list releases within Jira > Development > Releases, and to use the Version 'name' as a reference within my xray test issue types.
eg I may add the following Versions
24.12.1
24.12.2
25.1.1
25.2.1
I may then have a Test Execution containing tests that validate features of Release v24.12.2. These may result in defects. Analysis of defects may propose a resolution in future Release v25.2.1.
I would expect to create a Test Execution with a Release attribute assigned as 24.12.2
I would expect to create a Test Defect which allows me to assign Fix in Version (proposed) to 25.2.1
Currently, if I create an xray Test Execution, Releases has the ability to Add Feature Flags, but does not simply have 'Release', or 'Current Release'.
Is it the case that xray Jira has the mindset/methodology that Test Executions only test releases that have been 'fixed', and so the current release is 'Fix versions'?
To me, the terminology makes little sense, and is therefore unclear as to its meaning.
Also, it allows a single Execution to contain tests to validate features from multiple releases, meaning you have to individually assign a version to each test run. I guess that is a flexible approach, but I wouldn't use it.
Noting test Defects allow a 'Release version' to be selected as Fixed in Release, which makes perfect sense to me >>> once Released, I would then create a new Test Execution, with tests to validate the failed, and new, feature(s) of that release.
If my understanding of Releases is correct, surely it would make sense for it to be called Feature Flags, and for Fix versions to be called Release(s)? In that way, I could test different features that have been flagged using third party tools, for 'a' release under test.
NB Given that I can see a list of my Release versions when I select Fix versions, I may be answering my own question, but Fix versions means absolutely nothing to me, so I am just asking for confirmation how it is perceived to be used.
(my organisation does not develop, but implements vendor provided solutions. We therefore do integration/acceptance testing, which shouldn't necessarily result in defects. The solutions are not expected to be fixing anything, only providing a service ...of course, that isn't generally the case)
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.