ORIGIN OF DEFECTS

 Defects have detrimental affects on software users, and software engineers work
very hard to produce high quality software with a low numbers of defects. The
origins of defects are given below:
1. Education: The software engineer did not have the proper educational
background to prepare the software artifacts. They did not understand how to
do something. For example, a software engineer who did not understand the
precedence order of operators in a particular programming language could
inject a defect in an equation that uses the operators for calculation.
2. Communication:- The software engineer was not informed abut something
by a colleague. For example , if engineer 1 and engineer2 working on
interfacing modules, and engineer 1 doesn’t inform engineer2 that no error
checking code will appear in the interfacing module he is developing, engineer 2
might have an incorrect assumption relating to the presence /absence of an error
check and defects will result.
3. Oversight :- The software engineer omitted to do something .For example
a software engineer might omit an initialization statement
4. Transcription:- The software engineer knows what to do, but makes a
mistake in doing it. A simple example is a variable name being misspelled when
entering the code.
5. Process:- The process used by the software engineer misdirected the action.
For example, a development process that did not allow sufficient time for a
detailed specification to be developed and reviewed could lead to specification
defects.
A successful test is a one that reveals the presence of defect.

A tester role is compared with the role of a doctor.

A doctor who is in the process of constructing a diagnosis for an ill patient,

develops hypotheses about possible illness using her knowledge of possible
diseases, and the patients symptoms.

Test are made in order to make the correct diagnosis.

A successful text will reveal the problem and the doctor can begin the treatment.

Completing the analogy of doctor and ill patient, one could view defective
software as the ill patient.
 Testers as doctors need to have knowledge about possible defects (illness) in
order tom develop defect hypotheses. They use the hypotheses to:-
 Design Test cases;
 Design Test procedures;
 Assemble test sets;
 Select the testing levels(unit, integration,etc) appropriate for the tests;
 Evaluate the result of the tests;
DEFECT CLASSES:-

 Defect can be classified in many ways.

 It is important for an organization to adapt a single classification scheme
and apply it to all projects.
 Developers, testers and SQA staff should try to be as consistent as possible
when recording defect data
 Defects are assigned to four major classes reflecting their point of origin in the
software life cycle- the development phases in which they were injected.

These classes are:-

 Requirements\ Specification Defect Classes
 Design Defect Classes
 Code Defect Classes
 Testing Defect Classes
Requirements and Specification Defects:-

The beginning of software life cycle is critical for ensuring high quality in the
software being developed.
Defects injects in early phases can persist and be very difficult to remove in later
phases.
Since many requirements are written using natural language representation,
there are very often occurrences of ambiguous, contradictory, unclear,
redundant, and imprecise requirements.
1. Functional Description Defects:-
The overall description of what the product does, and how it should behave
(Input/Output), is incorrect, ambiguous, and /or incomplete.

2. Feature Defects
Features may be described as distinguishing characteristics of a software
component or system. Features refers to functional aspects of software that map
to functional requirement described by the user and the client, it also maps
quality such as performance and reliability. Feature defects are mainly due to
features description that are missing, incorrect, incomplete or superfluous.
3. Feature Interaction Defects:-
These defects are due to incorrect description of how the features should
interact. For ex:- 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.

Classification feature impacts on where the storage algorithm places the new
customer in the database, and also affects another feature that periodically
support sending advertising information to customers in a specific category.
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 specification of the software, offer
the best approach. Black Box testing techniques such as equivalence class
partitioning, boundary value analysis, state transition testing, and cause and
effect graphing are useful for detecting functional type of defects.
 BlackBox based tests can be planned at the unit, integration, system and
acceptance levels to detect requirements/specification defects.
DESIGN DEFECTS:-
Design defects occur when system components, interactions between system
components, interaction between the components and outside software
/hardware, or users are incorrectly designed.

Design of algorithm, control, logic, data elements, module interface description,

and external software/ hardware/ user interface description.

When describing these defects we assume that the detailed design description
for the software modules is the pseudo code level with processing steps
1. Algorithmic and Processing Defects:-
These occur when the processing steps in the algorithm as described by the
pseudo code are incorrect.

Eg:- the pseudo code may contain a calculation that is incorrectly specified,
or the processing steps in the algorithm written in pseudo code language may
not be in the correct order.
2. Control, Logic and Sequence Defects:-
Control defect 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 subclasses are unreachable pseudo code elements, improper
nesting, improper procedure or function calls.

Logic defects usually relate to incorrect use of logic operators.

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 field in a record, an array may not have the proper number of
elements assigned, or storage space may be allocated incorrectly.
4. Module Interface Description Defects :-
These are defects derived from, for example, using incorrect, and/or
inconsistent parameter type, an incorrect number of parameters, or an
incorrect ordering of parameters
5. Functional Description Defects:-
The defects in this category include incorrect, missing, and/or unclear design
element.

For example, the design may not properly describe the correct functionality of
a module.
5. External Interface Description Defects:-
These are derived from incorrect design description for interfaces with COTS
components, external software systems, databases and hardware devices(eg:-
I/O devices).

Other example are user interface description defects where there are missing
or improper commands, improper sequence of commands, lack of proper
message, and/or lack of feedback message for the users.
CODING DEFECTS:-

Coding Defects are derived from errors in implementing the code.

Coding defects classes are closely related to design 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 designer.
1. Algorithm and Processing Defects:-
Adding levels of programming detail to design , code related algorithmic and
processing defect would now include unchecked overflow and underflow
conditions, comparing inappropriate data types, converting one data type to
another, in correct ordering of arithmetic operators, misuse or omission of
parenthesis, precision loss 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 and missing paths
3. Typographical Defects:-
These are principally syntax errors, for example incorrect spelling of variable
name, that are usually detected by compiler, self reviews, or peer reviews
4. Initialization Defects:-
These occur when initialization statements are omitted or are incorrect.

This may occur because of misunderstanding or lack of communication

between programmers, and /or programmers and designers, carelessness, or
misunderstanding of 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 filed in a record, an incorrect type
or access is assigned to a file, an array may not be allocated the proper
number of elements.
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, improper design,
programmer may implement an incorrect sequence of calls or calls to non
existent modules
8. External Hardware, Software Interface 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 exchange with hardware, protocols formats,
interface with build files, and timing sequences
TESTING DEFECTS:

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 Defect:-
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.

Test harness code should be carefully designed, implements and tested since it
is a work product and much of this code can be reused when the new release
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 best detected in test plan reviews.

Sometimes, 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.