How to Report a Software Defect

As a software engineer, I've had the pleasure of receiving bug reports that make no sense whatsoever, and asking for additional info leads to dead ends and frustration.

I really like what Joel recommends should be on a good bug report:
  1. Steps to reproduce,
  2. What you expected to see, and
  3. What you saw instead.

But I have a couple of points to add, since in my experience people skip the basics:
  1. First and foremost, test it again to make sure that it is a valid bug.
  2. Specify what is not working, and where I can find it in the program.
  3. Avoid non-standard abbreviations.
  4. Proofread the bug report before submitting it to the resolver for any ambiguous information.

As I started to write this post I thought I was very clear on what I was going to write and what I wanted exactly to be in a bug report, but, as I kept typing I started to remember all those pesky bug reports that annoyed me because they take forever to research and solve (especially the ones that end up being no-bugs).

If you think I missed any other required piece of information, comment!

Comments

Popular posts from this blog

Failing

I am going to write daily

The Apple Effect