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!

5 answers

1 accepted

This widget could not be displayed.

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

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.

This widget could not be displayed.

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?

This widget could not be displayed.

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.

This widget could not be displayed.

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.

This widget could not be displayed.

The burndown chart will not reflect the story completion until all its sub tasks are completed and there is dependency on resources among team (there could be wait time). For example, after completing the Dev, QA might take some to start testing and after QA completion, Dev might take some time start fixing the reported bugs. Daily tracking of doneness will be impacted.

Please advise if there is any reliable solution of tracking the sprint progress on daily basis when assigned team member completes the user story task (Development, QA/Testing, Bug Fixes/Retesting)

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published Apr 22, 2018 in Jira Software

How-to setup a secured Jira Software 7.9.0 on Ubuntu 16.04.4 in less than 30 minutes

...PermissionsStartOnly=true User=www-data Group=www-data ExecStart=/opt/jira/bin/startup.sh ExecStop=/opt/jira/bin/shutdown.sh TimeoutStartSec=120 TimeoutStopSec=600 PrivateTmp=true [Install] WantedBy...

1,045 views 5 10
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