Easier Maintenance of Tests using Reusable Test Cases and Test Steps

Reusable Test Cases is a tool to improve re-usability and maintainability of Test Management by reducing redundancy between Test Cases in projects.

Often the Test scenarios require that some Test Steps, Pre- or Post-Actions of Test Cases contain repeated or similar actions performed during a Testing cycle. Just copying Test descriptions between Test Cases may result in lots of duplications and difficulty in maintenance when a wrong or outdated test-description appears several times in the Test Case hierarchy.

To improve this situation in codeBeamer 7.8 we have introduced two new features:

• Reusable Test Cases - certain Test Cases can be marked as "Reusable" makes it easier to find the Test Cases designed for reuse easier.
• Reference Test Steps - reuse Test Steps from other Test Cases while automatically keeping them synchronized as the original changes.

Additionally, as of codebeamer 21.04 (Dorothy), you can also benefit from reusable Pre- and Post-Actions, which similarly to Reference Test Steps, can be used to reuse Pre- and Post-Actions while automatically keeping it in sync with the original item.

Reusing Test Steps

Defining a new Test Case with reusing Test Steps

When editing a Test Case and defining its Test Steps users may want to reuse existing Test Steps defined as part other Test Cases. For that the Test Cases' editor's right side shows the Test Case tree and Test Case Library tree, where users can search and locate the Test Cases which contain the Test Steps they may want to reuse.

When a user Drag-and-Drops one or more Test Steps from Reference Test Case on the right side into the Test Case the user is going to be asked about the following options:

• If the user wants to create a copy of the Test Step(s)?
• Or if the user want to create a reference to the Test Step(s)?

The difference between the copy and reference mode is:

Copy of Test Steps

When using the Copy option the original and the copied Test Steps will have no relationship or connection between them, so if the original Test Step changes the copy will not change. Also the copied Test Step can be modified any time without restrictions, and such modification won't affect the original Test Step at all.

Reference Test Steps

When creating a Reference Test Step then the newly created Test Step will hold and maintain a reference to the original Test Step, which means that whenever the original Test Step changes the reference Test Step is automatically and immediately kept synchronized with the changes.

This also means that the text ("Action", "Expected Result) inside Reference Test Step can not be modified, as that would make the reference logic invalid. Therefore the reference Test Steps will appear as read-only on the UI.

However if the user needs they can break this strong reference relation, and turn a Reference Test Step to an simple copy later on by editing it. (See below...)

Creating Reference or Copy Test Steps

As mentioned earlier the on the Test Case editor page users can drag-and-drop Test Steps from other Test Cases. Once dropped the user can choose if the system creates a Copy or a Reference of the original. This screenshot illustrates that:

Or use the "Add Steps!" button on the right panel which will add all Steps of the selected Test Case into the edited Test Case.

The rules are:

• If you select few Steps by ctrl-clicking on the Steps then the Add Steps! button will only add these selected Steps.
• If no Steps are selected then all Steps will be added
• The Steps are added to the end of the Step list by default. To add Steps into the middle then start editing a Test Step there, and the Steps will be added right below the Step which is being edited.
• The "Add Steps!" button (also drag & dropping the steps) will ask confirmation if some/all of the Steps are already added and you have the option to add only those Steps which are not there yet!

Management of Reference Test Steps

When doing a simple "Copy" of a Test Step is not very different from creating a new one and just typing in the text manually: there won't be any restriction later on how the Test Step behaves, and the "Action" and "Expected Result" will be always editable by the user.

On the other hand an Reference Test Step behaves differently:

• The Reference Test Step is not editable, because all of its fields is always enforced to contain the values of the Referenced Test Step
• The Referenced Test Step is editable, but any changes on it is potentially dangerous because those changes may affect many other steps' description !

Navigating between the Reference and Referenced Test Steps

To identify the Reference Test Steps these will appear with a light yellow background color showing here. This can also be recognized by the up-right arrow icon. The link next to the icon shows the target/Referenced Test Case, and clicking on it will open a new window and scroll to the target Test Step (and highlights and focuses that Step too...). This makes it easy to jump to the target Test Step.

When user is viewing or editing a Test Case with Test Steps which are Referenced/Reused by other Test Steps then the UI will highlight those target Steps using light blue background color . The screenshot below shows that:

Such Reused/Referenced Test Cases will appear as:

• The down-right arrow icon
• Next to he icon the several links may appear, where each link will point to the Test Cases/Steps which point to this Step.
• If the reused TestStep is in a different project then that project's name also is shown (see #1 below)
• If you click on the reuse link that will open the TestCase. If you click on the small pen icon in the link that will open the TestStep in edit mode (see #2 below) thumbnailImagesInitialized

As there might be multiple references into a Test Step there might be multiple links listed here. By clicking on each link the UI will open the downstream/Referring Test Case in a new window, hightlight and focus to the step which is referencing.

So the links between the source/Reference and target/Reused Test Steps makes it easy to see where and how each Test Case is being reused or referenced.

Tracing Test Step references

The TestCase "A".TestStep1->TestCase "B".TestStep reuse references are stored in an "derived" associaton between the TestCase "A" and "B" - thes association(s) are "automatically" maintained (added/removed/updated) by the TestCase editor when such a TestCase is changed. This is how such an association looks like:

You can "trace" these associations in the Traceability browser. All you need to do is to uncheck the "Do not show related items" checkbox. Like this:

Editing Reference Test Steps

When working with Reference Test Steps the following rules apply:

Editing Referring Test Steps

The Test Step which refers/reuses other Test Step (source side) can not be edited. This happens because such Test Steps are just live references of other Test Steps. The UI will show a warning and controls are always read-only.

However if the user wants to modify this Test Step he can break the reference, and then the editing will be possible. The UI will show the "Break Reference" button for breaking the reference. After pressing that the Test Step will be editable and after save the reference-connection will be finally broken.

While editing the Test Step the user can change his mind and reset/rebuild the original reference using the "Reset Reference" button. This only works 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 will warn the user about that these changes will affect other Test Cases too !

So when user starts to edit a reused Test Step this warning appears:

When user tries to save an Test Case with such modifications also a second warning appears:

When deleting a reused Test Step also a warning appears. Deleting reused Test Steps means:

• The UI will warn the user
• If a reused Test Step is deleted then those steps which were referencing that will not be deleted, but they will stay so the the referencing Test Case will stay still correct and complete. These Referencing Test Steps will become ordinary steps, and their content will be updated to the latest content of the deleted Step.

Missing References and Error handling in Test Runner

While codeBeamer tries to maintain the references between the Referencing Test Steps it may happen that some of these references becoming are broken. This can happen if:

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

In both cases the Test Case editor and view pages will show a warning about this fact. This can be corrected by editing the Test Case or correcting the permissions.

However if such error happens during a Test Run then the Test Runner UI will show an error message about this. Because such Test Case definition is considered invalid the Test Runner will automatically mark all Test Steps as blocked and will force a "blocked" outcome of the Test Case.

This can be corrected after fixing the Test Case and by rerunning the broken Test Cases.

How the broken Test Cases appear in Test Runner:

Test Case libraries

Test Case libraries is a tool to help to manage Step-reuses between TestCases. When editing a TestCase the Test Case libraries will appear on the right side of the editor: and it will contain those Test Cases from those Trackers which are marked by the user previously as Test Case libraries. So practically if you want you can store those TestCases which are part of your "library" for reuse in one/few selected Trackers and pick only those TestCases from there !

It looks like this:

Click on Test Case Library and config-icon	Pick your Library-trackers in the overlay

Reusable Test Cases

Reusable Test Case is a tool to improve the re-usability and maintainability but reduce the redundancy between Test Cases in projects.

A user is able to define as many Reusable Test Cases as they want. A new field is added to Test Cases called Reusable, which is used to be able to distinguish the Reusable Test Cases from normal Test Cases.

When editing any Test Case the user can mark a Test Case as Reusable by setting the Reusable field to true. An example:

Finding and filtering for any "Reusable" Test Cases is easy by using a special filter option, which appears above the Test Case and Test Library trees when editing a Test Case. So to find only the "Reusable" Test Cases just click on the "Reusable only" checkbox (marked as #1 on screenshot). Once this filter is on the Test Case tree will show only the Reusable Test Cases. Additionally users can search and filter items by entering any text to the filter box above the tree, and this will further filter the Test Cases shown in the tree.

Any Reusable Test Cases is indicated by the a down-arrow next to the Test Case's name (see mark #2 on screenshot below).

Adding Reusable Test Cases support to legacy Trackers

If you're upgrading from older codeBeamer versions (before 7.8) you can still add support of Reusable Test Cases to your existing Test Case Trackers. For that go and customize Test Case tracker(s) and add a new Boolean custom field named "Reusable".

Detecting and automatically converting Test Step duplicates to Step-reuses

A new feature is available since CB version 10: which can automatically find duplicated Steps and convert them to Step-Reuses. This feature can be used in two cases:

• During the import: the duplicated Steps inside the imported items can be converted to Step-Reuses
• Using Rest API you can also find duplicated Steps in a set of TestCases and convert them to Step-Reuses.

Converting Test Step Duplicates during import

The importer will scan the imported Test-Cases for duplicated Steps and will automatically create Step-Reuses between the duplicated Steps.

This feature can be turned off or configured on the importer GUI-wizard like this:

The rules for the creation of Step-reuse is:

• Any Step-reuses that existed before the import is kept without any change
• For all Steps in the import data the importer will:
  • Check if exactly same Step already present in the import-data, and if so:
  • If there was already a "Reuse" association present which was created by the user previously then it will Re-use the SAME step. This is assuming that the user wants to reuse the SAME step that was already reused several times in his libraries. (If there are multiple "Reuse"-d steps then the algorithm will pick the one which is reused MOST times: so if X step is reused 3 times in "A" TestCase, and 1 times in "B" TestCase then it will pick the "A")
  • If we don't find an existing "Reused" Step for the duplicate-Step then the importer will pick the 1st TestCase within the imported items and will reuse that.
  • Lastly the importer can/will also scan and find the duplicated Steps in Test Case libraries, and will re-use Steps from these libraries. In this case it will ONLY create a Reuse to the Test Cases which are marked as "Reusable". Test Case libraries is a special Trackers which are marked to contain TestCases for Step-reuse: Test Case Libraries in Knowledge base

Converting Test Step Duplicates using REST API

Using REST API you can also scan a set of Test Cases and find duplicated Steps inside. Typically you want to do this after you have inserted several Test Cases into codeBeamer, and after that scan these new Test Cases in one REST call to find the duplicates.

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

Reusing Pre- and Post-Actions

As of codebeamer 21.04 (Dorothy), the Test Case edit functionality has been extended with reuseable Pre- and Post-Actions. As of this version, there is a tabbed selector that you can use to switch between Test Steps, Pre-Action and Post-Action reuse. The new Pre-Action and Post-Action tabs (depending on your permissions) preview the given field of the selected test case. Click on the "Add field!" button to reuse the selected field in the test case you are editing.

Alternatively, you can also drag & drop test cases from the test case selector to the highlighted area of the Pre-Action and Post-Action fields.

Once you click "Add field!" or drop a test case to a field, a popup appears with the available reuse options.

Pre-/Post-Action reuse via Copy

Selecting "Copy" on the "Add field!" overlay simply copies the content from the respective Pre- or Post-Action field of the selected Test Case ("source field") over to the related field of the test case being edited ("target field").

In case target field is not empty at the time of the copy, codebeamer offers you to either Overwrite or Append the field with the content of the source field.

Opting for Append adds the content of the source field to the end of the target field, while Overwrite simply 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-/Post-Action reuse overlay creates a reference from edited test case to the referred one in scope of the given Pre- or Post-Action field. codebeamer uses this reference to keep the content of the target field in sync 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 always 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-/Post-Action reuse via Global Stereotype

You can also use Global Stereotypes to reference properties of other tracker items. Test Management now has built in support for referencing the <<pre-action>> and <<post-action>> global stereotypes if they are defined. Please refer to the Global Stereotypes documentation on further details on how you can set this up.

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. In case the target field is not empty when applying this reuse, it prompts the same Overwrite/Append options as in case of a simple copy.