Download Release

IBM Rational Quality Manager

Quality management Manual testing Continuous improvement

Rational Quality Manager 4.0.5

Product Release / Trial | December 6, 2013
This is not the most recent version. We recommend Rational Quality Manager . This is made available for archival purposes and may contain bugs and/or security vulnerabilities. If you do download this version, it is being provided AS IS, without warranties of any kind, including the implied warranties of merchantability and fitness for a particular purpose. We strongly advise you review the support pages for this version and update the product or take actions recommended therein. Security bulletins contain instructions for the security vulnerability addressed therein, and may require upgrading to a newer version. Link to security vulnerability blog: IBM PSIRT blog.

Rational Quality Manager 4.0.5 New & Noteworthy

Rational Quality Manager 4.0.5 New & Noteworthy

Rational Quality Manager is an integral part of the Rational solution for Collaborative Lifecycle Management (CLM). For new and noteworthy information about other parts of the Rational solution for CLM, see these pages:

New in previous versions of Rational Quality Manager

For details about new features and functionality in previous releases, see these pages:

New in Rational Quality Manager 4.0.5

Correcting mistakes by restoring deleted test artifacts

You can now restore deleted test artifacts in the Trash view. To open the Trash view, click Admin > View Trash. The restore action is governed by a new Restore permission that was added for each artifact type. To set permissions, click Admin > Manage This Project Area > Permissions.

Restore Action

Improved organizational capabilities through categories

Category management through hierarchical views

The category editor was redesigned to provide a more dynamic and complete way to manage categories. Because of the need to categorize artifacts that are based on multiple and more specialized criteria, you sometimes must create and maintain complex category structures with several hierarchy levels that move from general to specific. In the new category editor, you can show the category structures as a tree so that you can see the dependencies between categories, subcategories, and values. You can also use the editor to create, associate, edit, and remove elements.

In addition, you can define the hierarchy by dragging elements to the tree. With this method, you can define a subcategory by dragging a category to another category. You can also associate multiple values across the tree by dragging values to a parent category.

To create category hierarchies that are based on defined values, use the Values panel that is near the tree. This panel lists the names of the values that are defined for a certain category in the context of the current test artifact. The panel can also include the names of all of the values that have been created so far for categories that belong to other artifacts. You can create a category by selecting a range of listed values from the panel and dragging them to a category to generate the category's values.

The new category editor

Views for category management

The category editor has two view modes: Show All and Show Outline. Use the Show Outline view to manage categories and subcategories. You can drag categories to arrange them and to establish dependencies between them so that you can define them as subcategories. After you define the hierarchy, you can switch to the Show All view mode to create and associate values.

To create and associate values, use the new Create window. In that window, you can also copy and paste a list of words that you want to be automatically generated as category values.

Use the Create dialog to copy and paste a list of words and generate multiple values at the same time

Ability to create values from values

When you are defining similar category hierarchies across different test artifacts, you can drag values from a list on the Values panel to the new category and generate new values. In the Values panel, you can filter to find specific values. You can also pin a value to the top of the list while you search for another value.

Avoid creating similar values by using drag and drop with the Values panel

Subcategory filters in artifact table views

With subcategories, you can create a hierarchy of categories to classify test artifacts. For example, a subset of subcategory values is related to a specific value of a parent category, showing the dependency between those values.

Parent category filter listing options

You can see the dependency when you use the category filters. When you select a filter on a parent category, a list of values is displayed.

Parent category filter listing options

Then, when you select one or more values from that list and filter on a subsequent child category filter, the options list for the dependent filter is populated based on the parent selection. The names of the parent values are shown in the list so that you can identify the child options.

Parent category filter listing options

In addition, a search field is displayed at the top of every category filter in which you can type to find specific options.

Parent category filter listing options

Multiple subcategories in a single category

You can now add multiple subcategories to a category. For example, if you had a Shoe category, it might include the "Upper material" and "Sole material" subcategories.

Improvements for governing the test artifact lifecycle

New test plan sections

Test plans have three new sections: Test Scripts, Test Case Results, and Test Suite Results. In those sections, you can see your test scripts, test execution results, and test suite results directly from a test plan.

The new sections improve the workflow for the multi-artifact approval process because you can transition between states and approve or reject artifacts without leaving the test plan editor.

The new Test Scripts section:

Test Scripts section of the test plan

The new Test Case Results section:

Test Case Results section of the test plan

The new Test Suite Results section:

Test Suite Results section of the test plan

New process advisors for state transitions

New process advisors prevent state transitions until child artifacts have transitioned to a given state group. For example, you can configure the new advisors to prevent a test plan from moving to approved until all of the child test cases are approved. The new process advisors are supported for these artifacts: test plans, test cases, test scripts, test suites, test case results, and test suite results.

New "Published" state group

You can customize a test artifact's workflow by adding states that belong to the new "Published" state group. You might use that state group to improve the workflow for controlled test artifact reuse.

More insight into test case results when you use datapools

The test case results for test scripts that have test data associated with them now include the row number of the test data for each step result. This information is useful when you want to understand how the overall result of the test script relates to a particular test data row. The summary section of the test case result also shows a summary of the test data rows that were run. You can also access this information in exported PDF files and from the REST APIs for test case results.

Test data associated with test script steps

Easier requirement-to-test traceability through reconciling a subset of requirement collections

When you reconcile requirement collections, instead of reconciling all of the collections, you can now select a subset of collections to reconcile. In the reconciliation results, you can view the removed items, which are requirements that were removed from the collections since the last reconciliation.

Removed requirements

If any requirements are not in the reconciled requirement collections but are associated with test cases in the test plan, those requirements are listed as unplanned items.

Unplaned requirements

When you reconcile only a subset of requirement collections in a test plan, you can hide the unplanned requirements from being shown in the reconciliation results. To hide unplanned requirements from the results, in your OSLC preferences, select When only a subset of requirement collections in the test plan are reconciled, hide any unplanned requirements, as shown in the following image.

User preference for hiding unplanned items

The preference to hide unplanned requirements works on only the subset of requirement collections. If you reconcile all of the requirement collections that are in a test plan, even if you set the preference to hide unplanned requirements, any unplanned requirements are still shown.

Improved productivity through test suite performance and scalability enhancements

Test suite scalability is improved in several ways. In the Run Test Suite window and in the results editor for test suites, tables are now paginated and can be sorted, filtered, and grouped, where applicable. On the Test Case Results page, the custom properties are also now paginated and can be filtered.  In addition, it takes less time to save large schedules. For more details, see these work items:

New capabilities to pause, resume, and stop test suites support long-running test suites

The Test Suite Execution Console contains two new buttons: a button to pause and resume a test suite run, and a button to stop a test suite run. You can also resume a test suite run from the Test Suite Execution Record editor and from the Test Suite Execution Record view.

Test suite execution console with pause and stop run button

Pausing a test suite run

When you click Pause, all of the execution requests that have not completed are paused. The names and test case progress information of the paused execution requests are disabled. After a test suite is paused, the Pause button becomes the Resume button. If a test suite is running a remote script and you click Pause, the test suite will be paused after the remote script finishes running.

Test suite in paused state

Resuming a test suite run

When you click Resume, the test suite run is resumed. All of the paused execution requests that are under the test suite run return to the states they were in before they were paused. After the test suite run is resumed, the Resume button becomes the Pause button.

Stopping a test suite run

When you press Stop, all of the execution requests that have not completed are canceled. You cannot resume a test suite run after you click Stop.

Test suite in cancelled state

For more information, see this story: 93098: As a User, I want to Pause my Suite Execution and Resume it afterwards.

Better lab data management through reportable REST API support for lab resource attributes and support of a simple properties format

The properties format is a mechanism for accessing lab resources by using REST calls, such as GET, POST, and PUT. By using a simple property naming scheme, you can fully address every attribute in a lab resource. Here is an example of the new properties format:

<ns2:property name="Machine"/>
<ns2:property name="Machine.Location" value="my office"/>
<ns2:property name="Machine.Manufacturer" value="IBM"/>
<ns2:property name="Machine.memory" value="16000"/>
<ns2:property name="" value="Test"/>
<ns2:property name="Machine.operatingsystem.Linux"/>
<ns2:property name="Machine.operatingsystem.Linux.SoftwareInstall[0].Firefox"/>
<ns2:property name="Machine.operatingsystem.Linux.SoftwareInstall[1].Chrome"/>
<ns2:property name="Machine.Operational Status" value="Unavailable"/>
<ns2:property name="Machine.owner" value="TestJazzAdmin1"/>

To use the properties format, specify the format=properties parameter to the REST calls.

A dictionary listing of all of the available catalog properties can be retrieved from //server/.../labresource?propertyDictionary=true.


In the 4.0.5 release, the default time-out values for licenses changed:

  • Floating licenses: The default time-out value changed from 7200 seconds (120 minutes) to 3600 seconds (60 minutes).
  • Token licenses: The default time-out value changed from 7200000 ms (120 minutes) to 1800000 ms (30 minutes).

In 4.0.5, the minimum time-out values for licenses are as follows:

  • Floating licenses: The minimum time-out value changed from 7200 seconds (120 minutes) to 1800 seconds (30 minutes).
  • Token licenses: The minimum time-out value remains at 1800000 ms (30 minutes). This value has been the same since the 4.0.3 release.
For information about how to change the time-out values for licenses, see the documentation:

In the 4.0.5 release, the reset frequency for the time-out of token licenses changed. Before this release, the time-out value was reset only after the license expired. Now, most actions reset the time-out value of the license to the value of the time-out. This change makes the resetting of the time-out for token licenses the same as for floating licenses. This change causes the lmgrd.log file on the Rational License Key Server to increase in size faster than it used to, because each reset of the license causes entries to be written to the lmgrd.log file. That file is in the common directory. For example, on Windows systems, the file is typically in C:\Program Files(x86)\IBM\RationalRLKS\common\lmgrd.log.

Prototype of offline testing application for mobile devices

The QM team has a working prototype of an application that you can use to run tests from a mobile device. The application facilitates offline scenarios, such as when you are working without a connection to the QM server. For more information, see 90088: Explore QM mobile client app to support offline execution. You can download an evaluation copy of the Rational Quality Manager Mobile App from the Extras section of the All Downloads page.

New video about test case execution records

You can learn more about test case execution records by watching a new video, Test Case Execution Records Part 1: Why You Need to Understand and Manage Test Case Execution Records. This video is the first in a series of videos aimed at explaining how you can use test case execution records to plan, execute, and report on testing. Part 1 introduces test case execution records and explains why they are so important. The video is hosted on