Or, my users do perfectly reasonable things and certain combinations of those things have effects that I didn't predict or handle. So, I get bug reports.
Some of those bug reports consist of somebody screaming at me about what an idiot I am and how upset the user is without providing any actual information. Some of them provide some information but few specifics and, again, a lot of screaming. Some of them clearly describe the problem. If you didn't already know, those last ones are the ones most likely to get fixed. Not because they didn't say mean things to me, but simply because they gave me what I needed to find and fix the problem.
There are certain members of my beta test group whose reports get my immediate attention. When these people report something, I know it's real and I know they've put an effort into providing me with the straightest possible path to the bug and the subsequent fix. If you want to be on a developer's priority list, consider following these guidelines for reporting bugs.
Things to include
Subject
A brief description of the bug. The subject should allow the developer to quickly determine what area of the software is affected. This allows them to quickly assign the bug to the correct team member, and to group related bugs together. It also helps them to check out related issues and previously fixed bugs that might be affected by current work.A useful subject line: Crash when loading invoice form
A not-so-useful subject line: CRASH!!!!
Version
As much information as you can provide about which version of the software in which you saw the bug. This information is often available in the About box for the software.Example: Microsoft Word 2010 (14.0.6024.1000) SP1 MSO (14.0.6112.5000) (32 bit) as part of Microsoft Office Professional Plus 2010
Environment
Provide information about which version of which operating system you are using. Depending on the software about which you are reporting, you may also want to include information about your graphics card and driver, amount of RAM, etc.Description
A complete description of the bug. This should include as much detail as you can give as to what you were doing when the problem occurred. If the software has modes, tell the developers which mode you were in. If the problem occurred when you saved, tell the developers whether you used a keystroke like Ctrl-S, or clicked on a toolbar button, or selected Save from a dropdown menu. The developer may be dealing with millions of lines of code. All the things that you take for granted because you always do it a particular way are critical in helping a developer track down which part of their code is causing the trouble.A useful description: I was adding a new Invoice. I filled out the main Invoice information, then clicked in the Line Items table to add a new item. I filled out the Line Item fields and clicked back to the Invoice Date to make a change. My new Line Item disappeared.
A not-so-useful description: I tried to add a new line item and it disappeared.
Steps to Reproduce
Bug fixing gets a lot harder when you can't make it happen and you can't test whether it's gone. If you can give the developer exact steps they can follow to reproduce your problem, your issue will get fixed a lot faster.Useful steps to reproduce:
Open any document
Click the Page Layout tab
Select all the text by pressing Ctrl-A
Click the Columns button on the ribbon
Click Three
Crash
Not-so-useful steps to reproduce:
Select some text
Set it to use three columns
Crash
Things to Not Include
As developers, we understand that bugs can be frustrating, upsetting, and even scary. We don't like them either. However, if you want to rant, you should talk to Customer Service. Development's job is to identify and fix the problem. Anything that doesn't help us do that is just a distraction. Along those lines, there are some things you want to leave out of bug reports.
Jokes
We appreciate that you want to soften the blow and humor is a wonderful thing, but a developer deep in bug reports and source code is in a very literal place. It may take them three readings to figure out that you are joking and, if your joke implies a problem, they may have spent an hour trying to track it down before they figure out that you're kidding. Dry-as-dust technical information is the way to go.Emotional Content, Emphasis, and Essays
We understand that the bug you are reporting may have caused you significant frustration, wasted time, and worry. We're really sorry about that. We didn't write it that way on purpose to upset you. We want to fix it so it doesn't upset you or anyone else ever again. Wading through three paragraphs typed in all capital letters about how stupid we are and how much of your time we wasted just makes it harder for us to dig the actual problem out of what you are saying. We get that you want to vent to somebody but, if you want your bug fixed, the developers might not be your best choice of outlet.Most of the time, developers don't need to be convinced to fix a bug. We want to fix our bugs. When management or suchlike prevents us from fixing our bugs, we get very frustrated and gnaw on things. We are likely to understand why your bug is a problem simply by reading the description. We don't need an essay about why it's a problem if the program crashes when you try to put text in columns to understand why we should fix that. It's just more stuff we have to dig through to find the actual description of the bug.
No comments:
Post a Comment