In TFS 2010/2012, how do you classify bugs?

Question

In TFS (2010 and up at least), we have the concept of iteration, which seems to be supposed to help assigning work (what do we do in release 1.0, what is planned for 1.1 and what is left in the backlog). I have to mention I've been looking at the Scrumm template for TFS2012.

Now, how do you classify bugs by product version? For example, imagine we have the a product with v1.0 and v2.0 in the wild and v3.0 in developpment.

Now, we discover a bug in v1.0, and it turns out v2.0 and v3.0 also contains the bug.

Code-wise, we'll correct the bug in dev, then merge it to v1.1 and v2.1 so that our current users are not left in the cold with their version (because we cannot always mandate upgrading to the latest version).

When creating a bug in TFS, we have the option of indicating an iteration path. But we can only use one iteration, whereas we need to be able to declare the bug as existing in all three version, and mark it as corrected independently as the merges happen.

Is there any way to support that way of working in TFS, or am I looking at it wrong?

Answer 1

One way to accomplish this would be to modify the default Work Item Type for Bug in TFS:

1. In VS 2010, open the editor by choosing Tools > Process Editor > Types > Open WIT From Server from the main menu

2. In the Select Work Item Type dialog, expand the Team Project that you would like this template to apply to, select Bug and click OK.

3. When the editor opens, you'll see a list of all available fields for the Bug work item. You should notice a Found In field available in the list. By providing the version number(s) in this field, it should be pretty easy to write queries that can find bugs by version.

4. To display this field, choose the Layout tab to bring up the form editor. It's basically just a big tree view. Expand the group for Group - Classification (or wherever you think this field is most appropriate), right-click Column and choose New Control

5. In the attributes panel, choose Found In for the Field Name, and also update the label.

6. Choose Preview Form to test your changes, then save and close the editor

Answer 2

There are a number of ways around this, depending on how you choose to approach it. One is to not use the standard Areas field (Mike C suggests a good alternative). Another is to create work items to more accurately reflect the state of the work you're doing. What I mean is this:

If you're releasing a fix across three different versions of your software, I'd assume that you'd want to test it against all three versions to assume the fix is consistent across all of the codebases. A fix that worked in V1.0 may not work the same in V3.0 because the surrounding/affected code may be different.

At some point in that process you could therefore have three separate (but linked) representations of the bug: maybe three copies of the bug itself, or three test cases (one per version that the bug should be tested on) all linked to the original bug. Then, if the bug is fixed in V1.0 but requires more work to be fixed in V3.0, your work items accurately reflect this.