Who should log bugs? [closed]

Question

1. 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?
2. Does this interfere with the test plan of the quality analyst? Especially if the logging method does not coincide with qa method?
3. Does this situation increase the time invested to fix them? Especially if they are not well described with steps to reproduce?
4. 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?
5. Does it impede qa's test design strategies to consider unexpected behaviours for the next run?

Answer 1

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.

Answer 2

Some thoughts here:

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?

This is normal - anyone can log a bug. The team decides which bugs are in scope for the project and which need to go into the main backlog. The team decides which bugs get fixed when they're planning the next iteration/sprint/cycle.

especially where no communication is done with the qa personnel on this matter?

I'm not entirely sure what you mean here - if you mean that the bug gets logged without the testers confirming that it's a bug, that's normal. If you mean that the testers aren't in communication with the development team, whatever your company is doing it isn't agile (there's a lot of that - organizations adopt some of the forms of agile development but turn it into a kind of mini-waterfall or worse).

Does this interfere with the test plan of the quality analyst?

In a word, no. A good tester is constantly monitoring what's happening in the project anyway and adding notes to the test planning to ensure that bugs and potentially problematic interactions get covered at some point. It doesn't matter where the information comes from, and since in agile development all team members are in constant communication, the information is always available.

Especially if the logging method does not coincide with qa method?

I'm not sure what you mean here - do you not have a means of tracking reported bugs that's available to people other than the test team?

Does this situation increase the time invested to fix them?

Not if you have a company-wide tracking system that explicitly asks people for the information testers and developers need to fix the bugs. What increases the time invested for a fix is a bug report that doesn't have enough information to identify the problem. "It's broken" is useless. "I get this error (with screenshot or stack dump) when I do this (with description of the actions)" is a lot easier to identify and fix.

Especially if they are not well described with steps to reproduce?

That does increase identification and fix time - this is why a tracking system that guides people to give the information testers and developers need is a good idea. At my last position I worked with a home-grown system that had these prompts (paraphrased because I haven't been there in over a year) in the problem description section:

• What actually happened?
• What did you expect to happen?
• Why did you expect this to happen?
• Can you reproduce the problem?
• Describe how you reproduce the problem?

Does it decrease the qa personnel's learning curve and morale on the long run?

No. A good test team is checking reported bugs anyway and learning from them that way. It doesn't matter who reports the problem: the goal is to produce the highest quality software possible (for whichever definition of quality your organization uses) with the time and resources available to you.

Especially if the project involves complex scenarios that need analysis and on the spot decision making?

There are projects that don't? Seriously, anything non-trivial is likely to involve complex scenarios and so forth. As long as everyone in the project team is communicating - and the team itself is communicating with the wider development, test, and project management teams - it doesn't matter who reports a problem. What matters is triaging it and deciding whether it needs to be fixed for the next sprint.

Does it impede qa's test design strategies to consider unexpected behaviours for the next run?

It doesn't impede anything. It can impact strategies, but it doesn't impede them. A good tester has already checked the bug reports before the next round of regression or the next sprint and knows to look for the reported problem.

I'd suggest that it sounds awfully like you don't have anything remotely agile going on here: instead your questions imply a completely isolated test team, no consistent issue reporting system, and functionally ad-hoc development - if this is the case, the first thing you want to do is to try to get more communication going, then you want to try to get one issue tracking system that everyone uses.

Answer 3

Anyone who has access to the application should be able to file bugs/defects.

1. Defects should be filed in a bug tracker with a status new.
2. New defects should be verified and extended (With at-least a reproduction path)
3. Defect should be added at the top of the backlog (Keep a no defect policy when being Agile)

Products Owners should monitor new incoming defects on their backlog and prioritize or reject as needed.

During the plannings sessions (This meeting include the whole team, including the testers of the team!) all tasks should be clarified. So everyone should be aware and understand the work for the upcoming sprint.

In a active Sprint "blocking" issues can be fixed adhoc, but should be put on the sprint board and the bug tracker if needed. The tasks should follow the normal processes including testing of-course.

Test scenarios should be added and run during the cycle of a task and be part of the definition of done, preferably they are automated to keep the cycle as short as possible.

Agile environments should include everyone in all the meetings and the work should be transparent and visible. I do not understand how you could miss anything :) unless your not part of the team. Separate QA teams is NOT agile.

The QA members of an Agile team should coach on better quality practices and identify room for improvement here, they should be the goto guy not "the you do all the testing" guy. Often the ratio testers vs developers is very low and thus you need to teach developers to use processes that lead to high quality software.

Answer 4

I agree with the others, anyone should be able to enter bugs. One comment on:

Especially if they are not well described with steps to reproduce?

If the bugs being entered are not productive, I would invest some time those people to train them in the art of great bug writing. You just might make a great tester in the end.

Answer 5

This is going to be a bit unpopular, but I am going to have to buck the tide on the answers so far. I agree that it is important to allow everyone to submit potential defects and that system should be as clear, helpful, and accessible as possible. However, I have found that it is important to separate the "official" bug list that the team is working from the "potential bug" list.

Before a "potential" gets promoted, it should be verified by someone (usually a tester). That person should be adept at posing follow-up questions to insure that the the classification of the bug as duplicate, new feature, etc. is correct. That is not a "territory" issue, it is simply a means of cutting through any confusion before the team addresses it.

This is especially true for reports from customers. I have found that prompt, intelligent follow up questions are always appreciated by customers. Also, no matter who submits the "potentials", it is important to follow up with status every once in a while. On a previous team, my desk resided next to the customer support lead. I would be called in on incoming calls where defects were triaged almost immediately on receipt when possible.