Developer Product Briefs
Customize the "Bug" Work Item Template
Learn how to customize the work item template for a bug to specify that only Testers can change the status to Closed.
Customize the "Bug" Work Item Template
Only Testers should have the power to determine if a bug has been fixed and Closed.
by Benjamin Day and Richard Hale Shaw
July 24, 2006
In an ideal world, all code compiles the first time, runs flawlessly, and deploys effortlessly. In the same world, developers will dutifully change Bug Work Items in Team Foundation Server (TFS) projects from Active to Resolved to Closed, when appropriate and in that order.
Guess what: We don't live in an ideal world.
If a user can access a Bug Work Item in a TFS project, he or she can change its status to and from any of the three default states at any time; there's no rule that says you can't change the status of a bug from Active to Closed without changing the status to Resolved first. This might be flexible (or "agile"), but it can wreak havoc on your testing process.
An Active bug should be assigned to a developer, who then sets it to Resolved after fixing it. Then a tester (or QA person) can check it and decide if it's really been fixed, in which case he or she can set it to Closed. If not, the bug can go back to Active. The point: Only Testers should have the power to determine if a bug has been fixed and Closed.
In TFS terms, a Bug Work Item's status change is known as a state transition. Each Work Item can be customized to specify the security authorization associated with state transitions. In other words, by customizing the work item template for a bug, you can specify that only Testers can change the status to Closed.
To do this, you'll first need to differentiate one kind of user from another by creating a TFS user group called "Testers." If a user is in this group, that user is in the "Tester" role on your Team Project.
Start by opening Visual Studio and connecting to TFS using Team Explorer. Then right-click on your Team Project, select Team Foundation Server Settings, and then select Group Membership. You should now see the Project Groups dialog (see Figure 1).
Click on the New button to pop up the Create New Team Foundation Server Group dialog. In the "Group name" box, type "Testers" and click on OK (see Figure 2). You've now created the Testers user group.
Work item templates are basically just XML, so you can edit them by hand, but it's a lot nicer to edit them using the Process Template Editor (PTE) that's available for download from GoDotNet. The PTE gives you a clean UI for editing the templates and also handles loading and saving templates to and from TFS.
Run the PTE, type in the name of your Team Foundation Server, and press Connect (see Figure 3). From the Work Item Types menu, select "Open from Server" then "Bug," and click on OK (see Figure 4).
You should now see the "Work Item Type Definition: Bug" page (see Figure 5). Click on the workflow tab and notice that all the available states for a Bug appear at the top and the list of transitions appears at the bottom. Click on the Resolved-to-Closed transition and click on the Open button.
When you first open this dialog (see Figure 6), you'll see that the For field is blank. This means that this state transition is unrestricted and available to anyone. Type "[Project]\Testers" in the For box and click on OK. Repeat this process for the Active-to-Closed transition.
The keyword "[Project]" is a placeholder for the name of the project. This allows TFS to ignore the specific name of your project when doing security and also helps you reuse your work item customizations across Team Projects.
After you have completed editing the transitions, click on Save on the "Work Item Type Definition: Bug" screen to upload your changes to the server.
You've finished the customization: Now bugs can be Closed only by users in the Testers group.
About the Authors
Benjamin Day is an independent consultant specializing in the design and development of Web and Windows applications using Microsoft .NET technologies. Ben also provides consulting and training on Visual Studio Team System and Team Foundation Server through The Richard Hale Shaw Group. He is a Microsoft MVP for C#, speaker at VSLive! and other conferences, and the leader of the Beantown.NET INETA User Group in Boston. When not developing software, Ben plays piano with a Boston-based jazz trio and is an enthusiastic restaurant, food, beer, and wine buff. Contact him through www.benday.com.
Richard Hale Shaw is the founder of The Richard Hale Shaw Group, which has consulted and trained software developers since 1993. He's created and chaired numerous technical conferences, including VSLive!. You can reach him at www.RichardHaleShawGroup.com.
About the Author
Benjamin Day is an independent consultant specializing in the design and development of Web and Windows applications using Microsoft .NET technologies. Ben also provides consulting and training on Visual Studio Team System and Team Foundation Server through The Richard Hale Shaw Group. He is a Microsoft MVP for C#, speaker at VSLive! and other conferences, and the leader of the Beantown.NET INETA User Group in Boston. When not developing software, Ben plays piano with a Boston-based jazz trio and is an enthusiastic restaurant, food, beer, and wine buff. Contact him through www.benday.com. Richard Hale Shaw is the founder of The Richard Hale Shaw Group, which has consulted and trained software developers since 1993. He's created and chaired numerous technical conferences, including VSLive!.