Unit 4: Defect Management

Defect: A defect is an error or a bug, in the application which is created. A programmer

while designing and building the software can make mistakes or errors. These mistakes or
errors mean that there are flaws in the software. These are called defects.
Defects in any system may arise in various stages of development life cycle. At each stage,
the impact and cost of fixing defects are dependent on various aspects including the defect
arising stage.

 Defect Classification:
The defects are classified mainly as:
1. Severity Basis
2. Priority Basis
3. Probability Basis

1. Severity Basis: Severity defines the degree of impact. It describe the impact of defect on
the system. It is status given to bug based on how damaging the bug is to customer business.
o Critical: The defects termed as 'critical', needs immediate attention and
treatment. A critical defect directly affects the critical and essential
functionalities, which may affect a software product or its functionality on a
large scale, such as failure of a feature/functionality or the whole system,
system crash-down, etc.
o Major: Defects, which are responsible for affecting the core and major
functionalities of a software product. Although, these defects does not results
into complete failure of a system, but may bring several major functions of a
software, to rest.
o Minor: These defects produces minor impact, and does not have any significant
influence on a software product. The results of these defects may be seen in the
product's working, however, it does not stops users to execute it task, which
may be carried out, using some other alternative.
o Trivial: These types of defects have no impact on a working of a product and
sometimes, it is ignored and skipped, such as spelling air grammatical mistakes.

2. Priority Basis: Priority is defined as the order in which the defects should be resolved.
Defects could also be seen from the business perspective, as which defects needs to be
corrected first and which may be fixed at a later stage, based on the current need and demand
of the business.
Similar to probability basis, priority may also be categorized into following forms:

o High: High priority defines the foremost need of a business, to correct a defect, as
soon as possible, in the same build.
 Unit 4: Defect Management
o Medium: Medium priority defects comes next to that of high priority, and may be
addressed in any next version or a release of a product.
o Low: These types of defects, does not needs to be individually corrected. It may or
may not be considered or corrected, along with any other defect, which needs to be
fixed.

 Causes of Defects:

Causes of Defects

1.Human Factor

2.Communication Failure

3.Unreal development timeframe

4.Poor coding practices

5.Buggy third-party tools

6.Lack of testing skill

1. Human Factor: Human factor introduces errors in code. This is because of the system
is developed by the human begin & they are not perfect all the time.
2. Communication Failure: This factor takes place in the different levels.
Miscommunication of the requirements is one of the most common problem in the
software development process which causes an introduction of defects in the code. It
means lack of communication or incorrect communication in the software development
process.
3. Unreal development timeframe: The situations when tester doesn't have enough
information and his/her development schedule is limited by deadlines arise very often. It
could lead to bad-quality and defective service.
4. Poor coding practices: Coding plays important role in software development process.
Simply bad coding leads to errors into code. Bad coding means unhandled exceptions,
errors, improper validations of inputs.
 Unit 4: Defect Management
5. Buggy third-party tools: Very often the development process requires a lot of thirty-
party tools, which may contain many defects in them. Such kind of bugs may in turn
cause defects in the current software.
6. Lack of testing skill: Nobody wants face it, but it is very important to have the
seriousness for testing and enough skill base. There can be insufficient knowledge of
testing skills which leads to defects in the system.

 Defect Management Process :

The defect management process is the core of software testing. Once the defects have
been identified, the most significant activity for any organization is to manage the flaws, not
only for the testing team but also for everyone involved in the software development or
project management process.
The defect management process is process where most of the organizations manage
Defect Discovery, Defect Removal and then process Improvement which is collectively
known as a Defect management Process.
As the name recommends, the Defect Management Process (DMP) manages defects by
purely detecting and resolving or fixing the faults.
o Given Below Rare the various goals of this process:
1. To expose the defects at an early stage of the software development process.
2. Minimize the impact or effects of defects on software.
3. Defect management process (DMP) helps us to avoid defects.
4. The main goal of the defect management process is to resolve or fixing the
defects.

Above diagram shows the defect management process. It includes several stages, which
are as follows:
 Unit 4: Defect Management

1. Defect Prevention
2. Deliverable Baseline
3. Defect Discovery
4. Defect Resolution
5. Process Improvement
6. Management Reporting

1) Defect Prevention:
- The first stage of the defect management process is defect prevention. Defect Prevention
is considered as the best mechanism to remove the defects in the early stage of testing rather
than of finding the defects in the later stage and then fixing it.
- This mechanism is also cost effective since the cost necessary to fix the defects found
in the early stages of testing is comparatively very low.
- However, it is not difficult to eliminate all the defects but at least is possible to
minimize the impact of the defect as well as the respective cost to fix the same.
- The important steps which are mainly involved in Defect Prevention are as follow:
o Identify Critical Risk: Identify the critical risks in the system which may
have big impact if occurred during testing or in the later stage.

o Estimate Expected Impact: For every critical risk, calculate the amount of
financial impact if the risk actually occurred.

o 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 completely eliminate the risk. For risks which cannot be
eliminated, it reduces the probability of occurrence and its financial impact.

2) Deliverable Baseline:
- The second stage of the defect management process is the Deliverable
baseline. Here, the deliverable defines the system, documents, or product.

- When deliverable reaches its pre-defined milestone then We can say that
the deliverable is a baseline .

- In this stage, the deliverable is carried from one step to another; the system's existing
defects also move forward to the next step or a milestone.
 Unit 4: Defect Management

3) Defect Discovery:
- The next stage of the defect management process is defect discovery.
- It is almost impossible to remove all the defects from the system and make a system
as a defect-free one. But you can identify the defects early before they become
costlier to the project.
- The following phases have been including in the defect discovery stage;
o Identify a defect: We need to find the defects before becoming a
critical problem.
o Report a Defect: As soon as the testing team finds a defect, their
responsibility is to make the development team aware that there is an
issue identified which needs to be analysed and fixed.
o Acknowledge Defect: Once the testing team assigns the defect to the
development team, it is development team's responsibility to
acknowledge the defect and continue further to fix it if it is a valid
defect.
4) Defect Resolution:
- Once the defect discovery stage has been completed successfully, we move to the
next step of the defect management process, Defect Resolution.
- The Defect Resolution is a step-by-step procedure of fixing the defects, or we can say
that this process is beneficial in order to specified and track the defects.
- The steps involved in the defect resolution are as follows:
o Prioritize the risk: Development team analyzes the defect and
prioritizes the fixing of the defect. If a defect has more impact on the
system then they make the fixing of the defect on a high priority.
o Fix the defect: Based on the priority, the development team fixes the
defect, higher priority defects are resolved first and lower priority
defects are fixed at the end.
o Report the Resolution: It is development team's responsibility to ensure
that the testing team is aware when the defects are going for a fix and
how the defect has been fixed i.e. by changing one of the configuration
files or making some code changes. This will be helpful for the testing
team to understand the cause of the defect.

5) Process Improvement:
- In the above stage (defect resolution), the defects have been arranged and fixed.
 Unit 4: Defect Management

- Though in the defect resolution process the defects are prioritized and fixed, from a
process perspective, it does not mean that lower priority defects are not important and
are not impacting much to the system. From process improvement point of view, all
defects identified are same as a critical defect.
- For process improvement, everyone in the project needs to look back and check from
where the defect was originated. Based on that you can make changes in the
validation process, base-lining document, review process which may catch the defects
early in the process which are less expensive.

6) Management Reporting:
- Management reporting is the last stage of the defect management process.
- The evaluation and reporting of defect information support organization and risk
management, process improvement, and project management.

 Defect Life Cycle/Bug life cycle:

Defect life cycle, also known as bug life cycle is the journey of defect life cycle,
which a defect goes through during its lifetime.

New

Assigned

Rejected
Open Deferred
Duplicate

Fixed

Re-Open Retest

Close

Fig: Defect life cycle

 Unit 4: Defect Management

Defect life cycle includes following stages:

o New: When a defect is logged and posted for the first time. Its state is given as new.

o Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug
and assigns the bug to developer team. There can be two scenario, first that the defect
can directly assign to the developer, who owns the functionality of the defect. Second,
it can also be assigned to the Development Lead and once it is approved with the
Development Lead, he or she can further move the defect to the developer.

o Open: It is the state when developer starts read, understand, analyzing and working
on the defect fix.

o Fixed: When developer makes necessary code changes and verifies the changes then
he/she can make bug status as 'Fixed'.

o Retest: At this stage the tester do the retesting of the changed code which developer
has given to him to check whether the defect got fixed or not. Once the latest build is
pushed to the environment. Development lead move all the fixed defects to Retest.

o Reopened: If the bug still exists even after the bug is fixed by the developer, the
tester changes the status to "reopened". The bug goes through the life cycle once
again.

o Deferred: Developer agree that it’s a bug, but they say we need time, then changed
status as “deferred” or “postpone” state. Means the bug is expected to be fixed in a
releases.

o Rejected: If the developer feels that the bug is not genuine, developer rejects the bug.
Then the state of the bug is changed to "rejected".

o Duplicate: If the bug is repeated twice or the two bugs mention the same concept of
the bug, then the recent/latest bug status is changed to "duplicate"

o 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, tester changes the status of the bug to "closed". This
state means that the bug is fixed, tested and approved.
 Unit 4: Defect Management

 Estimate Expected Impact of a Defect:

 Defect impact means problem which may arises when an application with defect is
executed with defect is executed.
 When the critical risk are identify the financial impact of each risk should be impact.
 This can be done by accessing the impact in $ dollars.
 If the risk 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
Where , P = Probability o the risk becoming a problem and
I = Impact in dollars if the risk becomes a problem

 Techniques for finding Defects:

Defect are found Either by preplanned activities specifically intended to uncover

defects (e.g., quality control activities such as inspection, testing, etc.) or by accident (e.g.,
users in production).

Techniques to find defects can be divided into three categories:

1. Static Techniques
2. Dynamic Technique
3. Operational Technique

1. Static techniques:
 Testing that is done without physically executing a program or system.
 A code review is an example of a static testing technique.
 It may also include several factors such as walkthroughs, inspection, and audits,
 In this technique the reviewer reviews the work product by using a checklist, standards,
knowledge as well as experience for the purpose of locating the defect with respect to the
established criteria.
 The name static technique is given since it does not involve actual execution of code,
product, documentation, etc.
 Unit 4: Defect Management

2. Dynamic techniques:
 Testing in which system components are physically executed to identify defects.
 Execution of test cases is an example of a dynamic testing technique.
 This testing technique involves black box testing methodology like system testing and
unit testing.
 The product is evaluated by the testing methods with respect to requirements
specified, designs generated and mark it as pass or fail.

3. Operational techniques:
 An operational system produces a deliverable containing a defect found by users,
customers, or control personnel i.e., the defect is found as a result of a failure.
 Operational techniques usually involves auditing work products as well as projects to
find out whether the processes which has been defined for development or testing are
revisiting the defects prior and alter fixing and analysis.
 Smoke testing and sanity testing of a work product are considered as common
operational techniques.

 Reporting a Defect:

Question: Which parameters are considered while writing good

Defect report?
What are the different points to be noted in reporting defects?

Answer:
Reporting Defect: Finding and fixing bugs is a challenging task that consumes a
lot of time and efforts.
To assure that the defects are reported effectively, so that time and effort is
not unnecessarily wasted in trying to understand and reproduce the defect, it is
important for testers to follow a set guideline while preparing defect report.

Defect Report Guideline

Be Specific
Be Detailed
Be Objective
Reproduce the defect
Review the Defect
 Unit 4: Defect Management

 Be Specific:
- Specify the exact action do not say something. Which add confusion.
- In case of multiple path mentioned exact path given follow

 Be Detailed:
- Provide more information in other words do not be lazy.
- Developer may or may not use all the information you provide but they sure
do not want to beg you for any information you have missed.

 Be Objective:
- Do not make subjective statement like you fixed it real bad.
- Avoid the emotions.

 Reproduce the defect:

- Software defect are very sensitive and they occur when there is a condition in
a software product which does not meet a software requirement.
- While filing the defect one should add the proper steps to reproduce the defect
and should not rush the process

 Review the Defect:

- Do not submit as soon as report you write the report
- Review it at list one.

 Defect Template:
Defect Report is a document that identifies and describe a defect detected by a
tester. The purpose of a defect report is to state the problem as clearly as possible so that
developers can replicate the defect easily and fix it.

Defect Report template:

- In most companies, a defect reporting tool is used and the elements of a report can
vary.
- However, in general, a defect report can consist of the following elements.
1) Defect ID
2) Project Name
3) Release Version
4) Module
5) Detected Build Version
6) Summary
7) Description
8) Steps To Replicate
9) Actual Result
10) Expected Result
11) Attachment
 Unit 4: Defect Management
12) Remark
13) Defect Severity
14) Defect Priority
15) Reported By
16) Assigned To
17) Status
18) Fix Build Version

Defect ID Unique identifier given to the defect. (Usually, automated)

Project Name Indicate the project name in which defect is form.

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

Module Specify module of the product where the defect was detected.

Detected Build Build version of the product where the defect was
Version detected.(e.g.1.1, 2)
Summary Summary of the defect. Keep this clear and concise.

Description Detailed Description of the defect. Describe as much as

possible but without repeating anything or using complex
words. Keep it simple but comprehensive.
Steps To Replicate Step by step description of the way to reproduce the defect.
Number the steps.
Actual Result The actual result you received when you followed steps.

Expected Result The expected result you received when you followed steps.

Attachment Attach any additional information like Screenshot and logs.

Remark Any additional comments on the defect.

Defect Severity Severity of the defect. (See defect severity)

Defect Priority Priority of the defect. (See defect priority)
Reported By The Name of the person to reported the defect
Assigned To The name of the person that is assigned to analyze/fix the
defect
Status The status of the defect(See defect life cycle)

Fix Build Version Build version of the product where the defect was fixed (e.g.
1.2)
 Unit 4: Defect Management

Que 1. Prepare a defect report after executing test cases for library management
system.

Defect ID Lb1

Project Name Library Management

Release Version 1.1

Module
Book_ed

Detected Build Version Be1

Summary Book edition is not accepting alphanumeric values

Description Only alphabets are accepted, not numbers

Steps To Replicate Enter-alphanumeric value

Actual Result Error
Expected Result Should be accepted
Attachment Bv.jpg
Remark Must accept alphanumeric value
Defect Severity
Defect Priority Pr-29
Reported By Mr.Kunal.B
Assigned To Mr.Rahul.S
Status Ss001
Fix Build Version 1.0A
 Unit 4: Defect Management

Que 2. Prepare a defect report after executing test cases for Withdrawn of
amount from ATM machine.

Defect ID A1

Project Name ATM

Release Version 1.1

Module Withdraw

Detected Build Version W1

Summary Not accepting amount greater than 10000

Description Bank allows up to 25000 at a time

Steps To Replicate Enter amount above 10000

Actual Result Error
Expected Result Should be accepted
Attachment Atm1.jpg
Remark Must accept value up to 25000
Defect Severity
Defect Priority Pr-14
Reported By Mr.Kunal.B
Assigned To Mr.Rahul.S
Status Ss001
Fix Build Version 1.0A
 Unit 4: Defect Management

Que 3. Prepare a defect report after executing test cases for any login form

Defect ID L1

Project Name Login Form

Release Version 1.1

Module Login

Detected Build Version L1

Summary Accepting blank username

Description Should not accept blank value for user name

Steps To Replicate Entered blank value

Actual Result Accepted
Expected Result Should not be accepted
Attachment Lg1.jpg
Remark Please check
Defect Severity
Defect Priority Pr-56
Reported By Mr.Kunal.B
Assigned To Mr.Rahul.S
Status Ss001
Fix Build Version 1.0A