Chapter – 5 Art of Defects Reporting

Certificate in Software Testing Skill

Page 1 of 28
 Confidentiality Statement

This document should not be carried outside the physical and virtual boundaries of TCS and
its client work locations. Sharing this document with any person other than a TCS associate
would tantamount to violation of confidentiality agreement signed by you while joining
TCS.

Notice
The information given in this course material is merely for reference. Certain third party
terminologies or matter that may be appearing in the course are used only for contextual
identification and explanation, without an intention to infringe.
Certificate in Software Testing Skill TCS Business Domain Academy

Contents
Chapter-5 Art of Defects Reporting ................................................................................4
5.1 Defect and its Classification ................................................................................... 5
5.2 Defect life cycle and Management....................................................................... 12
5.3 Defect Report ...................................................................................................... 16
Summary ........................................................................................................................ 25
References ...................................................................................................................... 27

Page 3 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Chapter-5 Art of Defects Reporting

Introduction
A software bug or defect is an error, flaw, failure, fault, or mistakes in a computer program
that avoids it from behaving as planned. Most of defects raised due to mistake and error
make during coding and design phase of software development life cycle

Learning Objective
After reading this chapter, you will be able to understand:
• What is Defect
• Defect Classification
• Common types of defects
• Defect Age
• Defect Life Cycle
• Defect Management
• Defect Tracking and Reporting
• Defect Reporting Characteristic
• Effective Defect Reporting Need
• Effective Defect Reporting
• Art of Defect Reporting
• Effective Defect Abstract
• Defect Reporting Usages

Page 4 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

5.1 Defect and its Classification

5.1.1 Defect Overview

A Software bug/defect is a condition in a software product which does not meet a software
requirement as specified in the requirement specifications or end use expectations, which
may not be specified but are practical.

In other words, a software bug or defect is an error, flaw, failure, fault, or mistakes in a
computer program that avoids it from behaving as intended (means producing an incorrect
or unexpected result).

Bugs are the gaps between the expected behaviour and the actual behaviours of the
application or system. Bugs arise from the verification and validation of the programming
products like Software Requirement Specifications, Test Specifications & code. Most bugs
arise from mistakes and errors made by people in either its design or programs source code
or, and a few are caused by compilers producing improper code. Defect can be prevented
from introducing during development by adopting right programming technique, software
development methodologies and peer reviews and Code Analysis. A program that contains
a large number of bugs that seriously affect with its functionality is said to be buggy
program.

5.1.2 Defect Classification

Defect classification of software defect based on severity to show the degree of negative
impact on the quality of software.

As per ISTQB Definition, defect severity is the degree of impact that a defects has on the
development or operation of a component or system.
Software defects are generally classified as per
• Severity / Impact
• Priority / Urgency
• Probability / Visibility
• Related dimensions of Quality
• Related Component / Module
• Phase detected
• Phase Injected

Page 5 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Severity / Impact

Defect classification of software defect based on severity to show the degree of negative
impact on the quality of software.

As per ISTQB Definition, defect severity is the degree of impact that a defects has on the
development or operation of a component or system.

The actual terms, and their meaning, can differ depending on people, organizations,
projects or defect tracking tools, but the following is a generally accepted classification.
The classification based on Severity are as follows
• Critical (S1): The defect affects critical functionality or critical data. It ensures not
have a workaround. For Example: Unsuccessful installation, complete failure of a
feature.
• Major (S2): The defect affects major data or major functionality. It has a
workaround but is not obvious and is difficult. For Example: A feature is not
functional from one module but the task is achievable if numbers of complicated
indirect steps are followed in another module/s.
• Minor (S3): The defect affects minor functionality or non-critical data. It has an easy
workaround. For Example: A minor feature that is not functional in one of module
but the same task is easily achievable from another module.
• Trivial (S4): The defect does not affect functionality or data. It does not even need a
workaround. It does not influence productivity or efficiency. It is just an
inconvenience. For Example: Petty layout discrepancies, spelling or grammatical
errors.

The following Figure 1 summarises the defect classification based on Severity

Page 6 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Figure 1 Defect Classification based on Severity

Priority / Urgency

Defect/Bug Priority indicates the importance or urgency of fixing a defect. Bugs Priority
may be initially set by the software tester; it is generally finalized by the Project/Product
Manager.

Defects Priority can be categorized into the following levels:

• Urgent - The defect must be fixed immediately because the defect is affecting the
application or the product strongly and the product cannot be used until it has been
fixed.
• High: The defect needs to be fixed as soon as possible. Further testing might not be
possible or meaningful unless this is fixed.
• Medium: The defect needs to be fixed at the earliest opportunity available. The
defect might be an obstacle for testing a section of the system. However, the
testing of the rest of the system is not severely handicapped by this defect. The
defect should be fixed in the subsequent builds.
• Low: The defect might be affecting only a minor section of the application and/or
overall testing is not severely affected by this. This defect can be fixed after the
critical ones are fixed

Page 7 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Probability / Visibility

Defect Probability/Defect Visibility/Bug Probability/Bug Visibility indicates the chance of a

user encountering the defect / bug.
• High: - Encountered by all or nearly all the users of the feature.
• Medium: - Encountered by around 50 % of the users of the feature.
• Low: - Encountered by very few or nearly no users of the feature.

Defect Probability can also be represented in percentage (%). The measure of visibility
/probability is with respect to the usage of a feature and not for the overall software. Hence
a defect in a hardly used feature can have a high probability if the bug is easily met by users
of the feature. Similarly, a defect in a widely used feature can have a low probability if the
users rarely detect it.

Related Dimension of Quality

Software Quality has several dimensions and below are some of among them
• Accessibility: - Degree to which software can be used easily by a wide variety of
people, including those who require assistive technologies for example voice
recognition or screen magnifiers.
• Compatibility: - Suitability of software for use in different environments like
different Browsers, Operating Systems etc.
• Concurrency: - Ability of software to deal with multiple requests to the same
resources at the same time.
• Efficiency: - Ability of software to perform well or reach a result without wasted
energy, resources, effort, money or time.
• Functionality: - Ability of software to carry out the functions as stated or desired.
• Install-ability: - Ability of software to be installed in an identified environment.
• Localizability: - Ability of software used in different languages, time zones etc.
• Maintainability: - Comfort with which software can be modified (adding new
features, enhancing features, fixing bugs, etc.)
• Performance: - Speed at which software performs under a specific load.
• Portability: - Ability of software to be transferred effortlessly from one location to
another.

Page 8 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

• Reliability: - Ability of software to perform a required function under stated

conditions for stated period of time without any errors.
• Scalability: - Measure of software’s ability to increase or decrease in performance in
response to changes in software’s processing demands.
• Security: - Protection of software against unauthorized access, invasion of privacy, ,
loss of data ,theft etc.
• Testability: - Ability of software to be easily tested.
• Usability: - Degree of software’s ease of use.

Related Module / Component

Related Module / Component indicate the module or component of the software where the
bug was detected. This provides information on which module / component is risky or
buggy.
• Module / Component A
• Module / Component B
• Module / Component C and so on

Phase Detected

Phase detected specifies the phase in the software development lifecycle (SDLC) where the
defect was identified.
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

Phase Injected

Phase Injected specifies the phase in the software development lifecycle where the defect
was introduced. Phase Injected is always prior in the software development lifecycle than
the Phase detected. Phase Injected can be known only after an appropriate root cause
analysis of the defect.
• Requirements Development
• High Level Design

Page 9 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

• Detailed Design
• Coding
• Build/Deployment

5.1.3 Common types of Defect

Following are the common types of defects/bugs that occurs during SDLC development
phase
• Conceptual error (code is correctly written, but the programmer really intended it to
do something else)
• Division by zero
• Use of the wrong operator, such as performing assignment in place of equality test
• Null pointer dereference
• Infinite loops and infinite recursion
• Using an uninitialized variable
• Accessing memory not owned /access violation
• Buffer overflow, in which a program tries to store data past the end of an array.
• Deadlock
• Arithmetic overflow or underflow
• Comments out of date or incorrect. e.g. "returns an integer", "The following
function is defect-free"

5.1.4 Defect Age

Defect Age can be measures based on any of the following

• Time
• Phases
Defect Age (Based on time): Defect Age is the difference in time between the date a defect
is noticed and the current date (if the defect is still open state) or the date the defect was
fixed (if the defect is already fixed).where the defect detection means not just reported but
it confirmed and assigned and fixed means that the defect is verified and closed.
Dropped defects are not counted and the difference in time can be calculated in hours and
days. Normally, average age of all defects is calculated.

Figure 2 shows formula for calculating defect age based on time.

Page 10 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Figure 2 formula for calculating defect age based on time

Example
If a defect was detected on 01/01/2016 10:00:00 AM and closed on 01/04/201610:00:00 PM,
the defect age is 72 hours uses.
For determining the responsiveness of the development / testing team. Lesser the defect
age better the responsiveness.

Defect Age (Based on Phases): Defect Age (in Phases) is the difference in phases between
the defect injection phase and the defect detection phase. Where “defect injection” phase is
the phase in the software life cycle where the defect was introduced and defect detection
phase is the phase in the software life cycle where the defect was identified. Normally,
average of all defects is calculated.

Figure 3 shows the formula for calculating defect age based on phases

Figure 3: formula for calculating defect age based on phases

Example
Let’s assume the software life cycle has the following phases
• Requirements Development
• High-Level Design
• Detail Design
• Coding
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

Page 11 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

If a defect is identified in System Testing and the defect was introduced in Requirements
Development, the Defect Age is 6.

For assessing the effectiveness of each phase and any review/testing activities. Lesser the
age better the effectiveness.

5.2 Defect life cycle and Management

5.2.1 Defect Life Cycle

Defect Life Cycle is the stages that the defect or bug goes through from when it is first
reported until it is fixed and confirmed. Defect can arise in any of the Software Test Life
Cycle Phase. Defects arising from each phase should be logged and tracked to closure.

The defect life cycle should be based upon the custom needs of the project and the
communication methodology used in the project. The closing category should have ample
options so that it can be easily recorded what the reason for closing of bug is.

The possible closed categories may include the following

• Not an Issue
• Could not be reproduced
• Requirement changed
• Not related to this piece of code
• Verified
• Duplicated
• Not reproducible
• As designed
• Deferred
• Withdrawn
• No action required

Such a wide list of closed categories will help to identify how the closed issues reached the
closing stage.

The number of states that a defect goes through varies from project to project. Below
lifecycle, covers all possible states.

Page 12 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

• New: - When a new defect is logged and posted for the first time. It is assigned a
status “New”.
• Assign: - Once the bug is posted by the tester, the lead of the tester approves the
bug and assigns the bug to developer team.
• Open: - The developer starts analysing and works on the defect fix.
• Fixed: - When developer makes necessary code change and verifies the change, he
or she can make bug status as "Fixed."
• Pending for retest: -Once the defect is fixed the developer gives particular code for
retesting the code to the tester. Since the testing remains pending from the testers
end, the status assigned is "pending request.”
• Retest: - Tester does the retesting of the code at this stage to check whether the
defect is fixed by the developer or not and change the status to "Re-test.”
• Reopen: - If the bug persists even after the developer has fixed the bug, the tester
changes the status to "reopened". Once again the bug goes through the life cycle.
• Verified: - The tester re-tests the bug after it got fixed by the developer. If there is
no bug detected in the software, then the bug is fixed and the status assigned is
"verified."
• Closed: - If the bug is no longer exits then tester assign the status "Closed."
• Duplicate: If the defect is repeated twice or the defect corresponds the same
concept of the bug, the status is changed to "duplicate."
• Rejected: If the developer feels the defect is not a genuine defect than it changes
the defect to "rejected."
• Deferred: If the present bug is not of a prime priority and if it is expected to get
fixed in the next release, then status "Deferred" is assigned to such bugs.
• Not a bug: If it does not affect the functionality of the application then the status
assigned to a bug is "Not a bug".

Page 13 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Below Figure 4 shows Defect Life Cycle.

Figure 4 Defect Life Cycle

5.2.2 Defect Management

It is a common practice for software to be released with known bugs that are considered
non-critical. Testing may provide a statistically reliable estimate of the number of likely
defects / bugs remaining. Most big software projects maintain a list of "known bugs". This
list informs users about bugs that are not fixed in the current product release, or not fixed at
all, and often a workaround is offered additionally.
There are various reasons for such a list
• The developers often don't have time to fix all non-severe defects.
• The defect could be fixed in a new version or patch that is not yet released.
• The changes to the code required to fix the defect would be large, and would bring
with them the chance of introducing other bugs into the system.

Page 14 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

5.2.3 Defect logging & Tracking

Defect logging is a process of finding defects in the application under test (AUT) or product
by testing or recording feedback from customers and making new versions of the product
to fix the defects or the client’s feedback.

Defect tracking is a vital process in software engineering as complex & business critical
systems have hundreds of defects. One of the challenging factors is to managing,
evaluating and prioritizing these defects. The number of defects gets increased over a
period of time and to effectively manage them, defect tracking system is used to make the
task easier.

Defect tracking is a process of finding defects /bugs in a product (by inspection, testing or
logging feedback from customers), and making new versions of the product that fix the
defects.

Defects tracking is useful

• In correcting the software
• To predict the quality of the software
• To take preventive actions like training, establishing methods & procedures etc.
• To gather statistics used to develop defect expectations in upcoming applications
• To improve the software development process
• To reduce CoQ (CoQ = Preventive + Appraisal + Failure)

Stakeholders should be informed about

• Test Progress
• Software Quality

Defect tracking systems are computer database systems that store defects and help people
to manage them. Some third-party defect management tools available are as follows
• Rational Clear Quest
• Bugzilla
• HP Quality Center

Page 15 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Defects are tracked based on various parameters such as

• Defect Id.
• Severity
• Priority
• Created by
• Created Date
• Assigned to
• Resolved Date
• Resolved By
• Current Status

5.3 Defect Report

Writing a good defect/bug report goes in a way long in find and resolving the problem
quickly.
Below are list of element normally included in a bug report.
• Defect Identifier (Defect ID): It is very important in being able to refer to the defect
in the reports. In reporting tool normally a program generated unique number
which increments per defect log.
• Summary: Summery is a high level description of the defect and the identified
failure. It should be highlight of the defect\bug as this is what the developers or
reviewers want to see first in the bug report.
• Description: The description should clarify exactly the steps to take to reproduce
the defect, along with what the expected results were and what the outcome of the
test step was.
• Severity: The severity of the defect shows how sever the defect is in terms of
damaging to other systems, businesses, environment and lives of people,
depending on the nature of the application system.
• Priority: The priority determines how quickly the defect should be fixed. The
priority normally concerns the business importance such as impact on the project
and the likely success of the product in the marketplace. Priority is categorized into
Urgent (P1), High (P2), Medium (P3), and Low (P4).
• Defect status: This indicates defect state like open, fixed, closed, user error, design,
and so on.

Page 16 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

• Date and Time: The date & time that the defect happened or reported is also
important. This is normally useful when you want to search for defects that were
identified for a particular release of software or from when the testing phase
started.
• Version / Build of the Software under Test: This is also very important. In most
cases there are many versions of software; each version has many defect fixes and
more functionality and enhancements to the previous versions. Therefore it is
essential to note that which version of the software showed the failure that we are
reporting.
• Reported by: This is important because if we may need to refer to the person who
raised the defect. We have to know who to contact to if required.
• Person assigned to: This element of defects report indicates person assigned to
research and correct the defect.
• Related requirement: All features of the software application can be outlined to
respective requirements. Hence, when a failure/bug is observed, we can able to see
what requirements have been impacted and also can help in reducing duplicate
defect reports in that if we can identify the foundation requirement.
• Attachments / Evidence: Evidence of the failure should be took and submitted with
the defect report. This is a visual description of the description of the defect and
helps the reviewer and developer to better understand the defect.

5.3.1 Necessity of Effective Defect Reporting

Defect/Bug reports are among the very important deliverables to come out of test. They are
as significant as the test plan and will have more impact on the quality of the product than
other deliverables from test. It is worth the effort to learn how to write effective defect
reports.

Effective defect reports will

• Reduce the number of bug returned from development
• Improve the speed of getting bug fixes
• Improve the credibility of test
• Enhance teamwork between test and development

Page 17 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

5.3.2 Effective Defect Reporting

If there is a defect in the software, then that should be proved through a well-documented,
detailed description of the steps to reproduce the defects and in some cases screen shot of
the defect when it occurred. A good defect not only helps the developers to quickly identify
the problem but also help them to prioritize which defects to fix first. A good defect report
is the proof for a defect discovered.
• Determines the “Quality” of the tester.
• Increases the probability of more defects getting fixed.
• A critical work product which helps in process improvement and risk management.
• Characteristics of a good defect report are that it’s right to the point, lists all
appropriate information, and easy to understand.
• It is easier and logical to follow a pattern rather that write unorganized and
confusing reports.

Key points to ensure effectiveness of reporting

• Condense: - The comments must be brief and clear.
• Accurate: - Is it a bug or could it be user error or any misunderstanding, etc.?
• Neutralize: - means just the facts. No humour No emotion.
• Precise: - Explicitly, what is the problem?
• Isolate: - Means what has been done to isolate the problem?
• Generalize: - What has been done to understand how general the problem is?
• Re-create: - What are the essentials in triggering/re-creating this problem?
(environment, conditions, steps)
• Impact: - What is the impact to the client? What is the impact to test?
• Debug: - What does development need to make it easier to debug? (traces, logs,
dumps, immediate access, etc.)
• Evidence: - Which documentation will prove the existence of the error?

It is not just good technical writing skills that leads to effective defect reports. It is more
important to make sure that you have asked and answered the right questions. It is key to
make sure that you have covered the essential items that will be of most benefit to the
intended audience of the defect report.

Page 18 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Condense Reporting
Below are characteristic of Condense Reporting
• Say it clearly but briefly.
• Eliminate unnecessary wordiness.
• Don’t add in extraneous information.
• It is important that you include all relevant information, but make sure that the
information is relevant.
• In situations where it is unclear how to reproduce the problem or the understanding
of the problem is vague for whatever reason you will probably need to capture more
information.
• Keep in mind that irrelevant information can be just as problematic as too little
relevant information.

Table 1 Condense Reporting

Condense Example Defect Remark
Don’t I was setting up a test whose real intent was to detect memory
Suffers from TMI (Too errors. In the process I noticed a new GUI field that I was not
Much Information), most familiar with. I decided to exercise the new field. I tried many
of which is not helpful. boundary and error conditions that worked just fine. Finally, I
cleared the field of any data and attempted to advance to the
next screen, then the program amended. Several retries
revealed that anytime there is not any data for the "product
description" field you cannot advance to the next screen or
even exit or cancel without amending.
Do The "exit", "next", and "cancel" functions for the "Product
Information" screen amends when the "product description"
field is empty or blank.

Accurate Reporting
Make sure that what you are reporting is really a bug. You can lose credibility very quickly if
you get a reputation of reporting problems that turn out to be setup problems, user errors,
or misunderstandings of the product.

Page 19 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Before writing up the problem consider

• In all cases, but especially if the description is long, you need to summarize the
problem(s) at the beginning of the description.
• Don’t depend on an abstract in a different field of the defect report to be available
or used by everyone who reads the problem description.
• Don’t assume that others will draw the same conclusions that you do.
• Explicitly and precisely describe the problem rather than just giving a description of
what happened

There are always numerous influences that can affect the outcome of a test. Make sure that
you understand what these influences are and consider their role in the perceived bug you
are reporting. This is one area that quickly separates the experienced tester from the
novice. If you are unsure about the validity of the problem it may be wise to consult with an
experienced tester or developer prior to writing up the problem.

Neutralize Reporting
• State the problem objectively. Don’t try to use humour and don’t use emotionally
charged zingers.
• What you think is funny when you write the defect may not be interpreted as funny
by a developer who is working overtime and is stressed by deadlines.
• Emotional statements just create barriers to communication and teamwork.
• Even if the developers doubted you and returned your previous defect and now you
have proof that you are correct and they are wrong, just state the problem and the
additional information that will be helpful to the developer.
• In the long run this added bit of professionalism will gain you respect and credibility.
• Read over your problem description before submitting it and remove or restate
those comments that could be interpreted as being negative towards a person

Page 20 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Table 2 Neutralize Reporting

Neutralize Example - This example is a Defect Remark

response to a developer returning a
defect for more information and
requesting more details on what values
caused the problem.
Don’t As could have been determined from the
The first clause will probably be original defect with very little effort,
interpreted as a jab at the developer and function ABC does indeed abend with
adds no useful information. any negative value as input.
Do Function ABC abends with any negative
value. Examples of some values tested
include -1, -36, -32767.

Precise Reporting
The person reading the problem description should not have to be a detective to determine
what the problem is.

Right up front in the description, describe exactly what you perceive the problem to be
• In all cases, but especially if the description is long, you need to summarize the
problem(s) at the beginning of the description.
• Don’t depend on an abstract in a different field of the defect report to be available
or used by everyone who reads the problem description.
• Don’t assume that others will draw the same conclusions that you do.
• Explicitly and precisely describe the problem rather than just giving a description of
what happened
Table 3 Precise Reporting

Precise Example Defect Remark

Don’t Issuing a cancel print when job is in PRT state (job is
In this example, it is hard to tell if already in the printer and AS/400 is waiting to
the problem is 1) the twinax port not receive print complete from printer) causes the
timing out or 2) the printer not Twinax port to not time out. The printer never

Page 21 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

returning to ready or 3) the message returns to a READY state and indefinitely displays
on the op panel. "PRINTING IPDS FROM TRAY1" in the op-panel.

Do Canceling a job while it is printing causes the

Precede the description with a short printer to hang.
summary of exactly what you Issuing a cancel print when job is in PRT state (job is
perceive the problem to be. already in the printer and AS/400 is waiting to
receive print complete from printer) causes the
Twinax port to not time out. The printer never
returns to a READY state and indefinitely displays
"PRINTING IPDS FROM TRAY1" in the op-panel.

Isolate and Generalize Reporting

Isolate
• A tester should always invest some reasonable amount of effort into isolating the
problem.
• Try to find the shortest, simplest set of the steps required to isolating the problem.
• Ask yourself if anything external to the specific code being tested contributed to the
problem.
• For example, if you experience a hang or delay, could it have been due to a network
problem?
• If you are doing end-to-end testing can you tell which component along the way
had the failure?
• Are there some things you could do to help narrow down which component had the
failure?
• If your test has multiple input conditions, vary the inputs until you can find which
one with which values triggered the problem

Generalize
• Often times, the developers will fix exactly what you report, without even realizing
the problem is a more general problem that needs a more general fix.
• When you detect a problem, take reasonable steps to determine if it is more general
than is immediately obvious.

Page 22 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

5.3.3 Effective Defect Abstract

The short one line abstract that gets associated with most defects is a very powerful
communication tool. Often times, the abstract is the only portion of the defect that gets
read by the decision-makers. It is the abstract, not the full description that gets built-in in
reports. This is the abstract that the project managers, team leads, screeners and other
managers look at when trying to understand the bugs associated with the product. Abstract
Checklist Mandatory - Concisely, explicitly state what the problem is.
Recommended (Space Permitting)
• Use meaningful keywords.
• State environment and impact.
• Answer who, what, when, where, why, and how
• Ok to use abbreviations
• Grammar is secondary over conveying the message
• Don’t use defaults

For example, the following abstract is true but does not provide closely as much information
as it could. Abstract - Problems found when saving and restoring data member. Perhaps a
more descriptive abstract would be -Abstract - xyz’s save/restore of data member on
WinNT fails, data corrupted
You can never get everything you want in an abstract.

5.3.4 Defect Reporting Usages

Some of the applicable reports derived from the logged defects

• Defect Report
• Defect Aging Analysis Report
• Defect Arrival Rate Report (by severity/priority, component)

Some of the Metrics that are calculated from the logged defects
• Defects related to size of software.
• Severity of defects such as very important, important, and unimportant.
• Age of defects - the number of days the defect has been uncovered but not
corrected
• Defects uncovered in testing
• Cost to locate a defect

Page 23 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Page 24 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

Summary

• A Software bug/defect is a condition in a software product which does not meet a

software requirement as specified in the requirement specifications or end use
expectations, which may not be specified but are practical.
• Bugs are the gaps between the expected behaviour and the actual behaviours of the
application or system.
• Bugs arise from the verification and validation of the programming products like
Software Requirement Specifications, Test Specifications & code.
• Defect classification of software defect based on severity to show the degree of
negative impact on the quality of software.
• Defect severity is the degree of impact that a defects has on the development or
operation of a component or system.
• Defect/Bug Priority indicates the importance or urgency of fixing a defect.
• Defect Probability/Defect Visibility/Bug Probability/Bug Visibility indicates the
chance of a user encountering the defect / bug.
• Related Module / Component indicate the module or component of the software
where the bug was detected.
• Phase detected specifies the phase in the software development lifecycle (SDLC)
where the defect was identified
• Phase Injected specifies the phase in the software development lifecycle where the
defect was introduced.
• Defect Age is the difference in time between the date a defect is noticed and the
current date or the date the defect was fixed (if the defect is already fixed).where
the defect detection means not just reported but it confirmed and assigned and
fixed means that the defect is verified and closed.
• Defect Life Cycle is the stages that the defect or bug goes through from when it is
first reported until it is fixed and confirmed.
• The defect life cycle should be based upon the custom needs of the project and the
communication methodology used in the project.
• Testing may provide a statistically reliable estimate of the number of likely defects /
bugs remaining.
• Most big software projects maintain a list of "known bugs".

Page 25 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

• Defect logging is a process of finding defects in the application under test (AUT) or
product by testing or recording feedback from customers and making new versions
of the product to fix the defects or the client’s feedback.
• Defect tracking is a vital process in software engineering as complex & business
critical systems have hundreds of defects.
• Defect tracking is a process of finding defects /bugs in a product, and making new
versions of the product that fix the defects.
• Defect/Bug reports are among the very important deliverables to come out of test.

Page 26 of 28
Certificate in Software Testing Skill TCS Business Domain Academy

References

Go through below links for Additional Knowledge on various topics.

https://tcsltd.skillport.com/skillportfe/main.action#summary/VIDEOS/RW$116815:_ss_
video:97839 -- For Common Defects

More reference need to add

Page 27 of 28