Defect Classes, the Defect

Repository, and Test Design

Defects can be classified in many ways.
• The defect types and frequency of
occurrence should be used to guide test
planning, and test design.
• Execution-based testing strategies should be
selected that have the strongest possibility of
detecting particular types of defects.
• It is important that tests for new and
modified software be designed to detect the
most frequently occurring defects.
 1.Requirements and Specificaton Defects
• The beginning of the software life cycle is critical for ensuring
high quality in the software being developed.
• Defects injected in early phases can persist and be very
difficult to remove in later phases. Since many requirements
documents are written using a natural language representation,
there are very often occurrences of ambiguous, contradictory,
unclear, redundant, and imprecise requirement.
• Some specific requirements/specification defects are:
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.
 Impedance Mismatches

As Management As the Project As Systems

requested it Leader defined it designed it

As Programming As Operations What the User

developed it installed it wanted

© Oscar Nierstrasz ESE — Requirements Collection ESE 2.4

2 . Feature Defects
• Features may be described as distinguishing
characteristics of a software component or
system.
• Features refer to functional aspects of the
software that map to functional requirements
as described by the users and clients.
• Feature defects are due to feature descriptions
that are missing, incorrect, incomplete.
3 . Feature Interaction Defects
• These are due to an incorrect description of how
the features should interact.
• For example, suppose one feature of a software
system supports adding a new customer to a
customer database. This feature interacts with
another feature that categorizes the new
customer.
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.
• For detecting many functional description
defects, black box testing techniques, which are
based on functional specifications of the
software, offer the best approach.
• Random testing and error guessing are also
useful for detecting these types of defects.
 2. D e s i g n D e f e c t s
• Design defects occur during interactions
between system components, interactions
between the components and outside
software/hardware, or users are incorrectly
designed.
• When describing these defects we assume that
the detailed design description for the software
modules is at the pseudo code level with
processing steps, data structures, input/output
parameters, and major control structures
defined.
1 . Algorithmic and Processing Defects
• These occur when the processing steps in the
algorithm as described by the pseudo code are
incorrect.
• For example, the pseudo code may contain a
calculation that is incorrectly specified, or the
processing steps in the algorithm written in the
pseudo code language may not be in the correct
order. In the latter case a step may be missing or
a step may be duplicated.
• Another example of a defect in this subclass is
the omission of error condition checks such as
division by zero.
 Algorithmic Error
Step 1: Get two variables a, b
Step 2: Find average using this formula
a+b/2.
Error b/2 - actually it should be (a+b)/2.
2 . Control, Logic, and Sequence Defects
• Control defects occur when logic flow in the
pseudo code is not correct.
• For example, branching to soon, branching to late,
or use of an incorrect branching condition.
• Other examples in this subclass are unreachable
pseudo code elements, improper nesting,
improper procedure or function calls.
• Logic defects usually relate to incorrect use of logic
operators, such as less than , greater than, etc.
These may be used incorrectly in a Boolean
expression controlling a branching instruction.
 Control, Logic, and Sequence Defects

• if ( money < 5 );
do this;
end;
3 . Data Defects
• These are associated with incorrect design of
data structures.
• For example, a record may be lacking a field, an
incorrect type is assigned to a variable or a field
in a record, an array may not have the proper
number of elements assigned, or storage space
may be allocated incorrectly.
• Software reviews and use of a data dictionary
work well to reveal these types of defects.
 Data Defects
#include <stdio.h>
int main()
{ int array[0], minimum, size, c, location = 1;
printf("Enter the number of elements in array\n"); scanf("%d",&size);
printf("Enter %d integers\n", size);
for ( c = 0 ; c < size ; c++ )
scanf("%d", &array[c]);
minimum = array[0];
for ( c = 1 ; c < size ; c++ )
{ if ( array[c] < minimum )
{
minimum = array[c];
location = c+1; }
}
printf("Minimum element is present at location %d and it's value is
%d.\n", location, minimum); return 0; }
 Correct program
#include <stdio.h>
int main()
{ int array[100], minimum, size, c, location = 1;
printf("Enter the number of elements in array\n"); scanf("%d",&size);
printf("Enter %d integers\n", size);
for ( c = 0 ; c < size ; c++ )
scanf("%d", &array[c]);
minimum = array[0];
for ( c = 1 ; c < size ; c++ )
{ if ( array[c] < minimum )
{ minimum = array[c];
location = c+1; } }
printf("Minimum element is present at location %d and it's value is
%d.\n", location, minimum); return 0; }
4 . Module Interface Description Defects
• These are defects derived from, for example,
using incorrect, and/or inconsistent parameter
types, an incorrect number of parameters, or
an incorrect ordering of parameters.
 Module Interface Description Defects

• Step 1: Get two variables a,b

• Step 2: Find average using this formula a+b/2.
Error b/2 actually it should be (a+b)/2.
5 . Functional Description Defects
• The defects in this category include incorrect,
missing, and/or unclear design elements.
• For example, the design may not properly
describe the correct functionality of a module.
These defects are best detected during a design
review.
 Functional Description Defects

• Without filling the data submit button

activated.
6. External Interface Description Defects
• These are derived from incorrect design
descriptions for interfaces with components,
external software systems, databases, and
hardware devices (e.g., I/O devices).
• Other examples are user interface description
defects where there are missing or improper
commands, improper sequences of commands,
lack of proper messages, and/or lack of feedback
messages for the user.
 External Interface Description Defects

Engineer: Sir what about the colour? ( Red)

Customer: ok
Engineer: sir what about the model?
Customer: ya latest model
Engineer: its save petrol…fuel consumption is
very low..
Customer: Is it so?
Engineer: Give feedback sir about the car
Customer: Sir I need vehicle with two wheels …
I specified clearly in my requirements ..
Engineer: ?????????????
3. CODING DEFECTS
• Coding defects are derived from errors in
implementing the code.
• Coding defects classes are closely related to
design defect classes especially if pseudo code
has been used for detailed design.
• Some coding defects come from a failure to
understand programming language constructs,
and miscommunication with the designers.
1 . Algorithmic and Processing Defects
• Adding levels of programming detail to design,
code-related algorithmic and processing
defects would now include unchecked overflow
and underflow conditions, comparing
inappropriate data types, converting one data
type to another, incorrect ordering of
arithmetic operators (perhaps due to
misunderstanding of the precedence of
operators), misuse or omission of parentheses,
and incorrect use of signs.
2 . Control, Logic and Sequence Defects
• On the coding level these would include
incorrect expression of case statements,
incorrect iteration of loops (loop boundary
problems) and missing paths.
3 . Typographical Defects
• These are principally syntax errors, for
example, incorrect spelling of a variable name,
that are usually detected by a compiler, self-
reviews, or peer reviews.
4 . Initialization Defects
• These occur when initialization statements are
omitted or are incorrect.
• This may occur because of misunderstandings or
lack of communication between programmers,
and/or programmers and designers carelessness,
or misunderstanding of the programming
environment.
5 . Data-Flow Defects
• There are certain reasonable operational
sequences that data should flow through.
• For example, a variable should be initialized,
before it is used in a calculation or a condition. It
should not be initialized twice before there is an
intermediate use.
• A variable should not be disregarded before it is
used.
6 . Data Defects
• These are indicated by incorrect
implementation of data structures.
• For example, the programmer may omit a
field in a record, an incorrect type or access is
assigned to a file, an array may not be
allocated the proper number of elements.
• Other data defects include flags, indices and
constants set incorrectly.
7 . Module Interface Defects
• As in the case of module design elements,
interface defects in the code may be due to
using incorrect or inconsistent parameter
types, an incorrect number of parameters, or
improper ordering of the parameters.
• In addition to defects due to improper design,
and improper implementation of design,
programmers may implement an incorrect
sequence of calls or calls to nonexistent
modules.
8 . Code Documentation Defects
• When the code documentation does not reflect
what the program actually does, or is incomplete
or ambiguous, this is called a code documentation
defect.
• Incomplete, unclear, incorrect, and out-of-date
code documentation affects testing efforts.
• Testers may be misled by documentation defects
and thus reuse improper tests or design new
tests that are not appropriate for the code.
• Code reviews are the best tools to detect these
types of defects.
9 . External Hardware, Software Interfaces
Defects
• These defects arise from 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, and timing
sequences (race conditions may result).
TestingDefects
• Defects are not confined to code and its related
artifacts. Test plans, test cases, test harnesses,
and test procedures can also contain defects.
• Defects in test plans are best detected using
review techniques.
1 . Test Harness Defects
• In order to test software, especially 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 a
work product and much of this code can be
reused when new releases of the software are
developed.
2 . Test Case Design and Test Procedure Defects
• These would encompass incorrect, incomplete,
missing, inappropriate test cases, and test
procedures.
• These defects are again detected in test
Plan.
• Sometimes the defects are revealed during
the testing process itself by means of a careful
analysis of test conditions and test results.
Repairs will then have to be made.