A normal day, a normal bug

After fixing approx. 5 billion bugs (+/- 1 billion) in my life so far, I have a clear picture of how a bug ticket should be written to actually support the developer rather than wasting his time. Maybe this is the reason why I always get a bit mad when I read descriptions like

The form validation depends on the gender radiobuttons, which is not normal.

Normally

So, this raises the good old question: what is normal? Especially, what is normal when there are no requirements for the radiobuttons? Common sense? Whose common sense? Mine? The reporters?

By the way, the bug turned out to be a feature. Srsly.

When a ticket states that something is “not normal”, “not ok” or “totally wrong”, then it adds some sort of personal judgement. No developer is happy to receive a bug ticket, so they should be written as neutral as possible, as we already have to live with the shame.

The Minimum Information Strategy

One nasty bug I was once only able to reproduce by clicking a couple of buttons in exact the same order as the Project Manager – of course this was not part of the ticket description, so after trying to reproduce the issue for half an hour (the ticket going back and forth a couple of times meanwhile, and the tone was about to get rougher…), I gave up and asked the PM to share the screen.

Aha!

After being able to reproduce the bug, it was fixed in 5 minutes. So in total, the PM and I together lost over an hour because the ticket was missing information that could have been added to it in two minutes. Not to mention the bad mood you and others get in. And this sums up over lifetime.

Minimum – and I mean it

My favorite bug screenshot of all times:

error_occured_alert

I’m not kidding. Someone really made the effort to take a screenshot of the alert, cut it precisely to not contain any valuable information at all (Browser? URL? Any other screen context?) and attached it to a ticket (which was quite a pain with the clumsy ticket system we worked with back then).

Sure, the error message itself leaves, erm, room for improvement. However I’m always wondering why bug reporters cut the screenshots. Probably it’s fun. I should try it myself.

Common sense

So what can we developers do? Give up? No. Resist.

Every time you get a bug ticket which is not written well, assign it back and kindly ask for more information. You can’t reproduce the issue? Don’t waste your time, write back and ask for steps to reproduce please. The CSS is messed up, but the ticket only contains a small part of the actual screen and not even a browser version? Don’t let your hair turn grey, assign it back with a smile!

When searching the net on how to write bug reports, you’ll find that here there actually is some sort of common sense. Basically, you’ll find more or less the following structure:

  1. Bug title
    The bug description. Simple, concise, to the point. Not as simple as “Application broken”, however.
  2. Steps to reproduce
    Ah, my favorite. This could make life so much easier. I know it’s annoying to write, but often necessary. “Select a product and put it into the cart” is a nice start, but most likely this will not make the bug reproducable.
  3. Expected results
    What results did you expect, and why? Is there a user story, ticket or any other document which could be helpful?
  4. Actual results
    What results did you get? Point out what is happening in contrary to the expected results.
  5. Browser Info
    A classic. Which Browser did you use? Please also add the version number, especially when IE is still to be supported.
  6. Screenshots
    A screenshot is helpful. Just keep it as it is, i.e. don’t cut out anything. Especially the browser URL is very helpful, so just keep it. Dammit. Developers absolutely don’t mind if there is too much information on it. If a lot of stuff is happening on it, consider adding markers (e.g. arrows).
  7. Additional info
    Any error message could be helpful. Do you find an error in the browser console? Please just copy & paste it!

Please also see the article “Writing Issue Reports That Work” by Joe Strazzere, the man with the “I got the bug fixed in no time because of your wonderful bug ticket“-smile. Sums it up really nicely.

Thanks for reading & happy bug fixing!