SOFTWARE TESTING

UNIT IV
Defect Management

Presented by
M S RATHOD
LIF, GPA
Unit Outcomes
Classify defects on the basis estimated
impact.
 Prepare defect template on the given
application.
 Apply defect management process on the
given application.
Write procedure to find defect using the
given technique.
Overview
Defect Classification
Defect Management Process.
Defect Life Cycle, Defect Template
Estimate Expected Impact of a Defect,
Techniques for Finding Defects
Reporting a Defect.
Defect Classification
Defects are classified using two different
perspective.
from the QA team perspective
as Priority
from the development perspective
as Severity (complexity of code to fix it).
Defect Classification
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 Degree of impact 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.
 Severity Listing
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 colour of the
Submit button does not match with that of the Save
button.
 Defect Management Process
A Defect in Software Testing is a variation
or deviation of the software application
from end user’s requirements or original
business requirements.
A software defect is an error in coding
which causes incorrect or unexpected
results from a software program which does
not meet actual requirements.
Testers might come across such defects
while executing the test cases.
 Defect Management Process
A Defect in Software Testing is a variation
or deviation of the software application
from end user’s requirements or original
business requirements.
A software defect is an error in coding
which causes incorrect or unexpected
results from a software program which does
not meet actual requirements.
Testers might come across such defects
while executing the test cases.
 Defect Management Process:
Bug/Defect Report
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.
 Defect Management Process:
Bug/Defect Report
 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
 Defect Management Process:
Bug/Defect Report
 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
What is Defect Management Process?

Defect Management is a systematic

process to identify and fix bugs.
A defect management cycle contains the
following stages
 1) Discovery of Defect,
2) Defect Categorization
3) Fixing of Defect by developers
4) Verification by Testers,
What is Defect Management Process?

 5) Defect Closure
6) Defect Reports at the end of project
Defect Management Process: Discovery

In the discovery phase, the project teams

have to discover as many defects
as possible, before the end customer can
discover it.
 A defect is said to be discovered and
change to status accepted when it is
acknowledged and accepted by the
developers.
Defect Management Process: Categorization

Defect categorization help the software

developers to prioritize their tasks.
That means that this kind of priority helps
the developers in fixing those defects first
that are highly crucial.
Defect Management Process: Categorization

Defect categorization help the software

developers to prioritize their tasks.
That means that this kind of priority helps
the developers in fixing those defects first
that are highly crucial.
 Defect Management Process: Categorization

N
o Description Priority Explanation
.
The website performance The performance bug can cause huge
1 High
is too slow inconvenience to user.

The login function of the Login is one of the main function of the banking
2 website does not work Critical website if this feature does not work, it is serious
properly bugs

The GUI of the website

The defect affects the user who use Smartphone to
3 does not display correctly Medium
view the website.
on mobile devices

The website could not This is a serious issue since the user will be able to
4 remember the user login High login but not be able to perform any further
session transactions

This is an easy fix for development guys and the

5 Some links doesn’t work Low
user can still access the site without these links
Defect Management Process: Defect Resolution

Defect Resolution in software testing is a step

by step process of fixing the defects.
Defect resolution process starts with assigning
defects to developers,
then developers schedule the defect to be
fixed as per priority,
then defects are fixed and finally developers
send a report of resolution to the test manager.
This process helps to fix and track defects
easily.
Defect Management Process: Verification

After the development

team fixed and reported the defect, the
testing team verifies that the defects are
actually resolved.
Closure
Once a defect has been resolved and
verified, the defect is changed status
as closed.
If not, you have send a notice to the
development to check the defect again.
Defect Management Process: Defect Reporting

Defect Reporting in software testing is a

process in which test managers prepare and
send the defect report to the management
team for feedback on defect management
process and defects’ status.
Then the management team checks the defect
report and sends feedback or provides further
support if needed.
Defect reporting helps to better communicate,
track and explain defects in detail.
Defect Life Cycle
Defect life cycle, also known as Bug Life
cycle is the journey of a defect cycle,
which a defect goes through during its
lifetime.
 It varies from organization to
organization and also from project to
project as it is governed by the software
testing process and also depends upon the
tools used.
Defect Life Cycle states
Defect Life Cycle states
 New: When a new defect is logged and posted for the first time. It is
assigned a status as NEW.
 Assigned: Once the bug is posted by the tester, the lead of the tester
approves the bug and assigns the bug to the developer team
 Open: The developer starts analyzing and works on the defect fix
 Fixed: When a developer makes a necessary code change and verifies the
change, he or she can make bug status as “Fixed.”
 Pending retest: Once the defect is fixed the developer gives a particular
code for retesting the code to the tester. Since the software testing remains
pending from the testers end, the status assigned is “pending retest.”
 Retest: Tester does the retesting of the code at this stage to check whether
the defect is fixed by the developer or not and changes the status to “Re-
test.”
 Verified: The tester re-tests the bug after it got fixed by the developer. If
there is no bug detected in the software, then the bug is fixed and the
status assigned is “verified.”
Defect Life Cycle states
 Reopen: If the bug persists even after the developer has fixed the
bug, the tester changes the status to “reopened”. Once again the bug
goes through the life cycle.
 Closed: If the bug is no longer exists then tester assigns the status
“Closed.”
 Duplicate: If the defect is repeated twice or the defect corresponds
to the same concept of the bug, the status is changed to “duplicate.”
 Rejected: If the developer feels the defect is not a genuine defect
then it changes the defect to “rejected.”
 Deferred: If the present bug is not of a prime priority and if it is
expected to get fixed in the next release, then status “Deferred” is
assigned to such bugs
 Not a bug:If it does not affect the functionality of the application
then the status assigned to a bug is “Not a bug”.
Estimation of expected impact of defect
 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
and I= Impact in dollars if the risk becomes a problem.
Estimation of expected impact of defect
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.
What will be important is to identify the
risk, and determine the risk's order of
magnitude.
Techniques to find defects
 a) Quick Attacks:
 The quick-attacks technique allows you to perform a
cursory analysis of a system in a very compressed
timeframe.
 Even without a specification, you know a little bit about
the software, so the time spent is also time invested in
developing expertise.
 b) Equivalence and Boundary Conditions:
 Boundaries and equivalence classes give us a technique
to reduce an infinite test set into something manageable.
 They also provide a mechanism for us to show that the
requirements are "covered".
Techniques to find defects
c) Common Failure Modes:
The heart of this method is to figure out what failures
are common for the platform, the project, or the team;
then try that test again on this build.
If your team is new, or you haven't previously tracked
bugs, you can still write down defects that "feel"
recurring as they occur—and start checking for them.
The more your team stretches itself (using a new
database, new programming language, new team
members, etc.), riskier the project will be—and, at the
same time, the less valuable this technique will be.
Techniques to find defects
 d) Use Cases:
 Use cases and scenarios focus on software in its role to enable
a human being to do something.
 Use cases and scenarios tend to resonate with business
customers, and if done as part of the requirement process, they
sort of magically generate test cases from the requirements.
 e) Code-Based Coverage Models:
 Imagine that you have a black-box recorder that writes down
every single line of code as it executes. Programmers prefer
code coverage.
 It allows them to attach a number— an actual, hard, real
number, such as 75%—to the performance of their unit tests,
and they can challenge themselves to improve the score.
Techniques to find defects
 Customer-level coverage tools are expensive, programmer-
level tools that tend to assume the team is doing automated
unit testing and has a continuous-integration server and a fair
bit of discipline.
 After installing the tool, most people tend to focus on
statement coverage—the least powerful of the measures.

 f) Regression and High-Volume Test Techniques:

 People spend a lot of money on regression testing, taking the
old test ideas described above and rerunning them over and
over.
 This is generally done with either expensive users or very
expensive programmers spending a lot of time writing and
later maintaining those automated tests.
Reporting a defect
DEFECT REPORT, also known as Bug
Report, is a document that identifies and
describes 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.
ISTQB Definition
defect report: Documentation of the
occurrence, nature, and status of a defect.
 Defect Report Template
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. 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 the steps.
Expected Results The expected results.
Attachments Attach any additional information like screenshots and logs.
Remarks Any additional comments on the defect.
Defect Probability Probability of the Defect. (See Defect Probability)

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 who 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)
Fixed Build Version Build version of the product where the defect was fixed (e.g. 1.2.3.9)