protest: bug tracking basics


There are tons of interesting queries you can do with a decent bug database (subliminal message:  buy TFS).   Managers and leads have all sorts of ways of looking at the data.  And it can be entertaining to pull out gems from your bug database every now and then just like Google and MSN Search hacks can be entertaining.  But over time as I've tried to develop the best bug queries to use in the protest system I've gravitated towards these two simple queries that are like the daily bread and butter:

Fire in the Hole  - Query the bugs [Opened by Me, Not Closed, Not Assigned To Me] - this query lets you know which bugs you've logged that still haven't been fixed yet - and reminds you to follow up offline where necessary or make sure the backlog isn't getting to big and that you are championing all of the out of band things that can be done to increase chances of it getting fixed right.

Assigned to Me - Query the bugs [Assigned To Me, Not Closed] - this query reminds you of what bugs you have back on your plate.  Try to keep this one as small as possible, if it gets too big start prioritizing which ones to address and schedule into your calendar rather than just starting at the first one and blindly trying to go down the list.  This is an organizational technique I stole from Take Back Your Life because having a system to deal with incoming email seems similar to having a system for dealing with incoming bug work.  The way our testing game works once the bug fix comes back around, one additional prioritization factor that can be used is how likely you think it was that the fix was good enough.  For example, if there was a complicated fix vs. 20 little typo bugs, the complicated fix was riskier.  This is an exaggeration but you get the idea.  It's a game of hot potato where some of the potatos are hotter than others.  If a bug fix was inadequate, and you wasted time getting that information back to the dev team, you also wasted time they could have spent putting more work into the right fix.   They're not going to care that you immediately and painstakingly verified that all 20 of the little typos were fixed.  The lost time becomes more and more critical as deadlines get closer, triage bars get tougher, etc.  So just making sure you don't have the emphasis so much on the number of bugs that are in your queue but making sure the right bugs are getting tackled first will give the dev team the benefit of more time and they will be better able to help you build a track record of a consistently high ratio of bugs fixed to bugs logged. 

Comments (1)

  1. Eric Jarvi says:

    Over the past few years I’ve been putting together a rough collection of ideas that I use internally

Skip to main content