IBM Rational Quality Manager
Quality management · Manual testing · Continuous improvement
This is not the most recent version. We recommend Rational Quality Manager 6.0.6.1 . 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.6 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:
- Jazz Foundation (Jazz Team Server) 4.0.6
- Change and Configuration Management 4.0.6
- Requirements Management 4.0.6
New in previous versions of Rational Quality Manager
For details about new features and functionality in previous releases, see these pages:
- Rational Quality Manager New & Noteworthy 4.0.5
- Rational Quality Manager New & Noteworthy 4.0.4
- Rational Quality Manager New & Noteworthy 4.0.3
- Rational Quality Manager New & Noteworthy 4.0.2
- Rational Quality Manager New & Noteworthy 4.0.1
- Rational Quality Manager New & Noteworthy 4.0
New in Rational Quality Manager 4.0.6
- Increased team productivity and agility
- Support for systems testing through enumerated project execution variables
- Requirement-driven testing
- Online migration: Reduce downtime that occurs during upgrades
Increased team productivity and agility
Easier planning and tracking with suites through automatic creation of test case execution records at the time of test suite execution record creation
When you run a test plan that has a test suite, the work load for the test iteration is calculated by the number of test case execution records and their estimations, weights, or both. For the calculation to work, test case execution records must exist for the test cases that are in the test suite. The test case execution records might already exist, or they might need to be created. In version 4.0.5 and earlier, the records are created when the test suite execution record is run in the execution phase of the testing cycle.
To support planning the work load and assigning the test case execution records, you can now enable a feature to create test case execution records when you create a test suite execution record. As a result, when test suite execution records are generated, all of the required test case execution records are available for planning. The progress bars on the test suite and test plan show the hours and weights. This optional feature can be enabled on the Execution Preferences page, which you can reach by clicking the Admin icon and then clicking Manage Project Properties > Execution Preferences.
Ability to drag table column headers to reorder columns
You can now move a column by dragging its header. This capability works in all list views and sections.
For more information, see work item 60921.
Support for systems testing through enumerated project execution variables
Execution variables with lists of predefined values
You can use a new kind of execution variable, called a project execution variable, to support a predefined list of values. Using a common list of variables facilitates better coordination across the testing team, fosters better reuse, and reduces user error by preventing input of invalid data in test runs. For more information, see this Jazz.net story: 97205: Capability to use enumerated values for execution variables for test execution.
New permissions for project execution variables
To create project execution variables and their predefined values, you must have permissions enabled for two new operations: "Save Project Execution Variables" and "Save Values of Project Execution Variables."
New "Project Execution Variables" section on the Manage Project Properties page
The Manage Project Properties page contains a new section, called Project Execution Variables, where you can create and manage project execution variables.
Execution variables within test artifacts
Manual test scripts, remote test scripts, test cases, and test suites now support two types of execution variables.
- Artifact variables, which are execution variables that you can create within a test artifact
- Project execution variable, which you can create on the Manage Project Properties page, and can be shared across multiple test artifacts
You can create an artifact variable by clicking the Create Execution Variable icon and then enter a variable name and a variable value. The value is used as the default value at run time. You can also pass artifact values from test suites or test cases that are associated with the test script by creating an artifact execution variable with the same name as the variable to be passed.
When you are working with project variables, click the Add button to add an existing project execution variable to the test artifact. You can select values for project variables only from the predefined list values that are defined on the Manage Project Properties page.
Within a test artifact, two execution variables cannot have same name. If two execution variables in a test artifact have the same name, an error occurs when you try to save the artifact. However, on the Manage Project Properties page, you can rename a project variable that has the same name as an artifact variable. In that case, during test artifact execution, the artifact variable is given preference over the project variable.
The Execution Variables window in the manual test script editor
In the manual test script editor, the Execution Variables window now supports two types of execution variables: artifact variables and project variables. In the window, you can select the type of the execution variable.
Based on the type that you select, the corresponding variables are shown in the window. Within the steps of the manual test script editor, artifact variables and project variables are represented by different colors.
The Execution Variables section in the remote test script, test case, and test suite editors
In remote test scripts that support execution variables, execution variables are now shown in a new section. You can also see the Execution Variables section when you view a test case or test suite. In the Execution Variables section, you can select the type of execution variable. Based on the type that you select, the corresponding variables are shown.
Test execution with execution variables
You can provide values for execution variables before the test runs. That gets highest preferences during test execution. After that preferences are in these order - test suite, test case and test script. Artifact variable gets preference over project variable if there is a name conflict of two execution variable within same artifact. You can select values for project variables only from the predefined list values that are defined on the Manage Project Properties page.
The Run Test Case wizard
The Run Test Case window has been expanded into a wizard. If you select Modify Execution Variable Values, the Next button is enabled. If you click Next, you can modify artifact and project variables for both test cases and test scripts.
The Run Test Suite wizard
The Run Test Suite window has been expanded into a wizard. If you select Modify Execution Variable Values, the Next button is enabled. If you click Next, you can modify artifact and project variables for a test suite.
Requirement-driven testing
Fine-grained requirement tracing through traceability to test script steps
The functionality around traceability of requirements to test script steps is improved in Rational Quality Manager 4.0.6.
OSLC API for test script steps
OSLC APIs are available for test script steps with requirement links. For more information, see the API documentation on Jazz.net.
Integration with Rational DOORS Web Access through OSLC
From IBM Rational DOORS Web Access, you can link a requirement to the test script step that the requirement is to be validated by. To do so, select the specific step from the test script in Rational Quality Manager.
When you hover over the script step link, you can see detailed information about the script steps.
If you click the test script step, a link from Rational DOORS Web Access takes you to the test script editor in Rational Quality Manager. The step is selected and you can see the validates requirement link.
Synchronization of requirement links between test scripts and test cases
In a test script, when you add, modify, or remove requirements links, the requirements traceability is automatically updated for any test cases that reference that test script. This behavior occurs only when the appropriate project property is enabled.
Addition of requirement-to-step links in the data warehouse
Information about test script steps and their links to requirements is now in the data warehouse and is populated through the ETL that comes with the product.
Increased productivity and agility in coverage views
Performance improvements in the Coverage view of collections
In test plans, the performance of loading data is improved in the Coverage View of collections in the Requirement Collection section. You can tune performance by adjusting the value of the "Requirements search result page size" advanced property.
New filters for OSLC traceability links in tables
You can now filter test artifacts by whether they have OSLC traceability links, as shown in this image:
The filter has three conditions:
- Any: Displays any test asset, whether or not it has has links
- Has [Link Type] Link: Displays only the test assets that have links of the given type
- Does Not Have [Link Type] Link: Displays only the test assets that do not have links of the given type
You can filter artifacts by OSLC traceability links in following tables:
- Test Plans table
Filter by: Requirement Collection or Development Plan links
- Test Cases table
Filter by: Development Item links
- Test Case Execution Records table
Filter by: Defects or Deployment Plan links
- Test Case Results table
Filter by: Defects links
- Test Suite Execution Records table
Filter by: Defects links
- Test Suite Results table
Filter by: Defects links
For more information, see plan item 98146.
Online migration: Reduce downtime that occurs during upgrades
Online migration is a new feature in 4.0.6. The purpose of online migration is to reduce server downtime during migrations by completing some of the database migration tasks while the existing product version server is still running.
In 4.0.6, the only application in the Rational solution for Collaborative Lifecycle Management (CLM) that uses online migration is the Quality Management (QM) application. For more information, see Jazz Foundation plan item 282873. The 4.0.6 information center has comprehensive documentation about when to consider using the online migration feature and how to do so.