Duplicate bugs
When I talk about bug data - or potential uses for bug data, there are two things I typically mention. Both are strong opinions of mine, and while the first is now becoming more accepted, the second is less so (as far as I know).
The first opinion I share is the notion of using bug data to measure tester performance. This is dumb, and I'm betting most of you agree. Over the years, I see fewer and fewer cases of this, both inside and outside of Microsoft, so I probably don't need to repeat the story here.
The second opinion is my take on duplicate bugs. On most test teams (ok - nearly all test teams) I have worked with, entering a duplicate bug is viewed as a bad thing. (Some teams (typically those who disagree with me on the first point) even have fancy algorithms that use found, fixed, and resolution to come up with a magic tester efficiency number).
I guess duplicate bugs are viewed as bad because they can waste someone's time. The nerve of Bobby Tester entering a bug that Jane entered so clearly just a few days before - now someone has to take the time to resolve that bug as duplicate. So what if they test different areas of the product and didn't realize that the bug was actually in a shared component. Bad Bobby, Bad Bobby!
I don't think entering duplicate bugs is bad at all - in fact, I think worrying about them is bad. let me tell you why.
- If there is any sort of negative consequence for a tester entering a duplicate bug, that tester will err on the side of not entering a bug at all if they are worried about entering a duplicate bug. Think about this: say I find a high impact bug. I take some time to look to see if the bug is known, and see one that's kind of close. If there is a negative consequence for entering the bug, I am more inclined to not enter the bug. Ideally, I'll make a note of the bug, and verify that it fixes the problem I just found, or I'll email the owner and get their opinion, but in many cases, a tester simply thinks "dupe", and moves on to something else even if it means missing a potentially important issue.
- The idea that entering duplicate bugs wastes somebody's time is a myth. Most testers know their own areas pretty well, but may not know as much about the rest of the system. After I find a bug, it may take me twenty minutes to dig around and see if any of the other bugs in the area are similar - or possibly the same as the one I just found. If I were to just enter the bug, and let the triage team (or whoever examines the incoming bugs)** look at it, chances are that they would know if it was a duplicate in far less than 20 minutes. The only time wasted was my own.
- So what if a tester enters a duplicate bug. Often, the information in one bug report doesn't provide enough information to diagnose the problem. Another report on the same issue may lead the developer to the root cause. Most bug database systems have way to mark bugs "related" (or "duplicate") and retain a link between the bugs.
So, the next time someone tells you that entering duplicate bugs is bad, tell them that I said they were wrong. Of course, if you are entering verbatim duplicates of your own bugs, none of the above applies :-}.
** The term "triage" is taken from emergency medicine, and is often used to describe the process of examining and dealing with bugs. I assume it's familiar to everyone, but can elaborate as necessary.
Comments
- Anonymous
August 01, 2007
The comment has been removed - Anonymous
August 01, 2007
To extend the idea, I try to teach my testers and developers to think of the bug database as a knowledge warehouse. I don't care if there are dupes entered into the database, in fact I welcome them (barring the situation you mentioned where you are duping your own bugs). The more instances of a bug being (independently) reported by different members of the team, the higher it gets placed on the "likely to affect customers if we're finding it this much in our little protected sandbox" queue. Yes, there are situations where that is not the case, but it works more often than not.