Does anyone know a good way to get users to write a semi-decent (read: useful) bug report?
We wanted to put up something that would make sense to most users (be easy to read and understand), yet give useful information to developers as well.
It does not work when I click the blue button! Ahhh, I just lost a week's work ... make it work.
isn't very useful, as it is.
I started to fix about a list, but thought to check up with you guys, whether a similar method already exists.
In my opinion, what's more important is using the bug to establish meaningful on going contact with the user. Writing and understanding bug reports is a skill, and my advice would to be to make it as easy as possible for the user to make first contact, then progressively make their feedback of more value as needed.
For example, just get the user's email, and give them a plain-text field with the following text to complete:
"I did _____ , and expected ______ to happen, but ______ happened instead."
After you get the email, do an auto-reply to get a double-opt to confirm they submitted the bug, you've received it, and follow-up on the bug is okay.
The most effective way to get users to write decent and useful bug reports is
I would go as far as to claim that it's the only effective way.
Let's face it, skill to write bug reports effectively comes only with experience. One needs to learn to gain experience. Learning involves practicing, getting feedback and improving.
User-editable online bug reports are the most efficient way to teach users improve.
You might consider taking some ideas from Mozilla and Sun on this topic:
Particularly (from the Mozilla "How to Write a Proper Bug" page):
General Outline of a Bug Report
Summary: How would you describe the bug in less than 60 characters? It should quickly and uniquely identify a bug report as well as explain the problem, not your suggested solution.
Good: “Cancelling a File Copy dialog crashes File Manager”
Bad: “Software crashes”
Bad: “Browser should work with my web site”
Component: In which sub-part of the software does it exist?This field is a requirement to submit any bug report. Click the word “Component” to see a description of each component. If none seems appropriate, highlight the “General” component.
OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)Example: “If you know the bug happens on more than one type of operating system, choose “All”. If your OS isn’t listed, choose Other”.
Description: The details of your problem report, including:
-Overview: This is a larger detailed restatement of the summary. An example would be: “Drag-selecting any page crashes Mac builds in the NSGetFactory function”.
-Build Id: To find this either go to the “about:” page via the location bar or, if you have MozQA’s Nightly Tester Tools extension, then go to Tools | Nightly Tester Tools and select the option that contains the output of the build Id. It should look something like this: “Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3″.
-Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable). It should look something like this: “Doesn’t Occur On Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20081107 Firefox/3.1b2″.
Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. If they’re necessary, make sure to include any special setup steps.A good example of this would look like the following: 1) View any web page. (I used the default sample page, http://www.google.com/). 2) Drag-select the page. Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser’s content region to the bottom of the browser’s content region.
Actual Results: What the application did after performing the above steps.An example would be: The application crashed.
Expected Results: What the application should have done, were the bug not present.An example would be: The window should scroll downwards. Scrolled content should be selected. Or, at least, the application should not crash.
There is How to Report Bugs Effectively by Simon Tatham. It does explain things nicely, to make it easy to understand for less experienced users. However the downside is that it is quite a bit of text. When you have a user trying to report an issue but failing at explaining it you will usually not be able to convince him to read all this.
You can ask easy to understand and easy to answer questions to users to expect useful reports.
For example, "What was your last action before this error?", "Did you try to ... just before this error?".
No user would write you a bug report like : "My video driver is not uptodate. Your graphics library might not be compatible with old graphic drivers."
Assuming the user base is end users who have had a problem with the software you wrote....
It's not your users job to become a proficient Software Engineer or Testing professional, and you should not expect them to. Your users are average people who rightly expect the the software to "just work". When it doesn't, they will report whatever they think they heed to to get your attention. You cannot change that, and should not attempt to. Any attempt to insist on the kind of reports a professional is expected to make will result in the loss of the bug report, and the customer - "I had a problem with that software, but instead of helping me, they made be fill in all sorts of useless forms that mean nothing and have no value to me. I'll go find some software that actually works.".
i.e. It's not their job.....
If you want good bug reports, employ professionals to find your bugs. If you, as a software developer, can't be bothered dealing with customers, employ someone who can.
