Wednesday, December 17, 2008

Found In Fixed In

One of the standard items in bugs is the "found in" field. This indicates all releases that you know of that have the bug. Another common item, although slightly less standard, is the "fixed in field". This indicates all releases or all branches that contain the fix.

First level of smarts.... use releases
Found in and fixed in are fields that are typically not updated that much. You describe it when you find the bug, update it (maybe) when you've diagnosed the bug, and add "fixed in" when you verify the bug. The biggest use of these fields comes after the bug is closed. This gets looked at when, for example, a customer issue comes up and someone wants to know if a bug existed in a given release. What you really care about capturing easily is what releases the bug can be found in, and what releases a bug is fixed in. In many development environments, this translates to branches (with one or a few releases per branch). So don't worry about build numbers - those can go in comments. Worry instead about releases.

Second level of smarts..... multi-select
In some defect tracking systems (RT, for example), found in and fixed in are single-select fields. This is wrong. You can certainly have a bug that is found in more than one branch of code. And you can have a bug that is fixed in more than one branch of code. For example, maybe a bug was fixed on head and the most recent release branch. The bug should note every release that is known to contain the problem and every release that is known to fix the problem (note that "head" means "all go forward releases branched and taken from here").

Third level of smarts... different resolution types
This is the level that I have yet to see a defect tracking system actually support. When you're working with a bug, you may find it in the 3.5 branch, the 3.7 branch and head. And then you may decide to fix it on head and the 3.7 branch, but not to fix it on the 3.5 branch since you're not intending to release 3.5 again. How do you close the bug? Is it fixed? Well, yes. Is it deliberately not fixed? Well, yes. Or did someone just screw up and accidentally not mark the "fixed in 3.5"? In this case, no, but we're all human and that's going to happen some day.

You basically need one resolution type per "found in". Think something like this:
Found In       Resolution
3.5                     Won't Fix
3.7                     Fixed
head                  Fixed

Anyone know of a defect tracking system that does this? Or is it good enough to just put this information in the comments in case you need it later?

2 comments:

  1. The defect tracking system that we use (that I believe was developed internally) has a separate tab for each release that it will be fixed in (whether this is the same release number but different languages, or just different release branches). Each tab contains the information specific to that fix.
    So when we run reports to see what was fixed in certain releases, the same defect will show up in each release.

    ReplyDelete
  2. I think there's one more column, does this bug exist on release x?

    The other way of storing this information is to keep one ticket per release and link them together, then each of them can have the fixed/won't-fix status separate.

    ReplyDelete