I'm guessing there are some users here who are either new to testing
or to using testing / issue tracking software, so I thought I'd post
some tips from Elementool.com on how to build an effective bug
tracking report. Is there anything else to add?
Issue tracking software can be extremely useful in QA testing and bug
tracking, but only if it's used correctly. Generating issue reports
is
a major component of issue tracking software, and one main reason that
managers choose to implement a tool, so having the
correct information in these reports is essential.
The first report of an issue lifecycle is the most critical one. It
is
this first report that everything else in the issue's history is
built
upon. For this reason, everyone involved in development and QA should
understand the three main components of an initial issue report.
First: how to get to, or where to find, the issue. This piece should
explain to anyone reading the report, how to see the bug, and it
should be extremely detailed. A team member who may be unfamiliar
with
the issue should be able to experience the bug by reading and
following these directions. How are you going to fix an issue if you
can't find it?
Second: what should have happened if the bug wasn't present. This too
should be detailed; it's obviously important to explain the desired
action, so you and your team knows when the issue has been
successfully resolved.
Third: what occurred because this issue was present. This piece
should
explain what effect the bug had and how it changed the program. This,
again, should be detailed. If the issue tracking team knows exactly
what the issue is doing, or what chain reactions it's causing, they
can figure out the best way to fix it.
Make sure that all three essential elements are included in each
report, and you can ensure
that you're playing an effective role in handling bugs in your
company's software system.
http://www.elementool.com/contact/articles/Issue_Tracking_Report.html
Best,
Beth, from Elementool
www.elementool.com