<< Coping with the Time Crunch | Isolation and Generalisation >>

Defect Management

<< Coping with the Time Crunch | Isolation and Generalisation >>

Defect Management

Defects need to be handled in a methodical and systematic fashion.

There's no point in finding a defect if it's not going to be fixed. There's no point getting it fixed if it
you don't know it has been fixed and there's no point in releasing software if you don't know
which defects have been fixed and which remain.

How will you know?

The answer is to have a defect tracking system.

The simplest can be a database or a spreadsheet. A better alternative is a dedicated system which
enforce the rules and process of defect handling and makes reporting easier. Some of these
systems are costly but there are many freely available variants.

Importance of Good Defect Reporting

Cem Kaner said it best - "the purpose of reporting a defect is to get it fixed."

A badly written defect report wastes time and effort for many people. A concisely written,
descriptive report results in the elimination of a bug in the easiest possible manner.

Also, for testers, defect reports represent the primary deliverable for their work. The quality of a
tester's defect reports is a direct representation of the quality of their skills.

Defect Reports have a longevity that far exceeds their immediate use. They may be distributed
beyond the immediate project team and passed on to various levels of management within
different organisations. Developers and testers alike should be careful to always maintain a
professional attitude when dealing with defect reports.

Characteristics of a Good Defect Report

Objective criticising someone else's work can be difficult. Care should be taken that
defects are objective, non-judgemental and unemotional. e.g. don't say "your program
crashed" say "the program crashed" and don't use words like "stupid" or "broken".

Specific one report should be logged per defect and only one defect per report.

Concise each defect report should be simple and to-the-point. Defects should be reviewed
and edited after being written to reduce unnecessary complexity.

Reproducible the single biggest reason for developers rejecting defects is because they
can't reproduce them. As a minimum, a defect report must contain enough information to
allow anyone to easily reproduce the issue.

Explicit defect reports should state information clearly or they should refer to a specific
source where the information can be found. e.g. "click the button to continue" implies the
reader knows which button to click, whereas "click the `Next' button" explicitly states
what they should do.

Persuasive the pinnacle of good defect reporting is the ability to champion defects by
presenting them in a way which makes developers want to fix them.