Let’s face it: There is no such thing as a perfect software. There are always bugs and you don’t need to be tech-savvy to find them. It is even crucial to test software with people missing technical background – they are in general less merciful about issues which are trivial in a programmer’s eye. Getting trivial bug reports is the key to improve the usability and the user experience of web applications.
In general the person with the missing technical background will hit your inbox in this way:
I found this email-thread (It does not work) in my email-client, the communication started with “I click the button and nothing happens”, followed by a decent refinement of the issue about the color of the button (“it’s the blue one!”) and ended with a precise description of the used browser (“Explorer”). Some “I need this fixed ASAP” followed by slightly more desparate “How long will it take you to provide a solution?” didn’t speed up the process either.
It’s not your customers’ fault.
From the first email to the last it took three days with an estimated total communication time of about 2 hours, just to get enough information to be able to reproduce the bug, but this is not your clients’ fault. It simply is what he experience when he clicks on the blue button on a specific landing page of his new website in his beloved Internet Explorer 8 – it did not work. What went wrong is the way the issue was reported, but it is also not a clients’ job to provide class-A bug reports including all the information you need. He is not an expert in web development – if he was, chances are that he would not have commissioned the work
Let’s set up a new tool to track bugs!
There are a lot of great tools out there which provide exactly what’s needed to track bugs efficiently and to organize your projects. You get them in any flavour, ranging from pure bug trackers to general purpose project management tools such as Basecamp. Anyways: tools don’t solve anything, it’s the adoption of anybody involved in the projects which counts. And here’s the problem: You need your client to jump on your bandwagon. But why should he adopt your tools when he can send you an email?
Imagine sitting next to your client and he shows you what went wrong. If you are an experienced web developer, it will take you just seconds to understand where the bug occurs and which situation leads to the experienced bug.
Please send a screenshot!
Screenshots are in general the easiest way to enable your clients to show you where they found a bug. One of the best tools available is PicPick (free for non-commercial use). Microsoft Windows provides an on-board tool, the snipping tool.
A slightly different approach is used by Usersnap: adding a small snippet of code to your web project equips your customer with sticky notes and a highlighting tool. The annotated screenshots can be transfered directly to your Basecamp project and will appear as entries in your ToDo-list, including meta-information such as the used browser – your client does not have to install anything.
How do you deal with bug reports? What’s your best practices?