4.

DEFECT
REPORT
4.0 INTRODUCTION
A software defect arises when the expected result don't
match with the actual results. It can also be error, flaw,
failure, or fault in a computer program.
The variation in the expected and actual results is known as
defects. A defect is an error or a bug in the application.
Defect can be defined as "an inconsistency in the behavior of
the software”
Root causes of defects are:
1. Requirements are not defined clearly by customer.
2. Designs are wrong and not implemented properly.
3. People are not trained for work in collecting requirements.
4. Processes used for product development, testing are not
Examples Of Defective
Statements
1. Accept user details on the registration form
2. Shape of a submit button is circular on one page and rectangular
on another page
3. Functional requirements are collected but non-functional
requirements are not collected
4. After requirement analysis, Feasibility study is skipped and
directly started with designing.
4.1 DEFECT LIFE CYCLE
Defect life cycle also known as Bug Life cycle is
the journey of a defect cycle, through which a defect
goes through during its lifetime.
It varies from organization to organization and also
from project to project as it is governed by the
software testing process and also depends upon the
tools used.
It is a cycle of defects from which it goes through
covering the different states in its entire life.
This starts as soon as any new defect is found by a tester and comes to an
end when a tester closes that defect assuring that it won't get reproduced
again.
1. New: Whenever any new defect is found in application, it is defined as a
"New" state, and validations and testing are performed on this defect in the
later stages of the Defect Life Cycle.
2. Assigned: Newly created defect is assigned to the development team to
work on the defect. This is assigned by the project lead or the manager of
the testing team to a developer. It's state is now defined as "assign“
3. Open: Developer analyzes the defect and works on it and fix it, if
required. If the developer feels that the defect is not appropriate then it may
get transferred to any of the below four states namely Duplicate, Deferred,
Rejected, or Not a Bug-based upon a specific reason.
4. Fixed: When the developer finishes the task of fixing a defect by making
the required changes then it is marked as "Fixed".
5. Pending Retest: After fixing the defect, the developer assigns the
defect to the tester to retest the defect at their end, and until the tester
works on retesting the defect, the state of the defect remains in "Pending
Retest".
6. Retest: At this point, the tester starts the task of retesting the defect to
verify if the defect is fixed accurately by the developer as per the
requirements or not.
7. Reopen: If any issue persists in the defect, then it will be assigned to the
developer again for testing and the status of the defect gets changed to
'Reopen".
8. Verified: If the tester does not find any issue in the defect after being
assigned to the developer for retesting and he feels that if the defect has
been fixed accurately then the status of the defect gets assigned to Verified.
9. Closed: When the defect does not exist any longer, then the tester
changes the status of the defect to "Closed". A few more state includes: .
1. Rejected: If the defect is not considered a genuine defect by
the developer then it is marked as "Rejected by the developer.
2. Duplicate: If the developer finds the defect as same as any
other defect or if the concept of the defect matches any other
defect then the status of the defect changed to 'Duplicate' by the
developer.
3. Deferred: If the developer feels that the defect is not very
important and it can get fixed in the next releases or so in such a
case, he can change status of the defect as 'Deferred.
4. Not a Bug: If the defect does not have an impact on the
functionality of the application, then the status of the defect gets
changed to "Not a Bug"
4.2 DEFECT CLASSIFICATION
1. Requirement Defects: These defects arise in a product when one fails
to understand what is required by the customer.
Requirement 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.
Requirement-related defects may be further classified as given below:
(A) Functional defects are mainly about the functionalities
present/absent in the applications which are expected/not expected by the
customer.
(B) Interface defects talk about various interfaces essential as per the
requirement statement. Generally, these defects may be due to user
interface problems, problems with connectivity to other systems
including hardware, etc.
4.2 DEFECT CLASSIFICATION
Defects may be a 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

Requirement
Design Defects Testing Defects Coding Defects
Defects
-System
-Test
interface -Initialization
-Functional environment
-User interface -Database
-Interface -Test tool
-Module related.
-test design
-Algorithmic
4.2 DEFECT CLASSIFICATION
2. Design Defects:
1. These defects generally refer to the way of design creation
or in usage while creating a software product.
2. The customer may or may not be in a position to
understand these defects, if structures are not correct.
3. They may be due to problems with design creation and
implementation during SDLC (Software Development Life
Cycle).
A)Algorithmic defects may be introduced in a product if
designs of various decisions are not handled correctly.
B) Module interface defects are about communication
problem between various modules. If one module gives some
parameters which are not recognized by another, it creates
4.2 DEFECT CLASSIFICATION

C)User interface defects may be a part of system

interface defects where the other system working
with the application is a human being. User-interface
defects may be a part of navigation, look and
feel type of defects which affect usability of an
application.
D)System interface defects may be generated
when application communication with environmental
factors is hampered. System may not be able to
recognize inputs coming from the environment
or may not be able to give outputs which can
be used by the environment.
4.2 DEFECT CLASSIFICATION
3. Coding Defects:
These 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.
A) Variable declaration/initialization defects arise when variables are not
initialized properly, or variables are not declared correctly. These types of
defects refer to wrong coding practices which may arise due to wrong standards of
development.
B) Commenting/Documentation defects, coding also needs adequate
commenting to make it readable and maintainable in future.
C)Database related defects may occur when a database is not created
appropriately or it is not optimized. It may be a part of design defects if
database design is wrong or it may be a coding defect if database is not
implemented correctly as per design.
4.2 DEFECT CLASSIFICATION
4. Testing defect:
A)Test design defects refer to defects in test artifacts. These can be
defects in test plans, test scenarios, test cases and test data
definition which can lead to defect Introduction in software if it is not
handled correctly.
B) Test tool defects generally, assumed that there are no defects in
a test tool. Any defect introduced by a test tool may be very difficult to
find and resolve, as one may have to find the defect using manual
tests as against automated tools.
C) Test environment defects may arise when test environment is not
set properly. Test environment may be comprised of hardware, software,
simulators and people doing testing. If test environment definition and
reality are mismatched may lead to defects. Test environment may
include operator training also.
4.3 WRITE DEFECT REPORT.
Defects reports provide information about defects that are related to a test
plan, the status of those defects, and trends in those defects over time.
A defect report describes defects in software and documentation. Defect
reports have a priority rating that indicates the impact the problem has on the
customer.
A defect report documents is an anomaly discovered during testing. 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.
4.3 WRITE DEFECT REPORT.
Defect/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
A good defect report should:
1. Give sufficient and high-quality information to reproduce and fix the defect
2. Be well written and simple to understand.
3. Enable stakeholders to make wise decisions about which defects to fix.
A defect report or defect template lists an anomaly discovered during testing.
Each and every organization must have a defect template which captures a defect data.
4.3 WRITE DEFECT REPORT.
A defect report includes all the information needed to reproduce the problem. including
the author, release/build number, open/close dates, problem area, problem description,
test environment, defect type, how it was detected, who detected it. priority, severity,
status, etc.
DEFECT ATTRIBUTES:
 Defect ID: Unique identification number for the defect.
 Defect Name: Name describing the defect, including its
nature and type.
 Project Name: The project where the defect is found.
 Module/Sub-module Name: The specific part of the project
where the defect occurred.
 Phase Introduced: When the defect was added during
development. (coding phase/ design phase/ integration phase)
 Phase Found: Phase of the project when the defect is
discovered (used for defect leakage analysis). Ex. Unit Testing
Phase/Maintainace phase/User testing Phase
DEFECT TYPES
 Categorized based on nature, priority, and severity, as declared in the test
plan.

Severity Classification:
 Critical: Severe impact causing crashes, data loss, or security issues.
 Major: Affects major functionality or data; requires urgent fixing.
 Minor: Affects minor functionality or non-critical data; easy workaround.
 Trivial: No impact on functionality or data; just an inconvenience.

Priority Levels:
 High (P1): Immediate fixing required due to severe impact on the application
(e.g., crashes, data loss, security vulnerabilities).
 Medium (P2): Fixed in the next release (e.g., non-critical formatting issues).
 Low (P3): May not be fixed at all (e.g., spelling mistakes).
DEFECT REPORT
INFORMATION:
Summary: Brief description of the defect with reproduction
details (e.g., browsers, OS used).
 Defect Description: Detailed explanation of the defect.
 Status: Indicates the defect's current state (open, resolved,
closed, etc.).
 Reported By/Reported On: Tester details and the date the
defect was reported.
 Version: Version of the application where the defect was found.
 Date Raised: Date the defect was reported.
 Detected By: Tester who raised the defect.
 Fixed By: Developer who fixed the defect.
 Date Closed: Date the defect was closed.
ASSIGNMENTS
WRITE DEFECT REPORT IN ABOVE
FORMAT
1. Incorrect total calculation in shopping
cart
2. Missing 'Forgot Password' link
3. Instagram Profile picture upload not
working