That is the question. Or at least, hypothetically, it could be. As my current project nears its "Go-No-Go" (I really hate that phrase) date, my decisions on how I spend my dwindling time are becoming as critical as the bugs I still have to find.
My former manager, Alex, and I had an interesting disagreement today. If given a choice between verifying fixed bugs or searching for new ones, which would be more valuable to the project at the bitter end of its development life? Alex said verifying fixed bugs because you know the code around those bugs has been fiddled with and the chances of related bugs are significant. I would instead choose to spend this time searching for new bugs because I believe these unexecuted tests are more dangerous than those bugs said to have been fixed.
Well, it all boils down to a bunch of variables I guess...
- How critical are these unexecuted tests or do we even know what they are?
- What does history tell us about the percentage of our fixed bugs that get reopened after retest?
- How critical are said fixed bugs?
The main reason we entered this discussion in the first place was because I am stubborn when it comes to fixed bug retesting (we call it "verifying bug fixes"). I find it dull and a waste of my skills. It seems more like busy work. The test steps are the repro steps and the outcome is typically boring. "Yay! It's fixed!" is less interesting than "Yay! I can't wait to log this!".
What do you think?
Eric, a good tester should be able to do both. That means s/he should not only verify old bugs but also look for potential new ones, especially new ones introduced by the fix. A good tester should be a trouble-shooter. When a bug is fixed, a good tester should try to figure out how it is fixed. Does the fix leave some room for new bugs? As for your manager he probably doeswhat a manager does best - to cover his behind. Quality is secondary to a manager if he can't cover his behind.