4.
4 Defect Template
Defect report is probably primary work product for most of the software testers.
Good bug report is informative & understandable. Weak reports generate
extra work for everyone.
Defect reports are used to alert software programmers about the defect &
give them sufficient information to find root cause & fix the problem.
A good defect report might have following sections:
1) Severity: It indicates how bad the bug is, the likelihood and the degree of
impact when the user encounters the bug.
1. System crash, data loss, data corruption.
2. Operational error, wrong result, loss of functionality.
3. Minor problem, misspelling, IJI layout, rare occurrence.
2) Priority: It indicates how much emphasis should be placed on fixing the bug
and the urgency of making the fix.
Levels are:
Immediate fix, blocks further testing, very visible.
Must fix before the product is released.
Should fix when time permits.
Would like to fix but the product can be released as it is.
3) Headline: One line description of the defect. Remember a good headline will
always be clear, related to the defect & give some hints on how critical defect
could be.
4) Product: In most cases defect tracking system is used for more than one
product. So specifying appropriate product & version is very important.
5) Component: Products are normally very complex & can be divided into
components. A defect report containing proper information about component
can help managers in assigning it to appropriate person.
6) Defect Type: Defect type could be functionality, specification, regression, IJI,
etc. This classification can be used to analyze how defects are distributed in the
system.
7) Environment: Proper information about your test execution environment
should be present. eg. Database, platform, etc.
8) Steps: All the steps should be specified clearly. You should not assumed
that programmer will understand this.
9) Attachments: Whatever additional information is needed for the defect,
should also be attached.
10) Comments: If you have any additional comments on the defect, you should
specify early.
Example
Name of Reporter:
Email ld of Reporter:
Version or Build: <Version or Build of the product>
Module or component: <mention here the name of tested module or
component>
Platform I Operating System:
Type of error: <coding error/ design error/ suggestion /UI/ documentation /
text error/ hardware error >
Priority:
Severity:
Status:
Assigned to:
Summary:
Description: <mention here the steps to reproduce, expected result and actual
result>
4.5 Estimate Expected Impact of Defect
• Defect Impact means degree of impact on the development or
operation of a component or system is called defect impact.
Once the critical risk are identified, the financial impact of each risk
should be estimated.
This can be done by assessing the impact, in dollars, if the risk
does become a problem combined with the probability that the
risk will become problem.
• The product of these two numbers is the expected impact of the
risk. The expected impact of a risk (E) is calculated as;
E=P*I,
where: P= probability of the risk becoming a problem and
I=Impact in dollars if the risk becomes a problem.
• Once the expected impact of each risk is identified, the risks
should be prioritized by the expected impact and the degree to
which the expected impact can be reduced. While guess work
will constitute a major role in producing these numbers,
precision is not important.
Techniques For Finding Defect:
Defects are found either by pre planned activities
specifically intended to uncover defects (eg. Quality control
activities such as inspection, testing, etc.) or by accident (e.g.
user in production). Following are the different techniques used
in finding defects:
• Static Techniques:
Testing that is done without physically
executing a program or system. A code review is an example
of static testing techniques.
• Dynamic Techniques: Testing in which system components
are physically executed to identify defects. Execution of test
case is an example of dynamic testing techniques.
• Operational Techniques: When the software system product
is completed it produces deliverables of the user, customer or
control personnel. While using the final software product the
defect is found & software is not working or fails.
4.6 Reporting A Defect
It is essential that you report defects effectively so that
time & effort is not unnecessarily wasted in trying to understand
& reproduce the defect.
Following are some guidelines for making bug reports:
• Be Specific: Specify the exact action: Do not say something
which adds confusion. In case of multiple paths, mention the
exact path you followed.
• Be Detailed: Provide more information. i.e. do not be lazy.
• Be Objective: Do not make subjective statements like "This
is lousy applications" or "You fixed it real bad".
• Reproduce the defect: Do not be impatient & file a defect
report as soon as you uncover a defect. Replicate it at least
once more to be sure.
• Review the report: Do not submit as soon as you write the
report. Review it at least once.
