Ask Slashdot: How To Get Non-Developers To Send Meaningful Bug Reports? 360
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?"
Make it send data to you (Score:5, Insightful)
You can not teach the world, so why try?
Pray? (Score:4, Insightful)
Either that, or send them all to reeducation camps.
Try not to stress about it, it's hopeless.
More pressing question (Score:5, Insightful)
A more pressing question is how to get developers to stop ignoring bug reports.
Re:Make it send data to you (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.
Make the users fill in a form... (Score:4, Insightful)
and find out what you think might be wrong, instead of what is wrong.
Engage the users. It's your problem, not theirs.
Re:Make it send data to you (Score:5, Insightful)
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.
Re:Make it send data to you (Score:5, Insightful)
increasing signal to noise with business triage (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.
Simple solution. (Score:5, Insightful)
From the question:
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.
Re:Make it send data to you (Score:4, 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.
Re:More pressing question (Score:4, Insightful)
I have ignored bugs, not because it doesnt need to be addressed, but because it is low priority.
This is just how things work.
Re:mark the bug "[closed] can not reproduce" (Score:4, Insightful)
YSOD? (Score:4, Insightful)
Re:More pressing question (Score:5, Insightful)
"Report Bug" clicky (Score:5, Insightful)
Give them a "Report bug" clicky that brings up a form for them to fill out and which automatically extracts relevant information.
Re:Pray? (Score:5, Insightful)
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:You Don't (Score:3, 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.
Re:Developers don't read bug reports anyway (Score:5, 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.
Re:You Don't (Score:5, 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).
Re:Make it send data to you (Score:5, Insightful)
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.
There are no bugs, there are no requirements (Score:5, Insightful)
Re:"Report Bug" clicky (Score:4, 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.