Test Case

A team uses test cases to define both manual and automated tests that can be run and managed by using Microsoft Test Manager. By using Microsoft Test Manager, you can create not only test cases but also test suites and test configurations that support testing your project. You can use test configurations to define how you want to run your test cases and test suites. You can group your test cases together by organizing them into a hierarchy of test suites in your test plan. By creating test suites, you can run sets of test cases as a group. For more information, see Defining Your Testing Effort Using Test Plans.

Note

You can define a test case by using Team Explorer, but it is best if you define test cases by using Microsoft Test Manager. You can access Microsoft Test Manager from Visual Studio Premium, Visual Studio Ultimate, or Visual Studio Test Professional. For more information, see Creating and Managing Tests.

To define the sequence of action steps that define a manual test or a set of shared steps, you must use Microsoft Test Manager. You can view and modify other fields that are defined for test cases and shared steps by using Team Explorer or Team Web Access. However, you cannot modify the fields that appear on the Steps tab in these clients.

If you upgraded a team project, you may need to perform additional tasks before you can use test cases and interface with Microsoft Test Manager. For more information, see Enabling Interfacing with Microsoft Test Manager for Upgraded Team Projects.

Many tests require the tester to perform the same sequence of steps for multiple test cases. By creating shared steps, you can define a sequence of steps once and insert it into many test cases. For example, if each test case requires a tester to log on to the application, you can create a set of shared steps to perform these actions. You can then add the shared steps to each test case and run the steps by using Test Runner. Because you use shared steps only to streamline the definition of manual test cases, you should use Microsoft Test Manager to create shared steps. For more information, see How to: Share Common Test Case Steps Using Shared Steps.

In this topic

Related topics

Defining a Test Case Linking a Test Case to a User Story Adding Attachments or Hyperlinks to a TestCase Changing the State of a Test Case

Agile Processes Test Early and Often Agile Reports (Reporting Services) Test Case Readiness Report Test Plan Progress Report Stories Overview Report (Agile) Field Reference Titles, IDs, Descriptions, and History Field Reference Assignments and Workflow Field Reference Planning, Ranking, and Priorities Field Reference Build and Test Integration Field Reference Areas and Iterations Field Reference Link Controls, Restrictions, and Field Reference Attachment Controls and Field Reference

Required Permissions

To view a test case, you must be a member of the Readers group or your View work items in this node must be set to Allow. To create or modify a test case, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining a Test Case

You can define a test case by using Team Explorer or Team Web Access and later add it to a test plan by using Microsoft Test Manager. When you define a test case, you specify the fields that the following illustration shows.

When you define a test case, all fields are optional except for Title.

You can always modify fields and add more detail as you work on the test case. To perform this procedure by using Microsoft Test Manager, see How to: Create a Manual Test Case.

To define a test case

1. In the top section of the work item form for a test case, specify one or more of the following fields:

   • (Required) In Title, type a descriptive phrase that defines the criteria to test.

   • In the Assigned To list, click the appropriate owner for the test case.

     Note

     You can assign work items only to members of the Contributors group.

     If you leave the test case unassigned, it is automatically assigned to you.

   • In the State list, leave the default value, Design.

     Note

     You can run a test case that is in the Design state.

   • In the Priority list, click the level of importance for the test case on a scale of 1 (most important) to 4 (least important).

     The default value of this field is 2.

   • In Automation Status, leave the default value, Not Automated, for manual cases, or click Planned if you plan to automate the test case.

     Note

     If you add an automation method from the Associated Automation tab, the value of this field is automatically updated to Automated. For more information about how to convert a manual test case into an automated test case, see Associating an Automated Test with a Manual Test Case.

   • In the Area list, click the appropriate area in the team project for the test case.

     This value should match the area that is specified for the user story that the test case addresses. The default value is the top area node that is defined for the project.

   • In the Iteration list, click the iteration in your team project for the test case.

     The default value is the top iteration node that is defined for the project.

     Note

     The project administrator for each team project defines Area and Iteration paths for that project so that the team can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

2. Click the SUMMARY tab, and specify one or both of the following fields:

   • In Description, provide as much detail as you want to describe the test case.

   • In History, add comments that you want to capture as part of the historical record.

     Every time that a team member updates the work item, its history shows the date of the change, the team member who made the change, and the fields that changed.

3. Link the test case to the user story that it tests.

   For more information, see Linking a Test Case to a User Story later in this topic.

4. Click Save Work Item.

   Note

   After you save the test case, the identifier appears under the work item toolbar.

5. On the STEPS tab, click Edit with Microsoft Test Manager to define the action and validation steps and parameters to be performed as part of the test.

   Microsoft Test Manager will open and display the test case.

   Note

   You can define test steps only by using Microsoft Test Manager.

   For more information, see Creating and Managing Tests.

Linking a Test Case to a User Story

You link test cases to a user story to track the progress of testing made for the user story. After you have defined your test cases, you can link them to the user stories that they implement by using the following procedure. For information about how to perform this procedure by using Microsoft Test Manager, see How to: Add Product Backlog Items, User Story, or Requirements Work Items to Your Test Plan.

To link a test case to a user story

1. Click the Tested Work Items tab.

   

2. Click Link to.

   The Add Link to Test Case dialog box opens.

3. In the Link Type list, leave the default value, Tests.

   You can specify only the Tests type of link when you create a link from the Tested Work Items tab.

4. Click Browse.

   The following dialog box appears:

   

5. In the Saved query list, click the Open User Stories team query, and then click Find.

6. Select the check box next to the user story to which you want to link to the test case.

   For more information, see Find Work Items to Link or Import.

7. (Optional) In the Comment text box, type a description for the link.

8. Click OK.

9. Click Save Work Item.

   Note

   Both the user story and test case that you linked are updated. A Tested By link is added to the user story.

Adding Details, Attachments, or Hyperlinks to a Test Case

You can add information to a test case that provides more information to implement the test case. You add details to test cases in the following ways:

• In the Description or History field, type information.

• Attach a file.

  For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

• Add a hyperlink to Web site or to a file that is stored on a server or Web site.

To add details to a test case

1. Click the Summary tab.

2. In Description, type information.

3. (Optional) In the History field, type information.

   You can format information to provide emphasis or capture a bulleted list. For more information, see Titles, IDs, Descriptions, and History Field Reference.

4. Click Save Work Item.

To add an attachment to a test case

1. Click the Attachments tab.

   

2. Perform one of the following actions:

   • Drag a file into the attachment area.

   • Click or press CTRL-V to paste a file that you have copied.

   • Click Add, click Browse, and, in the Attachment dialog box, type or browse to the name of the file that you want to attach.

     (Optional) In the Comment box, type additional information about the attachment. To close the Attachment dialog box, click OK.

3. Click Save Work Item.

To add a hyperlink to a test case

1. Click the Other Links tab.

   

2. Click Link to.

   

3. In the Link Type list, click Hyperlink.

4. In the Address box, type the address of the target of the link.

5. If the target is a Web site, type the URL, or copy it from your Internet browser and paste it into the Address box. If the target is a server location, type the address in the form of a UNC name.

6. (Optional) In the Comment box, type additional information about the hyperlink.

7. Click OK.

8. Click Save Work Item.

Changing the State of a Test Case

When you create a test case, its state is automatically set to Design. You change the state to Ready after you define all action and validation steps for the test case and the test case is approved as ready to run. When a test case is no longer required, you change its state from Ready to Closed. For more information about data fields that track state changes, see Assignments and Workflow Field Reference.

For information about how to perform this procedure by using Microsoft Test Manager, see How to: Change the State of a Test Case to Closed. You can edit multiple test cases at the same time in Office Excel by opening the Open Test Cases team query and updating the State field for those test cases that you want to update. 

After you save a test case, you can change its state to one of those that the following procedure describes.

To change the state of a test case

1. Open the test case.

2. In the State list, click one of the following values:

   • Design: The test case is being designed and has not yet been reviewed and approved.

     Note

     You can run a test case that is in the Design state.

   • Ready: The test case has been reviewed and approved and is ready to be run.

   • Closed: The test case is no longer required for future iterations of this team project.

3. In the Reason list, leave the default value, Obsolete. If you are closing the test case for some other reason, click Deferred or Duplicate.

4. Click Save Work Item.

Typical workflow progression: A team member creates a test case in the Design state with a default reason of New, A team member changes the state of a test case from Design to Ready to indicate that it is ready to be used for acceptance testing of the user stories it tests. A team member changes the state of a test case from Ready to Closed to indicate that it is no longer being used. Additional workflow transitions states: A team member changes the state of a test case from Design to Closed to indicate that a test case that has been defined for a user story is not relevant or is a duplicate of another test case. A team member changes the state of a test case from Ready to Design to indicate that additional test criteria has been discovered that must be added to a test case. A team member changes the state of a test case from Closed to Design to indicate that a test case was closed in error or the user story that it tests is now in scope.

Test Case State Diagram

Design [New]

A team member creates a test case, provides a descriptive title, and defines the steps and parameters to run. After the team member has defined all steps for the test case and it is ready to run, the team member changes the state from Design to Ready.

The following data fields are automatically captured when a team member creates a test case:

• Assigned To: Name of the team member who created the test case.

• Created By: Name of the team member who created the test case.

• Created Date: Date and time when the test case was created, as recorded by the server clock.

From Design to Ready

When you can change the state of a test case from Design to Ready, the Reason field is automatically set to Completed.

Reason	When to use	Additional actions to take
Completed	All action and validation steps for the test case are defined.	Review the test cases that are defined for similar user stories to determine whether you can define any shared steps that will minimize maintenance of the test cases.

From Design or Ready to Closed

You can close a test case from the Design or Ready state because of one of the following reasons:

Reason	When to use	Additional actions to take
Obsolete (default)	The test case is no longer required for acceptance testing of user stories.	Verify that all user stories that are linked to the test case are in a Closed state.
Deferred	The test case will not be run during the current product cycle or iteration. You can also specify this reason when the user story that is being tested is Closed because it is Out of Scope or Abandoned.	None.
Duplicate	When the test case duplicates another test case.	Create a link to the duplicate test case that remains open.

The following data fields are captured when a team member closes a test case:

• Closed By: Name of the team member who closed the test case.

• Closed Date: Date and time when the test case was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the test case was changed.

Ready

When a test case is well defined and ready to be run, you change the state to Ready.

From Ready to Design

You can change the state of a test case from Ready to Design for the following reasons:

Reason	When to use	Additional actions to take
Update Test Case	Changes to the test case must be made to address the acceptance criteria for the test. For example, you can change the sequence of steps, add new steps, and change or add parameters.	None.

The following data is automatically captured when a team member reactivates a test case:

• Activated By: Name of the team member who reactivated the test case.

• Activated Date: Date and time when the test case was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the test case was changed.

Closed

You can reactivate a closed test case if the user stories that it tests come back into scope.

From Closed to Design or Ready

When you update the state of a test case from Closed to Design or Ready, the default and only value for Reason is listed in the following table:

Reason	When to use	Additional actions to take
Reactivated	The test case is required to support acceptance testing of a user story.	Review all action and validation steps to make sure that they are sufficient to test the user story.

The following data fields are captured when a team member updates the state of a test case from Closed to Design or Ready:

• Activated By: Name of the team member who reactivated the test case.

• Activated Date: Date and time when the test case was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the test case was changed.

See Also

Concepts

User Story (Agile)

Testing the Application

Other Resources

Shared Steps

MSF for Agile Software Development 6.0

Work Items and Workflow (Agile)