Enabling Interfacing with Microsoft Test Manager for Upgraded Team Projects

Article
02/04/2013

You must add the new work item types, test case and shared steps, to your upgraded team project to use Microsoft Test Manager. A team uses test cases to define both manual and automated tests that can be run and managed by using Microsoft Test Manager. Microsoft Test Manager is available with Visual Studio 2010 Ultimate and Visual Studio Test Professional 2010. These test tools are integrated with Visual Studio Team Foundation Server, which lets you define your tests based on the same team projects that other areas of your organization use.

The work item types, test case, and shared steps are included in the process templates for Microsoft Solutions Framework (MSF). For more information, see the following topics:

In addition to the new work item types, you must add link types and categories that are provided with version 5.0 of the MSF process templates. You must customize existing work item types to have the new fields appear on the work item forms. You must also upload a mapping file that specifies the work item type to support automatic creation of bugs or code defects by Microsoft Test Manager.

Important

You should upgrade your existing team project after your deployment has been updated to Team Foundation Server 2010.

This topic provides the steps that you must follow to upgrade a single team project to interface with Microsoft Test Manager. After you perform the upgrade steps, you can use the information to script the upgrade of multiple projects and to add the new features to the custom process template of your organization.

In this topic

About Work Item Names, Work Item Fields, and Potential Conflicts
Renaming a Type of Work Item
Customizing an Existing Test Case Type of Work Item
Download the Process Template: MSF for Agile Software Development v5.0
Adding Work Item Tracking Objects
Modify Work Item Type Definitions
Specifying the Bug Type to be Created in Microsoft Test Manager
Granting Permissions to Test Team Members
Launching Microsoft Test Manager

Required Permissions

To perform these procedures, you must have the following permissions:

To download a process template, you must be a member of the Project Collection Administrators group. If the required security permissions are set explicitly, your Manage process template permission for the team project collection must be set to Allow.
To run the witadmin and tcm command-line tools, you must be a member of the Team Foundation Administrators group or a member of the Project Administrators group for the project.
To grant permissions, you must be a member of the administrative group at the level of the group that you want to change. For example, if you want to change permissions for a group or user at the team project collection level, you must be a member of the Project Collection Administrators group for that collection, or your Edit Collection-Level Information permission must be set to Allow.

For more information, see Team Foundation Server Permissions.

About Work Item Names, Work Item Fields, and Potential Conflicts

When you modify the definition of a work item type, you may encounter the following potential conflicts:

You have a work item type whose name conflicts with the name of a work item type that you must import. For example, you may already have a work item type that is labeled "test case."

You can resolve a work item type name conflict either by renaming a work item type or by customizing the existing work item type to contain the new work item controls to support Microsoft Test Manager. For more information, see the following sections later in this topic:
- Renaming a Type of Work Item
- Customizing an Existing Test Case Type of Work Item
You may have a field that is defined in a work item type that is used by other team projects in one or more of the project collections that are defined for the Team Foundation deployment. If the attributes that are assigned to reportable fields differ across team projects in the deployment, data conflicts can occur when the data warehouse is processed. For more information, see Resolving Schema Conflicts That Are Occurring in the Data Warehouse.
When you import types of work items, an error message might indicate a naming conflict. This conflict occurs more frequently in deployments that were upgraded from an earlier release of Team Foundation. The friendly name was renamed for several system and test case management fields before the final release of Visual Studio Team Foundation Server 2010. System fields that were renamed include System.AreaID, System.IterationID, System.HyperLinkCount, System.ExternalLinkCount, and System.AttachedFileCount.

You can resolve this error by renaming the field either in the XML definition for a work item type or by using the witadmin changefield command-line tool. For more information, see Managing Work Item Fields [witadmin].

Renaming a Type of Work Item

You can resolve a work item type name conflict by renaming a work item type.

To rename a work item type

On a computer where Visual Studio 2010 is installed, open a Command Prompt window.
Change to the directory that contains the witadmin command-line tool by typing the following command and then pressing ENTER.

cd Drive:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE
Type the following command, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin renamewitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:CurrentName /new:NewName
```
The following command shows an example of how to rename the Test Case work item type to My Test Case:

witadmin renamewitd /collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject /n:"Test Case" /new:"My Test Case"

Customizing an Existing Test Case Type of Work Item

If your existing team project contains a work item type that you use to manage test cases, you can customize it to support the new controls that are required to interface with Microsoft Test Manager. Otherwise you can import the test case type of work item that is described in Add Work Item Types: Test Case and Shared Steps later in this topic.

To customize an existing test case work item type

On a computer where Visual Studio 2010 is installed, open a Command Prompt window.
Change to the directory that contains the witadmin command-line tool by typing the following command and then pressing ENTER.

cd Drive:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

Type the following command, substituting your data for the arguments that are shown, and then press ENTER.

witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:"Test Case" /f:MyTestCase.xml

In Visual Studio or a text editor, open the MyTestCase.xml file.

Add the following FIELD elements in the FIELDS section of the XML file, as the following excerpt shows:

<FIELD name="Steps" refname="Microsoft.VSTS.TCM.Steps" type="HTML">
       <HELPTEXT>Steps required to perform the test</HELPTEXT>
</FIELD>
<FIELD name="Automated Test Name" refname="Microsoft.VSTS.TCM.AutomatedTestName" type="String" >
       <HELPTEXT>The name of the test that automates this test case</HELPTEXT>
</FIELD>
<FIELD name="Automated Test Storage" refname="Microsoft.VSTS.TCM.AutomatedTestStorage" type="String" >
       <HELPTEXT>The assembly containing the test that automates this test case</HELPTEXT>
</FIELD>
<FIELD name="Automated Test Id" refname="Microsoft.VSTS.TCM.AutomatedTestId" type="String" >
       <HELPTEXT>The ID of the test that automates this test case</HELPTEXT>
</FIELD>
=<FIELD name="Automated Test Type" refname="Microsoft.VSTS.TCM.AutomatedTestType" type="String" >
       <HELPTEXT>The type of the test that automates this test case</HELPTEXT>
</FIELD>
<FIELD name="Parameters" refname="Microsoft.VSTS.TCM.Parameters" type="HTML" />
<FIELD name="Local Data Source" refname="Microsoft.VSTS.TCM.LocalDataSource" type="HTML" />
<FIELD reportable="detail" type="String" name="Automation status" refname="Microsoft.VSTS.TCM.AutomationStatus">
       <WHEN field="Microsoft.VSTS.TCM.AutomatedTestId" value="">
         <ALLOWEDVALUES>
           <LISTITEM value="Not Automated" />
           <LISTITEM value="Planned" />
         </ALLOWEDVALUES>
         <DEFAULT from="value" value="Not Automated" />
       </WHEN>
       <WHENNOT field="Microsoft.VSTS.TCM.AutomatedTestId" value="">
         <ALLOWEDVALUES>
           <LISTITEM value="Automated" />
         </ALLOWEDVALUES>
         <COPY from="value" value="Automated" />
       </WHENNOT>
</FIELD>

Add the following Control element to the FORM section:

<Control FieldName="Microsoft.VSTS.TCM.AutomationStatus" Type="FieldControl" Label="Automation Status:" LabelPosition="Left" />

You can add this to the top section of the work item form.

Add the following Tab element to the FORM section:

<Tab Label="Steps">
           <Control FieldName="Microsoft.VSTS.TCM.Steps" Type="Test Steps Control" LabelPosition="Top" Dock="Fill" />
         </Tab>

You should add this as the first tab in the group of tabs that are defined in the FORM section.

Add the following Tab element to the FORM section of the XML definition file:

<Tab Label="Tested Work Items">
   <Control Type="LinksControl" Name="Tested">
      <LinksControlOptions>
      <WorkItemLinkFilters FilterType="include">
      <Filter LinkType="Microsoft.VSTS.Common.TestedBy" FilterOn="reversename"/>
      </WorkItemLinkFilters>
      <ExternalLinkFilters FilterType="excludeAll"/>
         <LinkColumns>
                 <LinkColumn RefName="System.ID" />
                 <LinkColumn RefName="System.WorkItemType" />
                 <LinkColumn RefName="System.Title" />
                 <LinkColumn RefName="System.AssignedTo" />
                 <LinkColumn RefName="System.State" />
                 <LinkColumn LinkAttribute="System.Links.Comment" />
           </LinkColumns>
      </LinksControlOptions>
   </Control>
</Tab>

This element is used to restrict the formation of link relationships in this tab to include only the TestedBy link type. This tab is typically used to create link relationships to work items that are tested, which are usually user stories, scenarios, or requirements. For more information, see Linking Work Items (Agile).

Add the following Tab element to the FORM section of the XML definition file:
```
<Tab Label="Associated Automation">
    <Control Type="AssociatedAutomationControl" LabelPosition="Top" Dock="Fill" />
</Tab>
```
This element is used to support the association of a test case with an automated test. For more information, see How to: Associate an Automated Test with a Test Case.
Save the XML file.
Type the following command to import the MyTestCase file, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:MyTestCase.xml
```
When the import has completed successfully, the following message appears:

The work item type import has been completed.
To verify the changes, in Team Explorer, right-click your team project, and then click Refresh.
Right-click Work Items, point to New Work Item, and then click Test Case.

Verify that the new fields and changes to the work item form appear.

Download the MSF for Agile Software Development v5.0 Process Template

Download version 5.0 of the MSF process template. For more information, see Download Version 5.0 of the MSF Process Templates.

Adding Work Item Tracking Objects

To add objects for tracking work items, you must follow these steps in the indicated sequence:

Add Link Types: SharedSteps and TestedBy
Add Work Item Types: Test Case and Shared Steps
Add Categories for Work Item Types

Add Link Types: SharedSteps and TestedBy

To add link types

On a computer where Visual Studio 2010 is installed, open a Command Prompt window.
Change to the directory that contains the witadmin command-line tool by typing the following command and then pressing ENTER.

cd Drive:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE
To import the link type definition files, type the following two commands, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin importlinktype /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /f:"DirectoryPath\TestedBy.xml"
witadmin importlinktype /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /f:"DirectoryPath\SharedStep.xml"
```
For DirectoryPath, specify the location of the LinkTypes folder for the process template that you downloaded. The directory path should follow this structure:

Drive:\MSFTemplateFolder\Agile\Files\WorkItem Tracking\LinkTypes

The following command shows an example of how to import the TestedBy link type:

witadmin importlinktype /collection:"http://MyServer:8080/tfs/Collection0" /f:"C:\MyTemplates\Agile\Files\WorkItem Tracking\LinkTypes\TestedBy.xml"

Add Work Item Types: Test Case and Shared Step

Note

If you have modified an existing test case type of work item, as described in Customizing an Existing Test Case Type of Work Item earlier in this topic, you have to import only the shared step type of work item.

To import the definition files for work item types

In the Command Prompt window, type the following two commands, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:"DirectoryPath\TestCase.xml"
witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:"DirectoryPath\SharedStep.xml"
```
For DirectoryPath, specify the directory location of the TypeDefinitions folder for the process template that you downloaded. The directory path should follow this structure:

Drive:\MSFTemplateFolder\Agile\Files\WorkItem Tracking\TypeDefinitions

The following command shows an example of how to import the TestCase type definition file:

witadmin importwitd /collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject /f:"C:\MyTemplates\Agile\Files\WorkItem Tracking\TypeDefinitions\TestCase.xml"

Add Categories for Work Item Types

To import the definition files for categories

In the Command Prompt window, type the following command, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin importcategories /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:"DirectoryPath\categories.xml"
```
For DirectoryPath, specify the location of the WorkItem Tracking folder for the process template that you downloaded. The directory path should follow this structure:

Drive:\MSFTemplateFolder\Agile\Files\WorkItem Tracking\

The following command shows an example of how to import definition files for categories:

witadmin importcategories /collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject /f:"C:\MyTemplates\Agile\Files\WorkItem Tracking\categories.xml"

Note

Importing the categories XML file into a project will overwrite all existing categories. Categories that were previously defined but not specified in the file will be deleted.

Modify Work Item Type Definitions

You must modify the type definitions for the work item types for bug and for either scenario or requirement. You must add two fields to the bug definition and then add form controls to both definition types.

Perform the following tasks:

Modify the Bug Type Definition
Modify the Scenario or Requirement Type Definition

Modify the Bug Type Definition

To modify the bug type definition

In the Command Prompt window, type the following command, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:bug /f:MyBug.xml
```
In Visual Studio or a text editor, open the MyBug.xml file.

Add the following FIELD elements in the FIELDS section of the XML file:

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" >
   <HELPTEXT>Test context, provided automatically by test infrastructure</HELPTEXT>
</FIELD>
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML">
   <HELPTEXT>How to see the bug. End by contrasting expected with actual behavior.
   </HELPTEXT>
</FIELD>

Replace the following Tab element that is labeled "History":

<Tab Label="History">
<Control Type="WorkItemLogControl" FieldName="System.History" Label="&amp;History:" LabelPosition="Top" Dock="Fill"/>
</Tab>

with the following syntax:

<Tab Label="History">
   <Group>
      <Column PercentWidth="50">
      <Control FieldName="Microsoft.VSTS.TCM.ReproSteps" Type="HtmlFieldControl" Label="Steps to Repro&amp;duce:" LabelPosition="Top"  MinimumSize="(100,200)"  Dock="Fill"/>
      </Column>
      <Column PercentWidth="50">
      <Control FieldName="System.History" Type="WorkItemLogControl" Label="&amp;History:" LabelPosition="Top" Dock="Fill" />
      </Column>
   </Group>
</Tab>

Add the Control element after the Group element in the Tab that is labeled "Details" under the FORM section in the XML file:

<Tab Label="Details">
   <Group>
. . . 
    </Group>
<Control FieldName="Microsoft.VSTS.TCM.SystemInfo" Type="HtmlFieldControl" Label="System I&amp;nfo:" LabelPosition="Top" Dock="Fill" />
</Tab>

Delete the Tab element "Links", because you will replace it with two new tab elements.
```
<Tab Label="Links">   <Control Type="LinksControl"/></Tab>
```

Add a Tab element after the Details tab in the FORM section by using the following syntax:

<Tab Label="Test Cases" >
   <Control Type="LinksControl" Name="TestedBy" Label="Test &amp;Cases testing this Bug:" LabelPosition="Top">
      <LinksControlOptions>
         <WorkItemLinkFilters FilterType="include">
            <Filter LinkType="Microsoft.VSTS.Common.TestedBy" FilterOn="forwardname" />
            </WorkItemLinkFilters>
            <WorkItemTypeFilters FilterType="include">
            <Filter WorkItemType="Test Case" />
            </WorkItemTypeFilters>
            <ExternalLinkFilters FilterType="excludeAll"/>
                <LinkColumns>
                  <LinkColumn RefName="System.ID" />
                  <LinkColumn RefName="System.WorkItemType" />
                  <LinkColumn RefName="System.Title" />
                  <LinkColumn RefName="System.AssignedTo" />
                  <LinkColumn RefName="System.State" />
                  <LinkColumn LinkAttribute="System.Links.Comment" />
              </LinkColumns>
        </LinksControlOptions>
   </Control>
</Tab>

Add a Tab element after the Test Cases tab by using the following syntax:

<Tab Label="All Links" >
   <Control Type="LinksControl" Name="GeneralLinks">
      <LinksControlOptions>
         <LinkColumns>
         <LinkColumn RefName="System.ID" />
         <LinkColumn RefName="System.WorkItemType" />
         <LinkColumn RefName="System.Title" />
         <LinkColumn RefName="System.AssignedTo" />
         <LinkColumn RefName="System.State" />
         <LinkColumn LinkAttribute="System.Links.Comment" />
         </LinkColumns>
      </LinksControlOptions>
   </Control>
</Tab>

Save the XML file.
Type the following command to import the MyBug file, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:MyBug.xml
```
When the import has completed successfully, the following message appears:

The work item type import has been completed.
To verify the changes, in Team Explorer , right-click your team project, and then click Refresh.
Right-click Work Items, point to New Work Item, and then click Bug.
Verify that the new fields and changes to the work item form appear.

Modify the Scenario or Requirement Type Definition

To modify the scenario or requirement type definition

In the Command Prompt window, type the following command, substituting your data for the arguments shown, and then press ENTER.

Note

This example references the scenario work item type. If your team project is based on the CMMI process template, substitute the requirement or other type of work item that you use to track product features. If your team project does not have a requirement, you can import the user story or requirement type definition files that are provided with version 5.0 of the MSF process templates. For more information, see Export and Import Work Item Types from an Existing Project.
```
witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:bug /f:MyScenario.xml
```
In Visual Studio or a text editor, open the MyScenario.xml file.
Delete the Tab element "Links", because you will replace it with two new tab elements that provide link control.
```
<Tab Label="Links">   <Control Type="LinksControl"/></Tab>
```

Add the following Tab element in the FORM section of the XML file:

<Tab Label="Test Cases" >
   <Control Type="LinksControl" Name="TestedBy" Label="&amp;Work items testing this Story:" LabelPosition="Top">
   <LinksControlOptions>
      <WorkItemLinkFilters FilterType="include">
         <Filter LinkType="Microsoft.VSTS.Common.TestedBy" FilterOn="forwardname" />
      </WorkItemLinkFilters>
      <WorkItemTypeFilters FilterType="include">
      <Filter WorkItemType="Test Case" />
      </WorkItemTypeFilters>
      <ExternalLinkFilters FilterType="excludeAll"/>
      <LinkColumns>
         <LinkColumn RefName="System.ID" />
         <LinkColumn RefName="System.WorkItemType" />
         <LinkColumn RefName="System.Title" />
         <LinkColumn RefName="System.AssignedTo" />
         <LinkColumn RefName="System.State" />
         <LinkColumn LinkAttribute="System.Links.Comment" />
      </LinkColumns>
      </LinksControlOptions>
   </Control>
</Tab>

Add the following Tab element in the FORM section of the XML file:

<Tab Label="Other Links" >
   <Group>
      <Column PercentWidth="100">
         <Control Type="LinksControl" Name="GeneralLinks">
         <LinksControlOptions>
         <WorkItemLinkFilters FilterType="exclude">
         <Filter LinkType="System.LinkTypes.Hierarchy"   />
         <Filter LinkType="Microsoft.VSTS.Common.TestedBy" />
         <Filter LinkType="Microsoft.VSTS.TestCase.SharedStepReferencedBy" />
         </WorkItemLinkFilters>
         <LinkColumns>
            <LinkColumn RefName="System.ID" />
            <LinkColumn RefName="System.WorkItemType" />
            <LinkColumn RefName="System.Title" />
            <LinkColumn RefName="System.AssignedTo" />
            <LinkColumn RefName="System.State" />
            <LinkColumn LinkAttribute="System.Links.Comment" />
         </LinkColumns>
      </LinksControlOptions>
   </Control>
   </Column>
</Group>
</Tab>

Save the XML file.
Type the following command to import the MyScenario file, substituting your data for the arguments that are shown, and then press ENTER.
```
witadmin importwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /f:MyScenario.xml
```
When the import has completed successfully, the following message appears:

The work item type import has been completed.
To verify the changes, in Team Explorer , right-click your team project, and then click Refresh.
Right-click Work Items, point to New Work Item, and then click Scenario.
Verify that the new fields and changes to the work item form appear.

Specifying the Bug Type to be Created in Microsoft Test Manager

To support the automatic creation of a work item to track code defects or bugs that are found when a test team member uses Microsoft Test Manager, you must specify the bug type to be used for your existing team project. The tcm bugfieldmapping command supports the import and export of a mapping file to the team project. The mapping file defines the type of work item to create and the three data fields to be filled by Microsoft Test Manager. The three fields are reproducible steps, system information, and the build in which the defect was found. When a tester runs a test and finds a defect, they can create a bug in which the three fields are automatically filled.

For more information, see Specifying the Bug Type to File By Using Microsoft Test Manager.

To specify the bug type to be created by Microsoft Test Manager

Open Notepad or a text editor, and copy the following code into the file:

<?xml version="1.0" encoding="utf-16"?
<BugFilerMappings workitemtypetocreate="Bug">
   <ReproSteps>Microsoft.VSTS.TCM.ReproSteps</ReproSteps>
   <SystemInformation>Microsoft.VSTS.TCM.SystemInfo</SystemInformation>
   <BuildFoundIn>Microsoft.VSTS.Build.FoundIn</BuildFoundIn>
</BugFilerMappings>

Note

If the work item type that you use to create code defects is labeled something other than "Bug," replace "Bug" in the previous example with the name of that work item type.

Save the file, and label it bugfieldmappings.xml.
In the Command Prompt window, type the following command, substituting your data for the arguments that are shown, and then press ENTER.
```
tcm bugfieldmapping /import /mappingfile:"DirectoryPath\bugfieldmappings.xml" /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /teamproject:project
```
For DirectoryPath, specify the the folder where you saved the bugfieldmappings.xml file.

The following command shows an example for importing the bugfieldmappings.xml file:

tcm bugfieldmapping /import /mappingfile:"C:\MyFiles\bugfieldmappings.xml" collection:"http://MyServer:8080/tfs/Collection0" /p:MyProject

Granting Permissions to Test Team Members

You must grant permissions to team members who will manage test environments and test configurations, create and view test runs, and perform other tasks.

The following table describes the permissions that control access to test functions and support interfacing with the team project for testing. It also indicates the default assignments that are made in version 5.0 of the MSF process templates, in addition to the recommended permissions to grant manual testers and test leads.

Permission	Description	Scope
View project-level information	Can view membership of project-level groups and the permissions of those members.	Project-level
View test runs	Can view test plans in this node.	Project-level
Create test runs	Can add and remove test results and add or modify test runs for the team project.	Project-level
Manage test configurations	Can create and delete test configurations for the team project.	Project-level
Manage test environments	Can create and delete test environments for the team project.	Project-level
Delete test runs	Can delete a scheduled test for the team project.	Project-level
View this node	Can view the security settings for an area node.	Area node
Manage test plans	Can create and edit test plans that are assigned to an area node. If test plans have not been run, you can also delete them.	Area node
Manage test controllers	Can register and unregister test controllers for the team project collection.	Project collection

You can grant permissions by following the procedures that are indicated for the specific scope area:

You can set project-level permissions in Team Explorer by right-clicking the project, clicking Team Project Settings, and then clicking Security. You can also set these permissions by using the TFSSecurity command-line tool. For more information, see Managing Permissions.
You can set area node permissions in Team Explorer by right-clicking the project, clicking Areas and Iterations, clicking the Area tab, and then clicking Security. For more information, see Create and Modify Areas and Iterations.
You can set project collection permissions by right-clicking the server in Team Explorer and then clicking Security, by opening and using the administration console for Team Foundation, or by using the TFSSecurity and tf command-line tools. For more information, see Collection-Level Groups.

For more information, see Change Permissions for a Group or User.

Launching Microsoft Test Manager

After you have completed the upgrade tasks that are described earlier in this topic, you can start Microsoft Test Manager, connect to your project, and start to plan your test efforts. For more information, see Testing the Application.