MODULE III

Defect Management
Introduction to Defect
A Defect is a flaw or an error in an application that is restricting the normal flow of
an application by mismatching the expected behavior of an application with the
actual one.
A software defect is a malfunctioning of the software due to which the end-user
requirement does not get fulfilled.

The defect occurs when any mistake is made by a developer during the designing or
building of an application and when this flaw is found by a tester, it is termed as a
defect.

It is the responsibility of a tester to do thorough testing of an application to find as

many defects as possible to ensure that a quality product will reach the customer.
Defect Classification
Defect Classification
1. Software defects by nature
a) Functional defects
Functional defects are the errors identified in case the behavior of software is not
compliant with the functional requirements.
These defects are discovered through functional testing.

Example: an ecommerce website’s search engine didn’t return any results when a user
typed in a product ID, while it was stated in the requirements that the search could be
conducted by both a product’s name and ID.
Defect Classification
1. Software defects by nature
b) Performance defects
Performance defects are those bound to software’s speed, stability, response time, and
resource consumption.
They are discovered during performance testing.

An example of a performance defect is a system’s response time being very much

longer than that stated in the requirements.
Defect Classification
1. Software defects by nature
c) Usability defects
A usability defect makes the software difficult or inconvenient to use, for example -
complex registration form.

This type of error prevents the user from using the software to its full potential.

Software engineers and UX designers must review their software against the Web
Content Accessibility Guidelines (WCAG) and other usability requirements to detect
such errors.
Defect Classification
1. Software defects by nature
d) Compatibility defects
An application with compatibility errors doesn’t show consistent performance on
particular types of hardware, operating systems, browsers, and devices or when
integrated with certain software or operating under certain network configurations.
Compatibility testing is carried out in order to discover such issues.

For example: an application performs well in desktop OS but not in Mobile phone
(Android OS). The defects were related to the changes in font size, content alignment,
and scroll bar. That is, a defect related to a font size that renders ideally in Safari but
has the wrong size in Google Chrome.
Defect Classification
1. Software defects by nature
e) Security defects
Security defects are the weaknesses allowing for a potential security attack. It makes
the project to be vulnerable.

This type of bugs opens the software, company, and customers to a potential intense
attack. It can be found through security testing.

There are various approaches to structuring a security vulnerability. For example, the
Open Web Application Security Project (OWASP) lists ten security threats. The
most common are encryption errors, susceptibility to SQL injection, XSS
vulnerabilities, buffer overflows, and inferior authentication.
Defect Classification
2. Software defects by severity
The degree of impact that a defect has on the development or operation of a component or system
is known as severity. Defect Severity determines the defect’s effect on the application. It represents
the impact on the business of the client.
Example − For flight operating website, defect in generating the ticket number against reservation
is high severity and also high priority.

These defects are classified under several levels:

a) Critical defects
It usually block an entire system’s or module’s functionality, and testing cannot proceed further
without such a defect being fixed.
An example of a critical defect is an application’s returning a server error message after a login
attempt or App/Product crash frequently.
Defect Classification
2. Software defects by severity
b) High/Major-severity defects
It affects key functionality of an application, and the app behaves in a way that is
strongly different from the one stated in the requirements,
For instance, an email service provider does not allow adding more than one email
address to the recipient field.

c) Medium-severity defects
They are identified in case a minor function does not behave in a way stated in the
requirements.
An example of such a defect is a broken link in an application’s Terms and
Requirements section.
Defect Classification
2. Software defects by severity

d) Low-severity defects
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 Classification
3. Software defects by 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
development 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.
Defect Classification
3. Software defects by Priority
Defect Priority is classified into the following categories:
a) Immediate: The defect needs to be fixed right now, everything else can wait, the build cannot
be released with this defect.
b) Urgent: Needs to be fixed before any other high, medium or low defect should be fixed – a
timeframe can be set (for example - 24 hours). For example: An application failing to navigate
a user from the login page to the home page
c) Medium: These defects are the errors that may be fixed after an upcoming release or in the
subsequent release. An application returning the expected result, which, however, formats
incorrectly in a particular browser, is an example of a medium-priority defect.
d) Low: These defects are the errors that do not need to be fixed in order to meet the exit criteria
but require fixing before an application becomes generally available. Typos, alignment,
element size, and other cosmetic UI issues are usually included in this group.
Defect Management Process
The primary objective of DMP is to expose the defects at an early stage of the software
development process so as to reduce the impact or effects on the software.
Defect Management Process
1. Defect Prevention
The execution of procedures,
methodology, and standard approaches
to decrease the risk of defects.
Defect removal at the initial phase is
the best approach in order to reduce its
impact.
Identifying the frequent type of defect
and instruct the developers to avoid
such a situation.
Fixing or resolving defects at the initial
stage is less expensive

Fig. Stages in defect prevention

Defect Management Process
2. Deliverable Baseline

When a deliverable (system, product or document) reaches its pre-defined

milestone then you can say a deliverable is a baseline.
In this process, the product or the deliverable moves from one stage to another and
as the deliverable moves from one stage to another, the existing defects in the
system also gets carried forward to the next milestone or stage.

Basically, the deliverables are baselined when the changes in the deliverables are
finalized and all possible defects are identified and fixed. Then the same deliverable
passes on to the next group who will work on it.
Defect Management Process
3. Defect Discovery Steps involved in Defect Discovery are as follows:
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.
Defect discovered means it is formally
brought to the attention of the development
team and after analysis of that the defect
development team also accepted it as a defect.
Defect Management Process
4. Defect Resolution
Steps involved in Defect Resolution Process:
The Defect Resolution is a step-by-step
procedure of fixing the defects.
The testing team has identified the defect
and reported to the development team.
Then the development team needs to
proceed for the resolution of the defect.
Defect Management Process
5. Process Improvement
From process improvement point of view, all defects identified are same as a critical
defect. Major defects are normally corrected in the previous phase.
Minor defects can give an opportunity to learn how to improve the process and prevent the
occurrences of any defect which may impact system failure in the future.
Identification of a defect having a lower impact on the system may not be a big deal but the
occurrences of such defect in the system itself is a big deal.

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.
Advantages of Defect Management Process

1. Confirm Resolution
2. Accessibility of Automation Tools
3. Offer Valuable Metrics
Defect Life cycle

Defect Life Cycle or Bug Life Cycle in software testing is the

specific set of states that defect or bug goes through in its entire life.

The purpose of Defect life cycle is to easily coordinate and

communicate current status of defect which changes to various
assignees and make the defect fixing process systematic and
efficient.
Defect Life Cycle
Defect
Life
Cycle
Defect Life Cycle