UNIT 4

Defect Management
What Is A Defect?

● The defects which are also known as bugs or faults are anything that
cause threading to the value, quality and aim of the software.

● It can be identified by the tester through the variance of expected

results and actual results of execution of test cases.
● The defect-free software building is the impossible where the defects
detected and solving the defects is the only way to achieve the defect
free software.

● To achieve the goal the nature of the defects and the implementation
methods of solving the defects should be known.
Defect Classification
Let’s find the list of defects in software testing.

Design Defects:

The algorithms, login and data elements, module interface, the external software
and hardware should be correctly designed. The incompatible or incorrectly
designed modules lead to defects in the system.
Command Defects:

An error in the sequences and logic is known as control flow error or command error.
The reasons for such defects are missing command, wrong algorithm, incorrect data
and code errors.

Boundary Value Defects:

In case the login page is logging in by giving the password length to 16 characters in
the place of 15 characters, then the defect is the boundary value defect.
Error Handling Defects:

The error that is raised while the users interacting with the software need to be handled in
the correct flow. The flow should indicate the instruction in the popup message for the
mandatory fields to alert the users for incorrect information.

Multithreading Defects:

Executing or running multiple tasks at the time. Complex debugging is possible in the
multiple threading process. It may also lead to a system crash/failure due to the condition in
deadlock.
Security Defect:

The defects will be different by their nature of the risks. These defects are weaknesses
allowing for a potential security attack.

Interface Defects:

The defects in the interactions of the software and the users. Some of the interfaces in
the different kinds of forms are complicated interfaces, unclear interfaces and platform
based interfaces.
Defect Management Process

The process of defect management is at the core of software testing.

Managing defects is the most crucial thing for any organization to
do after they are discovered. This applies to the testing team as well
as to everyone else participating in the software development or
project management process.
● As we all know, defect prevention is an effective and efficient

technique to reduce the amount of defects. Defect prevention is

a very economical method for correcting flaws found in earlier phases

of software development.

● The majority of organizations handle Defect Discovery, Defect

Removal, and then Process Improvement through the

Defect Management Process.

As the name recommends, the Defect Management Process (DMP)

manages defects by purely detecting and resolving or fixing the faults.

The primary goals of the defect management process are to prevent

defects, identify defects at the earliest stages, and moderate the impact of

defects.
Given below are the various goals of this process:

● Prevent the Defect

● Early Detection
● Minimize the impact
● Resolution of the Defect
● Process improvement
Various Stages of Defect Management Process:

The defect management process includes several stages, which are as follows:

1. Discovery of Defect
2. Defect Categorization
3. Fixing of Defect
4. Verification
5. Defect Closure
6. Defect Reports
Discovery:During the discovery phase, project teams must find as many faults as

possible before the end user does. A defect is said to be discovered and change to status

accepted when it is acknowledged and accepted by the developers.

The following phases have been including in the defect discovery stage:

● Discover defect

● Report a defect

● Accept Defect
Categorization:
Defect categorization assists software developers in prioritizing their tasks. This
means that developers can address the most important bugs first according to this
kind of priority.
Critical : Defects that must be corrected immediately because they may cause
significant damage to the product
High : Main features of the product are affected by the defect.
Medium :The problem causes only minor deviations from the product’s
specifications.
Low : The defect has very minor affect product operation.
Defect Resolution:In software testing, defect resolution is the process of correcting
defects step by step. The method of fixing a defect begins with assigning it to a
developer, who then schedules it for correction according to priority, fixes it, and then
sends a report of resolution to the test manager. This procedure makes it simple to
track and fix issues.

You can follow the following steps to fix the defect:

● Assign to a Developer
● Schedule fixing
● Fix the defect
● Report the resolution
Verification:

After the development team has fixed and reported the errors, the testing team

confirms that they have been fixed.

When the development team reported that they had previously rectified all the

assigned issues, your team would retest to check that these defects had been

addressed.
Closure:

Once a defect has been addressed and verified, its status is changed to

closed. If not, you must notify the development team to recheck the

defect.
Defect Reporting:

–In software testing, defect reporting is the process through which test managers write

and transmit defect reports to the management team for input on the defect

management process and the status of defects. The management team then reviews the

problem report and delivers feedback or additional assistance as needed. Defect

reporting facilitates clearer communication, detailed tracking, and explanation of

defects.

—The management board is entitled to know the status of the defects. To assist you

with this project, they must be familiar with the defect management procedure. In

order to receive feedback from them, you must inform them of the present defect status
Defect Life Cycle
Defect Life Cycle –
The bug has different states in the Life Cycle. The Life cycle of the bug can be
shown diagrammatically as follows:
Bug or defect life cycle includes following steps or status:

● New: When a defect is logged and posted for the first time. It’s state is
given as new.
● Assigned: After the tester has posted the bug, the lead of the tester
approves that the bug is genuine and he assigns the bug to
corresponding developer and the developer team. It’s state given as
assigned.
● Open: At this state the developer has started analyzing and
working on the defect fix.
● Fixed: When developer makes necessary code changes and verifies
the changes then he/she can make bug status as ‘Fixed’ and the bug
is passed to testing team.
● Pending retest: After fixing the defect the developer has given that
particular code for retesting to the tester. Here the testing is pending
on the testers end. Hence its status is pending retest.
● Retest: At this stage the tester do the retesting of the changed
code which developer has given to him to check whether the
defect got fixed or not.
● Verified: The tester tests the bug again after it got fixed by the
developer. If the bug is not present in the software, he approves
that the bug is fixed and changes the status to “verified”.
● Reopen: If the bug still exists even after the bug is fixed by the
developer, the tester changes the status to “reopened”. The bug
goes through the life cycle once again.
● Closed: Once the bug is fixed, it is tested by the tester. If the tester
feels that the bug no longer exists in the software, he changes the
status of the bug to “closed”. This state means that the bug is fixed,
tested and approved.
● Duplicate: If the bug is repeated twice or the two bugs mention the
same concept of the bug, then one bug status is changed to
“duplicate“.
● Rejected: If the developer feels that the bug is not genuine, he
rejects the bug. Then the state of the bug is changed to “rejected”.
● Deferred: The bug, changed to deferred state means the bug is
expected to be fixed in next releases. The reasons for changing the bug
to this state have many factors. Some of them are priority of the bug
may be low, lack of time for the release or the bug may not have major
effect on the software.
● Not a bug: The state given as “Not a bug” if there is no change in the
functionality of the application. For an example: If customer asks for
some change in the look and feel of the application like change of
colour of some text then it is not a bug but just some change in the look
of the application.
Defect Template/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
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.
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 Defects

Defects are found either by preplanned 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.
When Shell Oil followed the inspection process, they recorded the following results:

● For each staff-hour spent in the inspection process, ten hours were saved!
● More informal (and less effective) reviews saved as much time as they cost.
In other words, worst case (informal reviews) -- no extra cost, best case
(formal inspections) -- a 10-1 savings.
● Their defect removal efficiency with inspections was 95-97% versus roughly
60% for systems that did not use inspections.