How to track bugs during QA of a user story

Let's say we have a user story comprised of 3 technical tasks for the developer and one technical task for the QA resource. Once the developer(s) has completed the 3 development technical tasks, the QA resource knows it's time to test the user story. By this point, the QA resource has already started work on his technical task by analyzing the user story and writing scripts. So, now the QA resource begins to test the user story as a whole. So, let's say that the QA resource finds 3 bugs in the user story. What is the best way to document and track those bugs?

We've considereed a few options, but none seem to be ideal. He could add comments to the appropriate technical task or tasks that are already there and drag the affected task(s) back into the 'To Do' column. The problem with this is that the QA Resource may not know which technical task to add the comment to and if the task ends up going back and forth a few times, the comments could become too hard to parse through.

Another option would be to add a new technical task under the same user story to describe the bug(s). But, will this make it difficult to track and count outstanding bugs? (We considered either using a label for these technical tasks or starting each issue with the literal 'BUG:'.)

Another option would be to enter an new issue with a type of 'Bug'. But, these would not be listed in the same swimlane as the original user story... seems like it would be difficult for the developer and the QA resource to fully understand the context of the bug.

Our ideal solution would be if Jira/Greenhopper allowed us to add a sub-task to a user story with the type 'Bug'. But, the only sub-task types that we can add areTechnical Tasks

I'm sure all development teams have tackled this situation. How do others address it? Thanks for your help!

4 answers

1 accepted

It would be quite easy to create a sub-task issue type called "Story bug" or something like that, which is what we did. Granted, it means you need to update the out of the box workflow but that is not a big deal.

I didn't know that we could create new issue types! So, if we did that, how would we need to change the workflow? Thanks for your help

Renjith Pillai Community Champion Jan 10, 2013

It depends on your organization, mostly you can use the workflow used for Bug. But if you want a lightweight workflow, get rid of the intermediate Resolved status as bugs during sprints need not have an extra verification status.

Dan... we ended up using the solutiuon suggested by Chris McFadden. We now have a new sub-task issue type under User Stories called Story Bug. These issues follow the same workflow as Technical Tasks. The columns on our Rapid Board are To Do, In Progress, In QA and Done. So, once the developers have completed all of the development Technical tasks under a User Story (and moved them to the Done column), the QA Analyst begins work on the QA Testing Technical task. If he finds no issues, he moves that technical task to the Done column. If he does find bugs, he creates a Story Bug issue for each one and then, the developers work on those. When the developers finish work on a Story Bug, they move that issue to the In QA column and the QA Analyss knows he can begin testing the bug. Once all of the Story Bugs are 'Done', the QA Analyst finishes his QA on the user story as a whole and moves his QA Testing technical task to the Done column. Hope that helps!

Fantastic, that makes a lot of sense. How do you approach the prioritization of bugs within a sprint? For example, if there's a critical bug related to each story, how do you ensure the team addresses those before moving on to lower priority bugs?

Lastly, for bugs that can't be addressed within the sprint, but aren't critical, do they get converted from a Story Bug to a defect and moved into the backlog?

How did you deal with the situation where the adding of these new Sub-tasks during a sprint affects the sprint scope and therefore your burndown?

LHamilton, our org is facing the same issue -- did you end up settling on a solution that worked for you? If so, would love to hear it.

Regarding prioritization of bugs within a sprint, our developers always work the board from the top down... so, Story Bugs within a higher priority user story are worked on first. And, you are correct regarding non-critical story bugs... if there's no time to work on them during the current sprint, they are closed and copied over as regular 'Bug' issue types to be included in a future sprint.

Suggest an answer

Log in or Join to answer
Community showcase
Bridget Sauer
Published Mar 05, 2018 in Jira Software

Jack Graves: Real Ale enthusiast with a knack for Jira Software implementation

@Jack Graves first caught our eye with his incredible breakdown of what, in his opinion, can make or break a Jira software implementation. (Read his thoughts on this thread)! In this followup Sh...

67,493 views 4 6
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot