VS2010 Work item categories
With VS2010 a new concept of work item categories is introduced. Out of the box there are four different categories defined: Requirements, Bugs, Shared test steps and Tests. They are used by the MTLM (Microsoft Test and Lab Manager – the new tool for manual testing) to filter the work items that will be shown in different parts of the MTLM’s UI.
Work items of the types belonging to the Requirement category are displayed in the window shown below:
Note: Images are taken from a VS 2010 Beta 1 build.
Categories are defined as a part of the process template. The only difference between categories defined in the two default process templates is that if you are using MSF Agile the Requirement is a User Story work item type, and in the MSF CMMI it is a Requirement work item type. It is easy to change these defaults – we can add different other work item types to a category, and they will appear in the MTLM’s UI as well.
Categories are defined as a xml file. The file is generated by the witadmin command line utility (available by default in the C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE). This is the new utility replacing several other command line tools like witexport, witimport etc…
The procedure is as follows: using witadmin with argument exportcategories to create the xml description, edit it and import back using witadmin importcategories.
The description for the Agile MSF looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<cat:CATEGORIES xmlns:cat= "http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/categories">
<CATEGORY refname="Microsoft.BugCategory" name="Bug Category">
<DEFAULTWORKITEMTYPE name="Bug" />
</CATEGORY>
<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
<DEFAULTWORKITEMTYPE name="User Story" />
</CATEGORY>
<CATEGORY refname="Microsoft.SharedStepCategory" name="Shared Step Category">
<DEFAULTWORKITEMTYPE name="Shared Steps" />
</CATEGORY>
<CATEGORY refname="Microsoft.TestCaseCategory" name="Test Case Category">
<DEFAULTWORKITEMTYPE name="Test Case" />
</CATEGORY>
</cat:CATEGORIES>
Let’s expand the Requirement category and add the Bug type to it (we want to be able to define the tests testing the error causing the bug). The xml would look like this:
<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
<DEFAULTWORKITEMTYPE name="User Story" />
<WORKITEMTYPE name="Bug" />
</CATEGORY>
And the MTLM would look like this - as requirements both user stories and bugs are listed:
Shared steps are another work item category. Out of the box the Shared steps work item type is the only one belonging to this category. This category is obviously used to show shared steps during the definition of the Test.
That’s it. Work item categories are just one additional level of indirection allowing for some flexibility in the MTLM.
Work items of the types belonging to the Requirement category are displayed in the window shown below:
Note: Images are taken from a VS 2010 Beta 1 build.
Categories are defined as a part of the process template. The only difference between categories defined in the two default process templates is that if you are using MSF Agile the Requirement is a User Story work item type, and in the MSF CMMI it is a Requirement work item type. It is easy to change these defaults – we can add different other work item types to a category, and they will appear in the MTLM’s UI as well.
Categories are defined as a xml file. The file is generated by the witadmin command line utility (available by default in the C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE). This is the new utility replacing several other command line tools like witexport, witimport etc…
The procedure is as follows: using witadmin with argument exportcategories to create the xml description, edit it and import back using witadmin importcategories.
The description for the Agile MSF looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<cat:CATEGORIES xmlns:cat= "http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/categories">
<CATEGORY refname="Microsoft.BugCategory" name="Bug Category">
<DEFAULTWORKITEMTYPE name="Bug" />
</CATEGORY>
<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
<DEFAULTWORKITEMTYPE name="User Story" />
</CATEGORY>
<CATEGORY refname="Microsoft.SharedStepCategory" name="Shared Step Category">
<DEFAULTWORKITEMTYPE name="Shared Steps" />
</CATEGORY>
<CATEGORY refname="Microsoft.TestCaseCategory" name="Test Case Category">
<DEFAULTWORKITEMTYPE name="Test Case" />
</CATEGORY>
</cat:CATEGORIES>
Let’s expand the Requirement category and add the Bug type to it (we want to be able to define the tests testing the error causing the bug). The xml would look like this:
<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
<DEFAULTWORKITEMTYPE name="User Story" />
<WORKITEMTYPE name="Bug" />
</CATEGORY>
And the MTLM would look like this - as requirements both user stories and bugs are listed:
Shared steps are another work item category. Out of the box the Shared steps work item type is the only one belonging to this category. This category is obviously used to show shared steps during the definition of the Test.
That’s it. Work item categories are just one additional level of indirection allowing for some flexibility in the MTLM.
0 Comments:
Post a Comment
<< Home