Defining custom workflows for test artifacts

About this task

A workflow is a state transition model that defines the states for test artifacts and the actions that users take to move the test artifact from one state to another. Typically, a workflow starts with a Draft state and ends with a state that reflects the final disposition of the artifact, such as Approved or Closed.

You define a state transition model by binding the workflow to a test artifact type. For example, in the default workflow, when a reviewer rejects a test plan that is under review. the test plan returns to the Draft state. One possible customization would be to create a new test plan state called Rejected, which would serve as the state for test plans that failed the review.

Ideally, you define workflows when you create a project area.

Important:

Avoid making changes to workflows in large projects. The only exceptions are name changes and additions.
If you open an artifact in an invalid state, the state is reset to the initial state.
If you remove states or workflows, states are likely to become invalid.

For additional details about defining custom workflows, see Leveraging custom workflows in ETM.

Procedure

In the banner click the Administration () icon and click Manage This Project Area.
In the Project Area editor, click Test Artifacts > Workflows.
The Workflow editor opens, showing first the Workflows Bindings section, which determines the workflow to be used for an artifact.
In the Workflow Definitions section, select a workflow to edit, such as the Test Plan Workflow.

In the Workflow Definitions section, you can edit a workflow, add a new workflow, or remove a workflow. The Start Action determines the initial state of the artifact, such as Draft. To add a new workflow:
1. Click Add.
2. In the ID field, enter a name for the new workflow. By default, the Name field is populated with the same value that you enter into the ID field. Optionally, you can edit the Name field value. Click OK.
In the States section, configure the states for the workflow. For each state, set the actions, which define the order in which actions are displayed throughout the user interface.
To define states in the workflow, repeat this process:
1. In the States section, click Add.
2. Enter a name and brief description for the state.
3. Select a group that is appropriate for the State, such as Draft, Under Review, Reviewed, Approved, or Closed. For example, if you create a state called Reopened, you might assign it to the Draft state.
  Note: State groups are used for business logic and are needed for consistent reporting. For examples of how business logic is configured in the Engineering Test Management application, see Preconditions for Engineering Test Management.
4. Select one of the icons that are included in the process templates. If you want an icon that is not in the list, click Browse and navigate to a graphics file to use as the icon.
5. Click OK.
Repeat this process to define all states in the workflow.
Optional: To enable cross-project linking between workflow states, in the States area, in the External Value field, specify a unique value to identify the state across projects.

Within a project, you must use a unique value for each state. If another project has an equivalent state, use the equivalent state's value to ensure consistency across projects and to enable a shared vocabulary for reporting.

For example, Project_A has a state named Retired and Project_B has a state named Closed. Your organization considers these states equivalent even though their names and enumeration values differ. If you assign the same value to these equivalent states, you can ensure that they have a consistent meaning and you can report on them across projects.
In the Actions section, define the actions for the workflow. Actions link states together and can have permissions assigned to them. Multiple actions can point to the same target state.

To add an action:
1. In the Actions section click Add.
2. Enter a name for the action, optionally select a target state and an icon, and then click OK.
Continue to add actions as necessary to support your state transition model. At a minimum, provide actions that users can use to move the artifact from its original state to its final state.
In the Transitions section, connect the From states to the To states by using actions, such as Reject, Approve, and Reopen. A matrix illustrates the state transition model. The row headings contain the From state, and the column headings contain the To state. The intersecting cells contain the actions that users take to move the artifact from one state to another.
Note: Define the states and actions before you define the transitions.

For example, in the From column, find the row containing the Draft state and select Ready for review in the Under Review column. This indicates that a test plan in the Draft state will transition to the Under Review state when a user selects the Ready for review workflow action.

In addition, you can define preconditions and follow-up actions for workflow transitions. These are defined for a particular role, such as a Test Team Member, and an operation, such as, Save Test Plan. For details, see Preconditions for Engineering Test Management.
When you are finished defining the workflow, click Save.
Optional: Add a permission to a workflow action. The following image shows permissions for workflow actions.

To add a permission to an action:
1. In the project area, click Permissions.
2. Select Project Configuration or Team Configuration.
3. Select a role, such as Test Team Member.
4. Under Engineering Test Management, expand a permitted action, such as Save Test Plan.
5. Expand Trigger a workflow action, and select the actions, such as Approve and Reject, to allow for the selected role.
6. Click Save.