Skip to main content

Advice on handling QA testing

Last post 06:51 pm September 23, 2019 by Janice Schole
8 replies
01:15 pm September 19, 2019

Hello everyone,

I am working with a team right now that used Kanban in the past and is now looking to use Scrum.  The members in the development team have roles/titles, dev and QA, which I know isn’t ideal but that is the situation.  

I am trying to help them use stories such that a completed story means it meets a definition of done - ie. dev and testing included within that Story.  The team estimates stories for the full DOD, So again dev and testing included.  

The problem I am seeing with this team is that when Development is done in the story, and a QA team member takes over for testing, any bugs found are created as brand new “bug type” issues within Jira that they want to leave unestimated since the work was included in the original story’s estimate.  The bugs contain a lot of details about bugs including how to reproduce the bug, and videos or screenshots.

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?

Thank you in advance.



01:53 pm September 19, 2019

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. 

02:38 pm September 19, 2019

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.


03:00 pm September 19, 2019

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. 

05:45 pm September 19, 2019


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. 

08:38 pm September 19, 2019

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?

07:58 am September 20, 2019

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. 


04:10 pm September 23, 2019

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.


06:51 pm September 23, 2019

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

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.