

The Perfect Bug Report - theli0nheart
http://dlo.me/archives/2013/02/11/the-perfect-bug-report/

======
hvidgaard
I agree on almost everything you've written, but, getting the general userbase
to understand this is... a challenge - the best we get is generally of the
form: "It's crashing when I press this button", and a stacktrace (but that is
thanks to the bug report feature).

My product have both a supporter and a product manager interacting with the
customers, and they generally file the bug reports. They have the contact with
the customer and try their best to fill out as much as possible. That said,
they're not developers and every now and then they cut the corner and need to
be reminded that "I cannot press this button" is not good enough - unless the
error is sporadic, always, and I really mean always, include a step by step
guide to reproduce and include any files or input that might be needed, and
double check that it's causing the error.

------
theli0nheart
I wrote this post with mostly small teams in mind, but I'm also curious how
much these principles apply to large tech companies such as Facebook, Google,
or Amazon. Can anyone who's worked there or been in a similar sort of place
chime in? I've only worked at smallish companies (<50 people) and startups
(including my own).

Also, all other feedback you might have is greatly appreciated :)

~~~
mmilo
I think this article is great and the first point is absolutely spot on. What
I dont’t really agree with is that teaching end-users and clients to report
issues the way developers want is the solution.

I think the communication gap between developers and non-developers can better
be resolved with intelligent software. Ideally I think this would be something
along the lines of: • automatically detect when an error happens, • provide a
list of all the actions leading up the error, • capture all the information it
can about the user that experienced the error, • take a screenshot
automatically • provide a simple way for them to communicate with devs, and
vice versa

There’s no reason why a customer should need to know about milestones,
assignment, error verification, etc... They should instead get a chance to say
they have a problem, and then be notified sometime later when that issue is
resolved.

We’re working towards this with <http://www.bugherd.com> from the bottom point
up to the first. For instance when an issue is reported in BugHerd we capture
as much user data as you can throw at us, information about the page they’re
on and optionally an automatic screenshot. Other startups like
<https://www.getsentry.com> are tackling this same thing from the other end by
focusing on the error detection side of things and working their way down.

All in all I think bug trackers that pay as much attention to end-users as
they do devs are doing it right, because as you say those are the people that
are going to be reporting the bulk of the issues and the ones devs ultimately
care about.

------
Adrock
One of our developers has this link as his permanent IM status:

<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>

It might seem a little passive-aggressive, but it's amazing what some people
consider to be a proper bug report. Try querying your tracker for issues with
the title ".* is broken".

