Classifying Failures and Defects

The correction of defects is managed via the reports in the defect database. The urgency of correcting any particular fault depends on how seriously it affects the product’s users. There is a big difference between unsolved failures that cause system crashes and defects that document simple visual issues in the interface layout. Defects that significantly impair (or even prevent) use of the product obviously have to be dealt with first.

Side Note: Classing defects

The “degree of impairment of product use” can be quantified by labeling the defect with a severity class. Table 6-2 shows a sample:

Table 6-2Defect severity

Prioritize fault correction

The severity of an issue alone does not determine the urgency of correcting the underlying fault. Factors affecting these kinds of decision include input from project or product management (for example, the estimated correction effort), test-related requirements (for example, whether the defect in question is blocking other tests), and release and update planning requirements.

The urgency attached to correcting a fault therefore has to be classified using an additional “priority” attribute.

Case Study: The VSR-II fault correction priorities

Because the defect reporting template and the defect management tool introduced and used by the team for the original VSR project are the same as those in VSR-II, so they have been directly adopted in the new version. The defect priority scheme looks like this:

Table 6-3Fault correction priority