About Defect Actions

Every defect must have at least one defect action that represents the work required to resolve the problem and defines the model version revision or model where the fix will be implemented.

Defect Management automatically creates a defect action when the defect action is promoted to Open, and you can manually create additional defect actions. Multiple defect actions can be created to track changes needed to resolve the problem, but implemented independently—such as a defect requiring a hardware and a software fix, each of which is implemented by a separate individual.

This page discusses:

Defect Action Names

When a defect action is created, it has the same name as the defect it is associated with. For example, if the defect is named DFT-0000024, then the defect action is named DFT-0000024 Rev 1. If multiple defect actions are required for a defect, the subsequent defect actions are created as revisions of the first defect. To continue the example, the second defect action would be named DFT-0000024 Rev 2, and the third, DFT-0000024 Rev 3, and so on.

Rejecting Defects and Defect Actions

Typically, a defect is rejected only if it is in the Submit or Evaluate state and the determination is that either there is not a problem or the issue will not be resolved. Once the defect is promoted to Open, the defect actions associated with that defect control the business process for resolving the issue.

If a defect action is rejected, the associated defect is also rejected unless there are other defect actions that have not been rejected. For example, if the Action Assignee determines that the defect was actually a user error, the Action Assignee would reject the defect action. If it was later determined that it was not user error, the business process dictates that the rejected defect action should be demoted to either the Evaluate or Open state. When this happens, the related defect is automatically demoted to the Open state. The resolution of the problem continues.

Where a Defect Action Is Fixed

A defect action must specify where the fix defined within the defect action will be implemented. If a defect action is planned to be implemented in a model version revision, it is marked as committed to the model version revision and is listed in the Committed Actions page for the model version revision. If a defect action is planned to be implemented in a future release of the model version, it is marked as a candidate for the model and is listed in the Defect Candidates page for the model. The defect action cannot be connected to both a model version revision and a model.

About Dependent Defect Actions

Defect actions can be interdependent. For example, the work to support a new branch option in the software could require a change to both the API and GUI, where the GUI change cannot be implemented until after the API is updated. The defect action to fix the GUI is marked as dependent on the defect action that fixes the API.

About Implementation Reviews

Implementation reviews can optionally be used to describe the set of changes made by an Action Assignee to resolve a defect action. For example, to fix an issue with a dialog box, changes may need to be made to several different files. Implementation reviews can be created at any point prior to a defect action being promoted to Closed.

An implementation review is created in the Initiated state. After reviewing the implementation details, it is promoted to Closed. If one or more implementation reviews are created for a defect action, they must all be closed before the defect action can be closed.