I guess bad bug reports are something that every developer can relate to. Or someone who works in customer support. Be it tickets/reports from a customer, fellow developer, tester or first level support. The problem with bad bug reports is, that they cost time. Aside from (most) open source projects where people spend their precious free time, they also cost money.
In this article I’ll explain how bad bug reports waste time and money and how you can do better. So let’s start with a short explanation, how a bad bug report looks like.
How does a bad bug report look like?
One of the first things that come to my mind when thinking of an awful bug report is this:
“I tried to do <insert any functionality> but it didn’t work.”
Quite a good one right? There is no specific information about what exactly happened or how it didn’t work. Chances are, the developer opens that part of the application that he thinks could be affected and I guarantee, most of the time it will work on his machine. So what is the criteria for a bad bug report? Here’s examples that I think matter the most:
- Missing details
Like you can see in the example above it is hard to find or reproduce a bug if there is no information on what you did to find it.
- Missing log files / error messages
Error messages appear, log files are written but somehow people tend to forget to add them to the bug report.
- Combination of multiple bugs in one ticket
This is something I’ve dealt with a lot of times. People find multiple things that do not work and create one huge bug report for everything.
There are many points left that I could add to this list, but I think these are the most important ones to start with. Now let’s move on and have a look at what happens with those bad bug reports once you filed them.
Bad bug reports waste time and money
Another example: You filed a really awful bug report. Let’s say we’re talking about a contact management system:
“I tried to do add a new contact but it didn’t work.”
Now what happens on the other side of that ticket system? Chances are, someone opens the application at his computer and tries to add a contact. Also, chances are that it works on that persons machine. Now at least two things can happen:
- You instantly get the ticket back and they ask you for more information about what happened. (I would definitely do this to you)
- Someone is trying to find out what could possibly have been going wrong, trying out every thinkable possibility to reproduce the behaviour you found: A contact that couldn’t be added. Nobody knows if there is an error, or if it just does nothing. Or if the bug appeared when clicking onto “Add contact” or when saving after putting in all of the data. Most of the time this someone will not be able to reproduce the given behaviour, so you get the ticket assigned back and will be asked for more information about what happened.
Sending tickets back and forth costs time
Doesn’t matter how support or the developer react, both possible situations cost time. At first, someone has to start working on the ticket and do some basic analytics. Since you did not provide much information, there is much guessing involved. So support spends time working on that ticket until they decide to ask you for more information. It’s even possible that nobody will analyse anything and you get the ticket instantly back because of the lack of information.
Either way, now it’s your turn. Maybe you are annoyed now, because nobody fixed your bug and they want additional information. (Why don’t they just fix that damn bug, right?) Chances are that some hours or days passed since you filed the bug report and you can’t remember what you did. But nevertheless you have to provide some information, otherwise support can’t reproduce the bug which again means that the developers can’t fix it. So what do you do? You open the contact management system again and try to add that contact you wanted to add back then. Guess what, possibly it works now. And that would be the point where you wasted at least one persons time at the software company and in addition: your own.
But let’s assume you can reproduce the error, and you reopen the ticket. This time with more information. So again, someone reads through the ticket and tries to reproduce the error. In the best case it is reproducible with the information you provided. Many times it won’t be that easy. So they ask for even more information. Again, you have to find some more information to provide and the story goes on ….
Time is money. Don’t waste money.
This back and forth of the ticket takes some time. And each time someone in the support team gets that ticket, he or she has to re-read everything because they have worked at something completely different in the meantime. If they got a ticket with sufficient information, much of that overhead wouldn’t be there and they could handle one or two tickets a week more instead of taking the time to dive back into that ticket. Time that costs money for the software company.
But what about you? Since you get the ticket back every time you also have to spend a decent amount of time to provide the additional information that support asked for. If you’re a freelancer or own a business, you could do something else in that time. Something like earning money instead of putting in time that you don’t get paid for because you didn’t provide enough info. Even if you get paid because you are employed, you waste at least your employers money because you could work on something that earns them money.
You see where all of this leads to. You are annoyed and probably the support person is annoyed too. And on top of that, everyone looses money. But we don’t want to be annoyed or loose money, so let’s have a look at how we can avoid this.
How should a good bug report look like?
Upfront I want to say that there are many ways to write a good bug report. Depending on the product you want to file a bug for, there is a chance that there are templates for bug reports. If this is the case, follow along these templates. Provide all the information they asked for.
When there is no template to follow, you will do good by providing at least (!) this information:
- If available: Include the version information.
Sometimes the bug you’re going to report has already been fixed in a newer version.
- How to reproduce
Provide a step by step description how someone else can reproduce the behaviour you experienced.
- Expected behaviour
What behaviour did you expect when performing the steps you described in 2. ? This is necessary to eliminate the possibility that you just had a wrong expectation of the given functionality. Things like this happen. Imagine how awful it would be to realise that after three or four rounds of ticket-ping-pong.
- Observed behaviour
Describe how the application or framework behaved different to the expected behaviour. Here you can explain how anything didn’t work or which behaviour motivated you to file a bug report.
- If available: Include log files
This depends on the type of product. If you know where the log files are, send them. For some type of products it can be possible that you get some detailed information to find a log file. It could also be possible that you simply don’t have access to any log files, but then again they won’t ask for them.
Of course you can always provide more information like screenshots or code samples (if it’s a framework/library), but always try to provide the information mentioned in 2., 3., and 4. – it is essential to save a lot of time.
Today you learned about
- bad bug reports,
- that they can be costly in time and money.
- how to write a bug report that doesn’t suck
Some weeks ago, I saw a discussion on twitter regarding bad bug reports. Unfortunately I can’t remember who discussed it, but I want to share one sentence that sticks in my mind since then.
Bug reports are handled with the same effort you put in writing them.
Maybe you just keep this in mind the next time you are going to create a ticket somewhere. I definitely will.
PS: If you know who said that, I’m happy to give credit to him or her.
I hope this article provided some useful information and helped you to understand the importance of good bug reports a little bit better.
If you liked this article, have a look at one of my last articles on how I got into web development.
I’m always happy to get feedback, so if there is something you want to add or if you just want to chat, leave a comment at this page or contact me on Twitter.