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: * Remove the previous Fix Versions and add the new Fix Versions * Leave the previous Fix Versions and add the new Fix Versions Example scenario below: * QA Team identify a bug in version 'A'* Affected Versions is set to 'A' * Developer reviews and fixes the bug* Fix Versions set to 'B' * QA Team retest the bug in version B and it is not fixed* Affected Versions is set to 'B' (so now contains both 'A' and 'B') * Developer reviews and fixes the bug * Fix Versions set to ????

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Correct Process Of Using Fix Versions

Graeme Fidler

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:

Remove the previous Fix Versions and add the new Fix Versions
Leave the previous Fix Versions and add the new Fix Versions

Example scenario below:

QA Team identify a bug in version 'A'
1. Affected Versions is set to 'A'
Developer reviews and fixes the bug
1. Fix Versions set to 'B'
QA Team retest the bug in version B and it is not fixed
1. Affected Versions is set to 'B' (so now contains both 'A' and 'B')
Developer reviews and fixes the bug

Fix Versions set to ????

Accepted answers

All comments

Phill Fox

I would support the following scenario (based on yours) assuming the version has been released.

QA Team identify a bug in version 'A'
1. Affected Versions is set to 'A'
Developer reviews and fixes the bug
1. Fix Versions set to 'B'
QA Team retest the bug in version B and it is not fixed
1. Affected Versions is updated to include 'B' (so now contains both 'A' and 'B')
2. Fix Version is removed
3. QA team provide details as to why the bug is not fixed including if possible a long-term test that can confirm the correct operation.
Developer now starts work on next version (C)
Go back to step 2 and repeat using the next set of versions....

If not released then I would go with

QA Team identify a bug in version 'A'
1. Affected Versions is set to 'A'
Developer reviews and fixes the bug
1. Fix Versions set to 'B'
QA Team retest the bug in version B and it is not fixed
1. Fix Version is removed
2. QA team provide details as to why the bug is not fixed including if possible a long-term test that can confirm the correct operation.
Go back to step 2 and repeat until QA approve fix.

(Thanks to @Jeremy Gaudet for making me think further about the scenario)

Jeremy Gaudet

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.

Phill Fox

Amended my response in the light of your comments. Thanks for making me think more.

Sten Sundelin

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 ), 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:

If time permitted, the bug/story would be rejected by QA, go back to developer and FV was unchanged.
If there was no time (or release already out the door), QA would file a new defect with a link to the prior one for reference.

We would not remove the fixversion from the 'unfixed' bug in either case.

Vera Henrichs

And how about this?

https://jira.atlassian.com/browse/JRA-59992

Please vote for it, thanks!

Stefan_oyk0wp

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.

unknown

@Phill Fox @Jeremy Gaudet Hi , may i know the consequences of the below: -

to leave the previous Fix Versions and add the new Fix Versions?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration