Software Testing (AY 2024-25) Defect Management

UNIT 4: DEFECT MANAGEMENT

4.1 Defect Classification

Requirements and specification defect: Requirement defects arise in a product when one
fails to understand what is required by the customer. These defects may be due to customer
gap, where the customer is unable to define his requirements, or producer gap, where
developing team is not able to make a product as per requirements. Since any requirements
documents are written using natural language representation, there are very often occurrences
of contradictory, unclear, redundant and imprecise requirements.

Design Defects: Design defects occur when system components, interactions between system
components, interactions between the outside software/hardware, or users are incorrectly
designed. This covers in the design of algorithms, control, logic/ data elements, module
interface descriptions and external software/hardware/user interface descriptions. Design
defects generally refer to the way of design creation or its usage while creating a product. The
customer may or may not be in a position to understand these defects. They may be due to
problems with design creation and implementation during software development life cycle.

Coding Defects: Coding defects may arise when designs are implemented wrongly. If there
is absence of development/coding standards or if they are wrong, it may lead to coding
defects. Coding defects are derived from errors in implementing the code. These defects arise
when variables are not initialized properly. Some coding defects come from a failure to
understand programming language constructs. Coding also needs adequate commenting to
make it readable and maintainable in future.

Testing Defects: Testing defect are defects introduced in an application due to wrong testing,
or defects in the test artifact leading to wrong testing. In this defect includes:
1. Test-design defect: test-design defect refers to defects in test artifacts. There can be
defects in test plans, test scenarios, test cases and test data definition which can lead to defect
in software.
2. Test-environment defect: this defect may arise when test environment is not set properly.
Test environment may be comprised of hardware, software, simulator and people doing
testing.
3. Test-tool defects: any defects introduced by a test tool may be very difficult to find and
resolve, as one may have to find the defect using manual test as against automated tools.

ZEBA SYED Page 1

Software Testing (AY 2024-25) Defect Management

Defect Management Process

1. Defect Prevention: Implementation of techniques, methodology and standard

processes to reduce the risk of defects.

2. 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 baseline.

3. 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 member(s) responsible
for the component(s) in error.

4. Defect Resolution: Work by the development team to prioritize, schedule and fix a
defect, and document the resolution. This also includes notification back to the tester
to ensure that the resolution is verified.

5. Process Improvement: To identify ways to improve the process to prevent further

future occurrences of similar defects i.e. Corrective and preventive action is taken for
processes improvement.

6. Management Reporting: Analysis and reporting of defect information to assist

management with risk management, process improvement and project management.

ZEBA SYED Page 2

Software Testing (AY 2024-25) Defect Management

4.2 Defect Life Cycle

The different states of defect life cycle are as shown in the above diagram:
New: When the defect is posted for the first time, its state will be “NEW”. This means that
the defect is not yet approved.
Open: After a tester has posted a defect, the lead of the tester approves that the defect is
genuine and he changes the state as “OPEN”.
Assign: Once the lead changes the state as “OPEN”, he assigns the defect to corresponding
developer or developer team. The state of the defect now is changed to “ASSIGN”.
Test/Retest: Once the developer fixes the defect, he has to assign the defect to the testing
team for next round of testing. Before he releases the software with defect fixed, he changes
the state of defect to “TEST”. It specifies that the defect has been fixed and is released to
testing team. At this stage the tester re-tests the changed code which developer has given to
him to check whether the defect got fixed or not.
Deferred: The defect, changed to deferred state means the defect is expected to be fixed in
next releases. The reasons for changing the defect to this state have many factors. Some of
them are priority of the defect may be low, lack of time for the release or the defect may not
have major effect on the software.
Rejected: If the developer feels that the defect is not genuine, he rejects the defect. Then the
state of the defect is changed to “REJECTED”.
Verified: Once the defect is fixed and the status is changed to “TEST”, the tester tests the
defect. If the defect is not present in the software, he approves that the defect is fixed and
changes the status to “VERIFIED”.
Reopened: If the defect still exists even after the defect is fixed by the developer, the tester
changes the status to “REOPENED”. The defect traverses the life cycle once again.
Closed: Once the defect is fixed, it is tested by the tester. If the tester feels that the defect no
longer exists in the software, he changes the status of the defect to “CLOSED”. This state
means that the defect is fixed, tested and approved.

ZEBA SYED Page 3

Software Testing (AY 2024-25) Defect Management

Defect Template

ID Unique identifier given to the defect

Defect name Name of the defect
Project name Project name
Module name Specific module of the product where the defect was detected
Detected build Build version of the product where the defect was detected
version
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.
Steps to Step by step description of the way to reproduce the defect.
Replicate
Attachments Attach any additional information like screenshots and logs
Remark Any additional comments on the defect
Defect Severity Severity of the defect
Defect Priority Priority of the defect
Reported by The name of the person who reported the defect
Assigned to The name of the person who is assigned to fix the defect
Status The status of the defect
Fixed build Build version of the product where the defect was fixed
version

4.3 Techniques for finding defects

Techniques to find defects can be divided into following three categories:
1. Static Technique: Testing that is done without executing the program or system. A
code review, walkthrough, inspections etc. are the examples of static testing
technique.
2. Dynamic Technique: Testing in which system components are executed to identify
the defects. Execution of test cases is an example of a dynamic testing technique.
3. Operational Technique: 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.

Reporting a Defect
Following are some of the important points to be noted in defect reporting-
1. Give complete record of inconsistency:
Complete description of defect helps the tester and user to take preventive and corrective
actions about the defect.
Module leader and project manager must conduct complete analysis of how the defect
occurred and what was not done correctly.
Complete record description also helps in process improvement
2. Defect report forms the base for quality measurement:
Number of defects serves as a measure of software quality. It must define severity, priority
and category of defects.
More defects indicate that the software quality is not good, while fewer defects may not be
able to certify that the product as good.
Thus, defect report is helpful in deciding the quality of software.
**************

ZEBA SYED Page 4