Timelines and Iterations in Rational Quality Manager

Sachin P. Patel, IBM
Last updated: March 20, 2012
Build basis: Rational Quality Manager Beta 2012

This release of Rational Quality Manager integrates with Timelines and Iterations, a core part of Jazz Foundation. This article explains the key differences from prior releases and how the changes introduced not only simplify the configuration of test schedules, but bring forth a host of new capabilities into the application. It is recommended that you have prior knowledge of Jazz Process, Timelines and Iterations before proceeding with this article.

The following articles will help you get acquainted with some of these concepts.

Process Behavior Lookup
Team Process Concepts
Team Process Customization

Background

In prior releases of Quality Manager, a test schedule consisted of a list of milestones that were specific to a given test plan. If two individual test plans wanted to share a common schedule the set of milestones needed to be duplicated and maintained independently in each test plan. In other words, there was no re-use of milestones within a project area as each milestone was unique to a single test plan. This release, as part of the improved integration with Jazz Process, we leverage timelines and iterations. This integration not only alleviates the inability to define a true common schedule, but introduces along with it four additional capabilities.

1. Current iterations(s)
2. Team Areas
3. Point-in-time process behavior and iteration types
4. A hierarchical iteration structure

In this article, we will start off by describing how timelines and iterations are used out of the box or after migrating from a prior release of RQM. This will help explain the basic usage of, and how RQM has transitioned to adopting iterations. Next, we’ll go into a slightly more advanced scenario explaining how multiple timelines and team areas can be introduced.

Let’s first quickly revisit the definition of timelines and iterations as described in the referenced articles above.

Timelines
The project area defines one or more timelines which define how a given planned period of time is partitioned into iterations such as releases, milestones, sprints etc. A project area can be assigned to exactly one project timeline to work against at any instance in time. Similarly, team areas contained in a project can also each be assigned to exactly one timeline, which could be the project or another parallel timeline. In RQM, a test plan can be created with a schedule that consists of one or more iterations from within a single timeline.

Iterations
Iterations typically have a start and end date. Iterations can be planned to deliver a result by marking them with “A release is planned for this iteration”. This flag designates an iteration to be consumable by a test plan and allows execution records to be created against those iterations. Iterations can optionally have an iteration type. Iteration types allow you to define a reusable permission and behavior model that can be associated to one or more iterations. For example, your organization might want to establish stricter control towards the end of a release. Iterations with no delivery planned and with no dates configured can be used to control the process behavior within a parent iteration. Each timeline has a current iteration that controls the process behavior. Note: What was previously referred to as “milestones” in prior releases of Quality Manager, is now equivalent to an “iteration with the deliverable flag selected.”

---

The Basics

The first step in using timelines in RQM is to define a set of iterations for your project area in your project timeline. At time of project area creation, a timeline is automatically created and set as the project timeline. You can also explicitly set a single timeline as the project timeline.

As mentioned earlier, out of the box we are limited to only using the timeline marked as the project timeline. The Manage Project Timelines link in the home menu allows you to access the project area’s timelines anywhere in the application to easily view/create/modify iterations.

The second step is to create a new test plan and construct a test schedule based on the defined iteration structure. In the new test schedule section you can browse for and select a single iteration within the configured timeline to populate the test schedule section.

The schedule is then automatically populated based on the iteration selected and any deliverable iterations underneath it. An iteration is considered having a deliverable if the “A release is scheduled with this iteration” option is selected when editing the properties of the iteration.

There is no limitation to which iteration in the timeline must be selected and this allows the flexibility to define a test plan at the granularity that you desire. E.g. You could create a test plan for an entire release, or for a single iteration. In a similar fashion to CCM development plans, different teams could also maintain their own test plan for the same iteration(s).

When the schedule table is populated, something subtle occurs that is important to take note of. When you create a new iteration in the timeline editor, the start and end date provided typically represent the “planned dates” at that moment in time. As time moves forward and as schedules change, updates made to these dates become more accurate and reflective of the “actual dates”. Both “planned dates” and “actual dates” existed in prior releases of QM and we still carry these concepts forward with our use of iterations. At the time when the schedule table is populated the planned start/end date is automatically set to the start/end dates of the iteration at that point in time. The values for these planned dates maintain their original value even if the dates in the iteration are modified. The dates of the iteration in the test plan schedule table however will always reflect the start and end dates as defined in the timeline. The planned dates in the test schedule table are always editable for corrections if the initialized date(s) are empty or incorrect.

If an iteration name or structure changes, the changes will be reflected back to any consuming test plan. For example, if two test plans reference the 4.0 iteration above and then an additional milestone is added, both test plans will have that additional iteration reflected in their schedule. The same holds true when an iteration is archived. It will no longer appear by default in the test schedule and execution records may not be created for it. Archived iterations can always be viewed within the test schedule by enabling the “View archived” filter on the table. Archived iterations can also be “restored” if needed within the timeline editor.

---

Additional Timelines and Team Areas

Now that you understand the basic usage of iterations in Quality Manager, let’s go back and revisit the advanced option that was referred to earlier, Enable team area and multiple timeline support. Enabling this option enables the ability to associate artifacts such as Test Plans and Test Cases, (and more), to team areas.

Creating a new team area allows you to associate the team area to any timeline in the project area.

By default, all team areas work in the project timeline. If an artifact is associated to a team area, the selected team area will be used as the governing process area for any operations for that artifact, otherwise the resource will be considered a project resource and the project area will act as governing process area and thus adhere to the process of the project timeline.

In combination with iteration types and custom defined roles, you now have full control on governing your project area, allowing the behavior of the application to differ between users, teams, or even different points in time. The referenced article Process Behavior Lookup explains this association in great length and so we’re going to skip ahead and talk about what this association means in terms of timelines.

When you create a test plan, associating a team area in addition to declaring the governing team area will also determine which timeline can be used to configure the test schedule. This may or may not be the project timeline based depending on which timeline was chosen for that team area. To further clarify this statement, if the artifact is not associated to a team area (i.e. is a project resource), the available timeline for the test schedule will be the project timeline. If the artifact is associated to a team area, the available timeline will be the one associated to the team area.

This may appear like a restriction at first, but the constraint of building a schedule off of a sub hierarchy of iterations within a single timeline is extremely important when execution records for test cases are created. The constraint prevents misalignment between the execution record’s selected iteration and its team area. In Rational Team Concert, the parallel concept is that when the planned iteration for a work item changes, its team area may automatically change as well in order to ensure that the correct governing process area is set (based on the work item’s category and its team area/timeline association). In RQM, when we create an execution record for a test case and associate it to the plan a similar thing happens. The execution record’s team area is set automatically to that of the test plan’s team area; and the iterations available for selection are a subset of the iterations within a single timeline. Both RQM and RTC in their own ways prevent a mismatch between an artifacts team area and its associated iteration.

---

About the author

Sachin P. Patel is a lead developer on Rational Quality Manager in Durham, NC. He can be contacted at sppatel@us.ibm.com.

Copyright © 2012 IBM Corporation