Test Case (CMMI)

Your team can use test cases to define both manual and automated tests that can be run and managed by using Test Runner and 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 Test Professional 2010, Visual Studio 2010 Professional, or Visual Studio 2010 Ultimate. 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 by using 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 Requirement Adding Attachments or Hyperlinks to a TestCase Changing the State of a Test Case	Dashboards and Reports Test Dashboard (CMMI) Test Case Readiness Report Test Plan Progress Report Test Management Reports Field Reference Titles, IDs, Description, and History (CMMI) Assignments, Workflow, and Planning (CMMI) Areas and Iterations Build and Test Integration (CMMI) Linking Work Items (CMMI) Attachments

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

Test cases are designed to work with Test Runner and Microsoft Test Manager. You can define a test case by using Team Explorer, but it is best if you create test cases by using Microsoft Test Manager. For more information about how to define and use test cases by using Microsoft Test Manager, see Creating and Managing Tests.

You can define a test case by using Team Explorer or Team Web Access and later add that case 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, specify one or more of the following fields:

   • In Title (required), 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 it 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 How to: Associate an Automated Test with a 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 requirement 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. On the Steps tab, define the action and validation steps and parameters to be performed as part of the test.

   For more information, see Creating and Managing Tests.

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

4. On the Tested Requirements and All Links tabs, create links from the test case to one or more other work items, such as requirements, tasks, change requests, and bugs.

5. On the Attachments tab, attach specifications, images, or other files that provide more details about the test case to be run.

   For more information, see the following sections later in this topic:

   • Linking a Test Case to a Requirement

   • Adding Attachments or Hyperlinks to a TestCase

6. Click Save Work Item.

   Note

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

Linking a Test Case to a Requirement

You link test cases to a requirement to track the progress of testing made for the requirement. After you have defined your test cases, you can link them to the Requirements 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 Requirements or User Stories to Your Test Plan.

To link a test case to a requirement

1. Click the Tested Requirements 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 Requirements team query, and then click Find.

6. Select the check box next to the requirement 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 requirement and test case that you linked are updated. A Tested By link is added to the requirement.

Adding Details, Attachments, or Hyperlinks to a Test Case

You can provide more information to implement the test case 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 (Agile).

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 (Agile).

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 a team member saves a test case, they 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 requirements that 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. Atypical transitions: A team member changes the state of a test case from Design to Closedto indicate that a test case that has been defined for a requirement 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 have 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 requirement 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 a team member changes 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 requirements to determine whether you can define any shared steps that will minimize maintenance of the test cases.

From Design or Ready to Closed

A team member 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 requirements.	Verify that all requirements 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 requirement 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

A team member 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

A team member can reactivate a closed test case if the requirements 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 requirement.	Review all action and validation steps to make sure that they are sufficient to test the requirement.

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

Testing the Application

Artifacts (CMMI)

MSF for CMMI Process Improvement v5.0

Other Resources

Work Items and Workflow (CMMI)