Built-in Workflow for Change Requests

Lifecycle for Change Requests

The above diagram shows the lifecycle for a change request with an initial status of Open. The status was then set to Fixed. After this setting, the built-in workflow added an additional status field of Verified Fixed. Finally, the change request was closed, meaning its status was set to Closed (Fixed).

The diagram also shows that a change request can be reopened at any stage in its lifecycle because the arrows leading from each of the three fixed statuses can lead back to the Open status at any time.

Summary of the Change Request Automatic Workflow

The following summarizes the steps used in processing change requests as explained in this topic. It includes the automatic workflow changes the application makes to change requests based on their statuses.

Submit

Anyone (usually a tester or quality assurance engineer) can submit a change request.

Process: Select the Change Request tab. Then select New from the Change Request or context menu.

A change request has the following default properties (which you can change if necessary).

Status: New

Severity: Low

Priority: Not prioritized

Type: Defect

Platform: All

Last Build Tested: Current build label

Entered by: Person currently logged on to the application

Many other fields are initially blank. Some team leaders prefer to have all change requests submitted at the root folder. They use drag-and-drop to move the change requests to the appropriate child folders.

Assign*

Process: The team leader finds all new change requests and does one of the following:

• Opens the change request and assigns it to a developer, help writer, or other appropriate team member.
• Defers the change request until a later date, perhaps the next release of the product.
• Specifies that the change request is As Designed and not to be fixed. If the change request status is Open, no automatic changes occur. If the change request status is Deferred or As Designed, then Addressed in Build is disabled and the responsibility is assigned to the user who created the change request.

Resolve

Process: Users find the Open or In Progress change requests assigned to them, and do one of the following for each request:

• Resolve the problem in the system and update the properties of the change request. (The statuses that indicate that a change request has been resolved are Cannot Reproduce, As Designed, Fixed, Documented, or Is Duplicate.)
• Defer the change request until a later date, perhaps the next release of the product. Your team leader may prefer that you do not defer change requests.
• If the change request status is one of the possible resolution statuses, then Addressed in Build becomes Next Build for Fixed and Documented statuses. It becomes disabled for other statuses. By default, the responsibility is assigned to the person who submitted the change request, who is expected to verify the resolution.
• If the change request status is Deferred, then Addressed in Build is disabled and the responsibility is assigned, by default, to the user who created the change request.

Build

Who builds the project? The project view may have a formal or informal build process. However, at some point, all the files, and so on currently in the view receive that build label. It is usually applied to the source code files, and so on that were compiled (and may need to be changed) rather than to the executable files that result from the build.

Effect on change requests: For any resolved change request that has Next Build as the setting for its Addressed In Build property, Next Build is replaced with the next build label that is created.

Note: If a new build label is based on a past configuration (rather than the current configuration), it has no effect on the Addressed In Build property.

If a change request has not branched in its current location, Next Build may be replaced with a build label from another view. For example, suppose you create a branching child view or share a folder from one view to another. Suppose that Next Build is the value of some change request’s Addressed In Build property and that change request has not branched. When a build label is created in the source view, Next Build is replaced with the name of that build label, regardless of the location.

Verify*

The person who submitted the change request (usually a tester or quality assurance engineer) verifies a resolution.

Process: Install the build in which the resolution is to be verified and determine whether the change request has been resolved correctly. Do one of the following:

• Verify the change request, marking it as Verified Cannot Reproduce, Verified As Designed, Verified Fixed, Verified Documented, or Verified Is Duplicate.
• Reopen the change request and update the setting for Last Build Tested.
• If the change request status is Verified, no automatic changes occur.
• If the change request status is Open, Addressed in Build is blank. If the change request has changed from resolved to Open, the user who changed the status to Fixed or Documented becomes responsible.

Close*

Usually the team leader closes the change request.

Process: The team leader does one of the following:

• Reviews and closes the verified change request.
• Reopens the change request.
• If the change request status is Closed, then no automatic changes occur.
• If the change request status isOpen, then Addressed in Build is blank. If the change request has changed from resolved to Open, the user who changed the status to Fixed or Documented becomes responsible.
• If the status of a change request changes from Verified to Open, the user who changed the status to Fixed or Documented becomes responsible and Addressed in Build is blank.

*Changes in status can result in automatic changes to other properties.