Defect Report

 The variation in the expected and actual results is known as defects. A defect is an
error or a bug in the application.
 In other words, a defect is an error in coding or logic that causes a program to
malfunction or to produce incorrect/unexpected results.
 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 capable. They are not able
to deliver right software product.
Software Testing Defect
Tools Report

4.1 DEFECT LIFE CYCLE

 It ensures a quality of product which will reach the customer’s requirements. It is
important to understand the defect life cycle before moving to the workflow and
different states of the defect.
 Defect life cycle also known as Bug Life cycle is the journey of a defect cycle, 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.

Fig. 4.1: Defect/Bug Life Cycle

4.2
Software Testing Defect
Tools Report

 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.
 The actual workflow of a Defect Life Cycle with the help of a simple diagram as shown
in Fig. 4.1.
 Defect life cycle is a cycle in which a defect goes through during its lifetime. The defect
life cycle starts when defect is found and ends when a defect is closed, after ensuring
it’s not reproduced.
 Defect life cycle is the representation of the different states of a defect which it attains
at different levels during its lifetime.
 The defect/bug has following states in its life cycle:
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.

4.3
Software Testing Defect
Tools Report

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 is
changed to ‘Duplicate’ by the developer.
3. Deferred: If the developer feels that the defect is not of very important priority
and it can get fixed in the next releases or so in such a case, he can change the
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

 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. Fig. 4.2 shows
classification of defect.

Defect classification

Requirement Design defects Testing defects Coding defects

defects
System interface
Function Test Initialization
al defects environment defects
defects User interface defects
defects Database
Interfac Module defects Test tool defects related defects
e Test design
Algorithmic
defects
Fig. 4.2: Classification of Defects
 Let us see above defects in detail:
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:
(i) Functional defects are mainly about the functionalities present/absent in the
applications which are expected/not expected by the customer.
(ii) 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.4
Software Testing Defect
Tools Report

2. Design Defects:
 These defects generally refer to the way of design creation or its usage while creating a
software product.
 The customer may or may not be in a position to understand these defects, if
structures are not correct.
 They may be due to problems with design creation and implementation during SDLC
(Software Development Life Cycle).
 Design related defects may be classified as follows:
(i) Algorithmic defects may be introduced in a product if designs of various
decisions are not handled correctly.
(ii) Module interface defects are about communication problem between various
modules. If one module gives some parameters which are not recognized by
another, it creates module-interface defects.
(iii) 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.
(iv) 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.
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.
 Some coding defect are given below:
(i) 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.
(ii) Commenting/Documentation defects, coding also needs adequate commenting
to make it readable and maintainable in future.
(iii) 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. Testing Defects:
 These defects are introduced in an application due to wrong testing or defects in the
test artifacts leading to wrong testing.

4.5
Software Testing Defect
Tools Report

(i) 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.
(ii) 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.
(iii) 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, it
may lead to defects. Test environment may include operator training also.

4.3 WRITE DEFECT REPORT

 Reporting defects is an important step for an organization in software development

life cycle to establish capability of processes and for initiating corrective and
preventive actions along with corrections, if problems are found.
 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.
 A bug report in Software testing is a detailed document about bugs found in the
software application.
 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.
 Different software management tools offers defect templates, sometimes test case
template is extended as defect template.

4.6
 Software Testing Defect
Tools 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.
 The general sample defect template is shown in Fig. 4.3.
DEFECT REPORT

Defect ID : Defect Name :

Software/Project Name : Module Name : Version:
Tester : Date : Assigned To:
Severity : S1 S2 S3 S4 Priority: 1 2 3 4 Reproducible : Y/N
Title:
Description:

Resolution : Fixed / No-Reproducible Can't Fix / Deferred Won't Fix (Minor)

Date Resolved : Resolved By : Version :
Resolution Comment:

Retested By : Version Tested : Dated Tested :

Retest Comment :

Signatures :
Originator: Tested:
Programmer: Project Manager:
Marketing: Product Support:

Fig. 4.3: Sample Defect Template

4.7
Software Testing Defect
Tools Report

 Every defect has distinctive attributes in comparison to a test case. It defines the defect
in detail and also helps in identification/fixing and categorization of defect.
 Following are some of the attributes of a defect.
1. Defect ID is the unique identification number for the defect.
2. Defect Name is the name of the defect must explain the defect in brief, its nature
and type.
3. Project Name indicates the project for which the defect is found.
4. 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.
5. Phase Introduced gives information about when the defect has been added in the
application being developed.
6. Phase Found is the phase of the project when the defect is found is added here.
This is used to find defect leakage or stage contamination or stage containment.
7. Defect Type is the definition of defect type may be declared in test plan.
8. Severity is the definition of severity of the defect is declared in test plan.
Severity describes the impact of the defect on the application. Severities may be
critical, high, medium or low depending on the impact of a defect. Severity can be
defined as, “the degree of impact that a defect has on the development or
operation of a component or system.”
Classification of Defect Severity:
(i) Critical: The defect affects critical functionality or critical data. It does not
have a workaround. Example: Unsuccessful installation, complete failure of a
feature.
(ii) Major: The defect affects major functionality or major data. It has a
workaround but is not obvious and is difficult. Example: A feature is not
functional from one module but the task is doable if 10 complicated indirect
steps are followed in another module/s.
(iii) Minor: The defect affects minor functionality or non-critical data. It has an
easy workaround. Example: A minor feature that is not functional in one
module but the same task is easily doable from another module.
(iv) Trivial: The defect does not affect functionality or data. It does not even
need a workaround. It does not impact productivity or efficiency. It is
merely an inconvenience. Example: Petty layout discrepancies,
spelling/grammatical errors.

4.8
Software Testing Defect
Tools Report

Severity is also denoted as:

o S1 = Critical
o S2 = Major
o S3 = Minor
o S4 = Trivial
9. Priority is defined on the basis of how the project decides a schedule to take the
defects for fixing. Defect or Bug Priority indicates the importance or urgency of
fixing a defect. Though priority may be initially set by the Software Tester, it is
usually finalized by the Project/Product Manager.
Priority can be categorized into the following levels:
(i) High (P1): Must be fixed in any of the upcoming builds but should be included
in the release.
(ii) Medium (P2): May be fixed after the release / in the next release.
(iii) Low (P3): May or may not be fixed at all.
Priority is also denoted as P1 for high, P2 for Medium and P3 for low.
10. Summary of the defect shall tell in short about the defect, how many times it has
been reproduced and which browsers, operating system and environmental facts
have been used for reproducing it.
11. Defect Description is the detailed description of the defect including information
about the module in which Defect was found.
12. Status of a Defect is a dynamic field and it indicates the present status of the
defect. Typically, the status of the defect is 'open', 'resolved', 'closed', 'deferred' or
'reopened'.
13. Reported By/Reported On is information about the testers who found the effect
and date of finding defects are report in the defect report.
14. Version is the version of the application in which defect was found.
15. Date Raised is the date when the defect is raised.
16. Detected By is the name/ID of the tester who raised the defect.
17. Fixed By is the name/ID of the developer who fixed the defect.
18. Date Closed is the date when the defect is closed.
 Defect report varies from organization to organization. Here, we take another defect
report template.
 To prepare a concise and clear report of the bugs occurred during testing/debugging to
convey the performance report of an application, it is very necessary to present the
details in a manner that is easily comprehensible.
 Defect template is a very important part of the defect life cycle. Defect template is a
systematic document to arrange defect in easy to find manner.

4.9
Software Testing Defect
Tools Report

Example: Defect/Bug report for Facebook Login Page.

4.1
0
 With the help of defect attributes, defects easily customized and tracked. Here, are
some major attribute used in defect reports: