Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Jan 28 '12 at 5:44

This question came from our site for professional and enthusiast programmers.

1  
I could understand voting for closing to programmers, but offtopic? Bug reports on a programmer's site?! –  ldigas Jan 27 '12 at 3:36
1  
Does it matter? They'll write bad bug reports anyway. What you typically need to do is communicate with the users somehow. –  David Thornley Feb 16 '12 at 15:25
    
@DavidThornley - We're in a kind of a specific industry. With most users I never communicate, or get those reports a few months later. Don't ask. –  ldigas Feb 16 '12 at 17:16
3  
Build the reporting mechanism into your application, so the user can click a button, add a comment, and have the appropriate state attached by the application. "Now, please click the location on the screeen where it is wrong"... –  user1249 May 18 '12 at 8:49
3  
Let me know if you find an answer. I'm having enough trouble getting useful bug reports from testers, never mind users. –  Kristof Provost May 18 '12 at 11:47
show 2 more comments

6 Answers

up vote 11 down vote accepted

The most effective way to get users to write decent and useful bug reports is

  1. to let them see their reports online...
    [System] Thanks for reporting, you can find status of your request here: ...
  2. ...along with the evaluation and comments from assigned engineer...
    [Engineer] Request rejected, for the following details are missing: ...
  3. ...with an option to edit / improve their report.
    [User] Requested details are added, please re-evaluate: ...

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.

  • Alternative options to above are 1) to arrange face-to-face learning sessions with users (yeah sure, especially when there are thousands of them spread across the globe). Or 2) explain them things by the phone ("look, if you could only see the crap you wrote at line 225..."). What else? Oh 3) by email, sure "in the mail you sent us two months ago, you mentioned... no not that email, you sent us five emails this day, three of them were with subject Re: blue button click, look at the second one, the one with 10Mb screen shot attached to it... what? you can't find it?"
share|improve this answer
add comment

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.

share|improve this answer
2  
Great answer. Succinct and communicative. I'm going to pilfer this going forward for explaining to people. –  Erik Dietrich May 18 '12 at 15:44
add comment

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.

share|improve this answer
    
I'll check it out ... –  ldigas Jan 27 '12 at 3:36
7  
I don't really understand why this got so many votes. The question is not "how to write a decent bug report?" but "how to get users to write a decent bug report". –  Tamás Szelei May 18 '12 at 8:45
6  
Those resources are mostly targeted at technical people. Also Mozilla is the organization that brought us Bugzilla. I'm not saying that Bugzilla is bad, but it's been made by engineers for engineers: It's really not an end-user tool at all. –  Joachim Sauer May 18 '12 at 8:45
3  
Have to agree with @fish. We can give our testers all the guidelines in the world - doesn't make them actually produce useful bug reports. And I'm talking about people who's job it is to report bugs - if we can't motivate them with guidelines we've got no hope at all with actual users. The only thing we found effective was actively closing "useless" bug reports as "not enough information" - they got the the message pretty quickly then. I don't advise it for external users though :-) –  HappyCat May 18 '12 at 11:36
2  
I'm not debating the usefulness of the post at all (quite good resources there, really) but this does not answer the question, and I think the voting policy is based on that (I might be wrong). –  Tamás Szelei May 18 '12 at 13:26
show 6 more comments

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.

share|improve this answer
add comment

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."

share|improve this answer
add comment

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.

share|improve this answer
    
I don't think the OP is saying they don't want to deal with users. I think the OP is saying that they can't really fix anything based on the bug report 'it crashed'. The OP wants a way to get the most of out of the users who are complaining, so that the OP can actually FIX the problem. –  Michael Kohne May 18 '12 at 11:40
    
My point is that if "it crashed" is what happens from the perspective of the user. When I take my car to a mechanic, he does not expect me to give him an expertly detailed diagnostic report of what is wrong - he asks me questions to help him use his expertise to diagnose the problem. For instance one visit my problem was "It stalls when its cold, but is ok when its hot", a few well considered questions (with yes no answers)later he was fairly sure (and turned out to be correct) it was a faulty thermometer. Our job is to ask the questions, framed to give yes not answers. –  mattnz May 18 '12 at 22:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.