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?"
It's no secret, but underused (Score:2, Interesting)
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.
Listen (Score:5, Interesting)
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.
Re:Pray? (Score:4, Interesting)
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.
Re:Make it send data to you (Score:2, Interesting)
Keep a circular buffer of the last 100 (or 1000) commands the user issued - that should give you a good idea of what they were doing when it crashed.
Re:More pressing question (Score:4, Interesting)
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.
Re:Make it send data to you (Score:5, Interesting)
Exactly. Make those people a browser extension that captures a screenshot, lets them paint a big red rectangle, a comment field, then annotates with things like all cookies for current page, browser history (on the current site), user email address, ...
Then teach them "something goes wrong, push the button".
And use a general exception handler that makes damn sure that the user id cookie is available inside the exception.