INTRODUCTION TO

SOFTWARE DEFECTS
 What is a Defect?
 A software bug arises when the expected result don't match with
the actual results. It can also be error, flaw, failure, or fault in a
computer program. Most bugs arise from mistakes and errors made
by developers, architects.
 Following are the methods for preventing programmers from
introducing bugs during development:
 Programming Techniques adopted
 Software Development methodologies
 Peer Review
 Code Analysis
Common Types of Defects

 Following are the common types of defects that occur during

development:
 Arithmetic Defects
 Logical Defects
 Syntax Defects
 Multithreading Defects
 Interface Defects
 Performance Defects
 Arithmetic Defects:
It include the defects made by the developer in some
arithmetic expression or mistake in finding solution of such
arithmetic expression. This type of defects are basically made by
the programmer due to access work or less knowledge. Code
congestion may also lead to the arithmetic defects as programmer
is unable to properly watch the written code
 Logical Defects:
Logical defects are mistakes done regarding the
implementation of the code. When the programmer doesn’t
understand the problem clearly or thinks in a wrong way then such
types of defects happen. Also while implementing the code if the
programmer doesn’t take care of the corner cases then logical
defects happen. It is basically related to the core of the software
 Syntax Defects:
Syntax defects means mistake in the writing style of the code. It also
focuses on the small mistake made by developer while writing the code.
Often the developers do the syntax defects as there might be some small
symbols escaped. For example, while writing a code in C++ there is
possibility that a semicolon(;) is escaped.
 Multithreading Defects:
Multithreading means running or executing the multiple tasks at the same
time. Hence in multithreading process there is possibility of the complex
debugging. In multithreading processes sometimes there is condition of the
deadlock and the starvation is created that may lead to system’s failure.
 Interface Defects:
Interface defects means the defects in the interaction of the software and the
users. The system may suffer different kinds of the interface testing in the
forms of the complicated interface, unclear interface or the platform based
interface.
 Performance Defects:
Performance defects are the defects when the system or the software
application is unable to meet the desired and the expected results
 Origins of Defects:

Defects have negative effects on software users. Software engineers

work very hard to produce high-quality software with a low number of
defects.
 Education: The software engineer did not have the proper
educational background to prepare the software artifact.
 Communication: The software engineer was not informed about
something by a colleague.
 Oversight: The software engineer omitted to do something.
 Transcription: The software engineer knows what to do, but makes a
mistake in doing it.
 Process: The process used by the software engineer misdirected
his/her actions
COST OF DEFECTS:

 What is the cost of defects in software testing?

The cost of defects can be measured by the impact of the defects

and when we find them.

Earlier the defect is found lesser is the cost of defect.

For example if error is found in the requirement specifications during

requirements gathering and analysis, then it is somewhat cheap to fix it
.
The correction to the requirement specification can be done and then it
can be re-issued.
 The same applies for construction phase. If however, a defect is
introduced in the requirement specification and it is not detected
until acceptance testing or even once the system has been
implemented then it will be much more expensive to fix. This is
because rework will be needed in the specification and design before
changes can be made in construction; because one defect in the
requirements may well propagate into several places in the design
and code; and because all the testing work done-to that point will
need to be repeated in order to reach the confidence level in the
software that we require.
 It is quite often the case that defects detected at a very late stage,
depending on how serious they are, are not corrected because the
cost of doing so is too expensive.
 In design phase: the design has been done it may felt that may be
the cost of the defect is high . when compare to requirement
gathering.
DEFECT REPOSITORY

To increase the effectiveness of their testing and debugging

processes, software organizations need to initiate the creation of a
defect database, or defect repository. The defect repository
supports storage and retrieval of defect data from all projects in a
centrally accessible location
DEFECT CLASSES

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
Execution-based testing strategies should be selected that have the
strongest possibility of detecting particular types of defects.
The four classes of defects are
1. Requirements and specifications defects
2. 2. Design defects
3. Code defects
4. . Testing defects
1.REQUIREMENT AND SPECIFICATION DEFECTS

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 System components, Interactions

between system components, Interactions between the
components and outside software/hardware, or users are incorrectly
designed.
Some of 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. .

Some coding defects come from a failure to understand
programming language constructs, and miscommunication with the
designers.
Coding defects include….
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:
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.
TESTING DEFECTS

The defects in test plans, test cases, test harness, and

test procedures are called Testing Defects The testing
defects including Test harness Defects Test case design
and Test procedure defects
4.1 Test Harness Defects :The test harness or scaffolding
code is the auxiliary code which is developed to test software
at the unit and integration levels. 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
TEST DESIGN

Test design is the process of designing the input values

that will effectively test software. The general
approaches to designing the tests are Criteria-based test
design Human-based test design
Criteria-based test design

In criteria-based test design, we design test values that

satisfy engineering goals such as coverage criteria. To
apply criteria effectively, the tester needs knowledge of
discrete math, programming, and testing. Much of this
work involves creating abstract models and
manipulating them to design high-quality tests
Human-based test design

In human-based test design, we design the test values

based on domain knowledge of the program and human
knowledge of testing. Human-based test designers
explicitly attempt to find stress tests.
DEFECT EXAMPLE
DESIGN DEFECTS OF PROBLEM ARE

Control, logic, and sequencing defects Algorithmic, and

processing defects Data defects External interface
description defects
CODING DEFECTS OF THE PROBLEM
ARE
Control, logic, and sequence defects. Algorithmic and
processing defects. Data Flow defects Data defects Code
Documentation Defects
Developer/Tester support for developing a defect
repository

 As a member of test organization, it is important to illustrate to

management and your colleagues the benefits of developing a
defect repository to store defect information.
 A requirement for repository development should be a part of
testing and/or debugging policy statements.
 We begin with development of a defect classification scheme
and then initiate the collection of defect data from organizational
projects.
 Forms and templates will need to be designed to collect the data
We will need to be careful about recording each defect after testing, and
also recording the frequency of occurrence for each of the defect types.
 Defect monitoring should continue for each on-going project.  The
distribution of defects will change as we make changes in our
processes.  The defect data is useful for test planning, select applicable
testing techniques , design the test cases we need, and allocate the
resources to detect and remove these defects
A defect repository can help to support achievement and continuous
implementation of several TMM maturity goals including controlling and
monitoring of test, software quality evaluation and control, test
measurement, and test process improvement
Test planning and Test case development :- A Test Plan is a detailed
document that catalogs the test strategies, objectives, schedule,
estimations, deadlines, and resources required to complete that project.
A test case is a document, which includes test data, preconditions,
expected results and post conditions, developed for a particular test
scenario in order to verify compliance against a specific requirement.
Test controlling and Monitoring:- Test Monitoring is a process of
evaluating and providing feedback on the “currently in progress” testing
phase. Test Control is an activity of guiding and taking corrective action
based on some metrics or information to improve efficiency and quality.
Defect prevention:- Defect Prevention involves analyzing defects that
were encountered in the past and taking specific actions to prevent the
occurrence of those types of defects in the future.
Quality evaluation and Control:- A Quality evaluation is a quality
management activity in which another individual, typically a supervisor
from the QM/QA team scores an agent interaction based on key criteria.
Quality Control (QC) is the process through which you achieve, or
improve, product quality. The QC process can also include the activities
used to eliminate waste processes in the SDLC.
Test Measurement:- testing metrics (also known as test measurement)
is the “quantitative measure of the extent, capacity, dimension, amount
or size of some attribute of a system, system component, or process.
Test Process Improvement:- There are some common issues in any
test project. Many Organizations realize that improving the test process
can solve these problems. Learning from past mistakes can help in
improving test management process
Defect prevention Techniques

For defect prevention, there are different methods .These methods

or activities or Techniques are given below
Software Requirement Analysis :
The main cause of defects in software products is due to error in
software requirements and designs. Software requirements and
design both are important, and should be analyzed in an efficient
way with more focus. Software requirement is basically considered
an integral part of (SDLC). It is very much needed to understand
about software requirements more carefully, If requirements are not
understood well by tester and developers, then there might be
chance of occurring of issue or defect in further process. Therefore,
it is essential to analyze and evaluate requirements in more
appropriate and proper manner.
Review and Inspection :
Review and inspection, both are essential and integral part of
software development. They are considered as powerful tools that
can be used to identify and remove defects if present before there
occurrence and impact on production. Review and inspection come
in different levels or stages of defect prevention to meet different
needs. They are used in all software development and maintenance
methods. There are two types of review i.e. self-review and peer-
review
Defect Logging and Documentation :

After successful analysis and review, there should be records maintained

about defects to simply complete description of defect. This record can be
further used to have better understanding of defects. After getting
knowledge and understanding of defect, then only one can take some
effective and required measures and actions to resolve particular defects
so that defect cannot be carried further to next phase.
Root Cause Analysis :

Root cause analysis is basically analysis of main cause of defect. It simply

analysis what triggered defect to occur. After analyzing main cause of
defect, one can find best way to simply avoid occurrence of such types of
defects next time.