About Defect Actions

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

Defect Management automatically creates a Defect Action when the Defect 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.

If a rejected Defect is demoted, the Defect Actions remain in the Rejected state. You must individually assess the Defect Actions, and manually demote any of them as needed to the Open state.

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-00024 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.

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 Product Version, it is marked as committed to the product and is listed in the Committed Defects category for the Product. If a Defect Action is planned to be implemented in a future release of the product, it is marked as a candidate for the model and is listed in the Candidate Defects category for the Model. The Defect Action cannot be connected to both a Product Version 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.