UNIT-04 Marks-12

Defect Management
4.1 Defect Classification, Defect Management Process.
4.2 Defect Life Cycle, Defect Template
4.3 Estimate Expected Impact of Defect, Techniques for
finding Defect, Reporting a Defect.

4.1 Defect Classification, Defect Management

Process.
Defect Classification
Defects are classified from the QA team perspective
as Priority and from the development perspective
as Severity (complexity of code to fix it). These are two
major classifications that play an important role in the
timeframe and the amount of work that goes in to fix
defects.

What is Priority?
Priority is defined as the order in which the defects
should be resolved. The priority status is usually set by
the QA team while raising the defect against the dev
team mentioning the timeframe to fix the defect. The
Priority status is set based on the requirements of the
end users.
For example, if the company logo is incorrectly placed in
the company's web page then the priority is high but it is
of low severity.
Priority Listing
A Priority can be categorized in the following ways −
• Low − This defect can be fixed after the critical ones
are fixed.
• Medium − The defect should be resolved in the
subsequent builds.
• High − The defect must be resolved immediately
because the defect affects the application to a
considerable extent and the relevant modules cannot
be used until it is fixed.
• Urgent − The defect must be resolved immediately
because the defect affects the application or the
product severely and the product cannot be used
until it has been fixed.
What is Severity?
Severity is defined as the impishness of defect on the
application and complexity of code to fix it from
development perspective. It is related to the development
aspect of the product. Severity can be decided based on
how bad/crucial is the defect for the system. Severity
status can give an idea about the deviation in the
functionality due to the defect.
Example − For flight operating website, defect in
generating the ticket number against reservation is high
severity and also high priority.
Severity Listing
Severity can be categorized in the following ways −
• Critical /Severity 1 − Defect impacts most crucial
functionality of Application and the QA team cannot
continue with the validation of application under
test without fixing it. For example, App/Product
crash frequently.
• Major / Severity 2 − Defect impacts a functional
module; the QA team cannot test that particular
module but continue with the validation of other
modules. For example, flight reservation is not
working.
• Medium / Severity 3 − Defect has issue with single
screen or related to a single function, but the system
is still functioning. The defect here does not block
any functionality. For example, Ticket# is a
representation which does not follow proper alpha
numeric characters like the first five characters and
the last five as numeric.
• Low / Severity 4 − It does not impact the
functionality. It may be a cosmetic defect, UI
inconsistency for a field or a suggestion to improve
the end user experience from the UI side. For
example, the background color of the Submit button
does not match with that of the Save button.
# Defect Management Process

1. Defect Prevention -- Implementation of techniques,

methodology and standard processes to reduce the risk
of defects.
Defect Prevention Process

2. Deliverable Baseline -- Establishment of milestones

where deliverables will be considered complete and ready
for further development work. When a deliverable is
baselined, any further changes are controlled. Errors in
a deliverable are not considered defects until after the
deliverable is baselined.
3. 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.

• Find Defect : Discover defects before they become

major problems.
• Report Defect : Report defects to developers so that
they can be resolved.
• Acknowledge Defect : Obtain development
acknowledgement that the defect is valid and should be
addressed.
4. 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.

• Prioritize Risk : Developers determine the

importance of fixing a particular defect.

• Schedule Fix and Fix Defect: Developers schedule

when to fix a defect. Then developers should fix
defects in order of importance.

• Report Resolution: Developers notify all relevant

parties how and when the defect was repaired.

5. Process Improvement -- Identification and analysis of

the process in which a defect originated to identify ways
to improve the process to prevent future occurrences of
similar defects. Also the validation process that should
have identified the defect earlier is analyzed to determine
ways to strengthen that process.
Management Reporting -- Analysis and reporting of
defect information to assist management with risk
management, process improvement and project
management.
4.2 Defect Life Cycle, Defect Template
# Defect Life Cycle

• New - Potential defect that is raised and yet to be

validated.
• Assigned - Assigned against a development team to
address it but not yet resolved.
• Active - The Defect is being addressed by the
developer and investigation is under progress. At
this stage there are two possible outcomes, Deferred
or Rejected.
• Test - The Defect is fixed and ready for testing.
 • Verified - The Defect that is retested and the test
has been verified by QA.
• Closed - The final state of the defect that can be
closed after the QA retesting or can be closed if the
defect is duplicate or considered as NOT a defect.
• Reopened - When the defect is NOT fixed, QA
reopens/reactivates the defect.
• Deferred - When a defect cannot be addressed in
that particular cycle it is deferred to future release.
• Rejected - A defect can be rejected for any of the 3
reasons, duplicate defect, NOT a Defect, Non
Reproducible.
# Defect Template

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

Project Project name.

Product Product name.

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

Version

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

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

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 Step by step description of the way to reproduce the defect.
Replicate Number the steps.

Actual Result The actual result you received when you followed the steps.

Expected The expected results.

Results

Attachments Attach any additional information like screenshots and logs.

Remarks Any additional comments on the defect.

Defect Severity Severity of the Defect.

Defect Priority Priority of the Defect.

Reported By The name of the person who reported the defect.

Assigned To The name of the person that is assigned to analyze/fix the defect.

Status The

Fixed Build Build version of the product where the defect was fixed (e.g.
Version 1.2.3.9)

4.3 Estimate Expected Impact of Defect, Techniques

for finding Defect, Reporting a Defect.

# Estimate Expected Impact

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, where:

P= Probability of the risk becoming a problem,

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. While guess work will constitute a major role in
producing these numbers, precision is not
important. What will be important is to identify the risk,
and determine the risk's order of magnitude.

Large, complex systems will have many critical

risks. Whatever can be done to reduce the probability of
each individual critical risk becoming a problem to a very
small number should be done. Doing this increases the
probability of a successful project by increasing the
probability that none of the critical risks will become a
problem.

One should assume that an individual critical risk has a

low probability of becoming a problem only when there is
specific knowledge justifying why it is low. For example,
the likelihood that an important requirement was missed
may be high if developers have not involved users in the
project. If users have actively participated in the
requirements definition, and the new system is not a
radical departure from an existing system or process, the
likelihood may be low.
One of the more effective methods for estimating the
expected impact of a risk is the annual loss expectation
(ALE) formula. This is discussed below:

The occurrence of a risk can be called an "event."

Loss per event can be defined as the average loss for a
sample of events.
The formula states that the ALE equals the loss per
event multiplied by the number of events.
For example, if the risk is that the software system will
abnormally terminate, then the average cost of correcting
an abnormal termination is calculated and multiplied by
the expected number of abnormal terminations
associated with this risk
For the annual calculation, the number of events
should be the number of events per year.

# Techniques for finding Defect

The first step in preventing defects is to understand the
critical risks facing the project or system. The best way
to do this is to identify the types of defects that pose the
largest threat. In short, they are the defects that could
jeopardize the successful construction, delivery and/or
operation of the system. These risks can vary widely
from project to project depending on the type of system,
the technology, the users of the software, etc. These
risks might include:

• Missing a key requirement

• Critical application software that does not function
properly
 • Vendor supplied software does not function properly
• Performance is unacceptably poor
• Hardware malfunction
o Hardware and/or software does not integrate

properly
• Hardware new to installation site
o Hardware not delivered on-time

• Users unable or unwilling to embrace new system

• User's inability to actively participate in project

It should be emphasized that the purpose of this step is

not to identify every conceivable risk, but to identify
those critical risks that merit special attention because
they could jeopardize the success of the project.

#Reporting a Defect
A Bug Report in Software Testing is a detailed document
about bugs found in the software application. Bug report
contains each detail about bugs like description, date
when bug was found, name of tester who found it, name
of developer who fixed it, etc. Bug report helps to identify
similar bugs in future so it can be avoided.
While reporting the bug to developer, your Bug Report
should contain the following information
• Defect_ID - Unique identification number for the
defect.
• Defect Description - Detailed description of the
Defect including information about the module in
which Defect was found.
 • Version - Version of the application in which defect
was found.
• Steps - Detailed steps along with screenshots with
which the developer can reproduce the defects.
• Date Raised - Date when the defect is raised
• Reference- where in you provide reference to the
documents like. requirements, design, architecture
or maybe even screenshots of the error to help
understand the defect
• Detected By - Name/ID of the tester who raised the
defect
• Status - Status of the defect , more on this later
• Fixed by - Name/ID of the developer who fixed it
• Date Closed - Date when the defect is closed
• Severity which describes the impact of the defect on
the application
• Priority which is related to defect fixing urgency.
Severity Priority could be High/Medium/Low based
on the impact urgency at which the defect should be
fixed respectively
SAMPLE BUG REPORT

Bug Name: Application crash on clicking the SAVE

button while creating a new user.
Bug ID: (It will be automatically created by the BUG
Tracking tool once you save this bug)
Area Path: USERS menu > New Users
Build Number: Version Number 5.0.1
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-X
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are
using)
Environment: Windows 2003/SQL Server 2005