Process customization in Rational Quality Manager 4.0.1
Overview
Rational Quality Manager 4.0 added the ability to customize the behavior of the product using the Jazz process support. This includes the ability to customize the workflows for test artifacts. If an organization has the requirement to provide two levels of reviews for their test artifacts, they can modify the workflow, for example, to include “initial review” and “final review” as states for a test case. The process customization support also includes support for Team Areas and the ability to customize timelines, operations, and roles at both the overall process and team area level. Support for team areas gives administrators the ability to host sub-groups of users within the same project area with different requirements in terms of their ability to update test artifacts and the operational behavior around those updates such as requiring reviews or e-signatures.
Scenario
This article will use a fictitious scenario to illustrate how the behavior of Rational Quality Manager can be customized to fit the requirements of different teams within an organization. Javelin Medical Products is expanding their line of diabetic treatment products to include a new Insulin Pump in the product line. With the expanding product line, the company has also decided to introduce a Diabetics Product Selector web site to help doctors and patients navigate the product line and select the appropriate product. Being a regulated medical device, the test team for the insulin pump must follow a rigorous process that includes tight controls over review and approval of the test artifacts along with e-signatures to record the identity of who put the artifact in an approved and locked state. The test team for the product selector web site will follow a less formal process that only needs to meet the internal standards set forth by the company. This article will show how to configure Rational Quality Manager to meet the needs of both test teams operating within the Diabetics Products project area.
Team Area Setup
Let’s start by creating team areas for the device development and web development teams. This can be done in the overview section of the project area in the web admin interface on the right side of the screen as shown in figure 1. Each team area supports a unique set of users, roles, permissions, and operations behavior. Team areas are also associated with a timeline at the time of creation, so you may want to create a timeline before creating the team area. If you need to change the timeline associated with a team area, it can be done from the RTC eclipse client. We will create two team areas called “Device Development” and “Web Development”
Figure 1. Team Area Hierarchy
Next, we’ll assign users to the team areas. We will assign a user named “Deb” to the “Device Development” team area and give her the role “Test Team Member” as shown in figure 2 and the user “Bob” to the “Web Development” team area also with the “Test Team Member” role.
Figure 2. Team Area Members
Team area support is disabled in RQM by default. This is to eliminate confusion for users that do not need team area support and to allow for proper planning of team area structures before it’s exposed in the product. It is important to ensure that administrators and users have a thorough understanding of team areas before enabling this feature. Once enabled, it cannot be turned off because it’s impractical and destructive to revert to a flat project area structure. Team area support is enabled in project properties as shown in figure 3.
Figure 3. Team Area Enablement
Team Area Ownership of Test Artifacts
Now that we have created team areas and enabled the team area support in RQM. We can assign test artifacts team area ownership. The overall project area owns test resources that do not have a team area assigned. This is how RQM worked pre-4.0 or when team area support is disabled. Resources owned by the project area are governed by the users role and permissions assigned at the project area level. When a team area owns a resource, then access to the resource is governed by the users role and permissions assigned at the team area level; specifically to the team area that owns the resources. The structure is shown in figure 4.
Figure 4. Team Area Ownership
Timelines
Beginning with RQM 4.0, Project or Team area timelines are now used to define the test schedule. The iterations for a test plan come from the timeline associated with the team area that owns the test plan. Figure 5 shows an example timeline that is structured into two releases with multiple iterations in each release. The timeline is structured as a tree that can include multiple levels of parent-child relationships. You select a node in the tree such as “Release V1.x”, and all the child iterations for that node are included in the test plan. Timelines also support a “current iteration”, this provides context to dashboard widgets and other displays. As the current iteration changes, the dashboards and queries based on it are automatically updated. Test plans migrated from earlier versions of RQM, that did not support timelines, are migrated into the project area default timeline.
Additional details are available in Timelines and Iterations in Rational Quality Manager
Figure 5. Timelines
A common set of iterations can now be shared across multiple test plans as shown in figure 6. This provides a common place to maintain a schedule for a complex project that consists of multiple coordinated testing efforts.
Figure 6. Timelines shared across test plans
Customizing the Operations for a Team Area
Customizing operations in RQM 4.0 requires that the Team Concert Eclipse Client be installed and configured to connect to the Rational Quality Manager project area. Beginning with RQM 4.0.1, operations can be configured in the project area admin web interface. Figure 7 will show the web interface that’s available in 4.0.1, but the same capabilities are available in 4.0 using Team Concert Eclipse Client.
Operations can be configured at the project area or team area level in the hierarchy, care must be taken to achieve the desired result since operations defined at a higher level are inherited at lower levels. For our scenario, “E-Sig Required for Lock/Unlock” is configured on test case save in the Device Development team area as shown in figure 7, but not in the Web Development team area. It’s important to examine the “Everyone” role in the project and team area. In this example, “E-Signature Required for Lock/Unlock” had to be removed from the “Everyone” role in the Project Area configuration to achieve the desired behavior.
Additional details are available in Process behavior lookup in Rational Team Concert 2.0
Figure 7. Customizing operations for a team area
The Device Development team also requires that test cases be approved by at least one “Test Team Member”, so a “Required Approvals” precondition is also added to this team area as shown in figure 8.
Figure 8. Customizing operations for a team area
Customizing the users Role for a Team Area
Users assigned to Team Areas have roles defined in the team area that apply to any resource owned by the team area. For our scenario, Deb has the “Test Team Member Role” defined in the Device Development team area as shown in Figure 9. Deb is not a member of the Web Development team area and hence has no roles in that Team Area. Bob has the “Test Team Member” role in the Web Development team area and is not a member of the “Device Development” team area. This gives Deb the ability to update artifacts owned by the Device Development team area, but not artifacts in the Web Development team area. The opposite is true for Bob.
Figure 9. Team Area Roles
Roles and Permissions can be configured at multiple levels in the Project Area, Team Area, Timeline hierarchy. Roles can be defined at the Project Area and Team Area level. Permission can be defined at the Project Area, Team Configuration, Individual Team Areas, Timelines, or Iterations as shown in figure 10. Permissions for operations defined in the Project Area Configuration apply only to root/direct members of the Project Area. Permissions for operations defined in the Team Configuration are the default permissions for all teams unless a team has a defined its own permission customization.
Figure 10. Role and Permission Hierarchy
Customizing Workflow
Unique workflows can be assigned to Test Plans, Test Cases, Test Scripts, Test Suites, Test Case Results, and Test Suite Results as shown in figure 11.
Figure 11. Workflows by Artifact Type
Workflows consist of a set of States such as “Approved”, the set of Actions such as “Approve” that cause state transitions, and a state machine to define the transitions between States. States are associated to a set of pre-defined State Groups that the internal logic in Rational Quality Manager references. State Groups provide an abstraction from user defined States such that product modifications are not required when States are added or modified. The Diabetics Products teams needed to have both “Initial Review” and “Final Review” states for their test plan workflow instead of the single “Under Review” state in the default workflow. Figure 12 shows the modification to add the two review states to the Test Plan workflow.
Additional details are available in Leveraging custom workflows in Rational Quality Manager
Figure 12. Workflows Definition
Approval Tracking
Approval Tracking is another new feature in RQM 4.0.1 related to workflows. It lets an approval state change trigger a workflow action. The Diabetics Products team wants the successful approval of a Test Case to automatically trigger the “Approve” action on the test case such that the test case state is automatically changed to “Approved”. This is shown in figure 13.
Figure 13. Approval Tracking
Auto-Lock
Auto-lock is also another new feature of RQM 4.0.1. It lets an artifact state change trigger a lock or unlock of the artifact. The Diabetics Products team wants “Approved” Test Cases to automatically be locked. This is shown in figure 14.
Figure 14. Auto-Lock
Validating the Process Customizations
Now that customization of the process is finished, it’s time to give it a test drive. We start by creating a test plan for the Insulin Pump and the Product Selector web site as shown in figure 15. Next, we create a set of test cases for each project as shown in figure 16. The ÒDevice DevelopmentÓ team area owns all the test artifacts for the Insulin Pump and the ÒWeb DevelopmentÓ team area owns the artifacts for the Product Selector web site.
Figure 15. Test Plans
Figure 16. Test Cases
Saving Artifacts
If Deb, a member of the “Device Development” team area, saves an artifact that is owned by “Device Development”, the save is successful as shown in figure 17. If she tries to save an artifact that’s owned by “Web Development”, the save fails as shown in figure 18.
Figure 17. Successful Test Plan Save
Figure 18. Unsuccessful Test Plan Save
Locking Test Cases
If Bob, a member of the “Web Development” team area locks a test case, the test case is locked without requesting an e-signature as shown in figure 19. If Deb, a member of the “Device Development” team area, locks an artifact that is owned by “Device Development”, then an e-signature is requested as shown in figure 20.
Figure 19. Test Case lock without e-signature
Figure 20. Test Case lock with e-signature
Process Templates
Process templates can be extracted from an existing project areas using the Team Concert Eclipse Client as shown in figure 21.
Figure 21. Extracting Process Templates
Once extracted, the templates can be used to create new project areas on the same server or on remote servers by saving the process attachments into zip files as show in figure 22. The process template is made up of a set of process attachments, which can be manipulated independently.
Figure 22. Process Template Attachments
About the author
John Whitfield is the architect for the Rational Quality Management business segment and is responsible for Rational Quality Manager, Rational Performance Tester, Rational Functional Tester and the newly acquired Green Hat products. He is an expert in best practices and usage models for test management and spends a great deal of time working with customers on the usage and adoption of Rational Quality Manager. He can be contacted at jpwhit@us.ibm.com.
Copyright © 2012 IBM Corporation