How Do You Get Better Bug Reports From Users? 205
itwbennett writes "You can try to train them, you can try to streamline or automate the process, you can demand that all bug reports go through a middleman (i.e., a QA tester) or you can throw up your hands and accept that users will forever submit bug reports that in no way help you solve the problem. Like the stages of grief, you've probably tried or experienced all of these at some point. But have you found any approach that really works for getting useful bug reports from your users?"
Make them feel connected. (Score:4, Insightful)
I think bug reporting was one of the things that the early Mozilla project did right. If anything give your users tools to track down the source of the bugs themselves. Your few power users who are developers, if you give them tools to view the stack trace or other such things often will, and they might be able to do much of the work for you.
Re: (Score:3)
Re: (Score:3, Insightful)
Sounds to me like the developers just didn't like dealing with bugs and wanted the users to do it all and present them with a gift-wrapped solution.
Re:Make them feel connected. (Score:5, Informative)
How is a USER supposed to track down a bug?
In the same way a beta tester does (among other things). Every time I do 'X' then 'Z' will happen instead of 'Y'. Please fix.
Recreating a repeatable problem is a pretty good start. In my experience the hardest part seems to be getting the average user to explain what the problem in a way that can be understood that is beyond 'it just doesn't work'
Re: (Score:3)
One of the commonest problems is that the error occurs in a way that's not repeatable from the user's point of view. For example, he's editing a file and the software does something weird. Was it that I pressed the A key after I pressed the ESC key? Was it because I pressed the space bar while moving the mouse? Was it because the program's window was maximized in the right display instead of the left display? Was it because the program auto-saved while I was editing and part of my file had swapped out?
Re: (Score:2)
There's an 80/20 ratio here, if you fix the 80% that fail the same every time then you wouldn't solve everything but you'd solve a lot. And sometimes the exact set of conditions is obvious after a few tries (Example: A chess program I use, if you have hit "analyze" but is still reviewing the options and haven't started it, get challenged to a match (usually a rematch) and hit cancel in the analysis dialog, the client crashes. First time I thought random crash, second time waaaait didn't it crash before on s
Re: (Score:2)
How is a USER supposed to track down a bug? They're users.
They're users because they're using the program in question. They run into the use cases that trigger the bug.
And an open bug reporting system means that users can get educated on what sort of bug reporting actually helps developers.
Re: (Score:2)
How is a USER supposed to track down a bug? They're users.
Sounds to me like the developers just didn't like dealing with bugs and wanted the users to do it all and present them with a gift-wrapped solution.
Bullshit.
Asking for the most basic of useful information, as in "steps to duplicate" is not "gift wrapping". Bugs that appear at the user's hands are, almost always, bugs that developers and alpha testers did not see. It is reasonable, then, to expect the user to do what they can to document the steps that gave rise to the unexpected behavior. It is absolutely not reasonable to expect the developers to cast about blindly, guessing at how the user might have behaved.
No (Score:2)
Force them to be better (Score:2, Insightful)
We have a big internal web app, when it throws an error it will log that error as part of a graceful error handling process. (Page, scope vars, user info, time, etc) From there, the reporting system requires a unique bug tracking number (the error number logged above) and it checks for uniqueness and to see if it exists before it lets you open it. The only edge case it doesn't catch is when our tracking mechanism is also broken and these tend to be severe outages that are pretty easy to diagnose and repro
Re: (Score:2)
Force them to be better. By beating the required information out of them. They'll soon learn to pay attention to what they did wrong, and to any error messages, if they consequences of not doing so are a thorough thrashing.
Of course, in some nancy pancy places they frown on beating the users. In those cases, I guess you could try the carrot approach. Give them a chocolate coin for every useful detail in the error report.
Have a clear list of what is required and what is helpful for any error report. Then, ma
No (Score:2)
Depends on the user base (Score:4, Informative)
I've worked in support organizations for 15 years. In a commercial environment where you can afford the staff, having a tiered approach works best - you have a help desk to gather and refine the questions and answer the small stuff, then work your way up to the engineers that wrote the code. The tough part of that is having a skilled enough help desk to know when to skip the canned questions and just forward a request on once you have the right information.
For organizations without those resources, you need to rely on the user base to be the help desk. Give them as much concise information as possible and frame the bug submission so that any and all needed data is in the report. Then it's up to the developer to give good information back to the user.
As an example, I had a problem with my laptop's trackpad going wonky. Ubuntu made it really easy to compile information about my system and submit it as a bug report, then open it for me so I can add any additional text I wanted. The answer I got back asked me to try a different kernel, and included well-documented links and information on how to get and install it. Just saying something like "yeah, go grab something out of backports" doesn't help the user if they have no idea what you're talking about.
Re: (Score:2)
Depends on your users (Score:5, Insightful)
If your users are, say, someone who works in a different department of the same company as you do, then I've found that the best approach is to positively encourage them to send me reports. If I can't figure it out from the report, I'll even walk over and ask them to show me exactly what they did to cause the bug. When I do that, I give them some tips on how to write a report that explains that more clearly: "I logged into the website, clicked 'Foo', entered 'baz' into this box, then clicked 'Submit'. I got an error page instead of this other page I was expecting."
If your users are mostly developers, then by all means give them easy access to stack traces, memory dumps, etc.
If your users are mass-market end users, then include with your application a system that tracks user actions and sends it (along with a crash dump) to you at the user's request if there's a problem.
If your users are calling in to your company to complain, plan on using some kind of desktop sharing software so that the user and you can see exactly what happened.
If your users are dumber than a pack of hammers, then I have no answers for you.
Re: (Score:2)
I see your problem already. You should have type "bar", not "baz"
Worse error messages (Score:5, Interesting)
When writing error messages, don't have it spit out something sensible. Have it spit out something completely crazy but memorable, which you can then grep the code for. Something along the lines of "The Cake has hit the Fan" or "The Chickens are eating Pie". This improves the odds the user will remember it and report it correctly, giving you some hope of finding where the bug is in the code.
Re:Worse error messages (Score:4, Insightful)
When writing error messages, don't have it spit out something sensible. Have it spit out something completely crazy but memorable, which you can then grep the code for. Something along the lines of "The Cake has hit the Fan" or "The Chickens are eating Pie". This improves the odds the user will remember it and report it correctly, giving you some hope of finding where the bug is in the code.
Or make it copy-and-pastable so no human memory is required. Or log it and make sending the log easy enough for your users. A nice user message followed by a more detailed procedure unwind or whatever applies in your application can be mighty useful.
Re: (Score:2)
So when they call, you say, "Click on the 'Help' menu [explain where that is], 'Troubleshooting', 'Send message log to helpdesk'," so you can see for yourself what the message was and what program state triggered it.
What, your product doesn't log that stuff? Yeah, this is totally the user's fault.
Re: (Score:2)
Re: (Score:2)
Interesting idea, I like it. The problem I've seen with errors is that they are sensible to programmers but cryptic and meaningless to users. If you are writing errors, put them in plain English (or whatever language you're programming for).
Re: (Score:2)
Yeah, the app should phone home when the bug report is "Loss of network crashes app"
And people love it when things record everything that happens. Look at how many loved the One.
Speak to the Submitter (Score:4, Interesting)
The sooner, the better. You need an agile bug response process.
Bug template (Score:4, Insightful)
In your bug tracking system, provide a bug template they need to fill in.
Encountered situation:
Expected situation:
Error messages, if any:
Steps to reproduce (please provide screenshots if appropriate):
If the template is not fully filled out, simply throw it out with "insufficient information/cannot reproduce". Eventually your users will grow up.
Also, there's nothing wrong with walking up to a user's desk (if physically possible!) and ask them to show you what they did.
Re: (Score:2)
The BUG! Button (Score:5, Interesting)
On every page of the site that I did for this company, in the upper right corner, there is a button labelled "BUG!". Click on it and a dialog box comes up that says simply "What's wrong with this page?" and has a big blank area to fill in. The dialog box has a "Submit" button.
What is not visible is that the JavaScript code for the BUG! button is grabbing all the information it can from the browser itself - what the current URL is, all the global JavaScript variables, name of the current logged-in user, time and date, browser type, web page contents, etc. All grabbed automatically.
And all stored in a special file on the server. The only thing the user has to tell me is what she doesn't like about that page.
The BUG! button was invented - by me - as a reaction to Bugzilla, which seems to be designed to keep users from reporting problems. I can ignore pointless bug reports, but I want to hear everything.
Re: (Score:2)
Click on it and a dialog box comes up that says simply "What's wrong with this page?" and has a big blank area to fill in.
"It's not working."
L2R (Score:2)
Click on it and a dialog box comes up that says simply "What's wrong with this page?" and has a big blank area to fill in.
"It's not working."
"What is not visible is that the JavaScript code for the BUG! button is grabbing all the information it can from the browser itself - what the current URL is, all the global JavaScript variables, name of the current logged-in user, time and date, browser type, web page contents, etc. All grabbed automatically. And all stored in a special file on the server. The only thing the user has to tell me is what she doesn't like about that page."
Re: (Score:3)
Bug reporting has to be extremely easy for users, or they just won't do it. Bugzilla is an absolutely excellent, unsurpassed example of how to prevent users from reporting bugs in software. It is absolutely wretched and damn near unusable.
Your idea is excellent: let users complain in their own words, but have the software transparently gather all the runtime information needed to reproduce and identify the problem. That should also work for desktop apps written in Java or C#, which is something I think I
Re: (Score:2)
Nice idea !
In my case, when the program catches an error, it displays a text input and a Send button.
I expressedly ask the users to explain how they reached this message, and I encourage them to report bugs in order to improve the quality of the program.
When they click Send, it sends a mail containing their message along with the (hidden) callstack and the error message.
Most of the time, people are unable to explain how they encountered this error, but at least they always press Send !
Re: (Score:2)
And odds are that'll be, "It doesn't work."
Show the reporters of bugs you care and appreciate (Score:4, Insightful)
If you're telling me you have time to program, but can't take the time to read an email that's bullet-pointed with very specific details and at least respond like a grateful human, then I am just going to say you have way to many e-mails to respond to or you're lying. In the prior, get more help. In the latter, please seek help.
follow-up (Score:2)
Screen Capture (Score:2)
Re: (Score:2)
Multiple Methods (Score:2)
Second stage is they let the form take logs from the computer, I automated the process so the form takes what it needs. They literally hit start and go have coffee or something well it works
Re: (Score:2)
Did you follow the setup directions properly, Did you download the newest version from the test server
I hate when QA tester ask bad question and complain about useless answers.
sigh
Re: (Score:2)
Re: (Score:2)
I wasn't responding to the dropped plural and incorrect capitalisation. I was responding to the irony in you complaining about bad questions and the achingly bad questions you posted as examples of what you ask.
Asking the user, "Did you download the newest version from the test server", when you already auto-grab user information, which I would damn well hope includes build info.
Or ever asking anyone "Did you follow the setup directions properly?" No, I sincerely believe I'm the problem, that's why I'm subm
Have tried everything (Score:3)
Hello everyone,
I have tried a bunch of ways. Trained the 'expert' users in the area on how to put in a better ticket. Sent tickets back to them because of lack of information. Judicious of cattle prods and a tack hammer... However, users will use what method is easiest to them, which tends to be:
Screen shots/sharing (Score:2)
If your organization is small enough, send screenshots together with the report, or if you have some kind of desktop sharing ability (remote assistance, Lync), take your dev through the process of how to trigger the bug. Just had an issue yesterday where they couldn't reproduce it, so we fired up a screen sharing process, they had me load up the Firefox debug console, and I went through the steps... turned out to be my mouse having a higher dpi than what they were using, so instead of getting floats, my sy
Give the user an incentive... (Score:2)
Security bugs in chrome, firefox etc get actively hunted down because of the explicit cash rewards, it clearly works.
I recently "submitted a bug" in an IOS app for a restaurant (web contact form, no email, in-app submission etc), they said I'd get a "free stamp" (collect 5, get a free meal etc) if I sent them the crash logs. Not a big deal, (I'm a developer so not difficult for me to do) but even a small incentive encourages me to actually DO it.
If you/parent company can give away something like like loyalt
Re: (Score:2)
If it's possible for the users to submit bad bug reports, it's likely that your bug report submission process is broken.
Give users an easy to leave feedback (Score:2)
Help, I live on Earth! (Score:2)
Re: (Score:2)
Have you tried turning it off and turning it on again?
Aactually yes... (Score:2)
Actually yes... I get very good bug reports from users. Luckily I did tech support for about 15 years before I got into development. So I had a lot of experience dealing with people that basically had no idea what they were doing. Keep in mind, I work in a corporate environment where what I create is consumed by a limited set of about 5k people.
1. Relationships: Where possible I get to know, personally, the people that will use my software. I can't know them all because there's thousands. But I can find key
Simple. Respond to them. (Score:2)
I am a developer. I write good bug reports. But when using a product I'm not working on, if the devs or the process seem out of touch, I don't tend to. If there's a crash report, I won't invest much because the seems to be zero investment back.
Whenever a bug is submitted, a real response... not just an automated mailer... should be sent within a day. Get more details if needed, provide an ETA. Otherwise, we're spitting in the wind, and it doesn't seem worth the effort.
Funnel (Score:2)
Embed logging technology in your software (Score:2)
Long term breeding program (Score:3)
I think the only chance is to create your own breed of users... May take some time ;-)
Create an Account (Score:2)
Force your users to create accounts at SuperDuperBugTrackingThingy.com to report anything. Then send them daily email updates from said tracking system. Also get your moderators to admonish any user that dares accidentally post an existing bug or posts in the wrong section of their clearly laid out bug tracking hierarchy. Or you could go full retard, like Google, and force people to use Google+ to do anything.
Screen sharing (Score:2)
If you can interact directly with your users, use Teamviewer or any screen sharing program. Watch them reproduce the error and you'll learn a lot.
This is closely related to the first point of this other comment [slashdot.org] so even if you can't interact with all your users (too many of them or too many layers inbetween) there will be someone who can. Again, a recorded screen sharing session can make its way to you.
PS: I know, making the user install the screen sharing program and properly start it can be a pain but many
have real QA testers (Score:2)
automated test can work or they can pass the test but still fail in ways that automated tests can see.
Dumping QA on to coders work load does not really work and you don't want the same people who code to be the testers any ways.
QA people need to be able to think out of the box and have full control over there PC systems for testing as well as well having more then 1 log in as well.
Also in power your help desk to be able to help and not be held back with call times and other BS.
Error messages (Score:2)
We have a huge problem with vague or misleading error messages. Instead of messages like "A file could not be accessed", how about you tell me which file could not be accessed?
Easy (Score:2)
What works for me is humans and feedback (Score:2)
I am a user, not a developer, so I have a little different perspective.
First, what does not work for me is a faceless drop box. Without feedback and a sense that the other end cares, it is hard to motivate to put in a bug request, let alone a good one. Submissions to nameless drop boxes become a rant to vent frustration.
For an external vendor, company A, whose design software I have now been using (suffering through) for 14 years I gave up submitting reports after 3-4 years. I never heard anything back,
Natural Selection (Score:2)
Shoot the users that submit bad bug reports. Within a few generations, only users that submit good bug reports will remain.
Re:Follow up (Score:5, Funny)
It's not working can you fix it. kthxby
Re:Follow up (Score:5, Funny)
Your users aren't code masters and never will be.
It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again". You don't have to be a "code master" to figure out that reporting a bug and not actually tell me _what_ broke, what the error was or let me log into a system that is currently exhibiting the problem so I can look myself is not going to be condusive to me fixing things.
And this stuff happens again and again with the same customers... "one of our users is having a problem accessing some websites, please can you fix it?" - ok, so I have to go back and ask "which user" and "which websites", if I'm lucky the customer will give me this information, if I'm unlucky I get "I didn't ask". A week later I'll get an almost identical problem report from the same person about a different (but extremely similar) problem, and again none of the information I ask for _every_ time is included.
Also the great one that comes up occasionally is "this has been broken for a month and you haven't fixed it yet!".. well, if you'd actually told me that there was a problem I might've known to look into it, but since this is the first I've heard of it...
Re:Follow up (Score:4, Insightful)
Your users aren't code masters and never will be.
It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again". You don't have to be a "code master" to figure out that reporting a bug and not actually tell me _what_ broke, what the error was or let me log into a system that is currently exhibiting the problem so I can look myself is not going to be condusive to me fixing things.
And this stuff happens again and again with the same customers... "one of our users is having a problem accessing some websites, please can you fix it?" - ok, so I have to go back and ask "which user" and "which websites", if I'm lucky the customer will give me this information, if I'm unlucky I get "I didn't ask". A week later I'll get an almost identical problem report from the same person about a different (but extremely similar) problem, and again none of the information I ask for _every_ time is included.
Also the great one that comes up occasionally is "this has been broken for a month and you haven't fixed it yet!".. well, if you'd actually told me that there was a problem I might've known to look into it, but since this is the first I've heard of it...
Right. Because users are filing bug reports. They're calling for customer service/support. You get good bug reports by having good people answer the phone. I'll accept, "something broke," from a user. However, I find it inexcusable that a Helpdesk rep sends me a bug report that says the same thing or, worse, asks me to call the user for details. That being said, if you can't rely on Helpdesk or the user, then your software should be able to rollup everything you need to resolve the issue.
Re:Follow up (Score:4, Interesting)
I had just sent the below list of things required in a bug report to a group of users/testers this morning......
In general, the following items should be included when possible:
â Reproduction steps
â Expected behavior
â Observed behavior
â If available, any related steps or values that worked (for example when a bug âoesometimesâ happens, itâ(TM)s useful to know when it works and when it doesnâ(TM)t)
Then, the trick is to reject or de-prioritize any bug that doesn't conform to the above. Train the users that if they provide accurate information, they get quicker response. It works for Pavlov.
Re: (Score:2)
Came here to say more-or-less the same thing as the combined parent and GP.
1. front line support (helpdesk, tier 1 support, whatever) must know how to take a decent problem report and walk the user through getting more information when needed. Support them with very good docs on how to submit a problem report, and thank and reward them when they do well.
2. any open tickets you get that are void of useful information, just close them. Follow up requests for more information are just going to tie up everyones
Re: (Score:2)
Requiring a user, after the fact, to recall an error message is futile. They simple have seen to many varied ones and their brain goes 'oh an error message' not 'oh a 504 error' or 'oh a invalid data type error'. This is when we have to write error handling code to be able to provide a text message, email, or simply a text file that records the details around a crash so you get the robustness you need to fix these types of errors without relying on iffy recall of users.
As an network admin, and closer to you
Re:Follow up (Score:5, Insightful)
Requiring a user, after the fact, to recall an error message is futile. They simple have seen to many varied ones and their brain goes 'oh an error message' not 'oh a 504 error' or 'oh a invalid data type error'.
Believe it or not a user that doesn't remember the error message is not the worst kind of user.
I have some users that love translating text errors into numeric error themselves. Any time a page doesn't load, it's a 404. So that's what they report. "I'm trying to connect to thisdomaindoesntexist.com and I'm getting a 404."
Re: (Score:2)
Requiring a user, after the fact, to recall an error message is futile.
Simple solution: Instead of just presenting an error message, popup a dialog that displays the error message, along with a button that says "Report this Error". When the user clicks it, your program then generates an email with the error message, a stack trace, and other relevant contextual information. You can also include a text box for the customer to type what they were doing at the time.
For internal company applications, I don't even ask for confirmation. Reporting the bug is the only option.
When w
Re:Follow up (Score:4, Informative)
That is nothing. I love it when users are overly specific, because they are always specifically wrong.
In user speak "My Password won't work." is code for everything, including an unplugged computer.
Re: (Score:2)
Re: (Score:2)
My manager had an email forwarded to her from a user's manager last week.
At the bottom was a bug report from 2009, a response from me saying I'd fixed the problem and the new version would be deployed overnight, and then a yearly update on the problem sent between the user and their manager -- nothing involving IT at all.
It turns out I did fix a problem, which matched the description from the bug report. I didn't fix the user's problem.
The user also had another 10 problems written down, and were waiting un
Re:Follow up (Score:4, Interesting)
Maybe, the user didn't want to confuse you by sending in multiple problem reports at once. Or maybe the user's manager thought that would overload IT, or make it appear they were just complaining too much. :)
I had users who just ignored, or worked around errors, errors that had never been reported. Some were user errors (resolved by both program changes to prevent those errors and user training), some were UI errors that didn't impact the results, and some were program errors with actual consequences or impact on the data or utility of the software. I found out about these errors by watching the users, or as a side issue when they were having some other problem that they did report. I explained that reporting all errors ASAP gives the developers a broader view of the potential problem, and allows all errors to be fixed faster and more completely. I trained them to report every problem, no matter how small, and made a point of addressing those errors as quickly as practical to reinforce the behavior of reporting them. And, of course, I explained that unreported errors were very unlikely to be fixed, ever.
Re: (Score:2)
Your users aren't code masters and never will be.
It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again". You don't have to be a "code master" to figure out that reporting a bug and not actually tell me _what_ broke, what the error was or let me log into a system that is currently exhibiting the problem so I can look myself is not going to be condusive to me fixing things.
And this stuff happens again and again with the same customers... "one of our users is having a problem accessing some websites, please can you fix it?" - ok, so I have to go back and ask "which user" and "which websites", if I'm lucky the customer will give me this information, if I'm unlucky I get "I didn't ask". A week later I'll get an almost identical problem report from the same person about a different (but extremely similar) problem, and again none of the information I ask for _every_ time is included.
Also the great one that comes up occasionally is "this has been broken for a month and you haven't fixed it yet!".. well, if you'd actually told me that there was a problem I might've known to look into it, but since this is the first I've heard of it...
Not sure why this was rated Funny when it is actually quite insightful. Why, because the above points out the obvious issue here with the approach and that is that a one way street doesn't exist and never will. The users will NEVER have the expertise to tell you what went wrong, and unless you understand how they abstract things in their minds (which takes time with each user) you will not understand what they are talking about and will have to inquire.
Bug fixing is a two way street. The user tells me somet
Re: (Score:2)
Re: (Score:2)
It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again".
It seems to me that your program should be logging and reporting its own errors --- or that you should be shipping a separate user-friendly diagnostic program to collect and report errors documented by the OS.
Re: (Score:2)
We had a user-friendly diagnostic program once. I had to add a "save to file" routine, because we ran into a user who couldn't understand the sentence "cut and paste the text into an email" ... even if you got on the phone to her and talked her through it... "Ctrl-A... Ctrl-C..."
The more foolproof you make things... the more the universe comes up with a better fool...
Re: (Score:2)
Re: (Score:2)
It doesn't involve users to be code masters, it just involves them engaging their brain a bit. I frequently get bug reports along the lines of "something broke last week, came up with some error (I don't remember what), but I rebooted it and its fine for now; please fix it so it doesn't happen again". You don't have to be a "code master" to figure out that reporting a bug and not actually tell me _what_ broke, what the error was or let me log into a system that is currently exhibiting the problem so I can look myself is not going to be condusive to me fixing things.
I think users don't always realize that a fault is not just obvious by inspecting your software. They don't realize you have identify possible places in hundreds of thousands of lines of code, that you need to step through what happened or that you need to be able to repeat it in order to gather more information and know when you've fixed. Without any experience of code or debugging, reasoning about what is and isn't important just isn't something the user will have done. Worse, it's easy for users to thin
Re:Follow up (Score:5, Funny)
You can reproduce the issue by getting their keystroke history. File an FOIA request with the NSA.
The NSA method works. (Score:5, Informative)
- Record all their actions on a self overwriting one hour long file.
- Give them a "one button" way of reporting a bug. The button saves the user and the time, then waits for five minutes and then sends you the recorded actions file.
It's simple to develop and gives you a lot of information. It might be illegal in some countries.
Re: (Score:2)
Not if you warn them and force them to click a button that reads "I accept". They won't read it anyway and blindly click it, so they won't complain too much.
If someone asks, blame it on some distant entity, like Microsoft, Adobe, the NSA or whatever you think they'll fall for.
Re: (Score:2)
That would be PEBKAC. Although I prefer PICNIC. Problem in chair, not in computer.
Re: (Score:3)
Layer8-error
ID-Ten-T error (ID10T) ...
Re: (Score:2)
Or, my favorite,
C) Pasting it into a MS word document
Re: (Score:3)
You *owe* them a bug free product. If you did your job properly, this complaint would be moot.
OK. How you gonna get there, Chief? Certainly not by testing, since that would involve testing which means "using". Maybe not by end users but by someone "using" the software, whether you call them QA or whatever. So, what, you just write it bug-free in the first place? I don't know what you make, but I think it's safe to say that you should be paid more.
Re: (Score:2)
For small stuff, yes. But we're now in a world where software and hardware is complex. Even in an environment like Apple where they have tight control over the hardware, there's variations between operating systems and their hardware offering that make it difficult for a company to write a single app that does it all. Then look at the PC world where it's pretty much a free for all.
Re: (Score:2)
Re: (Score:2)
I've filed many bugs against certain open source projects only for the developers to respond with "How am I supposed to fix this? Why aren't you telling me anything?". I'm not sure why they think the first submission will contain everything they need to replicate the bug, but that seems to be the expectation.
That's a fair request. When the developer is secretly thinking of a bug report format and required additional information and users are required to guess what that is, they'll probably give up after one guess. After all, they didn't develop the product, so without telling them what's required to debug and how to report it, they'll probably never guess the secret. Refining the report with some back-and-forth would go a long way in cases where you're dealing with a user capable and willing to provide this ext
Re: (Score:2)
It may or may not be a fair request, but it's only useful if the developer tells the user what information he needs and how to go about getting it.
-- hendrik
Re: (Score:2)
Which is why, whenever I file a bug report, I make a point of asking what information I should provide that might help diagnose a problem. In case the developer is as clueless about responding to users as the typical user is about responding to developers.
-- hendrik
Re: (Score:2)
Re: (Score:3)
There are many bugs that would easily be detected by actually using the application on a daily basis.
Users do not work for you. When they do post bug reports, it is most likely in frustration.
Providing that the developers actually have the ability and resources to do that. Most (much?, some?) software isn't developed for use in the programmers' domain, and real-world deployments often have conditions that aren't fully replicated or anticipated even in even a good simulated environment. Your developers probably don't operate a retail POS or limestone quarry or credit card call center or whatever environment the product is used in.
Not that this is an excuse not to do your best to test it out befor
Re: (Score:3)
Users will do things the devellopers never dreamed of, because no develpoer can have the level of ignorance of the software that the user has.
-- hendrik
Re: (Score:2)
There are many bugs that would easily be detected by actually using the application on a daily basis.
I don't know about you, but I don't have a pressing need to know what some ice-cream trucks in Switzerland are doing at a particular moment in time (The system I work on is fleet vehicle tracking and management). I have more important things to do, like watch TV or play games.
Re: (Score:2)
Even with forms, don't bet on getting clear bug reports.
Aside from all the other issues mentioned earlier, there is another reason users do not provide good bug reports: time. It takes time to write up a proper report, explaining all the details (what they were doing, what they expected the program to do, what it actually did), provide .LOG files, screenshots, annotations, etc.
A form can remind them of what information they need to provide, but it won't make the actual data-collection any simpler. And users
Re: (Score:3)
Not to mention the 'horse-to-water' problem with a formal ticketing system. If you have a phone, and they know your extension, they'll just call you directly instead of, you know, actually doing anything. And unless you've got C-level buy-in on the ticketing system, telling the user to go open a ticket is usually a Career Limiting Event.
No, the way to enforce usage of a ticketing system is to not tell the users about any other way to contact you.
Re: (Score:2)
Just as importantly, make that ticketing system responsive to the users. Because otherwise they will ignore it and find other ways of contacting you.
If a user creates a ticket explaining their problem and don't get a response at all - or only receive a generic "ticket #12743573 created" response - they will have absolutely no confidence that the problem is going to be noticed, much less resolved. Since their workflow probably depends on the problem being fixed, they will desperately seek out a human contact
Re: (Score:2)
To get there, you need enough developers to keep up with the flow of tickets. And as we all know, hiring enough staff to reasonably handle the workload is a concept that is mostly foreign to most for-profit businesses.
Re: (Score:2)
Re: (Score:2)
agree with the forms. You can't expect good answers if they're not replying to good questions.
the BARE minimum:
1. what were you trying to do?
2. what happened?
3. what were you actually expecting?
That's not necessarily a good list to give to a user, but this is what we tell our front line people to keep in mind when taking a call. There will be two basic limiting factors with online ticket forms. (1) people may not understand the questions and be intimidated enough to not be willing to use the system and (
Re: (Score:3)
One place I worked at recently, the users had almost totally lost confidence in the ticket system. It required me to have comprehensive personal followup on tickets for a solid year before people started trusting the system again. Techs in charge of the queue were summarily deleting vague or "cannot reproduce" tickets with not so much as a response. Tickets were also silently closed whenever a tech though they had fixed the issue. (several tickets had been freshly ressubmitted over a dozen times because the tech didn't understand the user's problem and thought he had fixed it and the user was just too dumb to realize it) Tickets that had several dups in the system from the same user or few users were deleted en mass just to clear the clutter. ("if it's still a problem I'm sure they'll submit another ticket shortly") It was terrible. They had conditioned users to submit duplicates almost daily until they thought their problem had been fixed.
Overall a great comment, but I'm puzzled by "the user was just too dumb to realize it." Chances are the user realizes exactly what is going on in that situation. Techs are closing tickets without resolving issues due to either laziness or metrics which grade them on closing tickets and not on resolving issues.
With globalization and out-sourcing, walking over to the support team and standing over someone until your issue gets attention isn't an option. Then systems are put in place so submitting a ticket
Re: (Score:2)
Or FaceTime, so you can tell them what to do and show you the result.