Three tips for better bug tracking

I recently stumbled across an old blog post by Joel Spolsky titled "Painless Bug Tracking". Even though the article was written in 2000 (eons ago in the internet age) it has a lot of valuable content for today's web developers with regards to bug tracking. For those who don't know Joel (of Trello fame) he has been in the software business for a long time. Joel's team at Fog Creek developed Fogbuz, one of the earliest bug tracking systems I can remember. 

What can web developers (and entire web teams: designers, QA, content) learn from a blog post written in 2000 ... a lot.

Three parts to a good bug report

1. Steps to reproduce
2. What did you expect to see
3. What did you see

That's a pretty short list but it's amazing how often you receive a bug report that is missing at least one of those items. Thankfully today's modern bug tracking systems (especially visual bug trackers like PageProofer) make completing that list as easy as possible. With automatic screen shots, browser and OS meta data appended to tickets and precise visual context (a marker placed exactly where the issue occurred), there should be no excuse for not having enough information when dealing with website bugs. If you still rely on manual processes (ie email, spreadsheets) to track bugs it's probably safe to say most reports do not include all three of these things. 

Top three tips for bug tracking

Joel had ten tips for good bug tracking but I think that can be boiled down to three key points (plus short lists are easier to remember). 

1. One person on a bug at a time
2. Don't accept bug reports from any other method
3. Simple is better, avoid custom solutions and information overload

1. One person at a time

Every bug needs a real person assigned to fix it. Not a team, not nobody, not some pseudo user that doesn't really exist. A real, breathing person, preferably someone in a position to fix the bug. If the assigned person can't fix the issue they need to assign it to someone else, pass it around until someone can fix it but don't let it drop (like hot potato). Ideally people will receive notifications when bugs are assigned to them, via email, Slack or whichever communication channel your team prefers.

2. Don't accept bug reports from any other method

This sounds like common sense but how many times have you encountered someone who tries to make an end run around the formal bug tracking system. There is always a list of "good" reasons why it needs to happen just this one time (I forgot my login, it's too hard to use, this is just a quick fix). In agency circles, external clients are infamous for sending in bug reports as emails. As soon as people start circumventing the system your team has in place it is only a matter of time before the system becomes useless. Bug tracking systems make it possible for developers to deal with bugs in the most efficient manner possible. Taking short cuts kills that efficiency because you lose the best way to capture the three key parts of a good bug report. 

3. Simple is better

I am a huge advocate of the KISS principle. It's why I built PageProofer and it's why I love Trello, black & white websites and IKEA furniture. I like things simple. Most bug tracking systems capture information at a level of detail that is sufficient for the development teams the system is primarily intended for. This is especially true for visual bug trackers being used on websites. The good ones get the details and nothing but. A good bug report should be boiled down to the bare minimum. What is the issue, who found it, who is responsible for it and is it fixed. Adding extra fields and giving more information isn't the solution, giving better details in the notes is. More is not better. As soon as you start adding fields and forms, multiple statuses and workflows the system you want everyone to use becomes the system everyone wants to avoid because it is too difficult to use. 

Kudo's to Joel for outlining some timeless points to good bug reporting. If your team does website development and does not have a visual bug tracking system in place checkout PageProofer. It was built from the ground up with these principles in mind.