Handling of Deferred Story Defects or Defects found During Iteration/Release Testing?

[Alison Clough]

Hi All - hoping to get some guidance from all of you experts out there :) I've got a couple of questions related to defect tracking in JIRA. We are looking to create a new "story defect" subtask in our instance for teams to track defects found during story testing. However, there are a couple of scenarios I'm unsure how to handle...

1. What is a story defect subtask is deferred? That is, what if there is a decision not to fix right away and take on as technical debt. Is there a best practice for what to convert the subtask to? 
2. What about defects found during iteration/release testing when there isn't necessarily a specific story to align a story defect subtask to? Do folks recommend creating a story for the release/iteration testing and then log the defects found as story defect subtasks or would you create a specific issue type for logging the release/iteration testing defects found? 

Your input is greatly appreciated.

[John Funk · Accepted solution]

Hi Alison - Welcome to the Community!

1. For our process, any Defect that is not going to be immediately fixed is converted to a Bug issue type. (Which is not a Sub-task type for us, by the way). 

Our definition - Defect - identified during QA Testing and must be fixed now and code cannot be deployed until the Defect is fixed. Bug - something doesn't work correctly, but we acknowledge that and will release the code anyway. We will fix it when we have time. Same goes with items found in Production - we consider all of them to be Bugs. 

2. We would still classify those as Bugs since the don't directly relate to current code/stories being deployed. But we could Expedite the priority if needed to get it out the door with the rest of the code. 

I hope that helps!

[Alison Clough]

Thank you! That is very helpful :)

[John Funk]

Great! If that solved it for you, can you click the Accept Answer button so others will be able to see the resolution in the future? 

[Alison Clough]

Sorry about that! I clicked on it earlier when I posted my reply but it must not have stuck.

[John Funk]

No worries - thanks for doing that!

[Alison Clough]

What about the second part of my question? If a team does some release/iteration testing on top of the sprint testing, is there a best practice for tracking defects found at that point? The individual stories would have been closed out at that point during the individual sprints so putting them as a story subtask under the original story would not be an option unless you reopen the associated story (assuming QA would even be able to map it back). Do you recommend release/iteration testing stories to nest those defects under?

[Alison Clough]

Never mind - I see that you guys don't have defects as a sub-task so I would assume you would just add as another defect. But - if you have thoughts on how to handle in our situation, I would love the guidance :)

[John Funk]

Defects are a Sub-type for us. But Bugs are not. We would create them as Bugs if they are not directly associated with the stories in that Sprint. Does that make sense?