You are not logged in. Click here to log in.

codebeamer Application Lifecycle Management (ALM)

Search In Project

Search inClear

Tags:  not added yet

Reference Test Cases and Test Step Reuse

Test case reuse is used to improve re-usability and maintainability in test management by reducing redundancy between test cases in projects. Often, the test scenarios require that some test steps, pre-actions, or post-actions of test cases contain repeated or similar actions performed during a testing cycle. Just copying test descriptions between test cases might result in duplications and in difficult maintenance when a wrong or outdated test description appears multiple times in the test case hierarchy.

The following features are available from codebeamer 7.8 to support test step reuse:

  • Reusable test cases: certain test cases can be marked as reusable, which makes it easier to find the test cases designed for reuse easier.
  • Reference test steps, reusable pre-actions and post-actions: reuse test steps, pre-actions, and post-actions from other test cases while automatically keeping them synchronized to the original item. The pre-action and post-action reuse is available from codebeamer 21.04 (DOROTHY)

Reusing Test Steps

Defining a New Test Case by Reusing Test Steps

When editing a test case and defining its test steps, users might want to reuse existing test steps from other test cases. For this, the test case editor shows the test case tree and test case library tree, where users can search and locate the test cases that contain the required test steps. For more information, see the Test Case Libraries section.

When a user drag and drops one or more test steps from the reference test case, two options are available: creating a copy of the test steps or using them as a reference.

Copy of Test Steps

When using the copy option, the original and the copied test steps have no relationship or connection between them. This means that if the original test step changes, the copy does not change. The copied test step can be modified any time without restrictions, and such modification do no affect the original test step. When a step is added as a copy, it is possible to change it into a reference test step with the [Reset Reference] button.


Reference Test Steps

When creating a reference test step, the newly created test step maintains a reference to the original test step. This means that whenever the original test step changes, the changes are automatically and immediately synchronized to the reference test step.

This also means that field values in referring test step cannot be modified, because that would make the reference logic invalid. Therefore, the referring test steps appears as read-only on the UI.

However, if required, the user can break this reference relation, and turn a reference test step to an copy by editing it.

By default, a test step can be reused a maximum of 3000 times. A lower limit can be configured in the application configuration with the following expression:

"testManagement" : {
    "maxStepReuse" : 2
}

If the limit is reached when a reference test step is added, an error message is shown and the test step must be removed manually.


In some cases, it is possible to go over the limit. For example, restoring referring steps from the trash or importing a project with referring steps does not add into the number of reuses, and the limit is ignored.

Creating Reference or Copy Test Steps

Users can drag and drop test steps from other test cases in the test case editor page. Once dropped, it is possible to choose between creating a copy or a reference of the original.

Steps can be added with the [Add Steps!] button too, located on the right-hand panel. This adds all steps of the selected test case into the edited test case. Adding steps has the following rules:

  • If selecting few steps by ctrl-clicking on the steps, the [Add Steps!] button only adds these selected steps.
  • If no steps are selected, all steps are added.
  • The steps are added to the end of the step list by default. To add steps into the middle, start editing a test step there, and the steps are added below the step which is being edited.
  • The [Add Steps!] button and the drag-and-drop action asks confirmation if some or all of the steps are already added, and users have the option to add only those steps which are not added yet.
  • Circular reference is not possible, this means that a test case cannot reuse its own step. If the user attempts to create a circular reference, an error is shown. The step with circular reference must be removed manually.

Reference Test Step Management

When a copy is created of a test step, the result is equivalent to creating a new test step manually. There are no restrictions on the test step behavior, and the Action and Expected Result remains editable.

A reference test step however behaves differently. A reference test step is not editable, because its fields contain the values of the referenced test step. The referenced test step is editable, but the changes made here might affect the reference test steps.

Navigating between the Reference and Referenced Test Steps

To identify the reference test steps, they appear with a light-yellow background color and with an arrow icon pointing up-right. The link next to the icon shows the referenced test case. Clicking the link opens a new window and jumps to the target test step. Clicking the pencil icon opens the test step editor.

When a test step is reused by another test case or multiple test cases, it is highlighted with light-blue color, and an arrow icon pointing down-right indicates the reuse. Under the test step name, a link show the number of test cases where this step is reused. Clicking the link opens an overlay window where these test cases are listed.


Reused step overlay window:


If the current user does not have permission to a referring test case, that test case is not shown in the list, and the following warning appears on the top of the window:

One or more referring test case/step are not shown due to missing permission.

Tracing Test Step References

When reusing a test step from one test case to another, the reuse references are automatically maintained by the test case editor when such test case is changed.

It is possible to trace these references in the traceability browser. To do this, check the Show Test Step Reuse References check box.


Similarly, the reuse references can be tracked in the Traceability section in the item details page of the test case if the Show Test Step Reuse References check box is selected.


Editing Reference Test Steps

Editing Referring Test Steps

The test step that reuses another test step (source side) cannot be edited because such test steps are live references of other test steps. The UI shows a warning and controls are always read-only.

However, it is possible break the reference with the [Break Reference] button, then modify the test step. The original reference can be restored with the [Reset Reference] button. This option is only available until the first save.

Editing Referenced Test Steps

When editing a test case with referenced test steps, these target steps are editable, however the UI warns the user that these changes affect other test cases too.


When trying to save a test case with such modifications, a second warning appears:

A warning is shown also at test step deletion. If a reused test step is deleted, those steps that were referencing it remain the same and are not deleted. These referencing test steps become ordinary steps, and their content is updated to the latest content of the deleted step.

Missing References and Error Handling in Test Runner

References between test steps can become broken. This can happen for the following reasons:

  • The source test step is referencing a test step that does not exist any more.
  • The source test step is referencing a test step that do exist, but the current user has no permission to view it.

In both cases, the test case editor and the item details page notifies the user about this fact.


The broken reference can be remedied by editing the test case or correcting the permissions.

However, if such error happens during a test run, the test runner UI shows an error message of this.


Test Case Libraries

Test case libraries help to manage step reuses between test cases. When editing a test case, the test case libraries appear on the right-hand side of the editor. The library contain test cases from trackers that are marked by the user as test case libraries.

Click on Test Case Library and Configure Icon Pick the Library Trackers in the Overlay

Reusable Test Cases

Reusable test cases improve the re-usability and maintainability, and reduce the redundancy between test cases in projects. The number of the reusable test case is not limited. The Reusable field in test cases is used to distinguish the reusable test cases from non-reused cases. To mark case reusable, set the Reusable field to true.

To filter for reusable test cases when editing a test case, select the Reusable only check box. See item 1 on the screen capture. Additionally, users can search and filter items by entering any text to the filter text box above the tree. The arrow icon pointing down-right indicates that a test case is reused. See item 2 on the screen capture.

Adding Support for Reusable Test Cases in Legacy Trackers

It is possible to add support for reusable test cases in trackers that were created before codebeamer 7.8. For this, go to tracker configuration and add a new custom Boolean field named Reusable.

Detecting and Automatically Converting Test Step Duplicates to Step Reuses

From codebeamer 10, a feature automatically finds duplicated test steps and converts them to step reuses. This feature can be used during when importing data from Microsoft Excel. The duplicated steps in the imported items can be converted to step reuses. It is also possible to find duplicates steps in a set of test cases using REST API, and convert the steps to step reuses. For more information on data import, see Importing Data from Excel to codebeamer.

Converting Test Step Duplicates during Import

The importer scans the imported test cases for duplicated steps and automatically creates step reuses between the duplicated steps. This feature can be turned off or configured on the importer GUI wizard.

Any step reuse that existed before the import are kept unchanged.

For all steps in the import data, the importer performs the following actions:

  • Checks whether the exact same step already present in the import data.
  • Reuses the same step if a reuse reference already exists. If there are multiple reused steps, the algorithm picks the one that is reused the most times.
  • Picks the first test case within the imported items to be reused if there are no existing reused steps for the duplicate.
  • Scans and finds the duplicated steps in test case libraries, and reuses steps from these libraries. In this case, it only creates a reuse to the test cases that are marked as Reusable. The test case library is a special tracker that contains test cases for test step reuse. For more information, see Test Case Libraries in Knowledge base.

Converting Test Step Duplicates with REST API

With REST API, users can scan a set of test cases and find duplicated test steps. It is recommended to do this after adding multiple test cases in codebeamer. The scan of the test cases can find the duplicates with one REST call.

For more information about the parameters of this REST call, check the Swagger editor for this functionality by opening the following url in the codebeamer instance: http://localhost:8080/cb/v2/swagger/editor.spr#/Test%20Case/autoApplyStepReuses.

Reusing Pre-Actions and Post-Actions

From codebeamer 21.04 (DOROTHY), the test case edit function is extended with reusable pre-actions and post-actions. With a tabbed selector, users can switch between test step, pre-action, and post-action reuse. Depending on the user permissions, the pre-action and post-action tabs provide a preview of the given field of the selected test case. Click the [Add field!] button to reuse the selected field in the test case that is being edited.

Alternatively, it is possible to drag and drop test cases from the test case selector to the highlighted area of the Pre-Action and Post-Action fields.


After clicking the [Add field!] button or dropping a test case to the field, a popup appears with the following available reuse options:

  • Reuse via stereotype
  • Copy
  • Use it as a reference


Pre-Action and Post-Action Reuse via Copy

Selecting [Copy] on the [Add field!] overlay copies the content from the respective pre-action or post-action of the selected test case (source field) over the related field of the test case being edited (target field). If the target field is not empty at the time of the copy, codebeamer offers the user to either overwrite or append the field with the content of the source field.

Choosing append adds the content of the source field to the end of the target field. Overwrite replaces the content of the target field with that of the source field.

Reference Test Case

Selecting the [Use it as reference] option on the pre-action or post-action reuse overlay creates a reference from edited test case to the referred one in scope of the given Pre-Action or Post-Action field. codebeamer uses this reference to keep the content of the target field in synchronization with the source field as the source changes. Once the test case is saved, the reuse reference is visible on tracker item details screen of both the referring and the referred test case.


This functionality also makes the target field read only, as it is meant to reflects the content of the source field. The reference to a reused field can be broken anytime using the [Break Reference] button, which makes the field editable again.

Pre-Action and Post-Action Reuse with Global Stereotype

When reusing test actions in other test actions via stereotype, parameter calls are not resolved. Only the value of the linked item is shown.

Global stereotypes can be used to reference properties of other tracker items. Test management has built-in support for referencing the <<pre-action>> and <<post-action>> global stereotypes that are defined. For more information, see Global Stereotypes.


Selecting [Reuse via stereotype] adds a [<<pre-action>>|ISSUE:12345] markup to the target field with the item ID of the source item, thus making it easier to reference global stereotypes. If the target field is not empty when applying this reuse, it prompts the same overwrite and append options as in case of a simple copy.