Painless Bug Tracking
BA Forum Moderator
http://www.joelonsoftware.com/articles/fog0000000029.html
=====================================
"It's pretty easy to remember the rule for a good bug report. Every
good bug report needs exactly three things.
1. Steps to reproduce,
2. What you expected to see, and
3. What you saw instead.
Seems easy, right? Maybe not. As a programmer, people regularly assign
me bugs where they left out one piece or another.
If you don't tell me how to repro the bug, I probably will have no idea
what you are talking about. "The program crashed and left a smelly
turd-like object on the desk." That's nice, honey. I can't do anything
about it unless you tell me what you were doing. Now, I admit that
there are two cases where it's hard to get exact steps to repro.
Sometimes you just don't remember, or you're just transcribing a bug
from "the field." (By the way, why do they call it "the field"? Is it,
like, a field of rye or something? Anyway...) The other time it's OK
not to have repro steps is when the bug happens sometimes but not all
the time, but you should still provide repro steps, with a little
annotation that says that it doesn't happen too often. In these cases,
it's going to be really hard to find the bug, but we can try.
If you don't specify what you expected to see, I may not understand why
this is a bug. The splash screen has blood on it. So what? I cut my
fingers when I was coding it. What did you expect? Ah, you say that the
spec required no blood! Now I understand why you consider this a bug.
Part three. What you saw instead. If you don't tell me this, I don't
know what the bug is. That one is kind of obvious."
-excerpt from Joel on Software
Hope you get to read the entire article at the link above. He's a
pretty cool writer, ain't he?