Department of Computer Engineering

Unit 4
(12 Marks)

Defect Management

G.H.RAISONI institute of engineering &

Technology,NAGPUR
RAISONI GROUP OF INSTITUTIONS
What is Defect Management
l
Defect : A defect is an error in coding that causes a program to fail or to produce incorrect /unexpected
results. It is an error or bug. Increased complexity of software. Programming Errors.
Root of defects:
i. Miscommunication of requirements introduces error in code.
ii. Lack of design Experience.
iii. Lack of coding practice.
iv. Unrealistic time schedule for development.
v. Multiple changes in the requirements.

What is Defect Management :

It is the process of recognizing, investigating, taking action & disposing of defect.
It involves recording defects, classifying them and identifying the impact.
Needs for Defect Management :
• It enhances quality by adding value to the most important attributes of software like
Reliability,maintainability,efficiency & portability.
• Defect analysis at early stages if software development reduces the time,cost & resources required for
rework
RAISONI GROUP OF INSTITUTIONS
Defect Classification

Defect Classification

Requirement Defect Design Defect Testing Defect Coding Defect

System interface defect Initialization defect

Functional Defect Test environment defects
User interface defects
Interface Defect Module defects Test tool defects
Algorithmic defects Test design defects Database defects
RAISONI GROUP OF INSTITUTIONS
Defect Classification
1. Requirement Defect :
Requirement-related defects arise in a product when one fails to understand what is required by
the customer. These defects may be due to customer gap, where the customer is unable to
define his requirement, or producer gap, where developing team is not able to make a product
as per requirements.

1. Functional defects: These defects are mainly about the functionalities present/absent
in the applications which are expected/not expected by the customer.

2. Interface Defects; These defects talk about various interface essential as per the
requirement statement. Generally, these defects may be due to user interface problem,
problems with connectivity to other system including hardware, etc.

RAISONI GROUP OF INSTITUTIONS

Defect Classification
2. Design Defect:
Design defects generally refer to the way of design creation or its usage while creating a product. The customer
may or may not be in a position to understand these defects, if structures are not correct.

1. Algorithmic Defects: Algorithmic defects may be introduced in a product if designs of various decisions
are not handled correctly. Some applications have a control over complexity and usage of various
algorithms to translate requirement correctly into coding.

2. Module-Interface Defects: Module-interface defects are about communication problem between various
modules. If one module gives some parameters which are not recognized by another, it creates module-
interface defects.

3. System-Interface Defects: System-interface defects may be generated when application communication

with environmental factors is hampered system may not be able to recognize Inputs coming from the
environment, or may not be able to give outputs which can be used by the environment.

4. User-Interface Defects: User-interface defects may be a part of system-interface defects where the other
system working with the application is a human being. User-interface defects may be a part of navigation,
look and feel type of defects which affect usability of an application.
RAISONI GROUP OF INSTITUTIONS
Defect Classification

3. Testing Defects:
1. Testing defect are defects introduced in an application due to wrong testing, or defects in the test
artifact leading to wrong testing.
2. Defects which cannot be reproduced, or are not supported by requirement or are duplicate may
represent a false call .

4. Coding Defects:
3. Coding defects may arise when designs are implemented wrongly. If there is absence of
development/coding standards or if they are wrong, it may lead to coding defects.
4. Coding defects are derived from errors in implementing the code.
5. Coding defect classes are closely related to design defect classes especially if pseudo code has
been used for detailed design.

RAISONI GROUP OF INSTITUTIONS

Defect Management Process

Defect Management process :

• Defect Prevention : Implementation of techniques, methodology and standard processes to reduce
the risk of defects.

• Deliverable Baseline : Establishment of milestones where deliverables will be considered complete

and ready for further development work. When a deliverable is base lined, any further changes are
controlled. Errors in a deliverable are not considered defects until after the deliverable is base lined.

• Defect Discovery : Identification and reporting of defects for development team acknowledgment.
A defect is only termed discovered when it has been documented and acknowledged as a valid
defect by the development team member(s) responsible for the component(s) in error.

• Defect Resolution : Work by the development team to prioritize, schedule and fix a defect, and
document the resolution. This also includes notification back to the tester to ensure that the
resolution is verified.

RAISONI GROUP OF INSTITUTIONS

Defect Management Process

Fig. Defect Management Process

RAISONI GROUP OF INSTITUTIONS

Defect Management Process

Defect Prevention : It is the best method to eliminate the defects in the early stage of testing
instead of finding the defects in the later stage and then fixing it. This method is also cost effective
as the cost required for fixing the defects found in the early stages of testing is very low.

The major steps involved in Defect Prevention are as follow:

1. Identify Critical Risk : Identify the critical risks in the system which will impact more if occurred
during testing or in the later stage.

2. Estimate Expected Impact : For each critical risk, calculate how much would be the financial
impact if the risk actually encountered.

3. Minimize expected impact : Once you identify all critical risks, take the topmost risks which may
be harmful to the system if encountered and try to minimize or eliminate the risk. For risks which
cannot be eliminated, it reduces the probability of occurrence and its financial impact.

RAISONI GROUP OF INSTITUTIONS

Defect Management Process

iii) Defect Discovery : Identification and reporting of defects for development team
acknowledgment. A defect is only termed discovered when it has been documented and
acknowledged as a valid defect by the development team member(s) responsible for the
component(s) in error.

RAISONI GROUP OF INSTITUTIONS

Defect Management Process

iv) Defect Resolution : Work by the development team to prioritize, schedule and fix a
defect, and document the resolution. This also includes notification back to the tester to
ensure that the resolution is verified.

RAISONI GROUP OF INSTITUTIONS

Defect Prevention Cycle

RAISONI GROUP OF INSTITUTIONS

Defect Prevention Cycle

• The defect prevention process begins with requirement analysis translating the customer
requirements into product specifications without introducing additional errors.

• The five general activities of defect prevention are:

1) Software Requirements Analysis

2) Reviews: Self Review & Peer Review

3) Defect Logging & Documentation

4) Root Cause Analysis & Preventive Measures Determination

5) Embedding Procedures into Software Development Process

RAISONI GROUP OF INSTITUTIONS

Defect Prevention Cycle

1) Software Requirements Analysis:-

Defects introduced during the requirements & design phase are not only more probable
but also are more severe & more difficult to remove.

Hence it is important to have a proper process of analysing the requirements in place to ensure that
the customer needs are correctly translated into product specifications.

2) Reviews: Self Review & Peer Review:-

Self review is one of the most effective activities in uncovering the defects which may
later be discovered by a testing team or directly by a customer.

RAISONI GROUP OF INSTITUTIONS

Defect Prevention Cycle

3) Defect Logging & Documentation:-

• Effective defect tracking begins with a systematic process.
• Defect analysis & reporting offer a powerful means to manage defects & defect depletion trends,
hence the structure to resolve them.
• Defect logging tool should document certain vital information regarding the defect such as
correct & complete description of the defect.

4)Root Cause Analysis & preventive measures determination:-

• Reducing the defects to improve the quality
• Applying local expertise
• Targeting the systematic errors

RAISONI GROUP OF INSTITUTIONS

Defect Prevention Cycle

5) Embedding Procedures into Software Development Process:-

A plan of action is made for deployment of the modification of the existing processes
or introduction of the new ones with the consent of management & the team.

Some activities in this phase of defect prevention are:-

• Monthly status of the team should mention the severe defects & their analyses.

• Embedding the defect prevention measures in software development life cycle processes.

• Learning from the previous project’s root cause analysis of defect should be used as the
baseline for future projects.

RAISONI GROUP OF INSTITUTIONS

Defect Life Cycle

New: Tester finds a defect & posts it with the status new. This defect is yet to be studied.
Open : After a tester has posted a bug, the lead of the tester approves that the bug is genuine
and he changes the state as OPEN.
Assign : Once the lead changes the state as OPEN, he assigns the bug to corresponding
developer or developer team. The state of the bug now is changed to ASSIGN.
Fixed: When developer makes necessary code changes and verifies the changes then he/she
can make bug status as „Fixed‟ and the bug is passed to testing team.
Verified : Once the bug is fixed and the status is changed to TEST, the tester tests the bug. If
the bug is not present in the software, he approves that the bug is fixed and changes the
status to VERIFIED.
Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no
longer exists in the software, he changes the status of the bug to CLOSED. This state means
that the bug is fixed, tested and approved.
Reopened : If the bug still exists even after the bug is fixed by the developer, the tester
changes the status to ―REOPENED. The bug traverses the life cycle once again.

• RAISONI GROUP OF INSTITUTIONS

Defect Report Template
• Defect reports are probably primary work product for most of the software tester. Good bug report, which
is informative & understandable, earns you a good reputation.
• Templates of Good Defect Report-
1)Headline
2)Product
3)Component
4) Defect Type
5)Priority
6)Severity
7) Environment
8)Steps
9)Attachments
10) Comments
Explain each in detail
RAISONI GROUP OF INSTITUTIONS
Defect Template

Defect template:

• A defect report documents an anomaly discovered

during testing.

• It includes all the information needed to reproduce

the problem, including the author, release/build
number, open/close dates, problem area, problem
description, test environment, defect type, how it was
detected, who detected it, priority, severity, status,
etc.

RAISONI GROUP OF INSTITUTIONS

Defect Template Attributes

ID Unique identifier given to the defect. (Usually Automated)

Project Project name.

Product Product name.

Release Version Release version of the product. (e.g. 1.2.3)

Module Specific module of the product where the defect was detected.
Detected Build Version Build version of the product where the defect was detected (e.g. 1.2.3.5)

Summary Summary of the defect. Keep this clear and concise.

Description Detailed description of the defect.
Actual Result The actual result you received when you followed the steps.
Expected Results The expected results.
Attachments Attach any additional information like screenshots and logs.
Defect Priority Priority of the Defect.
Status The status of the defect.

RAISONI GROUP OF INSTITUTIONS

Different techniques for Finding Defects

Different techniques for Finding Defects :

1. Static technique
2. Dynamic technique
3. Operational technique

1. Static Techniques:

• Static techniques of quality control define checking the software product and related artifacts
without executing them.
• It is also termed desk checking/verification/white box testing.

• It may include reviews, walkthroughs, inspection, and audits here; the work product is reviewed by
the reviewer with the help of a checklist, standards, any other artifact, knowledge and experience,
in order to locate the defect with respect to the established criteria.

• Static technique is so named because it involves no execution of code, product, documentation,

etc. This technique helps in establishing conformance to requirements view.
RAISONI GROUP OF INSTITUTIONS
Different techniques for Finding Defects

: 2. Dynamic Testing
• Dynamic testing is a validation technique which includes
dummy or actual execution of work products to evaluate
it with expected behavior.
• It includes black box testing methodology such as system
testing and unit testing.
• The testing methods evaluate the product with respect to
requirements defined; designs created and mark it as
pass or fail.

3. Operational techniques :
Operational techniques typically include auditing work
products and projects to understand whether the processes
defined for development /testing are being followed
correctly or not, and also whether they are effective or not.

RAISONI GROUP OF INSTITUTIONS

Estimate Expected Impact of a Defects

• Once the critical risks are identified, the financial impact of each
risk should be estimated.
• This can be done by assessing the impact, in dollars, if the risk
does become a problem combined with the probability that the
risk will become a problem.
• The product of these two numbers is the expected impact of
the risk.
• The expected impact of a risk (E) is calculated as E = P * I, Defect Prevention Process
where:
P Probability of the risk becoming a problem and
I  Impact in dollars if the risk becomes a problem

• Once the expected impact of each risk is identified, the risks

should be prioritized by the expected impact and the degree to
which the expected impact can be reduced.

RAISONI GROUP OF INSTITUTIONS

Defect Reporting

It is essential that you report defects effectively so that time & effort is not unnecessarily
wasted in trying to understand & reproduce the defect.
Defect Reporting Guidelines:-
• Be specific
Specify the exact action. Do not say something which adds confusion.
• Be Detailed
Provide more information(not less). In other words, do not be lazy.
• Be Objective
Stick to the facts & avoid the emotions.
• Reproduce the defect
Do not impatient & file a defect report as soon as you uncover a defect. Replicate it at least once to
be sure.
• Review the Report
RAISONI GROUP OF INSTITUTIONS
Do not submit as soon as you write the report. Review it at least once. Remove any types.
Thank you

RAISONI GROUP OF INSTITUTIONS