A Bug's Life

By Michael Flanakin @ 5:25 PM :: 1640 Views :: Development, Configuration Mgmt :: Digg it!

I've used about half a dozen or so bug and issue tracking systems over the years and, with that, have come to favor specific setups. The main configuration I'm referring to includes work item status, resolution, priority, and severity. When I first dug into TFS, this was something I looked at and didn't like all that much. With the ability to customize work item templates, tho, I wasn't too concerned. Given that not too many people who work with TFS seem to have much experience with other, more mature bug tracking systems, I figured I'd share my thoughts.

Work item status in TFS is limited to active, resolved, and closed, by default. Without some sort of reason or sub-state, this just isn't enough. I want to say sub-states are probably how most people get around this, but I'd argue that full states are better. This is obviously an individual preference, tho, and only really comes into play when you look at reporting. The statuses I prefer are as follows: unconfirmed, new, assigned, in progress, awaiting info, reopened, resolved, verified, and closed. As with the rest of what I'll cover, anyone with Bugzilla experience will recognize some of these values. Bugs are created as "unconfirmed" and are moved to the "new" status after being triaged. By default, TFS includes a triage property, but I feel this is better covered by status. Again, just my opinion and it comes more into play with reporting. I prefer bugs to remain unassigned by default and then have the status changed to "assigned" when it's actually been assigned to someone. "In progress" and "awaiting info" are gimmes. Once completed, the bug should change from "in progress" to "resolved." When this happens, a resolution needs to be specified to indicate what actually happened. Resolutions are pretty standard: fixed, invalid, won't fix, duplicate, unable to reproduce. I'm thinking there are more resolutions, but this is all I can think of off the top of my head. Once tested, the bug is changed to the "verified" state and ultimately to "closed" once it has been deployed.

Priority and severity go hand-in-hand. All-too-often, I see teams trying to calculate what bugs should be in a certain release by priority alone. While this is a great start, I don't think it's the only factor. Let's just start with priorities, tho. Personally, I like to have at least 5 priorities because it gives you a bit more flexibility than 3 or 4, which seems to be fairly common. That's just a start, tho. I had a conversation with a co-worker, Allan Askar, last week about putting some meaning behind these numbers. We haven't put this to use, but I'm pretty confident that it should make prioritizations across the team much clearer. The key here is that priority is based on the iteration a work item is assigned to. If not assigned to a specific iteration, the work item's priority indicates when the work item should be implemented: 1's in 2 weeks, 2's in a month, 3's in 2 months, 4's in 4 months, and 5's in 6 months. The idea is every wok item would be assigned to the backlog and given a priority based on its importance at that time. During release planning, every item on the backlog would be evaluated to update it's priority and determine whether it should be included in the upcoming release. If an item is included in the release, then priority loses its time-based meaning and picks up a relative priority that simply indicates what order it should be worked on, as you would typically expect. In smaller chunks, we felt the abstract nature of relative priority was adequate; however, a larger group, like the backlog needs more meaning and should work much better. I guess we'll see how that works for us. Obviously, any time frames could work. We just chose some that seem to be somewhat typical on our current project.

Lastly, severity is what brought me into this whole thing. Originally, severity was all about workarounds (on this project). I never felt comfortable with this, so I suggested the following: critical, major, normal, minor, trivial, and enhancement. My guess is that most people are fine with this until they hit "enhancement." To most, a bug is a bug and an enhancement is something completely different. I disagree. I see a "bugs" as code-changing tasks that require testing. This includes simple refactoring changes. Why? Because they have to be regression tested to ensure everything works as expected. If this is skipped, you're risking breaking the app. Seriously, how many times have you saved something without checking it only to find out it either doesn't build or simply breaks logic? Yeah, I thought so. If that's not enough of a reason, then I'll stick to something everyone likes: simplicity. Bugs and enhancements are the same for the most part. Separating them just overcomplicates reporting and tracking.

I should probably modify the default bug and task templates to add some of these things in. Severity probably only works with bugs, but the status and priority concepts are arguably the same.