Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.
  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?
share|improve this question

closed as too broad by dzieciou, user246, corsiKa Mar 17 at 16:41

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

4  
This is quite the loaded question/rant. Perhaps consider splitting each one, organizing your thoughts, and coming back with something more "answerable". Some helpful reference: sqa.stackexchange.com/help/dont-ask –  Meesh Mar 11 at 22:20
1  
Doesn't sound like an agile environment, just chaos. Do you think you are agile? –  Phil Kirkham Mar 12 at 2:29
    
I second Meesh proposal to split this into separate questions. –  dzieciou Mar 16 at 10:05
    
I definitely agree - this should be multiple questions, and each one should be expanded more to describe what the business problem actually is. –  corsiKa Mar 17 at 16:42
    
I think that the partitioned question has been answered already. My question rorated around the who. Now it would be interesting to elaborate more on how to manage an environment where bugs are logged by non QA members and find a solution of how to not interfere with the QA personnel's test plan, in the specific case where logged bugs do not follow any agreed methodology. –  user5529 Mar 18 at 7:53

5 Answers 5

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.

share|improve this answer
    
Thank you for the answer, it provides a good insight on how to handle the situation as a product owner or project manager. My question did not clarify how a qa member can handle this case, so now I have widened it to the qa member itself. By 'decreasing the learning curve' I mean decreasing the chances that a qa member can learn from mistakes he makes or learn about cases he did not include in his test cases, if bugs are logged by another member not part of the qa team. Also, as qa team runs test cases and closes them, it would interfere with the end report if they are not communicated with qa –  user5529 Mar 12 at 9:57
2  
Whenever a valid defect is filed, regardless of who entered it, the QA team should ensure that there is a test case to cover that scenario in the regression test suite. This allows you to "learn" from any defect entered. This is also the first mention of test cases. I did not say that other people should be executing test cases, they would likely be finding these defects through their own exploratory testing and QA should still run through their entire suite of test cases. –  Sam Woods Mar 13 at 18:52

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.

share|improve this answer
    
Thank you very much for the elaborative answer. I came up with another thought. Should quality assurance members insist to follow clearly defined methodologies or should they adapt and try to fit within any methodology? As all answers clarify that quality should be the concern of all, should methodologies be also of concern? –  user5529 Mar 12 at 19:42
    
@user5529 - my view is they should adapt and fit with any methodology. The end goal is the highest quality software the team can produce with the resources and time they have. It doesn't matter how they get to that goal - although it tends to work better if everyone on the team is using the same methodology. –  Kate Paulk Mar 13 at 10:33

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.

share|improve this answer
    
This clarifies my question very well. Also the previous answer I think asserts that the qa personnel should be an indispensable member within the quality goal, regardless of the status of the pfoject. The lack of this approach was what I was missing in my question. –  user5529 Mar 12 at 9:47

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.

share|improve this answer

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.

share|improve this answer
1  
We implemented your approach by defining a proper bug lifecycle in JIRA. Before a bug is considered in bugs triage it remains in a state "New" (or "potential", as you called it). If the bug report is unclear during the bug triage session, it is moved to the "Further Discussion Required" state. Only when enough information is collected, it will be promoted to the "official" state. –  dzieciou Mar 16 at 9:59
    
Another reason for having a separate customer bug list is that the customer-created issue should not be closed until the customer verifies it. (An "internal" bug is closed when the team verifies it.) In addition, keeping a separate list allows the original issue description to be maintained and a separate "team" interpretation be created for implementation. Of course, (as with most testing issues) context within each team is everything! –  Jeff_Lucas Mar 16 at 21:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.