5 Most Common Bug Regression Mistakes: Day #2
Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5Although you may need some outside input to regress, test, and verify certain bugs, only QA should close bugs. This will keep the accountability for all bugs of the project within QA.
Mistake #2: Non-QA Closes A Bug
When only QA closes bugs, it is much easier for them to track the progress of the project, build metrics, and make forecasts. Additionally, QA has the first line of responsibility and accountability whenever a bug appears in the field.Let me say that another way: If ANY bug appears in the field, the first question is always, “How did we miss that?” That question prompts people to look to QA for the answer. How did QA miss the bug? Although QA may have reported the bug, there are many reasons why the bug may not have been addressed: - The fix was too risky
- The fix was too costly
- The fix would delay the ship date
So as you can see, it is possible that QA can identify a bug yet it still may be seen by the public. In this case the bug would have been Deferred (action performed by producer or lead developer). When the bug is tracked down in the bugbase, QA can point to it and show that it was Deferred, not Closed. This means that the company knew it was shipping with this issue. If, however, the bug had been Closed? Then what? Then the Question becomes: “Why did we close a bug that was, and is, obviously still occurring?!? QA, what do you have to say for yourself?” Because now what has happened is that a bug was reported as fixed and VERIFIED as fixed – thus the company believed that the bug no longer existed. The bug was reported to NO LONGER BE ANY THREAT WHATSOEVER. So the Question now is, “How did QA screw up?” This is never a Good Question (but you probably figured that by now). So, how did QA screw up? – OR – Did QA screw up? There are a couple of possibilities, but hopefully QA didn’t screw up. Hopefully QA did their due diligence, but a rogue producer or developer decided they would go ahead and close a bug because they hadn’t seen it in awhile. Pray that this was the case. There is, of course, no way QA would ever close a bug that was still occurring, right? If you have executed all your tests and performed your job as a true Quality Assurance Professional should, the chances are that you did not close a bug that was still occurring. But how would you like to be accountable for anything going wrong in the field after allowing someone else to validate an implemented bug fix? Does that sound like a good idea to you? Not me. So make this a rule of thumb: Only QA Should Close a Bug (just make sure you only close bugs that no longer occur). Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5Return To Successful Quality Assurance Home

|