Monday, May 24, 2010

One Problem One Bug

A bug (defect, issue, whatever) logged in your defect tracking system should be about a single problem. Sounds straightforward. But it's sometimes hard to tell.

Let's look at some examples:

Failed Upgrade:
Problem Report: An upgrade failed because a hard drive failed mid-upgrade and then there were configuration issues. One problem or two?
Answer: One problem if the configuration issues were caused by the hard drive failure. Two problems if they were two separate problems that happened to occur during the same upgrade. Hard to tell.
Practically, what to do: Log this as one issue, and log separate child issues as you isolate separate problems.

Active Directory User Does Not Exist:
Problem Report: At two clients, an active directory user that the system was attempting to look up failed. In one case, the error returned was "INVALID_USER" and in another case, the error returned was "LOOKUP_FAILED". One problem or two?
Answer: One problem. In both cases, this was an issue where the system attempted to access Active Directory when AD was failing over and not servicing requests.
Practically, what to do: Log these as two separate bugs. It's not obvious they're the same issue. When it becomes clear that they are the same problem, mark one issue as a duplicate of the other and close it out (aka consolidate the two issues into one).

On a day to day basis, it doesn't really matter whether you log things in separate bugs or the same bug initially. What matters is that you stick with the "one problem, one bug" rule, even as your understanding changes. If that means marking bugs as duplicates, great. If that means logging new bugs and putting "this comes from bug X" in them, that's okay, too. The point is that your defect tracking system should reflect your current understanding of the problem, with only one problem in each ticket.

No comments:

Post a Comment