How to Write a Fully Effective Bug Report
Printed From: One Stop Testing
Category: Software Testing @ OneStopTesting
Forum Name: Bug Report @ OneStopTesting
Forum Discription: After Creating the Test Plan, Writing the Test Cases and using them, Finally We need to generate those Bug Reports which Proves that Testers are Good enough & most importantly Indispensable.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=4985
Printed Date: 29Dec2024 at 2:16pm
Topic: How to Write a Fully Effective Bug Report
Posted By: tanushree
Subject: How to Write a Fully Effective Bug Report
Date Posted: 04Mar2008 at 11:27pm
To write a fully effective report you must:
- Explain how to reproduce the problem - Analyze the error so you can describe it in a minimum number of steps.
- Write a report that is complete and easy to understand.
Write
bug reports immediately; the longer you wait between finding the
problem and reporting it, the more likely it is the description will be
incomplete, the problem not reproducible, or simply forgotten.
Writing
a one-line report summary (Bug's report title) is an art. You must
master it. Summaries help everyone quickly review outstanding problems
and find individual reports. The summary line is the most frequently
and carefully read part of the report. When a summary makes a problem
sound less severe than it is, managers are more likely to defer it.
Alternatively, if your summaries make problems sound more severe than
they are, you will gain a reputation for alarmism. Don't use the same
summary for two different reports, even if they are similar. The
summary line should describe only the problem, not the replication
steps. Don't run the summary into the description (Steps to reproduce)
as they will usually be printed independently of each other in reports.
Ideally
you should be able to write this clearly enough for a developer to
reproduce and fix the problem, and another QA engineer to verify the
fix without them having to go back to you, the author, for more
information. It is much better to over communicate in this field than
say too little. Of course it is ideal if the problem is reproducible
and you can write down those steps. But if you can't reproduce a bug,
and try and try and still can't reproduce it, admit it and write the
report anyway. A good programmer can often track down an irreproducible
problem from a careful description. For a good discussion on analyzing
problems and making them reproducible, see Chapter 5 of Testing
Computer Software by Cem Kaner.
The most controversial thing in
a bug report is often the bug Impacts: Low, Medium, High, and Urgent.
Report should show the priority which you, the bug submitter, believes
to be appropriate
|
|