Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted more than 2 years ago | from the it's-broken-just-fix-it dept.

Bug 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?"

cancel ×

360 comments

Sorry! There are no comments related to the filter you selected.

blowjob Tuesdays! (-1)

Anonymous Coward | more than 2 years ago | (#38365446)

just sayin'...

Re:blowjob Tuesdays! (-1)

Anonymous Coward | more than 2 years ago | (#38365870)

First, never use words like "rollout" or "rollup" or "utilize". They only alert your enemies that you are a bullshit artist and everything you say should be taken with a pound of salt, preferably up your ass. See how I did that, there?

Make it send data to you (5, Insightful)

jhoegl (638955) | more than 2 years ago | (#38365448)

Make your software send it...

You can not teach the world, so why try?

Re:Make it send data to you (0, Insightful)

Anonymous Coward | more than 2 years ago | (#38365488)

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.

Re:Make it send data to you (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38365524)

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.

Mod parent up! (1)

khasim (1285) | more than 2 years ago | (#38365502)

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?

Re:Mod parent up! (2)

Grishnakh (216268) | more than 2 years ago | (#38365670)

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 the UI, or some other imperfection that users might complain about? Those wouldn't be handled by an automated bug reporter.

"Report Bug" clicky (4, Insightful)

John Hasler (414242) | more than 2 years ago | (#38365872)

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

Re:"Report Bug" clicky (1)

Grishnakh (216268) | more than 2 years ago | (#38365952)

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.

Re:Make it send data to you (1)

RyuuzakiTetsuya (195424) | more than 2 years ago | (#38365506)

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.

Re:Make it send data to you (3, Insightful)

Mr. McGibby (41471) | more than 2 years ago | (#38365636)

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:Make it send data to you (2)

pthisis (27352) | more than 2 years ago | (#38365652)

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

Then you delete old info yourself on your end, but keep a lot more than you think you'll need.

Bugs that don't result in a crash are the harder ones; ideally you have some way to flag a user so that they get traced pretty fully, so if someone calls in a bug report you can turn on tracing for them and log a ton of crap. And it's often worth having the logs generally be a lot huger than you'd anticipate (even for general users who you haven't flagged for special debugging). But it's tougher than debugging the crashes, for sure.

Re:Make it send data to you (5, Insightful)

werdnapk (706357) | more than 2 years ago | (#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.

Re:Make it send data to you (1)

Anonymous Coward | more than 2 years ago | (#38365590)

Diagnostic info. Apple does this well, it spies on tasks that silently assert or take too long. They're opt-in on iOS devices, and you can view them on device or from xcode, helpful for debugging your own apps too.

Simple solution. (4, Insightful)

khasim (1285) | more than 2 years ago | (#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.

Re:Make it send data to you (5, Funny)

Slavik81 (1457219) | more than 2 years ago | (#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.

Guffaw! (-1)

Anonymous Coward | more than 2 years ago | (#38365892)

That's why you're not making the big bucks and parking close to the front door.

The correct retort, in all cases, is "can't you just look at the code?" This is seen as particularly insightful when the source code has been lost: "You've got object - that's code, isn't it? So what's the problelem?

A similar response is used for defective hardware: "can't you jut fix it in the code?"

Remember those phrases and how to make fancy pointless color charts and meaningless PowerPoint slides and soon you may no longer need to keep and umbrella in the car!

Re:Make it send data to you (1)

linuxgeek64 (1246964) | more than 2 years ago | (#38365576)

The problem with that is that the user can't provide information like what they were doing when the crash happened or what the expected behavior was. For uncaught exceptions, sending a stacktrace could be helpful. Depending on the language, though, there might not be exception handling - just crashes.

Re:Make it send data to you (1)

cfryback (870729) | more than 2 years ago | (#38365578)

Make your software send it...

You can not teach the world, so why try?

Absolutely should have been part of the software...

But let's face it most software now is about the pretty pictures....

Our two main kits of software generate error codes that can be submitted to the IT Helpdesk and assigned accordingly.

Re:Make it send data to you (4, Funny)

Anonymous Coward | more than 2 years ago | (#38365630)

Make your software send it...
 

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

Re:Make it send data to you (2)

corporateminion (1066292) | more than 2 years ago | (#38365638)

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 the user at the time they submitted the request. In a Java app, you could do something like this:

* have every command action in your application throw a special myappException
* define the myappException by extending the standard Exception and add the above fields
* catch that myAppException in your main event loop
* when caught, display a form that prompts the user for any additional explanation they might want to supply
* email the content of your myappException fields and their form-entered text to a dist list for your app support team

The resulting email will point your app support team and developers directly to the proper point in your application logs to figure out what else may have contributed to the error without being sent on a wild goose chase based upon bad timestamp information or incomplete text of the error / exception encountered.

Re:Make it send data to you (2, Funny)

Narksos (1111317) | more than 2 years ago | (#38365654)

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)

Re:Make it send data to you (0)

Anonymous Coward | more than 2 years ago | (#38365692)

I had my own technology impaired duck to deal with my entire childhood, I stopped trying to get accurate reports and instead resorted to remote desktop.

Re:Make it send data to you (1)

MBC1977 (978793) | more than 2 years ago | (#38365868)

"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? (3, Insightful)

mirix (1649853) | more than 2 years ago | (#38365450)

Either that, or send them all to reeducation camps.

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

Re:Pray? (4, Insightful)

moderatorrater (1095745) | more than 2 years ago | (#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.

You Don't (0)

Anonymous Coward | more than 2 years ago | (#38365452)

You Don't..It's called logging.

Cattle prod... (1)

Anonymous Coward | more than 2 years ago | (#38365460)

Electro-shock. 'Nuff said.

You're assuming developers can send good bug..... (0)

Anonymous Coward | more than 2 years ago | (#38365464)

You're assuming developers can send meaningful bug reports. They're just as bad sometimes....

Re:You're assuming developers can send good bug... (2)

Targen (844972) | more than 2 years ago | (#38365566)

This is a great point. The distinction that actually matters is not so much whether the bug reports are submitted by developers or lusers, but whether they're submitted by idiots. The fact that someone's been hired as a developer reduces the odds of idiocy w.r.t. software, but it's neither necessary nor sufficient, and a certain degree of optimism is required to assert even the correlation. Likewise, it's plausible that lusers are more likely than developers to be idiots about software, but exceptions exist.

The real, general solution to this problem is, of course, to get rid of the idiots on both sides. The solution to this problem is left as an exercise for the reader.

Re:You're assuming developers can send good bug... (0)

Anonymous Coward | more than 2 years ago | (#38365842)

Your assumption that users more than developers are likely to be "idiots" clearly illustrates that you should never rise above the level of back room code monkey. You should be kept the hell away from users, managers, in fact from anyone but your team lead, who can push red meat (well, okay, Doritos and Code Red) into your cube.
 
Bonus points for using the non-word "lusers".
 
And "left as an exercise for the reader"? Arrogant much? Impressed with your studly nerd skills?
 
Grow up, you pathetic man-child.

What a load... (0)

singingjim1 (1070652) | more than 2 years ago | (#38365472)

...ed and meaningless "article". This is probably the laziest and most pointless story I've seen on /. Try debugging in alpha and beta versions more before releasing into the wild.

Re:What a load... (1)

Ethanol-fueled (1125189) | more than 2 years ago | (#38365498)

I was thinking more along the lines of having a meeting for each group, then referring people to the rules if they don't submit enough information.

But yeah, lazy and pointless.

Re:What a load... (-1)

Anonymous Coward | more than 2 years ago | (#38365558)

Yes, after all, we all know that any software that makes it out of beta is completely bug-free!

Re:What a load... (1)

c0lo (1497653) | more than 2 years ago | (#38365564)

...ed and meaningless "article". This is probably the laziest and most pointless story I've seen on /. Try debugging in alpha and beta versions more before releasing into the wild.

So fast to jump the trigger. Letting aside that you don't debug, but you fix the bugs discovered by testing (well, you may use a debugger, but that's not the only mean available), consider this:
Recession; meaning: short of money; meaning: less development resources available or available for shorter time.
Consequence: do what you can within the bounds of "Cheap, good and quick: pick any two" - it is going to be way more expensive on long term, but... try teaching this to CEO-es under pressure to show results to shareholders.

More pressing question (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38365474)

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

Exactly. (1)

Anonymous Coward | more than 2 years ago | (#38365592)

Look at Firefox. Not only have they ignored the memory leak problem since inception, they not only dismiss it as fiction, but actively brand the users as liars. Is your company like that? If so, don't bother.

Re:Exactly. (0)

Anonymous Coward | more than 2 years ago | (#38366008)

Actually they've actively been tackling the issues and it's even in their road map. What they need to deal with are fucking idiots like you who don't actually send bug reports and are actually anti-fanboys trying to get people away from Firefox by spreading their bullshit all over discussion threads everywhere, whining about bugs that no longer exist or have been fixed in their current form. If you knew anything about the product you're probably not even using, you would've cancelled your post due to how completely stupid it is. They've even talked about this recently about how they are making more progress with Firefox 9 and 10.

Re:More pressing question (3, Insightful)

jhoegl (638955) | more than 2 years ago | (#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.

Re:More pressing question (0)

Anonymous Coward | more than 2 years ago | (#38365738)

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

^ this

Re:More pressing question (5, Insightful)

WeirdAlchemy (2530168) | more than 2 years ago | (#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:More pressing question (0)

Anonymous Coward | more than 2 years ago | (#38365908)

Or even just stop sending out buggy stuff. I don't mean tricky to encounter bugs that depend on fifteen different things all falling into place at once. All I'm asking is that when you code a bug fix or new feature, that you do some kind of testing, even just once through, to make sure it does what you're claiming it's supposed to do.

Everything that compiles (for compiled languages) or "successfully* saves" (for interpreted languages) isn't necessarily correct...

*returning success is a necessary condition to saving, but not sufficient. Your stuff isn't saved until you've sync'd and/or flushed....

Re:More pressing question (2, Informative)

Anonymous Coward | more than 2 years ago | (#38365944)

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.

Why not try this? (1)

Anonymous Coward | more than 2 years ago | (#38365486)

Give people a small, but meaningful bonus when they send in a meaningful bug report. If not, just disregard it and send them a canned form on which they will have to write all their bug reports.

It's no secret, but underused (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38365492)

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.

Re:It's no secret, but underused (1)

Grishnakh (216268) | more than 2 years ago | (#38365728)

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 reports to, which then on the server side dispatches them to the right place. Moreover, there's no standardization in toolkits and such, so KDE's tool works great for KDE, since it and all its apps are built with Qt, so they're in a position to be able to best interpret that data. MS probably has an easier time with this since they have several standard toolkits/APIs, so any program built with those APIs can take advantage of the provided crash reporter. However, I imagine any program that isn't built with standard MS APIs wouldn't have this ability. Also, MS has the resources to set up a website where this crash reporter can send all its reports to; getting the Linux community to cooperate on such a project (that serves all applications on all desktop environments) would be like herding cats. I think the best we'll see any time soon is each major DE/toolkit having its own crash reporter, which works for that DE and its apps, plus perhaps any other apps that other people write using that DE's libraries.

Template (1)

Anonymous Coward | more than 2 years ago | (#38365494)

Send them a bug report template. Mark in red the things that are very important for your particular application (e.g. you mentioned URLs).

You can then help you help them help you with little questions like 'can work around' or 'can be reproduced'.

Add a bug-report button (0)

Anonymous Coward | more than 2 years ago | (#38365496)

Add a button or link to each page called something like "report problem on this page" which dumps relevant state to somewhere sensible (i.e. don't fill up the root fs), and gives the user a text box to write a description of the problem in. As long as what the user types in is even vaguely sensible, you should have enough state dumped to figure out what's going on. Exactly what and how much state you want to dump is of course up to you.

Re:Add a bug-report button (2)

cusco (717999) | more than 2 years ago | (#38365680)

Bingo. One of the main apps that I use has a 'Feedback' button that tech support has hijacked to have users send in bug reports. I'm sure the Marketing department is annoyed, but that just makes it better.

Listen (4, Interesting)

Moof123 (1292134) | more than 2 years ago | (#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.

YSOD? (3, Informative)

Anonymous Coward | more than 2 years ago | (#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.

Re:YSOD? (0)

smileygladhands (1909508) | more than 2 years ago | (#38365560)

This.

Re:YSOD? (2)

smileygladhands (1909508) | more than 2 years ago | (#38365606)

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

Make the users fill in a form... (3, Insightful)

jet_silver (27654) | more than 2 years ago | (#38365516)

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 the users fill in a form... (0)

Anonymous Coward | more than 2 years ago | (#38366006)

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

This exactly. Here at my work, we have engineers whose responsibilities include answering and relaying issues that the customer finds.

It's tough work understanding users. If it wasn't, everyone would do it and it wouldn't be so important.

Developers don't read bug reports anyway (1)

Anonymous Coward | more than 2 years ago | (#38365530)

If they did Unity, Gnome 3 and Firefox wouldn't have the massive amounts of negative feedback they have now. In fact, Firefox development has gotten so bad they are currently having issues compiling [h-online.com]

Re:Developers don't read bug reports anyway (1)

Grishnakh (216268) | more than 2 years ago | (#38365896)

I completely disagree. There's a difference between a bug where a piece of software is not operating correctly according to its own designers, and a "bug" where a piece of software is not styled or architected the way some users think it should be.

For instance, suppose you have a program, and on one window, there's a "Next" button that's supposed to take you to another window (if there's any formal design docs, this would be specified there). But instead of doing that, clicking that button crashes the program. That's a bug. There's no disagreement about it.

What you're talking about is some users not liking the way the software is architected. To put it into the obligatory car analogy, it's like getting into a Chevy Aveo and complaining that it doesn't handle and accelerate like a Porsche or Ferrari. If the software is working the way its designers and architects intended for it to function, there's no bug.

This doesn't mean griping and complaining about the state of some of this software these days is wrong, it's just that you're calling it a "bug" when it isn't, and people may indeed be filing bug reports on these projects' respective bug tracking systems, but bug trackers are usually used for two things: bug reports (with "bug" being what I described above), and feature requests. A feature request is when the user tells the designers and architects how they think things should be done. However, if the architects have a different vision of what the software should be than the users making these requests/complaints, then they're obviously going to ignore them. Again, it'd be like a bunch of people complaining to Chevy that their Aveos have shitty handling and performance; the engineers would read these complaints, say "we did the best we could given the cost constraints imposed by management to meet this vehicle's price point; we can't include the components needed for higher performance without sacrificing fuel efficiency and/or greatly increasing build cost", and dismiss the complaints, rightfully.

WRT Unity and Gnome3, what we have here is a fundamental disagreement between the developers of these projects and the users who keep trying to user them. These projects want to impose dumbed-down UIs on users which are suitable for small touchscreen devices, because they believe that all devices should have the same interface to "reduce confusion", and so, even if you're using a giant quad-monitor desktop system, you need to be constrained to doing things in a way that works well on an iPhone, because you're too stupid (in their opinion) to be able to use different UIs on different systems. If you don't agree with this philosophy, then these systems are simply not right for you, and you're wasting your time complaining to the devs about it because they don't care what you think. Instead, you should be migrating to systems which suit you better, such as KDE whose developers believe that different devices should have different UIs, and have set up their system to work in exactly this way: there's different default UIs for desktops, netbooks, and tablets (there's actually a video somewhere showing an experimental version running on some kind of touchscreen smartphone IIRC). Furthermore, it has oodles of configuration options, in case the default behavior isn't to your liking--this is something else the Gnome and Unity devs don't believe in, because they think it's "too confusing" to have configuration options. If KDE is too heavyweight for your liking, there's a few other Linux DEs out there that strike a different balance, such as XFCE and LXDE, so try those out too if you hate Gnome3 and Unity and KDE doesn't do it for you.

Can't happen (2)

YrWrstNtmr (564987) | more than 2 years ago | (#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..."

Write a script/tool that collects all the data (0)

Anonymous Coward | more than 2 years ago | (#38365538)

Write a script that collects all the relevant data and zips it and then ask the person reporting the bug to run the tool on their system and send you the zip file.

Templates and strict acceptance (0)

Anonymous Coward | more than 2 years ago | (#38365546)

Make a template with all of the information you need in clear fields.

Require all bug reports to meet that format.

Automatically return any that don't with a request for more information.

At first you may get a reduction in bugs as people whine about it being a hassle, but once they get used to it, all will be fine.

Have a template for them to fill out (4, Informative)

mattack2 (1165421) | more than 2 years ago | (#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).

KISS (0)

Anonymous Coward | more than 2 years ago | (#38365574)

Well i can tell you one thing, don't put all the crap that Apple does on the screen. 5 seconds of trying to read that garbage pisses me off so bad there's no way I want to try to describe what was happening at the time.

mark the bug "[closed] can not reproduce" (0)

godrik (1287354) | more than 2 years ago | (#38365580)

marking the bug closed because it can not be reproduced is a good way of carrying the right message. You can also attach reasons why you can not reproduce it by listing missing details. With time the users might learn to make a bug report. Of course there should be an option to allow the user to reopen the bug.

Re:mark the bug "[closed] can not reproduce" (3, Insightful)

gtbritishskull (1435843) | more than 2 years ago | (#38365724)

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.

Not gonna happen (0)

Anonymous Coward | more than 2 years ago | (#38365584)

If you didn't get commitment from your beta testers to do that early on and also give them a format to give you feedback I gotta be honest...you wouldn't be doing a "major rollout" at my company again. Gotta be honest, it sounds like you didn't really think things through. Bug tracking system is just a tool...doesn't really help your problem.

YSOD? (1)

Anonymous Coward | more than 2 years ago | (#38365596)

Maybe if you didn't use obscure acronyms then your users would be less intimidated to write up a meaningful report without their situation being discussed on /.

FYI: YSOD = yellow screen of death (1)

tlambert (566799) | more than 2 years ago | (#38365948)

FYI: YSOD = yellow screen of d

It's a common occurrence when the back end server sends out the YSOD instead of the content you intended for it to send when you are running buggy ASP.NET code (ASP.NET is a Microsoft web application framework based on Active Server Pages. See http://en.wikipedia.org/wiki/ASP.NET [wikipedia.org] ).

Generally, you would hire someone who understood overriding the application_error, as was previously suggested by an AC poster in this posting: http://ask.slashdot.org/comments.pl?sid=2572922&cid=38365514 [slashdot.org] . In other words, you'd hire someone who could fix the problem, rather than asking Slashdot.

They'd probably also be clueful enough to know that the place to ask for help with Microsoft products is Microsoft, and that they are unlikely to get a lot of love from the Slashdot crowd, who typically avoid work-for-hire coding models that make it difficult to reuse their code later on if they go to work for a different employer. Very few clueful people like to have to solve a given problem more than once.

-- Terry

increasing signal to noise with business triage (4, Insightful)

Anonymous Coward | more than 2 years ago | (#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.

Re:increasing signal to noise with business triage (2)

caitriona81 (1032126) | more than 2 years ago | (#38365820)

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 so that they could advocate for their department's needs ("You can't change payroll the day before we run it!" "Tuesday doesn't work because that's year end closing!")

We also filtered everything IT through the helpdesk, from change controls, to access requests, to outage notification & paging, to trouble tickets and support requests. Problems which weren't reproducible were stopped there. Things that seemed to be user education would either be handled by the helpdesk, or assigned to the appropriate business liaison to see if there really was a problem and gather more details. Remote control sessions were utilized by the helpdesk to gather screenshots. Intermittent problems were weeded out unless they recurred, in which case the previous calls were referenced to verify that this really was recurring. We leveraged our engineering and operations teams for troubleshooting when appropriate to gather logs. Only after we had concrete, conclusive details of a problem did something get passed to developers - and when we did, it was handled quickly, because we'd gathered all the information efficiently and correctly.

As a result, the developer teams were able to focus on fixing bugs, not triaging problems. The helpdesk always had ready access to all the relevant teams via phone, email, and instant messaging, and was well respected within them, because we were their filter, firewall, and front line, as well as their secretaries. (And we had the decisionmaking power as far as who got paged at 3am and who didn't!)

flip the question around (0)

Anonymous Coward | more than 2 years ago | (#38365608)

how do you get developers to write meaningful warning and errors messages and with the additional info they'll need to efficiently address the problem

Hell, you'll be lucky if QA can do that (1)

NotSoHeavyD3 (1400425) | more than 2 years ago | (#38365632)

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

Re:Hell, you'll be lucky if QA can do that (2)

gratuitous_arp (1650741) | more than 2 years ago | (#38365978)

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.

Give up (1)

lightknight (213164) | more than 2 years ago | (#38365640)

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.

Just Me? (0)

Anonymous Coward | more than 2 years ago | (#38365646)

Maybe you could ask them better questions?

One question... (0)

Anonymous Coward | more than 2 years ago | (#38365650)

"Steps to reproduce the problem?"

I know it's pretty-much standard when going through testing, but when this was added to our issue tracking it helped the devs a lot (gives you a test case as well).

You can (and probably should) ask other things as well.

Prefill the form (1)

Anonymous Coward | more than 2 years ago | (#38365662)

The best thing you can do is prefill a form with something like:

1. What are the steps to reproduce the problem?
    a.
    b.
    c.
2. What happened?
3. What did you expect to happen?
4. Are there any workarounds to the problem?

Re:Prefill the form (1)

Reasonable Facsimile (2478544) | more than 2 years ago | (#38365886)

The best thing you can do is prefill a form with something like:

1. What are the steps to reproduce the problem? a. b. c. 2. What happened? 3. What did you expect to happen? 4. Are there any workarounds to the problem?

This is definitely a good start. Simple templates are easy for non-developers to understand, and will help capture the users' impressions of what happened (which may differ radically compared to a developer). There are bug tracking tools available that will capture the users' actions minutes/seconds before the error occurred, but that's probably overkill for use outside of a/the development group/environment.

Get them to create meaningful IT tickets too. (1)

Culture20 (968837) | more than 2 years ago | (#38365688)

"The computer is acting funny."
Which computer? Do you think it's a comedian? Is it here to amuse you?

apply pressure (-1, Troll)

mevets (322601) | more than 2 years ago | (#38365690)

Sell the email addresses from crappy reports to every scammer you can find. Its kinda like moderation, but with an edge.

Step 1: write fewer bugs (-1)

Anonymous Coward | more than 2 years ago | (#38365702)

Seriously, developers have the wrong attitude about making mistakes. A pilot is not doing an acceptable job if he only crashes 2 or 3 times a month, and a truck driver is not doing an acceptable job if he crashes 2 or 3 times a month, but most developers think they are doing an acceptable job if they introduce 2 or 3 bugs a month. They are not. Every bug is a giant fuck up. The job of QA is not to find bugs, it is to ensure that there are no bugs. Everytime QA finds a bug it is because some developer fucked up and developers should take it as a giant insult against their work. Focus more on doing your job properly and you won't have to worry about people submitting bug reports.

Re:Step 1: write fewer bugs (2)

Dahamma (304068) | more than 2 years ago | (#38365804)

What a ridiculous comment. You are clearly not a software developer. I guess that's why you posted AC...

Even the best programmers make mistakes - but they also write unit tests to find them and functional tests to find issues with systems/integration. Even given that, a developer would still need to thorougly test (in various automated or manual ways) their work to make sure there are no bugs in a complex system - and the point of QA is both that they have expertise in that area, and it's not worth higher paid developers' time to go through all of those tests themselves.

cheapand dirty (2)

Errosion (718822) | more than 2 years ago | (#38365706)

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.

honestly (0)

Anonymous Coward | more than 2 years ago | (#38365714)

You should not be complaining.

At my company, as I imagine most, it's insanely hard to get anyone to submit bugs at all unless you happen to be the product manager or developer working on the project.

I always consider bugs submitted from extra testers as a bonus.

Get Satisfaction (0)

Anonymous Coward | more than 2 years ago | (#38365744)

I can't get this to sound not like a plug, so deal with it, they're the example I know.

I recommend something similar to Get Satisfaction [getsatisfaction.com] . It's not free, but depending on your project you might already have budget for it. It has a bunch of social media things that I don't really care about, but it allows for other users to respond and ask questions. Hell, you can select a little frowny face when writing comments. It does have basic community rating stuff for responses and reports and whathaveyou.

Also, "bug" isn't going to mean anything to regular users. Users have problems. They want to be able to go to the website, click support, and write a complaint.

Users aren't going to go search to see if it's already there, so do the search for them after they write their complaint. I think this a key part of it. They don't want to be aloooone.

Also, if a single user has a bug, you're pretty much screwed anyway unless you have some sort of automated dump, or if they're technically literate. Best thing you can do is try to organize it so all the vague bug reports of the same thing are bunched together. From that you can (maybe) extract some usable information.

Check out Mojang's [getsatisfaction.com] Get Satisfaction.

Look, you can put in 'you suck' and you get a link to someone already saying it [getsatisfaction.com]

how are you getting info? (1)

Zargg (1596625) | more than 2 years ago | (#38365774)

It sounds like you are just depending on people to email their issues straight to a developer. I would put up a web portal for bug reporting that includes pre-defined sections and issue types. For instance: "Main page >> graphical issue >> unreadable graphic" or "Product specific page >> functionality >> button issue". Then have a "what were you trying to do" and a "what did you do" fill in section.

Duh (0)

Anonymous Coward | more than 2 years ago | (#38365784)

Sit next to them.

Don't even try, it's hopeless. (0)

Anonymous Coward | more than 2 years ago | (#38365792)

And don't go for back and forth either, just get some software that lets you share their screen, and if there is any question at all about what they meant in their bug report, spend 10 minutes to do an online meeting and watch them recreate it. You'll waste *way* less time this way.

YSOD? (3, Insightful)

Mattwolf7 (633112) | more than 2 years ago | (#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.

Re:YSOD? (2)

ralphdaugherty (225648) | more than 2 years ago | (#38365970)

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.

Tickets + templates (1)

edcheevy (1160545) | more than 2 years ago | (#38365800)

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.

If you're a big enough for this to be major... (0)

Anonymous Coward | more than 2 years ago | (#38365810)

You should really have semi-technical "Business Analysts" that can be the liaison between the users and the developers. User has a problem, user tells the BA, BA come by the desk, assembles enough for a bug report, then sends that to the developers.

Jira (0)

Anonymous Coward | more than 2 years ago | (#38365838)

I can't recommend Jira enough. Has a rich API, decent customization with screens and schemas, workflow, and it's nearly free ($10/10 users annual license). Lots of plugins as well.

Template (1)

SharpFang (651121) | more than 2 years ago | (#38365850)

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:

Learn to ask better questions (1)

Wonko the Sane (25252) | more than 2 years ago | (#38365884)

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 bug reporting issue irrelevant.

Tell them exactly what info you want (1)

bigsexyjoe (581721) | more than 2 years ago | (#38365902)

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 (5, Informative)

KevMar (471257) | more than 2 years ago | (#38365916)

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.

Easy... (1)

QuietLagoon (813062) | more than 2 years ago | (#38365922)

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 technical or use case reasons why what you suspect may be a bug is really a bug. There is hope here.

What have you done so far? (2)

gratuitous_arp (1650741) | more than 2 years ago | (#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).

Teach me (1)

mrmeval (662166) | more than 2 years ago | (#38365996)

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.

Its called "Pushing on a rope" (0)

Anonymous Coward | more than 2 years ago | (#38366014)

My mother had a plaque on her office wall. It read:

Never try and teach a pig to sing.

It wastes your time,

and annoys the pig.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>