Requirement Driven Testing Using Rational Quality Manager 4.0
This is the first in a series of articles discussing requirements related features in Rational Quality Manager (RQM). Requirement driven testing is not a new concept. It has been well adopted by System Domain and Agile projects. RQM provided support for this since it was first released and the capabilities of this support had been improved with each subsequent release.
Support products, versions and integration styles
Starting with RQM 3.x, the out-of-the-box requirements management (RM) capability is provided by Rational Requirements Composer (RRC). Any local requirement work items that were created in previous versions of RQM are moved to RRC and are then linked to the corresponding test plans and test cases in RQM. RQM focuses more on managing the association between test artifacts, while the requirements are managed through the integrated Requirement Management Tools. User can leverage the RM products to better manage the requirements, which can include lots of features such as rich text, comments, auditing, etc.
RQM 4.0 supports several well known RM products via a variety integration protocols such as Open Services for Lifecycle Collaboration (OSLC), API, and others. The table below lists the supported versions as well as how they are integrated.
Table 1. Supports products, versions, integration style
Requirement Product | Version | Integration Style |
|---|---|---|
| Rational DOORS | 9.3 and later | RQM Interface (RQMI) |
| Rational DOORS | 9.4 and later | OSLC [1][2] |
| Rational RequisitePro | 7.1.1.5 or 7.1.2.2 and later | API |
| Rational Requirements Composer (RRC) | All current versions | OSLC [3][4] |
- [1] RQM 4.0 integrates with Rational DOORs 9.4 as an OSLC QM 2.0 provider and an OSLC RM 2.0 consumer.
- [2] RQM 4.0 integrates with Rational DOORs 9.4 through OSLC and requires the usage of Rational DOORS Web Access (DWA) 1.5.
- [3] RQM 4.0 integrates with Rational RRC 4.0 and 3.x as an OSLC QM 2.0 provider and an OSLC RM 2.0 consumer.
- [4] RQM 4.0 integrates with Rational RRC 2.x and 1.x as an OSLC QM 1.0 provider and an OSLC RM 1.0 consumer.
Build the right tests and know what you test
Plan your tests better
The V-Model software development process has been widely adopted by System Domain as it can assure the business requirements, system requirements, detail design requirements, and has been verified in different phases. RQM supports the V-Model process by providing the associations between requirements artifacts and test artifacts on different levels. You can make the decision on which level to associate the requirements to based on project needs.
To get the best traceability results and reports, it is recommended that you use “Top-down” as the recommend scenario for associating relationships. Following articles in this series will cover these topics.
Figure 1: Associating Test Artifacts with Requirement Artifacts
Note:(OSLC*) – The association between Test Script and Requirements is only available for OSLC V2 integrations.
The first step for a Top-Down test plan is “Plan test coverage – associating requirement collections (*) with test plans. A test plan at the top level of the plan defines the scope and objective of a whole testing activity. By linking the requirement collections with a test plan, you claimed the scope of requirements this plan will need to cover. A requirement collection that has been added to a test plan means the requirements therein should be covered by this test plan. A requirement collection can be associated to one or to many test plans at the same time. That might mean a the requirement collection needs to be verified during different phases of the project such as System Test (plan), User Acceptance Test (plan), etc. It might also mean a set of general requirements that need to be considered for all the test cases, such as a requirement that documents a particular Key Performance Indicator.
Figure 2: Test Plan Coverage
After associating requirement collections with test plans, RQM provides the capability to facilitate the generation of test cases as well as distributing the requirement to the newly generated test cases. After clicking the Reconcile requirement collections button, a reconciliation wizard will pop-up. It normally includes 3 pages:
Step 1. Select Requirements that are not “covered”
Figure 3.1: Facilitate Coverage – Reconcile Wizard Page 1
Step 2. Generate or associate existing Test Cases with Requirements
Figure 3.2: Facilitate Coverage – Reconcile Wizard Page 2
Step 3. Compare requirements changes and create actions
Requirements that had been changed, removed, or deleted since last reconciliation will be discovered. You can take actions such as suspect the associated test case and create a quality task (optional).
More detail on the reconciliation and quality task feature will be provided in subsequent articles.
Make sure of the coverage
In RQM 4.0, we provide several Traceability Views which can help the user trace the cross products efforts. Two of them are related to requirements: Traceability View for Test Plans and Traceability View for Test Cases.
Figure 4: Test Plan Traceability View
In a test plan’s Traceability View, you are able to get the requirement collection coverage by test plan information at a glance. You are also able to change the association to fulfill or adjust the coverage by using the actions provided by the table. Refer to Figure 5 for more information.
Figure 5: Table Actions
In addition, to use the Traceability View, you are also allowed to add the requirement related column into General Views.
Figure 6: Add Validates Requirement Collection to General View
Align your testing with your requirements
During the testing lifecyle, the requirement associated to the test artifacts might require updates. To make sure your test efforts are reflecting the latest needs (requirement design), RQM provides several approaches to make you aware of changes from requirement tools.
Reconcile
The first way to get this information is performing reconciliation in the Requirement Collection Links section of the test plan or Requirement Links section of the test case. This feature helps you to get the latest change status for requirements (collection), and helps you to make decisions about whether you should take follow up actions for the corresponding test artifacts. We will cover this topic in more detail in a following article.Suspect Status
The second place to get this information is the General View for Test Cases, which has a column named Suspect. If the requirements linking to the test case has been changed since the last reconciliation, you have options to mark the test case as suspect. Thiss indicates that the tester should revisit the changed requirement and verify whether there are changes that need to be made for test case designs.
Figure 7: Suspect and Validates Requirement for Test Case
Are my requirements fulfilled?
You have planned your tests well and associated them with requirements. You also frequently update your test cases by reconciling them with the remote requirements. The next thing you might like to focus on should be, “How are things going with the requirements? Have they been tested? Are there any defects in them? Are we able to tell the customer that this requirement has been fulfilled and is ready to ship? RQM provides several out-of-the-box reports that can help you to get the answers to these questions. A detailed article about setting up, configuring, and how to get the best results from these reports will be published later. Here I have listed two of the reports just as a sample.
By viewing Plan Requirements Coverage Detail, you are able to get a whole picture of the coverage of requirements.
Figure 8: Plan Requirements Coverage Detail
By viewing Plan Requirements Defect Impact, you are able to know which defects are affecting requirements.
Figure 9: Plan Requirements Defect Impact
For more information
- Open Services for Lifecycle Collaboration OSLC Community
- Rational Quality Manager Know more about how to use RQM
- Rational Requirements Composer Know how to manage requirements using RRC
- Rational DOORS Know more about how to use DOORS
About the author
Scarlett Li is a lead developer on Rational Quality Manager in BeiJing, China. She can be contacted at lidb@cn.ibm.com.
Copyright © 2012 IBM Corporation