Defect Classes, the Defect Repository, and Test Design

Defects can be classified in many ways. It is important for an organization to follow a single classification scheme and apply it to all projects.

Some defects will fit into more than one class or category. Because of this problem, developers, testers, and SQA staff should try to be as consistent as possible when recording defect data.

The defect types and frequency of occurrence should be used in test planning, and test design. Execution-based testing strategies should be selected that have the strongest possibility of detecting particular types of defects. The four classes of defects are as follows,

  • Requirements and specifications defects,
  • Design defects,
  • Code defects,
  • Testing defects

1. Requirements and Specifications Defects

The beginning of the software life cycle is important for ensuring high quality in the software being developed. Defects injected in early phases can be very difficult to remove in later phases. Since many requirements documents are written using a natural language representation, they may become

  • Ambiguous,
  • Contradictory,
  • Unclear,
  • Redundant,
  • Imprecise.

Some specific requirements/specification defects are:

1.1 Functional Description Defects

The overall description of what the product does, and how it should behave (inputs/outputs), is incorrect, ambiguous, and/or incomplete.

1.2 Feature Defects

Features is described as distinguishing characteristics of a software component or system. Feature defects are due to feature descriptions that are missing, incorrect, incomplete, or unnecessary.

1.3 Feature Interaction Defects

These are due to an incorrect description of how the features should interact with each other.

1.4 Interface Description Defects

These are defects that occur in the description of how the target software is to interface with external software, hardware, and users.

2. Design Defects

Design defects occur when the following are incorrectly designed,

  • System components,
  • Interactions between system components,
  • Interactions between the components and outside software/hardware, or users

It includes defects in the design of algorithms, control, logic, data elements, module interface descriptions, and external software/hardware/user interface descriptions. The design defects are,

2.1 Algorithmic and Processing Defects

These occur when the processing steps in the algorithm as described by the pseudo code are incorrect.

2.2 Control, Logic, and Sequence Defects

Control defects occur when logic flow in the pseudo code is not correct.

2.3 Data Defects

These are associated with incorrect design of data structures.

2.4 Module Interface Description Defects

These defects occur because of incorrect or inconsistent usage of parameter types, incorrect number of parameters or incorrect ordering of parameters.

2.5 Functional Description Defects

The defects in this category include incorrect, missing, or unclear design elements.

2.6 External Interface Description Defects

These are derived from incorrect design descriptions for interfaces with COTS components, external software systems, databases, and hardware devices.

3. Coding Defects

Coding defects are derived from errors in implementing the code. Coding defects classes are similar to design defect classes. Some coding defects come from a failure to understand programming language constructs, and miscommunication with the designers.

3.1 Algorithmic and Processing Defects

Code related algorithm and processing defects include

  • Unchecked overflow and underflow conditions,
  • Comparing inappropriate data types,
  • Converting one data type to another,
  • Incorrect ordering of arithmetic operators,
  • Misuse or omission of parentheses,
  • Precision loss,
  • Incorrect use of signs.

3.2 Control, Logic and Sequence Defects

This type of defects include incorrect expression of case statements, incorrect iteration of loops, and missing paths.

3.3 Typographical Defects

These are mainly syntax errors, for example, incorrect spelling of a variable name that are usually detected by a compiler or self-reviews, or peer reviews.

3.4 Initialization Defects

This type of defects occur when initialization statements are omitted or are incorrect. This may occur because of misunderstandings or lack of communication between programmers, or programmer`s and designer`s, carelessness, or misunderstanding of the programming environment.

3.5 Data-Flow Defects

Data-Flow defects occur when the code does not follow the necessary data-flow conditions.

3.6 Data Defects

These are indicated by incorrect implementation of data structures.

3.7 Module Interface Defects

Module Interface defects occurs because of using incorrect or inconsistent parameter types, an incorrect number of parameters, or improper ordering of the parameters.

3.8 Code Documentation Defects

When the code documentation does not describe what the program actually does, or is incomplete or ambiguous, it is called a code documentation defect.

3.9 External Hardware, Software Interfaces Defects

These defects occur because of problems related to

  • System calls,
  • Links to databases,
  • Input/output sequences,
  • Memory usage,
  • Resource usage,
  • Interrupts and exception handling,
  • Data exchanges with hardware,
  • Protocols,
  • Formats,
  • Interfaces with build files,
  • Timing sequences.

4. Testing Defects

Test plans, test cases, test harnesses, and test procedures can also contain defects. These defects are called testing defects. Defects in test plans are best detected using review techniques.

4.1 Test Harness Defects

In order to test software, at the unit and integration levels, auxiliary code must be developed. This is called the test harness or scaffolding code. The test harness code should be carefully designed, implemented, and tested since it is a work product and this code can be reused when new releases of the software are developed.

4.2 Test Case Design and Test Procedure Defects

These consists of incorrect, incomplete, missing, inappropriate test cases, and test procedures.

Leave a comment