Chapter 4

Defect Management
4.1
* Concept Map

Software Test
Testing Basics Management

Defect
Management

Defect Defect Life Defect Defect Report

Classification Cycle Management Template
Process

1) Defect Classification – Severity wise.

Here are various ways in which we can classify defects. Below are some of the
classifications:
Major :- A defect, which will cause an observable product failure or departure
from requirements.
Minor :- A defect that will not cause a failure in execution of the product.
Fatal :- A defect that will cause the system to crash or close abruptly or effect
other applications.

2) Defect Classification – Work Product wise.

SSD :- A defect from System Study document.
FSD :- A defect from Functional Specification document.
ADS :- A defect from Architectural Design Document.
DDS :- A defect from Detailed Design document.
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.

3) Defect Classification – 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 population / 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.
Inadequate or sub optimal Design :- Design features/approach needs
additional inputs for it to be complete Design features described does not provide
the best approach (optimal approach) towards the solution required.
In correct Design :- Wrong or inaccurate Design.
Ambiguous Design :- Design feature/approach is not clear to the reviewer.
Also includes ambiguous use of words or unclear design features.
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.
Logic Error :- Missing or Inadequate or irrelevant or ambiguous functionality
in source code.
Message Error :- Inadequate/ incorrect/ misleading or missing error
messages in source code.
Navigation Error :- Navigation not coded correctly in source code.
Performance Error :- An error related to performance/optimality of the
code.
Missing Requirements :- Implicit/Explicit requirements are missed/not
documented during requirement phase.
Inadequate Requirements :- Requirement needs additional inputs for to
be complete.
Incorrect Requirements :- Wrong or inaccurate requirements.
Ambiguous Requirements :- Requirement is not clear to the reviewer.
Also includes ambiguous use of words – e.g. Like, such as, may be, could be, might
etc.
Sequencing / Timing Error :- Error due to incorrect/missing
consideration to timeouts and improper/missing sequencing in source code.
Standards :- Standards not followed like improper exception handling, use of
E & D Formats and project related design/requirements/coding standards.
System Error :- Hardware and Operating System related error, Memory leak.
Test Plan / Cases Error :- Inadequate/ incorrect/ ambiguous or duplicate
or missing - Test Plan/ Test Cases & Test Scripts, Incorrect/Incomplete test setup.
Typographical Error :- Spelling / Grammar mistake in documents/source
code.
Variable Declaration Error :- Improper declaration / usage of variables,
Type mismatch error in source code.

4) Defect Classification – Status wise.

Open.
Closed.
Deferred.
Cancelled.
4.2 Defect Management.
1) Defect Life Cycle.
Whenever the testing team finds a defect in the application, they raise the defect
with the status as “NEW”.
When a new defect is reviewed by a QA lead and if the defect is valid, then the
status of the defect would be “Open” and it is ready to be assigned to the
development team.
When a QA lead assigns the defect to the corresponding developer, the status of
the defect would be marked as “Assigned”. A developer should start analysing
and fixing the defect at this stage.
When the developer feels that the defect is not genuine or valid, then the
developer rejects the defect. The status of the defect is marked as “Rejected”
and assigned back to the testing team.
If the defect logged is repeated twice or both the defects reported have similar
results and steps to reproduce, then one defect status is changed to
“Duplicate”.
If there are some issues or hurdles in the current release for fixing a particular
defect, then the defect would be taken in the upcoming releases instead of the
current release and then it is marked as “Deferred” or “Postponed”.
When a developer is not able to reproduce the defect by the steps mentioned in
“Steps to Reproduce” by the testing team then the developer can mark the defect
as “Not Reproducible”. In this stage, the testing team should provide
detailed reproducing steps to a developer.
If the developer is not clear about the steps to reproduce provided by a QA to
reproduce the defect, then he/she can mark it as “Need more
information”. In this case, the testing team needs to provide the required
details to the development team.
If a defect is already known and currently present in the production environment
then the defect is marked as “Known defect”.
When a developer makes the necessary changes, then the defect is marked as
“Fixed”.
The developer now passes the defect to the testing team to verify, so the developer
changes the status as “Ready for Retest”.
If the defect has no further issues and it is properly verified, then the tester marks
the defect as “Closed”.
While retesting the defect if the tester found that, the defect is still reproducible or
partially fixed then the defect would be marked as “Reopened”. Now the
developer has to look again into this defect.
A well planned and controlled Defect Life Cycle gives the total number of defects
found in a release or in all releases.
This standardized process gives a clear picture of how the code was written, how
properly the testing has been carried out, how the defect or software has been
released, etc.
This will reduce the number of defects in production by finding the defects in the
testing phase itself.
2) Defect Report Template.
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.
1) Defect Management Process.

Defect Prevention is much more efficient and effective in reducing the

number of defects and also is very cost effective to fix the defects found during the
early stage of the software process. Most of the organizations conduct Defect
Discovery, Defect Removal and then Process
Improvement which is collectively known as a Defect Management
Process.

2) Defect Prevention.
It is the best method to eliminate the defects in the early stage of testing instead of
finding the defects in the later stage and then fixing it.
This method is also cost effective as the cost required for fixing the defects found
in the early stages of testing is very low.
However, it is not possible to remove all the defects but at least you can minimize
the impact of the defect and cost to fix the same.
The major steps involved in Defect Prevention are as follow:
Identify Critical Risk :-Identify the critical risks in the system which will
impact more if occurred during testing or in the later stage.
Estimate Expected Impact :-For each critical risk, calculate how much
would be the financial impact if the risk actually encountered.
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 eliminate the risk. For risks which cannot be eliminated, it reduces
the probability of occurrence and its financial impact.
3) 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.
For Example, consider a scenario of coding, unit testing and then system testing.
If a developer performs coding and unit testing then system testing is carried out
by the testing team. Here coding and Unit Testing is one milestone and System
Testing is another milestone.
So during unit testing, if the developer finds some issues then it is not called as a
defect as these issues are identified before the meeting of the milestone deadline.
Once the coding and unit testing have been completed, the developer hand-overs
the code for system testing and then you can say that the code is “baselined” and
ready for next milestone, here, in this case, it is “system testing”.
Now, if the issues are identified during testing then it is called as the defect as it is
identified after the completion of the earlier milestone i.e. coding and unit testing.
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.

4) 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.
We can say that the 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.
Steps involved in Defect Discovery are as follows:
Find a Defect :-Identify defects before they become a major problem to the
system.
Report 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 analyzed and fixed.
Acknowledge Defect :- Once the testing team assigns the defect to the
development team, its the development team’s responsibility to acknowledge the
defect and continue further to fix it if it is a valid defect.
5) Defect Resolution.
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.
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.
Report the Resolution :- Its the 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.

6) Process Improvement.
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.
Even these minor defects 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.

7) Management 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.
The management board has right to know the defect status.

4.3
1) Estimate Expected Impact of a 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.

2) Techniques of finding Defects.

Defects are found either by pre-planned activities specifically intended to

uncover defects (e.g., quality control activities such as inspections, testing,
etc.) or by accident (e.g., users in production).
Techniques to find defects can be divided into three categories:
Static techniques :- Testing that is done without physically executing a
program or system. A code review is an example of a static testing technique.
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.
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.
While it is beyond the scope of this study to compare and contrast the various
static, dynamic, and operational techniques, the research did arrive at the
following conclusions:
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.

3) Defect Report.
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.