Easier Maintenance of Tests using Reusable Test Cases and Test Steps

Reusable Test Cases and Test Steps 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 Cases and Test Steps 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.

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

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 Case using Drag-and-Drop

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:

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: