Unit IV:- Defect Management (10

Marks)
• Defect Classification, Defect Management Process

• Defect Life Cycle, Defect Template

• Estimate Expected Impact of a Defect, Techniques for Finding Defect,

Reporting a Defect.
 Introduction
• What is a Defect?
• It is a undesirable state. It is considered as cause of user/customer
dissatisfaction.
• The variation in the expected and actual result is known as defects. It is also
the variation from specification/expectation.
• It is an error or a bug.
• Defect can be defined as “An inconsistency in the behavior of the software”
OR “Any significant, unplanned event that occurs during testing that
requires subsequent investigation and/or correction. Defects are raised
when expected and actual test result differ.”
• A s/w defect or bug is a condition in a s/w product which does not meet a
s/w requirement or end user expectations.
Introduction(Conti…)
• Different causes of software defects
• Miscommunication of requirements introduces error in code
• Unrealistic time schedule for development
• Lack of designing experience
• Lack of coding practices experience
• Human factors introduces errors in code
• Lack of version control
• Buggy third-party tools
• Last minute changes in the requirement introduce error
• Poor Software testing skill
• Requirements are not defined clearly by customer
• Design are wrong and not implemented properly
Defect Classification
• Defects may be result of wrong implementation of requirements,
something missing that is required by the customer or putting
something more (extra) than required.
• Defects may be classified in different ways under different schemes.
 Defect Classification(Conti…)
• Severity Wise:
• Critical / Fatal: A defect that completely obstructs the execution of a core
functionality/feature of the software is classified a critical defect.
• Example – E-Commerce - When a user proceeds to the checkout page and enters
their payment information, there is a flaw in the validation process that does not
verify the payment. As a result, the user can complete the purchase without any
funds being deducted from their account.
• Example – Hospital Management- There is a critical flaw in the system's
authentication mechanism. Any user, even those without the necessary credentials,
can gain unauthorized access to sensitive patient records and medical data.
• Example- Calculator App - When a user attempts to divide a number by zero (e.g., 5
÷ 0), the calculator app does not handle this scenario properly. Instead of displaying
an error message, the app either crashes or gives an incorrect result (e.g., displaying
"Infinity" or an arbitrary number).
 Defect Classification(Conti…)
• Major / High: A defect that makes a major functionality/feature to behave
grossly away from what is specified in the requirements specification of the
software is classified a major defect.
• Example - E-commerce Website - When a user adds multiple items to their shopping
cart and then proceeds to the checkout, the total amount displayed in the cart
summary is incorrect. The defect causes an overcharge for some items and
undercharge for others.
• Example - Mobile Banking App - When a user attempts to transfer money from their
account to another account, the transaction sometimes fails without providing any
clear error message or explanation. The user's account balance remains unchanged,
and the recipient does not receive the funds.
• Example - Word Processing Software Save Error - When a user attempts to save a
document they've been working on, the software sometimes encounters an error
during the save process. As a result, the user's changes are not saved, and they risk
losing their work. The software may display a generic error message like "Save failed"
without providing further details
 Defect Classification(Conti…)
• Minor / Low: A defect which occurs when a functionality/feature does
not behave as intended or exhibits some unnatural behavior, however
the functionality/feature as a whole is not much impacted is classified
a minor defect.
• Example - Spelling Error in User Interface - In the software's user interface,
there is a minor spelling error in a non-essential label or button. For instance,
the label "Preferences" is used instead of "Preferences" in a settings menu.
• Example - Inconsistent Font Size in a Mobile App - In the app's settings menu,
the font size of some of the text labels is slightly larger or smaller than the
standard font size used throughout the rest of the app. This results in a minor
inconsistency in the appearance of the text.
• Example - Icon Color Variation - In the app's user interface, some icons that
should be of the same color have slight variations in their shades. For instance,
the "Refresh" icon is a slightly lighter shade of blue compared to the "Reload"
 Defect Classification(Conti…)
• Work Product Wise:
• SSD: A defect from System Study document
• provides a detailed analysis and documentation of defects or issues
discovered during the testing phase of a software development or
quality assurance project.
• FSD: A defect from Functional Specification document
• provides a detailed description of the expected functionality and
behavior of a software system or application.
• ADS: A defect from Architectural Design Document
• provides an in-depth description of the architectural aspects of a
software system. This document is essential for testers and
developers to understand the system's structure and components,
which is crucial for defect testing.
Defect Classification(Conti…)
• DDS: A defect from Detailed Design document
• provides a comprehensive description of the detailed design
and specifications of a software system or component. This
document is essential for testers and developers to understand
the system's inner workings, which is crucial for effective defect
testing
• Source code: A defect from Source code
• Test Plan/ Test Cases: A defect from Test Plan/ Test Cases
• User Documentation: A defect from User manuals, Operating
manuals
 Defect Classification(Conti…)
• Type of Error Wise:
• Comments: Inadequate/ incorrect/ misleading or missing comments in the
source code
• Computational Error: Improper computation of the formulae / improper
business validations in code.
• Data error: Incorrect data update in database
• Database Error: Error in the database schema/Design
• Missing Design: Design features/approach missed/not documented in the
design document and hence does not correspond to requirements
• In correct Design: Wrong or inaccurate Design
• Logic Error: Missing or Inadequate or irrelevant or ambiguous functionality
in source code
Defect Classification(Conti…)
• Boundary Conditions Neglected: Boundary conditions not
addressed/incorrect
• Interface Error: Internal or external to application interfacing error,
Incorrect handling of passing parameters, Incorrect alignment,
incorrect/misplaced fields/ objects, un friendly window/screen positions
• Typographical Error: Spelling / Grammar mistake in documents/source
code
• Variable Declaration Error: Improper declaration / usage of variables,
Type mismatch error in source code
 Defect Classification(Conti…)
• Status Wise:
• Open: A defect that has been identified and reported but has not yet been
assigned for resolution. It is awaiting review and assignment to a developer or
development team
• Closed : The defect has been successfully resolved, verified, and is now
considered closed. It is no longer an active issue in the defect management
system.
• Deferred : In some cases, a defect may not be resolved immediately due to
resource constraints, low priority, or other reasons. It is marked as "Deferred"
and set for resolution in a future release or update.
• Fixed : The defect has been addressed by the development team, and the
code has been modified to resolve the issue. It is now ready for testing.
 Defect Classification(Conti…)
• Scenario: Bug in a Text Editor
• Suppose you're part of a software development team working on a text editor application.
A user reported a bug where the spell checker is not functioning correctly. Here's how the
defect may progress through the defect tracking process:
• Open Status Defect:
• The user reports the issue, and it is entered into the defect tracking system with an
"open" status.
• The development team reviews the bug report and assigns it to a developer for
investigation.
• Fixed Status Defect:
• The assigned developer identifies the problem in the code, makes the necessary
changes to fix the issue, and marks the defect as "fixed."
• At this point, the defect is no longer considered "open," but it hasn't been fully
verified or tested yet. It is in the "fixed" state.
 Defect Classification(Conti…)
• Testing and Verification:
• The testing team now takes over. They test the application, focusing on the
spell checker functionality to verify that the issue is resolved.
• If testing confirms that the bug is indeed fixed and that no new issues have
been introduced, the defect is marked as "closed."
• Closed Status Defect:
• In the "closed" state, the defect is considered fully resolved and closed. It
won't require further attention in the current release cycle.
• Documentation is updated, and any relevant stakeholders are informed of the
resolution.
• So, in this example, the bug starts as an "open status defect" when reported,
progresses to a "fixed status defect" once a developer addresses it, and finally
reaches a "closed status defect" when the testing team confirms the successful
resolution
 Defect Management Process:
• The process of finding defects and reducing them at the lowest cost is
called as Defect Management Process.
• Defect management is the process of recognizing, investigating, taking
action and disposing of defects.
• It involves recording defects, classifying them and identifying the impact.
• The defect management approach includes counting and managing
defects.
• Defect management process must be defined by an organization’s quality
assurance function and project may adapt to it with some level of tailoring
if necessary.
Defect Management Process:
• Steps in Defect Management
Defect Management Process:
• Steps in Defect Management
 Defect Management Process:(Conti…)
• Defect Prevention: implementation of techniques, methodology and standard
processes to reduce the risk of defects.
• It involves the implementation of various techniques, methodologies, and
standard processes to minimize the risk of defects
• Here's an explanation of some key aspects of defect prevention:
• Quality Assurance Processes
• Code Reviews
• Root Cause Analysis
• Requirements Gathering and Validation
• Training and Skill Development
• Defect prevention is cost-effective and contributes to overall product quality
and customer satisfaction.
Defect Management Process: (Conti…)

• Deliverable Baseline: Establishment of milestones where

deliverables will be considered complete and ready for
further development work.
• When a deliverable is baseline, any further changes are
controlled. Errors in a deliverable are not considered defects
until after the deliverable is baselined.
 Defect Management Process: (Conti…)
• 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 members
responsible for the components 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 tester to ensure that the resolution
is verified.
 Defect Management Process: (Conti…)
• 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.
Defect Life Cycle
• It is a cycle which a defect goes through during its lifetime. Defect life
cycle is also known as Bug life cycle.
• It starts when defect is found and ends when a defect is closed, after
ensuring that it will not be reproduced.
• This cycle is related to bug found during testing.
• The bug has different states in the life cycle. This is as shown in
diagram.
Defect Life Cycle
 Defect Life Cycle(Conti…)
• 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; viz - 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.
 Defect Life Cycle(Conti…)
• 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; viz - duplicate
defect, NOT a Defect, Non Reproducible.
 Defect Template
• A defect report or defect template documents an irregularity discovered
during testing.

• Each and every organization must have a defect template which capture a
defect data.

• Different s/w management tools offer defect templates, sometimes test

case template is extended as defect template.

• The purpose of a defect template is to state the problem as early as

possible so that the developers can replicate the defect easily and fix it.
 Defect Template(Conti…)
• It includes the following information—
• Defect ID- may be numeric or some distinctive identifier.
• Defect name- is the name of the defect including the defect explanation in brief, its
nature and type.
• Project name- indicates the project for which the defects is found.
• Module/ Sub module name- for which the defect is found may be mentioned to
create a reference. It may not be required, if defect ID already contains this
information.
• Phase introduced- gives information about when the defect has been added in the
application being developed.
• Phase found- is the phase, when defect is found. This is used to find defect leakage.
• Defect type- is the definition of defect type may be declared in test plan.
• Severity- This indicates severity of defect which may be critical, major, minor or
trivial.
 Defect Template(Conti…)
• Critical- Affects critical functionality or critical data. E.g. unsuccessful
installation, complete failure of a feature.
• Major- Affects major functionality. E.g. a feature is not functional from one
module but the task is doable if 10 complicated indirect steps are followed
in another modules.
• Minor- Affects minor functionality. E.g. a minor feature that is not
functional in one module but the same task is easily doable from another
module.
 Defect Template(Conti…)
• Priority- is defined on the basis of how the project decides a schedule to take the
defects for fixing.
• Different levels are-
• High- Must be fixed in any of the upcoming builds but should be included in the release.
• Medium- May be fixed after the release/ in the next release.
• Low- May or may not be fixed at all
• Summary- includes in short about the defect, how many times it has been reproduced
and which browsers, OS and environmental facts have been used for reproducing it.
• Description- Details of defect which includes what has been observed and impact on
the users.
• Status of defect- it’s a dynamic field which can be either open, resolved, closed,
deferred or reopened.
• Reported by/ Reported on- information about testers, who found the defect and date
of finding defects are report.
Defect Template(Conti…)
Defect Template(Conti…)
 Estimate Expected Impact Of A Defect
• Defect Impact: The degree of severity that a defect has on the development
or operation of a component or system.
• Someone must estimate what loss will be suffered by a user in case of
occurrence of risk.
• Risk impact is categorized as high, medium and low or calculate on the basis
of money value of the loss.
• People close to the risk may be able to estimate the probable impact with
some level of certainty.
• Estimation may be done by different methods / approaches to find the
probability of risk occurrence and impact when it becomes reality. It must
be based on some model and thorough process.
 Estimate Expected Impact Of A Defect(Conti…)
• How to Estimate the defect impact
• 1. Once the critical risks are identified, the financial impact of each risk should be
estimated.
• 2. 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.
• 3. The product of these two numbers is the expected impact of the risk.
• 4. 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.
• 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.
 Techniques for Finding Defects
• Defects are found either by preplanned activities specifically intended to
uncover defects or by accident.

• Techniques to find defects can be divided into three categories-

• Static Techniques:
• Testing that is done without physically executing a program or system.
• 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.
• Static technique is so named because it involves no execution of code,
product, documentation, etc
• • E.g. code review, walkthrough, inspections etc.
 Techniques for Finding Defects(Conti…)
• Dynamic Techniques:
• • Testing in which system components are physically executed to identify
defects.
• 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.
• • E.g. execution of test case.
 Techniques for Finding Defects(Conti…)
• Operational Techniques:
• An operational system produces a deliverable containing a defect found by
user i.e defect is found as a result of failure.
• 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.
• It also includes revisiting the defects before and after fixing and analysis.
Techniques for Finding Defects(Conti…)
• Both static and dynamic techniques are required for an effective
defect management program.
• In each category, the more formally the techniques were integrated
into the development process, the more effective they were.
• Since static techniques will generally find defects earlier in the
process, they are more efficient at finding defects.
 Reporting a Defect

• Reporting defect is an important step for an organization in s/w

development life cycle to establish capability of a processes and for
initiating corrective and preventive actions along with corrections, if
problems are found.
• Once discovered, defects must be brought to the developers attention. It
can be reported by simple written or electronic report.
• Some defects are discovered by accident i.e. people who are not trying to
find defects.
• As s/w becomes more complex and more widely used, these techniques
become more valuable.
• When defect is initially discovered, it may be unclear whether it is a defect,
a change, user error or misunderstanding.
• Defect reports provide information about defects that are related to a test
plan, the status of those defects and trends in those defects over time.
Reporting a Defect:
• A defect report describes defects in s/w and documentation.
• It includes priority ratings which indicates the impact the problem has
on the customer.
 Guidelines for Reporting a Defect(Conti…)
• Some important points to be noted in defect report are-
• 1. Given complete record of discrepancies:
• Complete description of a defect indicates the symptom or what has been
observed by the s/w tester.
• What will happen to a user when defect is located and helps in taking
corrective actions.

• 2. Defect report forms the base for quality measurement:

• There is probability associated with defect finding.
• Nobody can find all the defects in s/w and if no defects are found then it
doesn’t mean that the s/w is good.
• Number of defects can be used to measure lack of quality in a s/w.
 Guidelines for Reporting a Defect(Conti…)
• Defect Management may go through the following steps-
• Correct the defect:
• Correcting the defect logged by the tester in validation/ verification during SDLC is the primary activity done for
fixing the defect.
• Corrected defect may undergo review, unit testing and retesting as the case may be.

• Report status of system:

• Status of system with respect to standards and acceptance criteria fulfillment can be assessed through status
reporting.

• Gather statistics to predict failure:

• It is used by an organization to plan corrective and preventive actions at project/ organizational level.

• Process improvement:
• Testing is not the efficient way of improving quality.
• An organization must stress on quality improvement programs through process improvements to ensure that
defects are not introduced in the system.
Chapter 4 End…………!