Ideal way to log bugs found by QA team while testing stores in running sprint

[Abhishek Sharma]

We have a scrum team that involves both developers and QA (Testers) team. We generally do a production release at the end of our 2 week sprint. Current workflow looks like this

Open -> In Progress (Dev) -> In Code Review -> Ready for QA -> QA in Progress -> Done

When an issue is in "QA in Progress" and QA team finds an issue that is a blocker or doesn't fulfill Definition of done, then they create a bug type issue, add it in current sprint, and link it with that story. With this approach we see many bugs getting logged after start of sprint, damaging scope of sprint.

Want to understand what is a better way to handle this? Where should QA team inform dev team about bugs present in stories and how developers will have a better clarity to track all of the bugs created by QA team

[Peter_DevSamurai · Accepted solution]

Hi @Abhishek Sharma , for my team we would use AgileTest.
It's easy to use, fast for my devs to track Uncovered or Untouched issues, bugs and stuff quickly using customizable Dashboard, also its an app specially made for QA to test and manage bug in real time. Plus it's a free tool.  

[Sanjog Sigdel · Accepted solution]

Hi @Abhishek Sharma 

I have created a custom issue type "Story Defect". For an active story the bugs identified by QA are Story defect. Create a Jira Status "Back To developer" From Test in Progress whenever there is a Story Defect logged, the ticket moves back to developer.

Implement Back to developer and Story defect and this will make developers accountable on finishing the bugs to complete this ticket.

YOu can also use the story defect count during the retro to discuss if the issue was in developing the story or understanding the requirements. This gives us plenty of room for improvement.

[Abhishek Sharma]

@Sanjog SigdelDoes QA team add these Story defects as a sub-task in Story or as a standalone issue and add it in sprint?

[Sanjog Sigdel]

The QA members are the ones reporting the Story Defects as well as Bug. I am referring Story Defect to be placed under a ticket as a sub-task. Sub-task but the issue type is "Story Defect". And yes active story's defect should be within the sprint and under a story. The story should be accepted only when the story meets all the requirements and is bug free. If you create separate bug, it will be hard for the Scrum Master or Project Managers to get hand of the Sprint activity.

[Abhishek Sharma]

This look like a workable approach. Moving ahead with it. Thanks for your suggestions.

[Sanjog Sigdel]

Thanks @Abhishek Sharma 

I'm practicing this in my organization and I'm getting good track of whaty dev and QA are delivering.

[Talib Usmani]

Hi @Abhishek Sharma 
Your way of doing sprint is also not wrong. If you want to enhance this and don't want to create new bug task.
Just add comments in the ticket like:
TESTING FAILED

REASON and DETAILS:

TAG ASSIGNEE and move that ticket again in OPEN status.

[mariya_solovey]

Hey,
Please let me know what you think about this option:

You can add a Reopen status to the workflow. If the original issue wasn't fixed (the functionality doesn't work) then the issue can be moved to Reopen or even back to ToDo with added comment and all details (like AR, ER, logs, screenshots etc.) and assigned to engineers.

I could also suggest using Smart Checklist. Each checklist item can be the acceptance criteria and you could mark it with custom status like QA Failed . This way all of the checklist items are inside the parent issue so your reporting is not affected. If at least one checklist item has a QA Failed status, you can move it back to Reopen/Todo. If other issues are found with a priority that’s not high - log them separately and prioritize during the grooming session so they can be addressed in the nearest Sprint.

You can also use mandatory checklist items to make sure a ticket can't be moved to Done/QA Passed unless all of the items that have been marked by QA as mandatory are completed.
Hope this was helpful,
Mariya

[Abhishek Sharma]

Tracking through comments is difficult, because there are likely chances that multiple issues are raised by QA. And we need to be certain that developer don't miss out anything. From both developer and QA end you need to be certain that we are not missing anything.