Mr Ed.: Testers: Are they Vegetable or Mineral?.
Well, uhm, umpf. Ahem. Of course, from a software developers point of view, the answer is: “Yes.”
Great post by Mr. Ed. I would like to elaborate a few points:
Omitting Screen Shots
It’s not about screen-shots per se, it’s about getting a snapshot of the systems state when the bug was noticed. In a desktop environment, that’s obviously a test document created with your application (plus any support files). Otherwise 9 out of 10, the developers won’t be able to reproduce the bug which causes lots of frustration. Plus it wastes valuable engineering resources.
Diagnosing Instead of Reporting
Refrain from wondering why the bug was introduced in the first place. Don’t give hints on how to resolve the bug (“You should refrain from dereferenceing a null-pointer”).
Don’t include phrases like “should be easy to fix” or “will only take 5minutes” in your bug reports. There are no easy fixes. The last easy-fix I heard about was seen in Tasmania in the late 1930s.
Bugs & Features
Carefully distinguish between bug and feature request. Especially if you’re an engineer testing software.
Last but not least: Don’t write bug-reports when being stressed-out. Beware of your language after having discovered a bug while being at the wrong time in the wrong place.