Scribd
Upload
5 views6 pages

Ste Chap4

The document outlines the essential components of a good defect report, including severity, priority, and detailed descriptions to aid programmers in identifying and fixing issues. It also discusses the importance of estimating the expected impact of defects and techniques for finding them, such as static and dynamic testing. Effective reporting guidelines emphasize specificity, detail, objectivity, and the need to reproduce defects before submission.

Uploaded by

atharvchavan0911
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views6 pages

Ste Chap4

The document outlines the essential components of a good defect report, including severity, priority, and detailed descriptions to aid programmers in identifying and fixing issues. It also discusses the importance of estimating the expected impact of defects and techniques for finding them, such as static and dynamic testing. Effective reporting guidelines emphasize specificity, detail, objectivity, and the need to reproduce defects before submission.

Uploaded by

atharvchavan0911
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

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.

You might also like