Who should log bugs?
- In an agile environment where project priorities constantly change meeting deliverables, how healthy is the situation where bugs are logged by project members other than the actual qa member who is the dedicated personnel for quality? especially where no communication is done with the qa personnel on this matter?
- Does this interfere with the test plan of the quality analyst? Especially if the logging method does not coincide with qa method?
- Does this situation increase the time invested to fix them? Especially if they are not well described with steps to reproduce?
- Does it decrease the qa personnel's learning curve and morale on the long run? Especially if the project involves complex scenarios that need analysis and on the spot decision making?
- Does it impede qa's test design strategies to consider unexpected behaviours for the next run?
inna last edited by user
I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would draw the line there since the quality level of those defects could potentially be much lower and you can end up spending way too much time trying to triage and chasing down issues that don't really exist. There should be another way for other people - including customers and people on other teams who have dependencies or are dependent on your application - to provide feedback though there are a lot of options on how you handle that feedback and would probably be an entire other question/answer.
To keep things from getting out of control, and from losing sight of defects coming in, I typically dedicate some time every single day to defect triage. Often, I set it up directly after stand up, so stand up finishes and we transition into defect triage which often has a few less people involved, but allows myself and the rest of the team to keep on top of defects. Any team member who entered a defect should be required to stick around for the triage and speak to the defect that they entered and answer questions. If a defect is missing details, or is a duplicate of an existing one, or is a misunderstanding and should be deleted, or is really a new story/feature request, we figure it out first thing in the morning. We can also make a decision immediately about whether it is related to current story work and we need to address it in the current sprint, or if we should prioritize it in the backlog.
I am confused at how other people entering defects could/would impact the QA team's learning curve or morale? If the QA team members are territorial and feel like they are the sole owners of quality and defects and anything related to that, then perhaps that would be the case, but I feel like you would have even larger problems if that were the case, because quality truly should be a team effort.
I'm also not sure what you mean by your question about impeding QA's test design strategies. How would learning about unexpected behaviors in your application do anything but help your team understand how the app works, and build even better, more robust test cases around those scenarios? The more knowledge you have about the application you are testing - especially from exploratory testing and feedback from other team members - the better equipped you will be to test it.