Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Soulskill on 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?"

22 of 360 comments (clear)

  1. Make it send data to you by jhoegl · · Score: 5, Insightful

    Make your software send it...

    You can not teach the world, so why try?

    1. Re:Make it send data to you by Anonymous Coward · · Score: 0, Insightful

      This. You kinda failed as a software engineer if you didn't see this coming. You can't rely on users to provide meaningful data on bugs.

    2. Re:Make it send data to you by Anonymous Coward · · Score: 5, Insightful

      Just gunna point out that I regularly have to post meaningful bug reports for a lot of the important software I (and probably you) use every day. I wouldn't say the people that made it failed.

      What they do get wrong is using the bug reporting systems like bugzilla. I look at the pages for those kinds of system and feel like I'm going to have a heart attack. And I'm the guy that could write it.

    3. Re:Make it send data to you by werdnapk · · Score: 5, Insightful

      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.

    4. Re:Make it send data to you by Mr.+McGibby · · Score: 3, Insightful

      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.

      --
      Mad Software: Rantings on Developing So
    5. Re:Make it send data to you by frisket · · Score: 4, Insightful
      Bug reporting systems aimed at developers should not be available to end users. They ask for (and expose) all kinds of irrelevant things that confuse the user.

      Instead, use a form that automatically picks up as much information as it can about the application, platform, and environment, and then asks what happened to make the user want to report it. Allow a screenshot to be attached (warning that unreadable shots can't be used). Don't try to gather information that the end user cannot be expected to know. By all means provide a link to a developer-oriented bug reporting system, for users who do know what they are doing, but for the end user Keep It Simple.

  2. Pray? by mirix · · Score: 3, Insightful

    Either that, or send them all to reeducation camps.

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

    --
    Sent from my PDP-11
    1. Re:Pray? by moderatorrater · · Score: 4, Insightful

      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.

  3. More pressing question by Anonymous Coward · · Score: 5, Insightful

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

    1. Re:More pressing question by jhoegl · · Score: 3, Insightful

      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.

    2. Re:More pressing question by WeirdAlchemy · · Score: 5, Insightful

      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.

  4. Make the users fill in a form... by jet_silver · · Score: 3, Insightful

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

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

  5. increasing signal to noise with business triage by Anonymous Coward · · Score: 4, Insightful

    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.

  6. Simple solution. by khasim · · Score: 4, Insightful

    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.

  7. Re:mark the bug "[closed] can not reproduce" by gtbritishskull · · Score: 3, Insightful

    Or they will just stop sending bug reports. If you are an ass to your users then they will weigh how much they care about the app working vs how much of a pain it is to deal with you. If the app is relatively unimportant to them or you are a very big ass then they will stop sending bug reports (and possibly stop using your app). In which case the dev loses.

  8. YSOD? by Mattwolf7 · · Score: 3, Insightful

    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.

  9. "Report Bug" clicky by John+Hasler · · Score: 4, Insightful

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

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    1. Re:"Report Bug" clicky by Grishnakh · · Score: 3, Insightful

      To be fair, software development is still a pretty new field, and is going through rapid changes. While we've been developing software since the 60s, a lot has changed since then; having an automated way of reporting crashes is actually fairly new, as it was impossible not very long ago before computers were networked or had much power. Of course, this isn't entirely true: we've had fairly powerful networked computers for some time, but they were very large and expensive computers that not that many people had access to; it wasn't until the mid 1990s (only 15 years ago) that these became commonplace for most people, with the rise of the PC. And of course, many lessons learned in the mainframe and other large computer space (like with UNIX machines) have either been slow to trickle over, or were outright re-invented with PCs because the two worlds started so differently.

      Also, a lot of people working in software development came from different fields and may not have that much formal education in it (I started in electrical engineering, for instance), and even those who did, may have gotten a rather poor education from what I'm reading about the way some colleges teach CompSci.

  10. Re:You Don't by rwven · · Score: 2, Insightful

    That's a cop-out....and completely unrealistic.

    Finding a decent way to look through GB of logs to find something that happened a week ago is going to be MUCH more of a challenge than just arguing with any client to get the information you need. Not to mention, the only way you're going to trace any random malfunction back to any random source is if you have so much logging that half your computation time is spent managing your logging system and the needed disk writes....and let's not talk about the volume of log data THAT would produce.

    Logging can, and should, only do so much. You can't, and won't, catch everything with it.

  11. Re:Developers don't read bug reports anyway by spongman · · Score: 4, Insightful

    If the software is working the way its designers and architects intended for it to function, there's no bug.

    absolutely correct, unless you consider usability to be a feature.

    if you do, then every time a user is confused about your application, it's a bug. it may not be easy to fix. but if you don't consider it a bug, track it, prioritize it and potentially fix it, then you don't care about usability.

  12. Re:You Don't by shish · · Score: 4, Insightful

    Finding a decent way to look through GB of logs to find something that happened a week ago is going to be MUCH more of a challenge

    I'm running a website with 2-3k concurrent users; using web server access logs for read-only users, and a more detailed custom logging system for any interactions that any user makes, only generates ~100GB of logs per month. In the grand scheme of things, this is a tiny amount (grep from the command line is still perfectly adequate). For someone who can dedicate a day or two to writing a log browser then I'd expect the search to be even better, with graphs and automated anomaly reports and such (As someone who actually has done this, I'm not sure whether to find your comment of unrealism worrying or complimenting :P).

    --
    I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
  13. There are no bugs, there are no requirements by gr8_phk · · Score: 4, Insightful

    I've had enough of software folks looking for requirements and now good "bug reports". Users/Customers do not have requirements they have PROBLEMS. It is up to the developers to create tools that solve those problems. The user doesn't even know what's possible or easy or hard to implement, so they can't tell you what the requirements are. Same for bugs. The user can't tell you details about which internal parts of your code have a bug, they tell you (at best) what they were doing when something happened. They don't know a crash from accidentally closing a dialog box. The solution - especially for internally developed software - is to go visit the users and have a conversation. Talk to them. Understand how they view your software and you can then understand their explanation of what it did wrong. This will also give you insight into how to make it better. Stop expecting detailed bug reports and start understanding users.