What is the best recommended way to track defects across multiple releases?

[Sumeet Agrawal]

I've gone through a couple of similar other questions:

• https://community.atlassian.com/t5/Jira-questions/Single-Issue-multiple-releases-at-different-times/qaq-p/829618
• https://community.atlassian.com/t5/Jira-questions/Using-defects-to-cover-multiple-release-streams/qaq-p/729805

However, I am yet to get a satisfactory answer. I know a lot may depend upon the team's methodology or process and that it may take years to perfect and there is no single perfect way and I am not seeking the 'perfect' way. I am looking for what the majority would say as the better way of defect tracking from reporting or management perspective.

However, from the point of view of Jira as an almost world-standard for defect tracking, depending upon a typical 'bug / defect life-cycle', what would be regarded as the better of the 2 (say 51 yays against a 49 nays!!) ways to track defects across multiple releases - if a bug has been raised by a customer for a released version of the software product and its urgent so it needs patching through Hotfixes and probably in the next monthly roll-up / maintenance pack too and then again in the current next major development branch:

1. Creating clones of the defect for each release and tracking each defect separately for each release so that each defect has its own life-cycle
2. Creating a single defect and adding sub-tasks to it for each release and close each task as a defect? How does this fit in a bug life cycle?

[Ste Wright]

Hi @Sumeet Agrawal 

I know you're looking for a "world-standard" approach - but from my experience, it's really down to how your teams work, and preference in relation to traceability, visibility, reporting, etc.

Based on your need...

• Bug is raised by a customer for a released version
• Bug requires multiple production releases

...I think this is how I'd recommend it:

• Initial Bug raised has the "Affects Version" added, which represents the released version it was located in
• Consider if the Bug can be released through multiple versions without creating duplicates. The release/version itself has a "status" which can track whether its been completed or not. The Bug can be added to multiple FixVersions / releases and tracked in this manner
• If not, you could do something like this...
  • Original Bug is released with the first release
  • A duplicate Bug is created for each other release - with the Affects Version updated to the specific release/environment impacted, and the FixVersion set per release. This is more relevant where "additional work" is needed beyond the initial hotfix
  • OR, if the initial fix is generating other work, but this work is no longer to fix a defect, generate Tasks/Stories instead
  • Ensure any additional issues are linked to the original Bug using "linked issues", so the whole lifecycle of the work can be tracked end-to-end

Let us know what you think!

Ste