Home Library Learn Downloads Support Community
Sign in | United States - English | |
This topic has not yet been rated - Rate this topic

Enabling Interfacing with Microsoft Test Manager for Upgraded Team Projects

Visual Studio 2010

Updated: July 2010

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 noteImportant

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

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.

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:

  • 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].

Back to top

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

To rename a work item type

  1. On a computer where Visual Studio 2010 is installed, open a Command Prompt window.

  2. 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

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

    Copy 
    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"

Back to top

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

  1. On a computer where Visual Studio 2010 is installed, open a Command Prompt window.

  2. 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

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

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

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

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

    Copy 
    <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>

  6. Add the following Control element to the FORM section:

    Copy 
    <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.

  7. Add the following Tab element to the FORM section:

    Copy 
    <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.

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

    Copy 
    <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).

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

    Copy 
    <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.

  10. Save the XML file.

  11. Type the following command to import the MyTestCase file, substituting your data for the arguments that are shown, and then press ENTER.

    Copy 
    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.

  12. To verify the changes, in Team Explorer, right-click your team project, and then click Refresh Refresh.

  13. 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.

Back to top

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

  1. Add Link Types: SharedSteps and TestedBy

  2. Add Work Item Types: Test Case and Shared Steps

  3. Add Categories for Work Item Types

Add Link Types: SharedSteps and TestedBy

To add link types

  1. On a computer where Visual Studio 2010 is installed, open a Command Prompt window.

  2. 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

  3. 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.

    Copy 
    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 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.

    Copy 
    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.

    Copy 
    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"

    NoteNote

    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.

Back to top

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

To modify the bug type definition

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

    Copy 
    witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:bug /f:MyBug.xml

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

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

    Copy 
    <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>

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

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

    with the following syntax:

    Copy 
    <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>

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

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

  6. Delete the Tab element "Links", because you will replace it with two new tab elements.

    Copy 
    <Tab Label="Links">   <Control Type="LinksControl"/></Tab>

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

    Copy 
    <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>

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

    Copy 
    <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>

  9. Save the XML file.

  10. Type the following command to import the MyBug file, substituting your data for the arguments that are shown, and then press ENTER.

    Copy 
    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.

  11. To verify the changes, in Team Explorer , right-click your team project, and then click Refresh Refresh.

  12. Right-click Work Items, point to New Work Item, and then click Bug.

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

Back to top

Modify the Scenario or Requirement Type Definition

To modify the scenario or requirement type definition

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

    Note 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.
    Copy 
    witadmin exportwitd /collection:http://ServerName:Port/VirtualDirectoryName/CollectionName /p:project /n:bug /f:MyScenario.xml

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

  3. Delete the Tab element "Links", because you will replace it with two new tab elements that provide link control.

    Copy 
    <Tab Label="Links">   <Control Type="LinksControl"/></Tab>

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

    Copy 
    <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>

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

    Copy 
    <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>

  6. Save the XML file.

  7. Type the following command to import the MyScenario file, substituting your data for the arguments that are shown, and then press ENTER.

    Copy 
    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.

  8. To verify the changes, in Team Explorer , right-click your team project, and then click Refresh Refresh.

  9. Right-click Work Items, point to New Work Item, and then click Scenario.

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

Back to top

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

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

    Copy 
    <?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>
    NoteNote

    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.

  2. Save the file, and label it bugfieldmappings.xml.

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

    Copy 
    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

Back to top

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

Readers

Contributors

Builders

Recommended for manual testers

Recommended for test leads

View project-level information

Can view membership of project-level groups and the permissions of those members.

Project-level

 check mark check mark check mark check mark check mark

View test runs

Can view test plans in this node.

Project-level

 check mark check mark check mark check mark check mark

Create test runs

Can add and remove test results and add or modify test runs for the team project.

Project-level

check mark check mark check mark check mark

Manage test configurations

Can create and delete test configurations for the team project.

Project-level

check mark check mark

check mark

Manage test environments

Can create and delete test environments for the team project.

Project-level

check mark check mark

check mark

Delete test runs

Can delete a scheduled test for the team project.

Project-level

check mark check mark

check mark

View this node

Can view the security settings for an area node.

Area node

 check mark check mark check mark

check mark

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

check mark check mark check mark check mark

Manage test controllers

Can register and unregister test controllers for the team project collection.

Project collection

check mark

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.

Back to top

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.

Back to top

Date

History

Reason

July 2010

Added information about potential conflicts with changes in friendly names of fields. Corrected some examples for the witadmin command because they were missing a backslash in the directory path. Corrected the friendly names of several fields for managing test cases, and added Back to top links.

Customer feedback.
Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Missing closing XML > for bugfieldmappings.xml
In the section - Specifying the Bug Type to be Created in Microsoft Test Manager, Step 1, is missing the end > for the xml.

<?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>

should be (missing closing > on first line)

<?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>

also found utf-8 was the way to go.
History
Contents of the Bug Field Mappings File not optional!
Contrary to the article and name of Bug MAPPINGS, you cannot specify another field you want the Test Runner to populate. I have tried to get it to use the existing Microsoft.VSTS.CMMI.StepsToReproduce field with no avail. MVP Ed Blankenship has confirmed this, that the values are hard coded! http://www.mail-archive.com/oztfs@oztfs.com/msg00752.html
History
Microsoft.VSTS.Common.Priority field must be set to run test cases
$0In an upgraded TFS2008 project, we updated our Test Case work item type and could create test cases but not run, with the error "You cannot run the selected tests - Object reference not set to an instance of an object."$0 $0$0 $0 $0A corresponding error was found in the Application Event Log on the server (see dump at end of this comment.)$0 $0$0 $0 $0Cracked open Microsoft.TeamFoundation.TestManagement.Server in Reflector and took a look at PopulateResultFromTestCase - the only call to GetIntField wants the Microsoft.VSTS.Common.Priority field. We had removed this field from our forms so the value was empty. $0 $0 $0 $0Temporary workaround was to add the priority field to the form and set it before attempting to run. Final workaround will be to script the setting of priority=1 on all existing test work items and add a DEFAULT=1 rule for new ones. $0 $0$0 $0$0 $0$0 $0$0 $0$0 $0 $0 $0$0 $0
TF53010: The following error has occurred in a Team Foundation component or extension:
Date (UTC): 6/15/2010 3:33:25 PM
Machine: USWVRDTEAM
Application Domain: /LM/W3SVC/8080/ROOT/tfs-1-129210710667854688
Assembly: Microsoft.TeamFoundation.Framework.Server, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; v2.0.50727
Service Host: 13592eea-18bb-447c-804f-06d8c1061c45 (Lonza)
Process Details:
  Process Name: w3wp
  Process Id: 5616
  Thread Id: 8380
  Account name: USWVRDTEAM\aryan

Detailed Message: TF30065: An unhandled exception occurred.

Web Request Details
    Url: http://uswvrdteam:8080/tfs/_tfs_resources/TestManagement/v1.0/TestResults.asmx [method: POST]
    User Agent: Team Foundation (mtm.exe, 10.0.30319.1)
    Headers: Content-Length=613&Content-Type=application%2fsoap%2bxml%3b+charset%3dutf-8&Accept-Encoding=gzip&Accept-Language=en-US&Expect=100-continue&Host=uswvrdteam%3a8080&User-Agent=Team+Foundation+(mtm.exe%2c+10.0.30319.1)&X-TFS-Version=1.0.0.0&X-TFS-Session=66d1af68-876a-4608-874e-28125793c738&TF-Instance=66d1af68-876a-4608-874e-28125793c738&SOAPAction=http%3a%2f%2fschemas.microsoft.com%2fTeamFoundation%2f2007%2f02%2fTCM%2fTestResults%2f01%2fCreateTestResults
    Path: /tfs/_tfs_resources/TestManagement/v1.0/TestResults.asmx
    Local Request: False
    Host Address: 10.20.106.79
    User: USWVRDTEAM\aryan [authentication type: NTLM]

Exception Message: Object reference not set to an instance of an object. (type NullReferenceException)

Exception Stack Trace:    at Microsoft.TeamFoundation.TestManagement.Server.TestCaseResult.GetIntField(WorkItem testCase, String fieldName)
   at 
$0 $0$0 $0
History
Suggestions if you get stuck with this article

Here are some of the things to try if you get stuck with this article:

1. At step "To import the definition files for work item types", you get the following error:

-> TF212018: Work item tracking schema validation error: TF26177: The field system.ExternalLinkCount cannot be renamed from 'ExternalLinkCount' to 'External Link Count'.
-> TF212018: Work item tracking schema validation error: TF26177: The field System.IterationId cannot be renamed from 'IterationID' to 'Iteration ID'.
** There might be others message similar to this

Fix:
a. Open the XML file for TestCase.xml/SharedStep.xml and remove the spaces that is is complaining about.
b. Or export "Test Case" and "Shared Steps" from a new team project created in TFS2010 and then upload
that to your upgraded project.
First,
o> witadmin exportwitd /collection:http://Servername:8080/tfs/defaultcollection /p:new2010teamprojectname /f:"sharedstep.xml" /n:"Shared Steps"

o> witadmin exportwitd /collection:http://Servername:8080/tfs/defaultcollection /p:new2010teamprojectname/f:"testcase.xml" /n:"Test Case"
Then,
o> witadmin importwitd /collection:http://Servername:8080/tfs/upgradecollection /p:myupgraded2008Projectname /f:"SharedStep.xml"

o> witadmin importwitd /collection:http://Servername:8080/tfs/upgradecollection /p:myupgraded2008Projectname /f:"testcase1.xml"

2. Under the section "To modify the bug type definition", step 3 there is a missing "<"
From: FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" >
To : <FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" >

3. Under section "To modify the scenario or requirement type definition", step 1, the "/n:bug" section needs to be replaced with the appropriate WIT name such as "Scenario" or "Requirement".

4. Under secton "To specify the bug type to be created by Microsoft Test Manager", step 3, if you get an error
"There is no Unicode byte order mark. Cannot switch to Unicode."
Fix: Export bugfieldmapping from a new TFS2010 team project and then upload that new xml instead.
http://msdn.microsoft.com/en-us/library/ff398070.aspx

History
Importing WIT Definitions will fail on a Project migrated from TFS 2008
There are some issues with field naming not matching.  I got updated files from support.

I also agree that this is weak at best as far as help in migrating existing projects.
History
Need power tools for these procedures
I'm glad there is a process for this, but I was disappointed that the TFS 2010 configuration tools or power tools don't automate these procedures, such as adding 2010 XML elements to work item types in an upgraded project (from 2008). The manual steps are complex and error-prone, even when using the Process Editor power tool to import/export data (instead of using the witadmin command lines).

Here's my vote for wizard tools that can perform these procedures. I haven't seen any community tools for this yet (on CodePlex etc.), but I'll keep looking.

Also: The article suggested using a script to upgrade multiple projects; are there any examples of that?

Update 27-May-2010: Found a sample script at http://blogs.msdn.com/b/hakane/archive/2010/04/27/sample-script-to-enable-new-features-in-upgraded-team-projects-tfs-2010-rtm.aspx. Thanks Hakan! I haven't tried it yet, but it looks like a good starting point. Suggestions: Make it available on CodePlex, and consider morphing it into the next batch of TFS Power Tools.
History
Power Tools, please!
I agree with the previous commenter.

We appreciate the steps, but can't you provide something like you typically see in a readiness assessment or best practices wizard?  At the very least, a project-wide validation tool like you already provide at the WIT level, which will tell you about potential misconfigurations, and, most importantly, will either fix them for you, or tell you how to fix them.

I'm still struggling with a mostly-converted 2008-to-2010 project after two weeks of forum-hunting.
History