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?
Mod parent up! (Score:2)
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: (Score:3)
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
"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: (Score:2)
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:"Report Bug" clicky (Score:5, Funny)
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.
Re: (Score:3)
It's always useful to compare notes. Sometimes you get so used to doing things one way that you never stop and think about what it is you're really trying to accomplish.
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.
Re:"Report Bug" clicky (Score:5, Informative)
Just type "PSR" into a command prompt or Start->run. It's a great tool.
Re: (Score:3)
Re:Mod parent up! (Score:5, Informative)
> 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.
Re:Mod parent up! (Score:5, Funny)
> 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.
Re: (Score:3)
Here's one I've been using, it worked well for my purposes:
http://www.codeproject.com/KB/debug/crash_report.aspx [codeproject.com]
Re: (Score:3)
Same. You can only get so many "I clicked X and an error popped up" bug reports with no information beyond that quote in the bug body before you look to a real solution.
You get information like "I clicked X"? The reports I get don't usually even tell me that much.
I tend to get "the internet doesn't work" (I write and manage proxy and email systems). This can mean various things:
1. The whole internet connection is down (why are you calling me? I'm not your ISP...)
2. I can't access my webmail
3. I can't send an email from my MUA
4. Someone on the other side of the planet sent me an email literally 2 seconds ago and I haven't received it!!!!
5. I can't access any web pages (a
Re: (Score:3)
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.
Re: (Score:2)
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 (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: (Score:3)
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
Re:Make it send data to you (Score:5, Insightful)
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:5, Funny)
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.
MadExcept! (your app should send bugreports) (Score:3)
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:
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
Re:Make it send data to you (Score:4, Funny)
Make your software send it...
I recommend call information, web history, and keystrokes. For more information check out carrieriq.com
Re: (Score:2)
* 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)
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: (Score:2)
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.
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)
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.
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.
There are no bugs, there are no requirements (Score:5, Insightful)
Re: (Score:3)
At first I thought you were going for funny. But your points seem serious, so I don't think so any longer.
To a certain extent you have to know your users. Some classes of user are simply not of the mindset to give you requirements or meaningful bug reports. The responsibility to bridge this gap belongs to the project manager or some designee if the project is of sufficient scale. Sometimes for small projects, the developer is the project manager, so that's the developer's responsibility.
Users/Customers do not have requirements they have PROBLEMS
Right, and the P
Re: (Score:3)
you've got a place where it should be "an" but it says "the"
No amount of understanding the user will allow me to figure out what the hell they're talking about, other than their giving me the context in which to find the line of text.
Re: (Score:3)
How do you log a bug report on the bug reporting feature?!?!?! :D
Actually, yes, provide them a button to submit bugs that grabs a lot of context data but lets them type in a description of what they were doing. The more you lead them, the better their input. In other words, don't give them a box that says "Additional comments" give them multiple boxes.
What business function were you performing? What was your expected outcome? What other programs did you have running? Is this the first time you've exper
You're right (Score:3)
We do this and it works great. We additionally send along some system data, such as last 5 actions, a URL (we're web based), and some other debug data.
It has saved us endless hours in finding the exact conditions needed to replicate a problem so we can fix it.
Re: (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.
Pray? (Score:4, Insightful)
Either that, or send them all to reeducation camps.
Try not to stress about it, it's hopeless.
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: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.
More pressing question (Score:5, Insightful)
A more pressing question is how to get developers to stop ignoring bug reports.
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: (Score:2)
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
Re: (Score:2)
A lead engineer sets priorities.
Re: (Score:2)
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
Re: (Score:3)
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.
Re:More pressing question (Score:5, Insightful)
Re: (Score:2, Informative)
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: (Score:2)
What memory leak? I remember a while back hearing about one that affected pages with a huge number of images, and they were going to fix that one. But most of the memory leak reports aren't Firefox and for most people Firefox uses less memory that the competition does.
I've used Fx since it was an alpha release and apart from the horrendous memory leaks of the 2.x days, there really haven't been too many problems caused by memory leaks.
If you've found a memory leak, then perhaps you ought to provide them wit
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.
Re: (Score:2)
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)
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: (Score:3)
YSOD? (Score:3, Informative)
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: (Score:2)
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... (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.
Can't happen (Score:3)
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..."
Have a template for them to fill out (Score:5, Informative)
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).
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.
Re: (Score:3)
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
Hell, you'll be lucky if QA can do that (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Give up (Score:2)
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.
Get them to create meaningful IT tickets too. (Score:2)
Which computer? Do you think it's a comedian? Is it here to amuse you?
cheapand dirty (Score:2)
YSOD? (Score:4, Insightful)
Re: (Score:3)
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 (Score:2)
Template (Score:2)
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 (Score:2)
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
Tell them exactly what info you want (Score:2)
coaching (Score:5, Informative)
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... (Score:2)
.
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
What have you done so far? (Score:3)
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 (Score:2)
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.
Exact Instructions (Score:2)
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
Re: (Score:2)
Re: (Score:2)
... 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...
Teach Science in School (Score:2)
Teach them (Score:2)
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
YSOD (Score:2)
if you're getting YSOD's you should NuGet Elmah [google.com]
Simple (Score:2)
The same thing doctors do (Score:2)
- 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.
Write something (Score:2)
They have complaints that aren't bugs? No they don't. Their complaints ARE bugs... just not software bugs. They are bugs in pr
Try Pavlov, Too (Score:3)
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.
Re: (Score:2)
...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 resu
Re: (Score:2)
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 ex
Re: (Score:3)
Re:mark the bug "[closed] can not reproduce" (Score:4, Insightful)
Re: (Score:2)
it's amazing how often i see this happen with open-source software: some guy releases his pet project that he's been working on in his mom's basement for 2 years, he thinks it's the greatest thing on earth and as soon as someone comes along and leaves some comment that isn't just gushing praise they start behaving like a defensive six-year-old.
Re: (Score:2)
that's the best way to communicate to the user, that took time out of their non-programming day in order to do you the favor of telling you how your application doesn't work, that you don't really care about them, the problem they were having, or if they are able to use your program.
you don't work on the TortoiseSVN project, do you?
Re: (Score:3)
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 highe
Re: (Score:2)
What a ridiculous comment.
What is ridiculous about it?
.
(note - I am not posting AC)
Why do even the best programmers call their mistakes bugs and not their mistakes? Why are even the best programmers avoiding taking responsibility for their errors
Why do you try to rationalize programmers' errors as being the result of ~there is too much to test~? Don't you think that programmers who really care about the quality of the code they write might object to your kicking the can down the road and blaming the problem on QA?
Why are y
Re: (Score:2)
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 pro
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: (Score:2)
The problem here is that everyone has a different idea of what "usable" means. The Gnome devs think things aren't "usable" if the UI isn't suited for a 5" touchscreen, but many users seem to disagree with that. Other users may think something isn't "usable" if you have to right-click to do certain things (as is common in most non-Mac systems), while other users disagree.
Sure, bug trackers should accept bugs from users complaining about usability features, but there's no way to please everyone, so users sh
Re: (Score:2)
"If you want to make enemies, try to change something"
FYI: YSOD = yellow screen of death (Score:2)
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&ci [slashdot.org]
Re: (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
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).