So I got a bug report the other day, from our own staff member no-less, that simply said: "Can not 'submit fixes' in finalize screen."
Now let's think about this for a minute. Fixing bugs is very much like solving a crime. You are presented with a bunch of clues about what went wrong, and now you have to follow those clues down different avenues to piece together what went wrong (which is a very time consuming process to do right). But you have to do this, because you can only fix the bug when you understand why it exists.
So, now, if you were a police detective and someone called with the brief report "I found a dead body", would you be able to catch the murderer? You don't even know where the body was found to be able to start collecting crime scene data with your trained eyes. It would, thus, be an impossible case to solve with just the information provided from your well intentioned, possibly anonymous citizen.
So, then, how does the submitter of such a brief bug report expect me to solve their bug?
The Things You Need To Provide
For a bug to be successfully fixed, the developer has a few things the he needs to know.
Although it is very important to give your computer's specifications and the software version that threw the bug, it turns out that it is actually more important for you to supply the following information:
- What you were trying to do,
- What you were doing before the bug occurred,
- What you expected to happen when the bug occurred,
- What you expected to see when the bug occurred, and
- What you saw when the bug occurred,
Of course, just like a murder investigation, the more information you can take the time to give, the more likely a developer can fix your problem.
Remember that a developer has to be able to re-create the bug you saw in order to fix it, so if you don't give them enough information to make the same thing happen on their own computer, they will possibly just jump to the next bug in their bug list!
And Why You Should Give It To Them
Of course, the main reason why you should give all this information to them is because you want the bug to be fixed! But you should also realize that giving all of this information also saves both you and the developer time (and money in most instances).
For one, it usually takes you about the same amount of time to describe a bug up-front or after asked for details later, so being so brief doesn't actually save you any time in the long run.
By not giving the information up front, however, the developer loses quite a bit of time due to a bunch of small reasons, such as lost time in bug list triage, inability to group and collectively solve related bugs, and loss of time in having to contact users for details.
And, I'm not going to lie; commercial companies are driven by money. So if it is going to cost them money to get the details on a minor bug, they are likely to just bump it to the bottom of the list and go on to more important things. It sucks, it may even seem wrong, but I guarantee you every software company does it (and that you would do it too).
Last Words
If there is one last thing I want to impress upon you is that, despite all my harsh words for people that don't give details, having a bad bug report is still better than no bug report. We can't fix a problem we don't know about, and appreciate any information we can get. Just remember that it can be frustrating for everyone if you don't spend the extra two minutes of your life to give us some details.
1 comment:
It is certainly interesting for me to read this post. Thanks for it. I like such themes and anything connected to this matter. I would like to read more soon.
Post a Comment