The levels for Defect management are typified as follows:
Please find the checkpoints below.
| Controlled | |||||||||||
| 1. The defect lifecycle is defined (including a retest) and applied. 2. The following items are recorded for each defect: unique ID, related test case ID (if applicable), person reporting the defect, date, severity category, description (the actions to reproduce the defect, expected and observed result) and defect status. 3. For further handling of defects the responsibilities are defined. 4. All those involved in assessing and solving defects have access to the relevant defect management tool. |
|||||||||||
| Efficient | |||||||||||
| 1. The defect management tool enforces the authorization structure for status transitions of defects. 2. All persons involved in logging and/or tracking defects use the same defect management tool or separate defect management tools with a seamless connection. 3. The defect administration lends itself for extensive reporting possibilities, which means that reports can be selected and sorted in different ways. 4. Trends are identified. For this, more information is recorded about a defect, the subsystem, priority, program and version, test basis and version, root cause, all status transitions and problem solver. |
|||||||||||
| Optimizing | |||||||||||
| 1. A set of guidelines for defect management is provided by the line organization or project management, and used for each test project. Defect management is the responsibility of the line or project organization, where the test process provides the necessary data. 2. Defects are analyzed for common properties and recommendations are made to avoid future defects. |
|||||||||||
(Source: “TPI Next, Business Driven Test Process Improvement” ISBN 9072194977)
