Share via


Shared Steps (CMMI)

Your team can use shared steps to streamline definition and maintenance of manual test cases. Many tests require the same sequence of steps to be performed 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 using Test Runner.

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 specify the sequence of action steps that define 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.

Because you define shared steps only to streamline the definition of manual test cases, it is best that you define shared steps by using Microsoft Test Manager. For more information about how to define and use shared steps, see the topics that are listed in the following table.

Task

Related topics

Reduce test maintenance by sharing test steps across test cases. You define shared steps to capture a sequence of test and validation steps that are inserted into the test steps of two or more manual test cases.

Run tests multiple times with different data. You can add parameters to your shared steps to use them in test cases where you want to run the same test multiple times with different data.

Speed up test efforts. You can make testing go more quickly by recording and playing back the repeated steps of your manual tests.

Run manual tests from a test plan. You can run manual tests from your test plan by using Test Runner to record whether each step passes or fails. You can save the test outcome and any data that is collected when you run the test.

close shared steps that are no longer needed. If you have shared steps that are not being used, you can change the state from active to closed. closed shared steps still exist in your team project, but they appear only in the results list for queries that specifically find shared steps that are closed.

Required Permissions

To view shared steps, 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 shared steps, 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.

Field Reference

For more information about the data fields and controls that are provided within the work item form for shared steps, see the following topics:

Shared Steps Workflow

You can use the Active and Closed states to distinguish shared steps that are being used from shared steps that are not being used. all shared steps are created in the Active state. A shared steps work item is useful only if it is inserted into one or more test cases. You change the state to Closed when all the test cases that contain the shared steps are also closed.

After you save a shared steps work item, you can change its state from Active to Closed.

Typical workflow progression:

  • A team member creates a shared steps work item in the Active state with the default reason, New.

  • A team member changes the state of a shared steps work item from Active to Closed to indicate that the work item is no longer used in any test cases.

Additional workflow transitions states:

  • A team member determines that the shared steps work item must be reactivated and changes its state from Closed to Active.

Shared Steps State Diagram

Shared Steps state diagram

Active (New)

Shared steps remain active as long as the test cases into which they are inserted are not closed.

The following data fields are automatically captured when you create shared steps:

  • Created By: Name of the team member who created the work item.

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

From Active to Closed

You can close an active shared steps work item because of one of the following reasons:

Reason

When to use

Additional actions to take

Obsolete (default)

The shared steps is no longer required for acceptance testing of user stories.

Verify that all test cases that reference the shared steps are Closed.

Deferred

The shared steps will not be run during the current product cycle or iteration. You can also specify this reason when the test cases in which the shared steps are inserted are set to Deferred.

None.

Duplicate

The shared steps work item is a duplicate of another shared steps work item.

Create a link to the duplicate work item that remains active.

The following data fields are captured when a team member closes a shared steps work item:

  • Closed By: Name of the team member who closed the work item.

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

  • State Change Date: Date and time when the state of the work item was changed.

Closed

A team member can reactivate a shared steps work item.

From Closed to Active

When a team member reactivates a shared steps work item, the Reason field is automatically set to Reactivated.

Reason

When to use

Additional actions to take

Reactivated

The shared steps work item is required to support the definition of a test case.

Review all action and validation steps to make sure that they support the Test Cases where the Shared Steps work item is inserted.

The following data fields are captured when a team member reactivates a shared steps work item:

  • Activated By: Name of the team member who reactivated the work item.

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

  • State Change Date: Date and time when the state of the work item was changed.

See Also

Concepts

Test Case (CMMI)

Bug (CMMI)

Requirement (CMMI)

MSF for CMMI Process Improvement v5.0

Other Resources

Work Items and Workflow (CMMI)