Advice on handling QA testing

Hi Janice, 

To me this is one of those things that the Development Team and Product Owner can experiment with. When I used to be in Product Ownership situations involving bugs really came down to communication. 

If they Dev Team found small bugs that they could easily fix they had the autonomy to go ahead and do so. If they found a bug that would prevent that story from being completed (or prevent other stories from being completed) within the Sprint we would have a conversation and negotiate work in or out. 

There were times where we placed the story / bug back into the backlog for a subsequent Sprint. There were others were it was important for the Sprint goal so we moved other stories so that the team could focus on the bug. 

How you choose to make this transparent is up to the team. As long as everyone understands the process and continues to inspect it I think you'll be okay. 

Hi Tony,

I can understand brand new bug issues being made for a bug we don’t want to fix in the current Sprint, so we can put it in the backlog, or creating a new bug issue in the case where a bug is found that is not related to the story.  

The problem is new bug issue types are being created for bugs related to the original story that we *do* want To fix within the current sprint.  I agree the team should have autonomy to fix those but what is happening is new bug issues are being created and then the team needs approval from the PO to pull them into the sprint.  It seems like bugs related to the story should stay within the original story.  I was hoping someone could share how other teams handle this within Jira? I was thinking if we want to document all the bug details, sub-tasks could be created for bugs?  Any other ideas?  I’d also be interested to know if anyone thinks what my team is doing is actually not too bad.

Janice

I've experienced this in many ways with different teams.  But what was eventually settled on was very similar to what @Tony Divel described. Before any tracking item was created, the person finding the problem would discuss it with the developers that worked in the code. Decisions were made about whether it could be fixed in the current sprint or not. If it was fixable, nothing ever was captured in what ever tracking tool was used. If it wasn't possible to fix it during the current sprint given the existing Sprint Backlog makeup, discussions ensued with the entire Scrum Team to determine the best way to proceed.

I have 20+ years of QA in my career and I do not feel that writing up bugs in a tracking tool and letting others decide when to fix them is the best way to deal with them.  Communication is critical to making decisions on how to deal with problems found.  Writing up defects without discussion is very much like saying "hey you messed up and now everyone will forever know it because it is now captured digitally."  In an agile team everyone is responsible for the work being done and no one is blamed for anything. 

@Janice, 

I think Daniel's comment may address some of what you mentioned above in regards to a possible way to handle bugs that. Do you know why the minor bugs are required to be approved by the PO in order to be brought into the Sprint? I could see some challenges there if the PO is not accessible you could end up causing the team to slow down or context switch to try to fill their time. 

Transparency could be achieved by just having the conversation within the development team (as Daniel mentioned) or it could be adding the bug to your JIRA board so that others outside of the Development team have insight into what's going on. 

Might the team perhaps be a bit over-reliant upon processes and tools, if it experiences such a problem in the first place?

Would the issue exist if there was more interaction between individual team members?

Isn’t best practice to keep all the dev and wa work within the one original story?  Can anyone share how they have handled this?

>> What difference will it make where you capture the bug ? At the end it has to be fixed depending on your priorities. Adding details of bugs in stories or in new bug ticket or even on a whiteboard would indeed help in transparency. But maybe think about the wastage being created in handovers & too much emphasis on process & features of tool being used. May be think about bringing the testing earlier, coach the team members to prevent bugs than finding & reporting them. 

Ideally you want the team to come to an agreement on the process that works best for the team and their DoD. If they can't call something Done because not all non-deferrable bugs are closed for the scope of that Story, then the next step is to find the best way to visualize this scenario.

For us, every non-deferrable bug enters the Sprint and blocks the Story from continuing forward. We can't close it and say the value of the Value Statement is ready for use, and we also don't want to combine Story/Bug efforts into one story. We use Jira so they are linked as Blocks/Is Blocked By and the Story is flagged so that it's visibly got something going on.

Our QA/Dev talk all the time, so they discuss amongst themselves if the effort should be captured as a ticket based on the scope of the bug, and not by how long it will take. A quick fix may have large set of AC's assumed in the Expected Behavior. Sometimes a bug will be used JUST to capture the bug fix in its own branch.

Often the Dev's say "yeah write it up" so they can later review the decision making practices. Bugs are encouraged. We also use a custom field for Reason/Cause that the Dev have to fill in, so at any time we have visibility on trends of bug creation. Ex: Poor AC, Edge, Deployment Issue, Environment Caused, Missed Dev Test, Missed Unit Test, etc

Hope those ideas help.

Thank you to everyone who replied, I really appreciate it!