Forgot your password?
typodupeerror
Bug

Ask Slashdot: How To Get Non-Developers To Send Meaningful Bug Reports? 360

Posted by Soulskill
from the it's-broken-just-fix-it dept.
DemonGenius writes "I'm in the midst of a major rollout of one of our primary internal applications at work and we have a beta version available for all the staff to use. The problem here is most of the staff don't know how to send reports meaningful enough to get us devs started on solving their problems without constant back and forth correspondence that wastes both developer time and theirs. Some common examples are: screenshots of the YSOD that don't include the page URL, scaled screenshots that are unreadable, the complaint that wants to be a bug report but is still just a complaint, etc. From the user's perspective, they just send an email, but that email registers in our tracking system. Any thoughts on how to get the non-devs sending us descriptive and/or meaningful reports? Does anyone here have an efficient and user-friendly bug tracking system/policy/standard at their workplace? How does it work?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To Get Non-Developers To Send Meaningful Bug Reports?

Comments Filter:
  • by jhoegl (638955) on Tuesday December 13, 2011 @11:11PM (#38365448)
    Make your software send it...

    You can not teach the world, so why try?
    • Was this really a question?

      Don't most of the apps you use have some means of reporting problems back to the developers when they crash or have errors?

      • by Grishnakh (216268)

        Wouldn't this depend a lot on the type of app, and also on the type of bugs you want information about?

        If it's a C++ app, then sure, having a built-in crash reporting mechanism shouldn't be that hard to build in. But what if it's a web app? Or some kind of low-level or embedded software?

        Judging by the question, it's probably not anything embedded, but web apps are pretty common these days, and crashing isn't even a problem with those, instead it's other problems. Or what if it's some kind of defect in th

        • by John Hasler (414242) on Wednesday December 14, 2011 @12:06AM (#38365872) Homepage

          Give them a "Report bug" clicky that brings up a form for them to fill out and which automatically extracts relevant information.

          • by Grishnakh (216268)

            Yeah, someone else said that farther down, and I think it's a good idea, especially since the asker said they were using a beta version, so a "report bug" button wouldn't be out of place on a testing version like that.

            • by Anonymous Coward on Wednesday December 14, 2011 @12:52AM (#38366172)

              Just make sure you ask a zillion questions about what version of video driver they have and if their path info is set correctly. You can never have too much information. Pop up long hexidecimal numbers numbers they have to enter, but can't copy or enter untill they close the popup. Make information that is only available to the developers mandatory.

          • by dj245 (732906) on Wednesday December 14, 2011 @02:57AM (#38366898) Homepage
            I use Problem Steps Recorder on Windows 7 to report problems to my IT department. If you have a problem which occurs when you do a certain thing, it can be a great tool. Especially on web-based software or forms.
            Just type "PSR" into a command prompt or Start->run. It's a great tool.
        • Re:Mod parent up! (Score:5, Informative)

          by Dyolf Knip (165446) on Wednesday December 14, 2011 @12:44AM (#38366106) Homepage

          > If it's a C++ app, then sure, having a built-in crash reporting mechanism shouldn't be that hard to build in

          That's precisely what I do. The default exception handling routine sends an email to me with the app, version, username, machine id, error description, call stack, and any useful data that that I saw fit to include while coding. It has saved me mountains of pain over the years, and also fuels my reputation as the all-seeing eye.

          • by Smallpond (221300) on Wednesday December 14, 2011 @09:00AM (#38368686) Homepage Journal

            > If it's a C++ app, then sure, having a built-in crash reporting mechanism shouldn't be that hard to build in

            That's precisely what I do. The default exception handling routine sends an email to me with the app, version, username, machine id, error description, call stack, and any useful data that that I saw fit to include while coding. It has saved me mountains of pain over the years, and also fuels my reputation as the all-seeing eye.

            I do much the same but include credit card information, mother's maiden name and social security number.

      • by jonbryce (703250)

        Bug reports are often "when I do this, it doesn't do what it is supposed to do (or what I would like it to do)" rather than crashes or error messages.

    • That's fine and all, and what I was going to suggest, but what happens when it's intermittent? What the hell exactly do you log? Do you have access to core dumps?

      The problem with trying to capture this kind of data is when there's no crash but it's doing something it's not supposed to. Worse yet, your user can't communicate what's wrong.

      • by Mr. McGibby (41471) on Tuesday December 13, 2011 @11:35PM (#38365636) Homepage Journal

        It's called a "report a bug" menu item that automatically compiles as much data as you can think of that might help, including making the user include a description of the bug. Also, there's nothing wrong with just going over to the coworkers desk and working it out. Or schedule a day with the users when you'll be in their "area" to address issues and watch for bugs.

        The reality is that most bugs *aren't* intermittent, and if you can fix all the bugs that aren't, then the intermittent ones tend to go away. The remaining stuff is tough to deal with, but certainly manageable.

      • by pthisis (27352)

        That's fine and all, and what I was going to suggest, but what happens when it's intermittent? What the hell exactly do you log? Do you have access to core dumps?
        You log every single exception or, from a core dump, stack trace, and all the local variables at the time it happens. And as you accumulate them, you get a sense for what more global info you need (in OP's case he mentions URLs--if it's a web app, the complete incoming request, including form variables and cookies and session info, is a no-brainer

    • by werdnapk (706357) on Tuesday December 13, 2011 @11:26PM (#38365556)
      Yes, a crash report can be sent by an application, but a non-crashing bug? If the bug isn't caught by tests (automated or manual) then the software won't know to send an issue like that, otherwise it wouldn't have been a bug in the first place.
      • Simple solution. (Score:5, Insightful)

        by khasim (1285) <brandioch.conner@gmail.com> on Tuesday December 13, 2011 @11:33PM (#38365624)

        From the question:

        I'm in the midst of a major rollout of one of our primary internal applications at work and we have a beta version available for all the staff to use.

        It's an internal app so just have the app log everything that the user does in that app.

        Then, when the user calls to say there is a problem, the dev team can pull the logs from that machine and recreate the exact sequence of events.

        And don't worry about the logs becoming too large. If the dev cannot figure that out then there are larger problems there.

        Also, have the app check the versions of the libraries and such in the OS.

      • by Slavik81 (1457219) on Tuesday December 13, 2011 @11:38PM (#38365668)

        Put 'report bug' as an option in the help menu. And make sure your bug-reporting mechanism is the best-tested portion of the entire piece of software.

      • Have your application send bugreports.
        If your application is coded in Delphi there is MadExcept: http://madshi.net/madExceptDescription.htm [madshi.net]

        Whenever my apps crash, hang/lockup or throw an exception, MadExcept steps in and the user will simply see:

        "This application had an unexpected error. Do you want to:"
        [SEND BUG REPORT] [CONTINUE] [CLOSE]

        When they chose send bug report, it asks for their name and email adress (minimum user incentive IMHO), asks what they where trying to do, and then asks them if the shown

    • by Anonymous Coward on Tuesday December 13, 2011 @11:34PM (#38365630)

      Make your software send it...
       

      I recommend call information, web history, and keystrokes. For more information check out carrieriq.com

    • Yup. Most applications are session oriented. At the point you encounter an error, you know all of the following crucial pieces of information:

      * the userid of the user (in case the error is role / security related)
      * the date/time of the error down to the second
      * the incoming request parameters that triggered the work that encountered your error
      * the error itself
      * which server executed the request (in case the code issue is server specific)

      The only thing missing is some information about the intent of

    • Re: (Score:2, Funny)

      by Narksos (1111317)

      Make your software send it...

      I recommend call information, web history, and keystrokes. For more information check out CarrierIQ [carrieriq.com]
      (this time I'm logged in)

    • by MBC1977 (978793)
      "Make your software send it..."

      And make sure you let your users know that it will send you this information; too many times people start screaming crazyiness like "spyware, malware, etc." without understanding what it is that the program is sending. So inform your users first.
  • Pray? (Score:4, Insightful)

    by mirix (1649853) on Tuesday December 13, 2011 @11:11PM (#38365450)

    Either that, or send them all to reeducation camps.

    Try not to stress about it, it's hopeless.

    • Re:Pray? (Score:5, Insightful)

      by moderatorrater (1095745) on Wednesday December 14, 2011 @12:20AM (#38365956)
      We've had success by making it very clear what information we need. We've given them the baseline information (username, account, environment, etc) that they have to send with every single bug, and we've made it clear that the steps they need to give us need to be something we can follow exactly and get the error every time.

      Obviously there are exceptions, and our user base includes people who are actually technical enough to exercise judgement over what we need, but for the most part it's just training and education. They can't know what information we need, so we need to tell them. It's a hard problem, but not unsolvable.
    • Re:Pray? (Score:4, Interesting)

      by rwven (663186) on Wednesday December 14, 2011 @12:31AM (#38366026)

      Definitely not hopeless. The main thing is that you have to set expectations. They will do what you let them do. If a bug report is inadequate, it's bounced with a request for more information, highlighting specifically what is needed.

      Our company has also instituted a layer of BA's that sit between the devs and the clients and have thankfully done a fantastic job of training the clients what they need to provide when they submit a bug report. Our BAs also know what we developers expect and nothing gets passed along to a dev until there's enough information to get started on it.

      It's also very important that if a client is just complaining, their complaint is either rejected due to lack of "whatever's missing" or it's turned into a new feature request.

      Even more important is letting the client know, with all due respect, that if they can't get you what you need, then they aren't going to get what they want. They need to understand that they can be wrong too, and all the arm waving and shouting in the world won't help if they don't give you what you need to do your job.

  • by Anonymous Coward on Tuesday December 13, 2011 @11:16PM (#38365474)

    A more pressing question is how to get developers to stop ignoring bug reports.

    • by jhoegl (638955) on Tuesday December 13, 2011 @11:42PM (#38365700)
      I laughed, because its true.

      I have ignored bugs, not because it doesnt need to be addressed, but because it is low priority.

      This is just how things work.
      • by jc42 (318812)

        I have ignored bugs, not because it doesnt need to be addressed, but because it is low priority.

        You have had priorities? Nearly every place I've worked, every problem (and every development task) is rated as top priority. That is, there's only one priority level ever used, which is logically equivalent to there being no priority ranking at all. The developers' natural reaction to this is to work on whatever seems most interesting at the moment. Some things then "fall through the cracks" for a very long time.

        How do you get people (customers, bosses, etc._ to prioritize things like bug reports as

        • by dcollins (135727)

          A lead engineer sets priorities.

        • by fizzup (788545)

          How do you get people (customers, bosses, etc._ to prioritize things like bug reports as anything other than "highest"?

          You say, as respectfully as you can muster, "This is your opportunity to provide input on the order in which the work should be done. If you don't prioritize then you let the developers decide what's important. After all we have to do the work in some sequence. We will do our best, but we can't prioritize as well as you can. Please help us to succeed. Can you identify the ten most important defects/use cases/whatever?"

          The first time you do this you will get some crazy priorities. At a very immature organiz

        • How do you get people (customers, bosses, etc._ to prioritize things like bug reports as anything other than "highest"?

          When I get in that kind of situation, where the managers aren't setting priorities (which happens, but is also a sign of a poorly run company), I try to do everything. When I can't, and someone comes with a new bug, I tell the person,

          "If I work on your project, it means Person Xs project will get delayed. Would you please go inform Person X of this fact?" If it is important enough to them, they will.

    • by WeirdAlchemy (2530168) on Wednesday December 14, 2011 @12:04AM (#38365858)
      This. In my experience, dealing with bugs is very much a two-way street. If you want users to submit better bug reports, you need to be responsive to them so that they feel like they're getting something out of it. Imagine yourself as a user who takes the time to prepare a nice bug report, then waits a month to see any progress. How much time are you going to spend on your next bug report? Either way you behave, it ends up as a feedback loop -- your choice whether it's a positive of negative one.
    • Re: (Score:2, Informative)

      by Anonymous Coward
      Sometimes bug reports are just feature requests. e.g.: a Thunderbird bug report [mozilla.org] is rapidly approaching its 10-year birthday because nobody at Mozilla thinks it's a bug, despite it operating contrary to most user expectations - and because it's behaving according to RFC definitions.
    • by DeBaas (470886) on Wednesday December 14, 2011 @06:11AM (#38367744) Homepage

      A more pressing question is how to get developers to stop ignoring bug reports.

      You'd be surprised how much proper bug reports have to do with developers solving your issues quickly in stead of ingore it.

      I'm a test manager and new testers in my team are trained to to follow strict rules for bug reporting. I find proper bug reports possibly more important deliverables then test plans and test reports.
      Since we started adhering to strict rules the developers started to handle our issues much faster as well as much better. Not only are they much more inclined to help you if you take the effort to make proper report, but also they have to spend _much_ less time on it. I've once calculated that a bad report can esaily cost more then 8 times the time it would have cost. And also they often otherwise fix the wrong thing. Why does it take so much more time? Because they first waste time to find out what's wrong, then they contact a designer, who does the same, wasting more time. Then they contact you again and as you probably logged it days or weeks ago, you do the same again. And before you know it, something that takes 30 minutes to fix caused 10 hours in work.
      If you're the only doing it right, you may see your developers picking yours up asap as the cherries.

      Basic rules for reporting:
      - always provide steps performed (bulleted!)
      - always provide expected result
      - always provide actual result + the base for expecting this (i.e. see design page x or this is not right because...).
      - if not plain obviuos explain why actual result is not correct
      - alway provide test data used (i.e. username, customername, results such as logs xml messages)

      If applicable (nearly always)
      - provide a screenshot

      NEVER:
      - never try to their work and tell the developer things like: the code is probably wrong so and so or the database should do this and that. Describe the behaviour, not the cause. The biggest problem with this is that they may take you seriously and could fix it in the wrong place. They are better suited to determine what the cause is for certain behaviour.

  • by Anonymous Coward

    For Windows developers at least, there is one spectacular piece of the OS to make use of for bug reports. Mini-dumps. So awesome I wish Linux had an equivalent. Makes finding bugs much easier when you can load a mini-dump and break into it with a debugger. Best of all you don't have to host your own server to cache those dumps, Microsoft will do it for you as long as your copy of Visual Studio is legit.

    • by Grishnakh (216268)

      This isn't quite at the same level, but the KDE desktop environment does have an automated crash reporting system that'll send bug reports to the devs when a KDE app crashes. Obviously, the problem here is that it only works in KDE, and with KDE apps, but it's a start. Due to the nature of Linux, having a whole-system crash-reporting mechanism would be quite a project, as the reporting program would need some way of deciding where to send each report, or there'd have to be a central server it sends all re

  • Listen (Score:5, Interesting)

    by Moof123 (1292134) on Tuesday December 13, 2011 @11:20PM (#38365500)

    Seriously, don't just keep blowing off the important user bugs for multiple release cycles. Once your bugs have been blown off for 6 months you stop submitting new ones.

    • by Sez Zero (586611)
      Listen is great advice. You can really save yourself a lot of time by going to see the bug reporter in person. While not always practical, it does increase your visibility and karma with your cow-orkers.
  • YSOD? (Score:3, Informative)

    by Anonymous Coward on Tuesday December 13, 2011 @11:21PM (#38365514)

    So it is an ASP.NET app? Seriously, override application_error in the global.asax, and just send the emails with detailed error dumps and messages straight to you, in real time.

    • So it is an ASP.NET app? Seriously, override application_error in the global.asax, and just send the emails with detailed error dumps and messages straight to you, in real time.

      Also, you should look into over-riding other "events" in the global.asax to help with general reporting of app usage while in alpha and beta phase. (also, do you guys have a senior developer, pretty ridiculous you have to ask slashdot this...)

  • by jet_silver (27654) on Tuesday December 13, 2011 @11:21PM (#38365516)

    and find out what you think might be wrong, instead of what is wrong.

    Engage the users. It's your problem, not theirs.

  • by YrWrstNtmr (564987) on Tuesday December 13, 2011 @11:23PM (#38365534)
    General users cannot and will not grasp the finer points of how you need the information. About all you can do is
    1. Ask them to resend, but with specific directions
    or 2. some sort of screen sharing application - "Ok, show me exactly what you were doing when..."
  • by mattack2 (1165421) on Tuesday December 13, 2011 @11:26PM (#38365568)

    I admittedly didn't read the full thread so far, and I know at least some of this was covered.

    But have either a web site or a bug reporting facility in your app filled with a template that the user can fill out. Something like:

    Brief description of problem:

    Steps to reproduce the problem:

    What you saw:
    include crash logs, snapshots, etc

    What you expected to see:

    Severity: Crash/UI/Performance/etc..

    Version of app/configuration info (filled in AUTOMATICALLY if possible).

    and of course do NOT make them fill in every single field (if it's not reproducible, they won't have exact steps.. but you might be able to narrow down on the problem with multiple different bug reports).

    Personally, I hate these templates in our bug system, and cmd-A, and type over them, since I already know what kind of info to put in.. but it is useful for regular users (or even developers, if there are special steps, like special debugging tools for your specific app/tools).

  • by Anonymous Coward on Tuesday December 13, 2011 @11:30PM (#38365600)

    I've had success by educating a small group of business users to serve as triagers of bug reports - it's a lot easier to have them enforce your rules about what a validated bug looks like, particularly when you've armed them with a template to check against (example - without a screenshot including a URL, time of incident, browers/OS, the report gets sent right back at them) or have them validate the issue on their own before an engineer even looks at it. Eventually the business users get good enough to aggregate incidents together to locate true bugs and also can shoulder some of the prioritization burden. Remember that its in their rational best interest to care about software quality even if they can't speak about it in a sophisticated way.

    We have also posted examples of good bug reports and a wall of shame for bad ones - if you can get incentives together (or punish those that resist reeducation) that helps too.

    • This is great, and exactly what one organization I once worked for did. We had "business liaison" positions within every department, and "application owners", which were dual roles - these people were generally business users, with extra training so that they could work effectively to bridge between IT and the userbase. As part of these dual roles, they were included in the IT decisionmaking and change control process, so that they knew what was up before it happened, rather than finding out afterwards, and

  • Since I've seen QA people do stuff like that. (And not put down the steps they did to produce the bug in the first place. Hell, I've seen QA not get the difference between a bug and a feature request.)
    • Sometimes that's because the difference between a defect and a feature request is only identified by the requirements document that was never given to QA in the first place. But yeah, it happens sometimes.

      • Well to make things worse we give them the document on what it's supposed to support. (And then they ignore that and ask for features.)
  • Give up while you're ahead. Getting useful diagnostic information from someone trained in the art of programming can be a trial in of itself; from someone not trained in the art, it's all but impossible.

    If anything, make your software grab all relevant information.

  • "The computer is acting funny."
    Which computer? Do you think it's a comedian? Is it here to amuse you?
  • A system that I've used in the past, that sometimes works, would be to have the users fill out a "checklist" of items/questions when submitting the email. Trouble Url? Error recieved? Complaint or problem? Etc etc. If you know the user base and this is provided up front, it may help with some of that. But that assumes the checklist is viable for them to fill out as well as making the questions answerable and usable from both their and the developers perspective.
  • YSOD? (Score:4, Insightful)

    by Mattwolf7 (633112) on Tuesday December 13, 2011 @11:55PM (#38365798)
    YSOD? Maybe you need to be more clear to your users. I don't know what YSOD is and I work in the industry... Make sure your users understand what a bug report is, and how it helps to give as much information as possible. Avoid using terms they won't understand, and assume they don't know what you want. Some users will try to help if you tell them what you need, but give up if they feel like they have to figure it out on their own.
    • My god. We have some dufus complaining about lack of "meaningful" bug reports who bemoans lack of a sufficient YSOD screen capture.

      And he complains about others not being meaningful? You got to be kidding me. Google tells me the PC kiddies call this Yellow Screen of Death.

      This guy is complaining that when his program blows up the user it blew up on didn't do a good enough screen capture for him?

      wow. Slashdot must pay a bounty for dumb questions to drive traffic.

  • We use JIRA and follow a general template (description of problem, steps to reproduce, users impacted/business impact, severity). Tickets submitted under a few different main project areas go to the respective SME for triage (follow-up, prioritization, reassignment to engineering). Speaking as one of the non-devs but with some prior QA experience, it seems to work just fine.
  • A thingy that taught me how to send bug reports was the template in Bugzilla. Just a pre-filled piece of text in the submission form:

    Summary:
    Description:

    Steps to reproduce:
    1.
    2.
    3...
    Expected Results:
    Actual Results:
    Additional informations:

  • One of the fundamental techniques of process improvement (regardless of which flavor) is learning to ask the right questions.

    The problem here is most of the staff don't know how to send reports meaningful enough to get us devs started on solving their problems without constant back and forth correspondence that wastes both developer time and theirs.

    It sounds like the actual problem is that the software does not meet the needs of the users (and presumably the organization). This is where you ask "why" recursively at least 5 levels deep to figure out what is actually going on before you assume that the problem is a lack of proper bug reporting. It may turn out that something more fundamental needs to be fixed first which makes the

  • Give them a checklist of information you want. When they give you a bad bug report tell them exactly information you want. You want them be specific, so be specific about what you want.
  • coaching (Score:5, Informative)

    by KevMar (471257) on Wednesday December 14, 2011 @12:14AM (#38365916) Homepage Journal

    You have to coach them. They don't really understand what you need.

    When I get a email from someone about a bug, I go meet with them. I ask them all the questions I think may be relevant. What were they doing, how were they doing it. Were there any extra small steps or actions that jump out. Sometimes I explain why I'm asking certain questions and relate them back to previous bugs or issues.

    I think what you need is someone to be the go between. Get a tester to receive those emails, recreate the issue, then file a bug report. Don't allow the end user to file bug reports directly into your system. It will mess with your tracking data. A high number of worthless bug reports closed quickly may look good in the reports but does not help anyone.

  • If it is a commercial product, present reasons why there is more money to be made by fixing the issue you raise.

    .
    If it is an open source product, it is not so easy....

    - some projects require you to appeal to the egos of the developers. This is a losing proposition, as their egos are far larger than you can imagine.(the Linux kernel comes to mind)

    - some projects require you to navigate a maze of problem reporting pages. These projects have lost their compass.

    - some projects require you to show techni

  • by gratuitous_arp (1650741) on Wednesday December 14, 2011 @12:20AM (#38365954)

    You haven't told us anything about what you've done to educate the staff about writing up defects. Have you done anything? Unless they also work as technical QAs, they almost certainly have no idea what is expected in a defect report.

    I'm surprised that the primary problem doesn't have to do with listing ambiguous steps to reproduce a defect. For example, "I went to the page again" vs "I clicked the link again" vs "I closed the browser, reopened it, entered the URL, and then clicked the link on the page again."

    Of the 3 things you mentioned (#1: screenshots of the YSOD that don't include the page URL, #2: scaled screenshots that are unreadable, #3: the complaint that wants to be a bug report but is still just a complaint), the first two sound like *you* are complaining -- if they're not technical people and they don't know how your system works or what you need to see in order to diagnose a problem, then the first two issues should have been expected.

    How do you solve #1 and #2? If you're asking users to perform rudimentary QA, you're going to have to work with them. So, the solution to the first two problems is for you to realize you need to help out in these situations, explain what was wrong and what they can do to fix it next time. They don't know what you need in advance. Progress will be incremental but sure. And if they have to do all this in addition to their other tasks, then be nice while you're doing it.

    How do you solve #3? First, if people are complaining then make sure you're not overreacting to a real usability issue and ignoring it because it's not in the format you wanted. Then mail a template with a description field, a steps to reproduce field, an expected results field, and an actual results field, with a description of what each one is. Have a meeting explaining how to use it. Give examples, especially highlighting the need for detailed and unambiguous steps to reproduce.

    As bad as e-mail is for tracking issues, if this is a short term thing it may be the best approach. If you can see this going on, getting away from e-mail is a very good idea. Having recently been through a issue tracking system transition, getting everyone used to the new systems took some time even though it was handled very well (and not by me).

  • Even better set up something that will automatically configure my system with all the debugging tools. Give me scripts that allow me to easily compile and run older versions to find where a regression occurs.

    Unscrew gdb so I don't have to know arcane crap just to get it to give the backtrace you need.

    Once I have that and some minimal instructions on how to generate the reports I will.

    Don't have a pissy fit when I ask you how to do stuff that you need done.

  • Programming is black magic voodoo to just about anyone who isn't a programmer and they think that we're wizards with keyboards who can solve any bug with the most vague instructions.

    Ask them for precise, numbered, step-by-step instructions on how to get to the point where you will see the exact problem they are seeing (don't bother shortening that phrase to "replicating the problem", they won't know what you're asking). You will likely need to ask them several times. Make sure they know that you need t
    • by rubycodez (864176)
      only the dumb-ass users think that. those with a little more brains know we are the cause of the problem. After puking a windows full of cryptic nonsense in their face (Error code upi53up3i4u53UPIU Context asl;fdg qpt4 -q3 tu Stack Trace Follows......), you think they want a long talk with the cylon skin-job who deals with that jibberish. hell no....
    • ... it's otherwise like going to a mechanic and saying, "my car is broken, fix it", if you need to.

      I suspect that this analogy will NOT have the effect you're going for...

  • The subject sounds offtopic, but seriously, a clear, natural, everyday usage of the scientific method to solve problems would make your average user be capable of sending meaningful bug reports,because they would understand how problems are solved in the most general sense. They would realize that in order to diagnose where a problem is coming from, all of the possible sources of that problem must be independently tested in a controlled way. Doing that by nature makes for naturally good bug reports.
  • So, really, two things come to mind:
    1.) In whatever bug reporting mechanism you have (which should be easy to access in a 'help' menu or a hyperlink that's easy to reach or whatever, provide directions that give people an idea of what a bug report should contain. How long should it be? What type of information is most relevant? Etc. If this is a company-internal application, generally your users will have more incentive to help you than many other applications you could be using, so they'll maybe even
  • by spongman (182339)

    if you're getting YSOD's you should NuGet Elmah [google.com]

  • by Greyfox (87712)
    Only sell your software to developers.
  • When your body has a bug to report (pain), you call the doctor. What does the doctor do?
    - Ask where it hurts.
    - Ask when the problem started.
    - Ask about other symptoms that might be occurring.
    - Run some diagnostic tests.
    The fact is, you're never going to get meaningful bug reports from non-technical people, any more than patients are going to report detailed symptoms and vital signs, complete with test results, to their doctor. That's the doctor's job, and diagnosing software problems is your job.
  • For bug reports, I wrote a tool that takes a screenshot, dumps the contents of every control in every open window as well as a bunch of crap from the registry, packages it all up in an email that it pops open, with all sorts of stuff pre-filled out and the cursor ends up at the end of a line that says "The problem I experienced was: " They type a couple of lines and click send. Done.

    They have complaints that aren't bugs? No they don't. Their complaints ARE bugs... just not software bugs. They are bugs in pr
  • by Bob9113 (14996) on Wednesday December 14, 2011 @02:29AM (#38366750) Homepage

    I have seen several good ideas in this thread already. Here is another that may be useful.

    Try to find a way to associate the outcome the user is hoping for with the behavior that you are trying to engender. The user is hoping for their problem to be resolved quickly. The behavior you want to engender is a complete, yet concise, description of the problem and the steps to reproduce it. Make the connection between the former and the latter in the user's mind, and you'll have a self-motivated convert.

    When you get a clear and concise report, be sure to thank the submitter and help them realize that the clarity and brevity made it easier to solve the problem. They'll feel good about it, and you might even be one of the few on the tech side to have ever said, "thank you" to that particular end user. (we can be an ornery lot)

    When you get an incomplete or vague report and have to ask the user for more information, be sure to explain that a more clear bug report will make it easier for you to solve their problem quickly in the future. Make sure it comes across as, "I want to solve your problem more quickly in the future", not, "You did it wrong."

    When you get a rambling, nitpicky, or pure-complaint report, you'll have to use a bit more judgment to figure out how to guide the person for future reference, but you can usually find a way if you think about it.

    Really it's just programming -- most end users don't exactly have a complicated UI. Be nice, help them understand how satisfying your needs will benefit them, they'll do it. A nice bonus is that they'll be better end users for every subsequent support person, and they will feel good about doing it.

Mommy, what happens to your files when you die?

Working...