IBM Rational Quality Manager
Quality management · Manual testing · Continuous improvement
Rational Quality Manager 5.0.1
Rational Quality Manager 5.0.1 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 CLM applications, see these pages:
- Jazz Foundation (Jazz Team Server) 5.0.1
- Change and Configuration Management 5.0.1
- Requirements Management 5.0.1
New in previous versions of Rational Quality Manager
For details about new features and functionality in the previous release, see Rational Quality Manager New & Noteworthy 5.0.
New in Rational Quality Manager 5.0.1
- Dashboard widget shows the query results for all major test artifacts
- Execution preference enables the use of a single machine for test suite execution
- Strict reservation-based automated testing
through an extended scheduling capability
- Scenario 1: You already reserved the machine
- Scenario 2: You do not have a reservation for the machine
- Scenario 3: You run the test by using a test cell
- Scenario 4: The machine reservation is canceled or the reservation time period ends while you are running the test suite
- Scenario 5: A test suite is run by using an execution schedule
- Scenario 6: You disallow the mixing of 2 test suite runs on a machine
- When run in parallel, test scripts are run in the order stated by the test suite
Dashboard widget shows the query results for all major test artifacts
A new dashboard widget, Test Artifact, is added to the widget catalog. The new widget supports both personal and shared queries for all major test artifacts. You can use the widget to embed the results of a query directly onto a dashboard. The widget supports these artifacts:
- Test plans
- Test cases
- Test suites
- Test scripts
- Test case execution records
- Test suite execution records
- Test case results
- Test suite results
In the settings for Test Artifact widget, you can select any project area and one of the eight available artifact types. Next, select a saved query. The query can be personal or shared.
From the display settings, you can select the columns to include in the widget. By default, these columns are shown:
|Test case execution record
|Id, Name, Last Result
|Test suite execution record
|Id, Name, Last Result
|Test case result
|Id, Name, Status
|Test suite result
|Id, Name, Status
Also by default, 10 records are shown per page. You can show 10, 25, 50, 75, or 100 items per page.
The following image shows a Test Artifact widget that shows the results of the Approved Test Cases query.
The header of the widget contains this information:
- An icon that indicates the test artifact. In this example, the test artifact is a test case.
- The artifact type, which is a test case.
- The name of the saved query, which is Approved Test Cases.
- The number of items that the query returned, which is 2.
If you click the title of the header, the test artifact table that is filtered by the saved query opens.
For more information, see this Jazz.net story: Story 79258.
Execution preference enables the use of a single machine for test suite execution
In earlier releases of Rational Quality Manager, the default behavior of test suite execution is to use as many test adapters as are available to run a test suite as quickly as possible. However, customers have indicated that they would value the repeatability of running a suite on one machine.
You can now change the default behavior so that only one adapter is selected to run a test suite if all of the steps of the test suite contain the same type of test script, such as command-line scripts or Rational Functional Tester scripts. In the execution preferences, select the Select a single machine for the test suite if all steps in the test suite contain the same type of test script check box.
You still have the option to explicitly assign other test adapters to any or all of the steps in the suite. In addition, usability improvements have been made to interface where you select adapters.
Strict reservation-based automated testing through an extended scheduling capability
To run a remote execution script, Rational Quality Manager first searches a list of available adapters and selects an adapter from that list. If the corresponding machine is not reserved for the current user, it is reserved for the current user and the test is run on that adapter. After the test is over, the reservation is removed from the machine so that other people can use it.
However, the Rational Quality Manager team has found that some deployments want tighter control of their lab resources for testing, particularly when they use sophisticated test harnesses and test beds that can be costly and popular resources. As a result, this milestone includes new execution behavior. To enable the behavior, in the execution preferences, select Enforce lab machine reservation and click Allow tests to be queued on any machine, and when the user receives the machine, automatically start the tests.
When you enable the new behavior, execution tasks (execution requests) have a new state named Awaiting Reservation. When an execution task is in the Awaiting Reservation state, adapters will not select that task for execution. Instead, adapters select only the tasks that are in the Queued state.
If you run a remote test script on an adapter and the corresponding machine is not reserved for you at that time, the generated execution task moves into the Awaiting Reservation state. After you have the reservation for that machine, the newly generated task moves into the Queued state and will be picked by an adapter after the adapter is free.
If the reservation start time is earlier or equal to current time, the generated execution task instantly moves into the Queued state. If the reservation is for a future time, the task waits until the reservation time. At that time, the generated execution task is moved into the Queued state by an asynchronous task that runs in every 5 minutes. In this mode, the automatic reservation of machines is not supported.
For more information, see this Jazz.net story: Story 111593.
Suppose a test suite has 15 test cases. All of the test cases are associated with same type of remote test scripts. A corresponding adapter is running on a machine. The following scenarios are examples of how the new execution behavior works in various situations.
Scenario 1: You already reserved the machine
You run the test suite. In the Run Test Suite window, the machine that is reserved for you is shown. You run the test on that machine. All of the tasks for that test suite are created in the Queued state. When adapter is free, it runs the queued tasks.
Scenario 2: You do not have a reservation for the machine
You run the test suite. In the Run Test Suite window, in the Machine column, this message is shown: No machines are reserved for you.
Select all of the steps in the Run Test Suite window and click the Change Machine icon in the heading of the Machine column. The "Select a machine to run this test" window opens. By default, that window shows the machines that are reserved for you. You can also view all of the machines, only the reserved machines, and only the unreserved machines.
Select an unreserved machine; then, click Finish in the Run Test Suite window. All of the tasks for that suite execution are in the Awaiting Reservation state because the machine is not yet reserved for you. After the machine is reserved for you, the task moves into the Queued state.
Scenario 3: You run the test by using a test cell
When test suite is run on a test cell, Rational Quality Manager searches the adapters at run time. While searching adapter at run time, the product will first try to find the reserved machine for you. If a machine is available, the test is queued on that machine. All of the tasks will be in the Queued state. Otherwise, the product selects an unreserved machine and runs the test on that machine. In this case, all of the tasks will be in the Awaiting Reservation state.
Scenario 4: The machine reservation is canceled or the reservation time period ends while you are running the test suite
Suppose 5 test cases of the test suite have already run and the sixth test case is running. At that time, someone cancels your machine reservation. The sixth test case run will still continue. However, the remaining 9 test cases move into the Awaiting Reservation state. When the reservation is available for you again, the remaining tasks move into the Queued state.
Scenario 5: A test suite is run by using an execution schedule
Typically, scheduled task are run by an ADMIN user who has many permissions enabled. By default, that user is disabled. If a machine is run by the ADMIN user, the machine is automatically reserved for that user and unreserved for other users.
Scenario 6: You disallow the mixing of 2 test suite runs on a machine
When the "Restrict reuse of lab resource if reserved for a Test execution" execution preference is enabled, if you try to run 2 test suites on the same machine, all of the steps of the first test suite will run. Then, the second test suite will run. The execution tasks for the second test suite will be in the Awaiting Reservation state until all of the steps in the first test suite are run. After the first test suite runs, tasks for the second test suite move into the Queued state.
When run in parallel, test scripts are run in the order stated by the test suite
If you run a test suite that contains the same type of remote test scripts in parallel mode on one machine, the steps are run in the order that is mentioned in the test suite. If you have a mix of script types then the behavior remains the same as in prior releases, where tests will be run as soon as possible based on machine availability.