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 capable. They are not able to deliver right software
product.
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

• 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 interface
-Test environment
-Functional -User interface -Initialization
-Test tool
-Interface -Module -Database related.
-test design
-Algorithmic
 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

2. Design Defects:
• These defects generally refer to the way of design creation or in 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).
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 module-interface
defects.
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.
 4.3 WRITE DEFECT 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.
• Following are some of the attributes of a defect.
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

• Defect Type: Defects by its Nature, Software Defects by its Priority, Software Defects by its Severity

be declared in test plan.

6. 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:

(1) Critical: A critical defect is a software bug that has a severe or catastrophic consequence on the operation
of the application. Critical defects can cause the application to crash, freeze, or perform incorrectly. They can
also result in data loss or security vulnerabilities. Critical defects are often given the highest priority by
developers and testers because they need to be fixed as soon as possible.
Example: Unsuccessful installation, complete failure of a feature.

2. Major: The defect affects major functionality or major data.. Major defects can cause the application to
perform slow or exhibit other unexpected behaviours. It is not obvious and is difficult. Major defects are often
given a high priority by developers and testers because they need to be fixed as soon as possible.

Example: A feature is not functional from one module but the task is able to do if 10 complicated indirect steps
are followed in another module/s.
3. 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.

4.Trivial: The defect does not affect functionality or data. It does not impact productivity or
efficiency. It is merely an inconvenience.Trivial defects can cause the application to display an error
message or exhibit other unexpected behaviours Example: Petty layout discrepancies,
spelling/grammatical errors.
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:
A) High (P₁): High priority defects are those which have a high impact on the functioning of the software. In most cases, these
defects need to be fixed immediately, as they can cause major disruptions in the normal workflow. High priority defects are
usually classified as showstoppers, as they can prevent the user from proceeding further with the task at hand.
Some of the common examples of high priority defects include:
• Defects that cause the application to crash
• Defects that prevent the user from completing a task
• Defects that result in data loss or corruption
• Defects that expose sensitive information to unauthorized users
• Defects that allow unauthorized access to the system
• Defects that cause the loss of functionality
• Defects that result in incorrect results or inaccurate data
• Defects that cause performance issues, such as excessive memory usage or slow response times
• II. Medium (P₂): May be fixed after the release/ in the next release.

An application returning the expected result, which, however, formats incorrectly in a particular browser, is an
example of a medium-priority defect.

• III. Low (P₁): May or may not be fixed at all.

Eg. spelling mistakes, incorrect alignment,

• 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.