|
How to write a bug Report
One of the most important (and most common) things an SQA Engineer does is to write "bug reports". How
well you report a bug directly affects how likely the programmer is to fix it. You should spend a minimum of time
needed to describe a problem in a way that maximizes the probability that it will be fixed. The content and manner
of your reports affect that probability.
 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. Bug 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 priority: Low, Medium, High, and Urgent. Report should show the priority which you, the bug submitter, believes to be appropriate
and does not get changed.
Bug Report example...
QA Qualified Bugs
Bugs meeting the following qualifications:
Detailed Short and Long Descriptions including accurate steps to reproduce. (A bug with a Short Description such
as, "Tool crashes when you click on a button." may not be accepted unless details are specified in the
Long Description field with adequate steps to help a developer reproduce the problem.)
Environment to reproduce the bug is supported and can be recreated by QA. (Examples of such bugs may involve a
certain operating system/database version combinations or user load conditions (e.g. thousands of user logins simultaneously
which QA cannot recreate. In these circumstances the submitter may need to assist in verification.) Specific data
used to recreate the problem is provided. Third party software is available to reproduce the problem. (Usually,
bugs like this cannot be reproduced due to lack of knowledge by QA of particular third party software.)
|
