My understanding is that the Fix Versions field is used as a way for developers to say 'the version that the bug will be/has been fixed in'.
My question is if when a bug is retested and it has not been fixed in the version that the developers have set for the 'Fix Versions', what should you do?
When the developers relook and fix the bug should they:
Example scenario below:
I would support the following scenario (based on yours) assuming the version has been released.
If not released then I would go with
(Thanks to @Jeremy Gaudet for making me think further about the scenario)
According to my language skills a "Fix version(s)" label tells which version shall have the fix. This is for release planning.
However, what I rather would like to see is a field "Fixed version(s)". Then it is clear, what it means.
Also, I would rather like to have a field "Affected version(s)" rather than "Affects version(s)".
I'm not native English so I wonder if my understanding of language is wrong here.
From a process perspective, it depends on whether or not the "Fix Version" has been released. If not, then just re-open the bug and fix it, or not as time permits. If it has, and the bug has already been published as being fixed in release notes, I'd file a new bug to cover the lack of functionality, otherwise it gets confusing. There also may be subtle changes in the behaviour from the original bug to the 'new' bug that would need to be captured.
As far as Affected Version/s goes, it's entirely correct to say Affected Version is A,B, and Fix Version is B; however, my preference there is to say that the Affected Version is a ".x" branch. Say A is 1.2 and B is 1.3, but the bug really affects all of 1.x, then Affected Version = 1.x and Fix Version = 1.3 makes it clear that 1.0, 1.1 and 1.2 are impacted only.
Also, "Fix Version", for an open issue, represents where you intend to fix it, and so it should not be removed, it should either remain B (if it will be fixed there before B is released), or updated to C, etc. Clearing the field implies there is no current fix plan for the issue.
A lot of this depends on if you use Fixversion to only reflect where the bug was actually fixed or where it is planned to be fixed and if the release made it out the door or not.
We use the FV for release planning, so we set it before the bug is actually fixed (or attempted).
Since we're agile/Scrum (or working to get there :o), QA is performed inside the sprint and the scenario does not really apply, but we were recently more waterfallish and it would work like this:
We would not remove the fixversion from the 'unfixed' bug in either case.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG