Defect classification

created: 1998-09-02, Lutz Prechelt
changed: 1999-01-14, Lutz Prechelt
RCS:     $Id$

You can either use this standard as is, or adapt it to your needs.
If you adapt it, summarize the changes below.

$log$

This defect classification uses three dimensions:

The injection phase: When was the defect produced?
The defect type (product-related): What was the structure of the defect itself (or: what sort of repair was required)?
The defect reason (process-related): Why was the defect introduced (or: what sort of mistake led to the defect)?

Defect injection phases

The injection phase of a defect describes when a defect was introduced. To be useful, this should not refer to the surface causal event of the defect (``When did I produce the part of the product that I now have to repair?''), but instead should refer to the deep causal event (root cause, RC) of the defect: ``When was the event that subsequently made me produce the part of the product that I now have to repair?''.

There are three cases:

Local: The RC can be in any one of the development phases of the program protocoled in the current time/defect log.
In this case I indicate that phase as the injection phase of the defect, for instance ds for design or cd for coding.
Regional: The defect can be in some other software produced in the same project (or the same organisation), but not the one protocoled in the current time/defect log.
In this case I call the injection phase pr (for `project') or op (for `other project' of my own organisation). Note that the original author of the defective piece of software should be informed of the problem and should log it in the respective time/defect log -- even if s/he does not repair the defect.
External: The defect is in some software I cannot control or repair. In this case I call the injection phase ex (for `external').

Defect types

This classification describes the structure of the defect:

IC: Interface Capability.
The design of an interface is wrong, so that the interface does not provide the functionality that it must provide.
IS: Interface Specification.
The specification of an interface is wrong, so that the parameters involved cannot transfer all of the information required for providing the intended functionality.
This is a less fundamental variant of IC: Only parameters need be added.
ID: Interface Description.
The non-formal part of the description of an interface is incomplete, wrong, or misleading. This is typically diagnosed after an IU.
Note that the description of a variable or class attribute or data structure invariant is also an (internal) interface.
II: Interface Implementation.
Something that I cannot influence does not work as it should.
This defect should never be used when I am the source of the defect. (In principle, this is a special case of ID.)
IU: Interface Use.
An interface was used wrongly, i.e., in such a way as to violate the interface specification.
IV: Data Invariant.
A special case of IU. The interface violation is: not maintaining the invariant of some variable or data structure.
Violating the meaning of a simple variable is a special case of this.
MD: Missing Design (of required functionality).
A certain requirement is covered nowhere in the design.
This is stronger than IC, where the coverage is present, but incomplete.
MI: Missing Implementation (of planned functionality).
A certain part of a design was not implemented.
If the part is small, MC, MA or WA may be more appropriate.
ME: Missed Errorhandling.
An error case was not handled in the program (or not handled properly).
MA: Missing Assignment.
A single variable was not initialized or updated.
Only one statement needs to be added.
MC: Missing Call.
A single method call is missing.
Only one statement needs to be added.
WA: Wrong Algorithm.
The entire logic in a method is wrong and cannot provide the desired functionality.
More than one statement needs to be added or changed.
WE: Wrong Expression.
An expression (in an assignment or method call) computes the wrong value.
Only one expression needs to be changed.
WC: Wrong Condition.
Special case of WE. A boolean expression was wrong.
Only one expression needs to be changed.
WN: Wrong Name.
Special case of WE. Objects or their names were confused. The wrong method, attribute, or variable was used.
Only one name needs to be changed.
WT: Wrong Type.
Two `similar' types were confused.
: .

IC, IS, ID, MD are typically related to design.
IU, IV, MI, MA, WE, WC, WN are typically related to implementation.

After some defect data have been collected one may adapt the above classification to one's own needs. Such changes should be upwards compatible so as not to render old data useless. This means that the only changes are typically clarification of the definition of a defect type and extension of the scheme to include additional defect types. Old defect types may be marked obsolete but should not be removed from the standard. Still, as a rule, changes to the defect classification should be made only rarely.

Defect reasons

This classification describes why the defect was introduced:

om: Omission.
I forgot something that I knew I had to do.
ig: Ignorance.
I forgot something, because I did not know I had to do it.
cm: Commission.
I did something wrong, although I knew in principle how to do it right.
ty: Typo.
I did something trivial wrong, although I knew exactly how to do it right.
kn: Knowledge.
I did something wrong, because I lacked the general knowledge (i.e., the education) how to do it right.
in: Information.
I did something wrong, because I lacked the specific knowledge how to do it right or had received misleading information about how to do it. This refers to a problem with communication.
ex: External.
I did nothing wrong. The problem was somewhere else and the defect was introduced by some other person.

Lutz Prechelt, prechelt@ira.uka.de, Last modified: Wed Apr 14 09:39:03 MET DST 1999