Monday, June 30, 2008

Bug Dances

There are lots of tricks to clean out a bug queue. Often it's a developer who wants to hit a certain bug count - either due to official or due to internal pressure. Sometimes it's a QA engineer, and in rare cases it's the project manager "helping" on triaging bugs. These are some of my favorites:

The Friday Afternoon Duplicate Rush
The classic phrase here is "these look pretty much the same". Two things with the same symptoms are typical candidates here. Two bugs in the same area of code with different symptoms but the same apparent result (e.g., stuff happened, and then it crashed) are also typical candidates here. Combine a duplicate rush with one or two bug fixes and you've got a recipe for a lot of closed bugs!

The Freak of Nature
This is another common one. Typically this happens to intermittent bugs that haven't recurred in a while. The bug will be marked as unreproducible, often with a notation like, "the network must have been congested" or "infrastructure hiccup". Sometimes this isn't closed outright; instead it's sent back to the finder "to try to reproduce it".

Info Any Info
This is nearly identical to "the freak of nature". The major difference is that the person is less sure, so the bug is being kicked back for more information. If this is the first time, then it's probably reasonable. When this happens more than once, the requests start getting a little weird.

The Miracle Cure
This one is my favorite. The code around the bug has changed, so odds are the bug isn't there any more! There are a couple variations on this one. Sometimes it's honest belief: "I was working in this module and changed the method that this bug is in. Given my loop change I think I fixed this one, too." Sometimes it's a little bit hopeful: "I worked on this code last week and cleaned it up. Surely this got fixed then." Sometimes it's outright wishful thinking: "I think [some-other-developer] was working on this module last week. This is probably fixed." I worked with a developer who was notorious for this for several years; his success ratio with this was about 20%.

Please note that all of these reasons to close bugs are perfectly valid - some bugs really are duplicates, some are the result of unreproducible infrastructure hiccups, sometimes more info is really needed, and sometimes fixing one bug also fixes another - but if there's a pattern and it happens a lot, then you need to look deeper. Make sure you're not incentivizing (directly or indirectly) low bug counts or high closure rates. Also look for patterns to make sure this isn't just a trick to clean out a queue: a couple of duplicates is normal, a lot is not.

No comments:

Post a Comment