Correct Process Of Using Fix Versions

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:

  1. Remove the previous Fix Versions and add the new Fix Versions
  2. Leave the previous Fix Versions and add the new Fix Versions

 

Example scenario below:

  1. QA Team identify a bug in version 'A'
    1. Affected Versions is set to 'A'
  2. Developer reviews and fixes the bug
    1. Fix Versions set to 'B'
  3. 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')
  4. Developer reviews and fixes the bug
    1. Fix Versions set to ????

 

 

 

5 answers

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

  1. QA Team identify a bug in version 'A'
    1. Affected Versions is set to 'A'
  2. Developer reviews and fixes the bug
    1. Fix Versions set to 'B'
  3. 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.
  4. Developer now starts work on next version (C)
  5. Go back to step 2 and repeat using the next set of versions....

If not released then I would go with

  1. QA Team identify a bug in version 'A'
    1. Affected Versions is set to 'A'
  2. Developer reviews and fixes the bug
    1. Fix Versions set to 'B'
  3. 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.
  4. Go back to step 2 and repeat until QA approve fix.

(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.

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

@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?

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:

  1. If time permitted, the bug/story would be rejected by QA, go back to developer and FV was unchanged.
  2. 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.

 

 

And how about this? 

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

Please vote for it, thanks!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

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...

2,450 views 15 19
Read article

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you