Bug tracking & cane toads

This post is part of the Pride & Paradev series.


Should agile software development teams use tools to track bugs?


Don’t use a tool to track bugs

When working in a collaborative, co-located agile team working in a iterative manner, it’s often more efficient to fix bugs as they’re found than spend time raising them and tracking them using a bug tracking tool. The time spent to raise and manage a bug is often higher than actually fixing the bug, so in this case it’s better avoided.

Most testers aren’t comfortable with this approach, initially at least, because it may look like they’re not raising bugs. But a tester should never be measured on how many bugs they have raised. Doing so encourages testers to game the system by raising insignificant bugs and splitting bugs which is a waste of everyone’s time.

Once a tester realizes their job isn’t to record bugs but instead deliver bug free stories: they will be a lot more comfortable not raising and tracking bugs. The only true measurement of the quality of testing performed is bugs missed, which aren’t recorded anyway.

One approach I have taken is to simply record bugs on sticky notes or index cards stuck to the team’s story wall. This is a lightweight approach as the only time taken is to write the sticky note and once resolved, it can be scrunched into a ball: a symbolic act of squashing the bug.


Use a tool to track bugs

“What’s measured improves” ~ Peter Drucker

If you’ve got remote team members, you can’t really avoid using a tool to track bugs. It ensures you’re communicating and tracking the progress effectively across geographic borders.

Without some form of bug tracking tool in place on your project, it’s difficult to keep a historical track of bugs and how they are resolved. Without this, it may lead to some of the nastiest bugs reappearing: I call these cane toads.

Beware of Cane Toads

If you weren’t aware, cane toads are a highly invasive species of toad in Australia that were introduced to control native cane beetles, but have ended up threatening natural wildlife. They have two notable characteristics:

  1. They secrete toxic poison affecting their surroundings; and
  2. They have an uncanny ability to survive even the harshest of conditions (here in Queensland there are competitions to kill cane toads but they’re amazingly hard to kill: just when you think you’re done with one it’ll bounce back to life).

Therefore, a cane toad on a software project is an issue that:

  1. Causes other issues by secreting toxic poison; and/or
  2. Seems to come back to life even though you’re sure you’ve already killed and buried it before.

Without tracking these cane toads, and how you killed fixed them, you’ll see patterns of these reemerging. You can easily look up when it last happened, what you did then, and why it shouldn’t be happening again.

This is also why it’s really important to have automated regression tests.

You must keep bug tracking tools as lightweight as possible. These should allow rapid recording and resolution of bugs. Avoid the temptation to introduce ‘defect workflow’ of any description: empower people to do the right thing in regards to tracking and resolving bugs, don’t make it harder than it should be.

An even better approach is to incorporate bug tracking into your existing user story tracking tool. Trello allows checklists on user story cards: these are a great way to track bugs in a lightweight, flexible manner.

Trello Bug Tracking

6 thoughts on “Bug tracking & cane toads

  1. Interestingly, my group currently tracks devbugs in story cards much like you describe. We use Mingle–which to my knowledge, doesn’t offer checkboxes– and enter the bugs via ordered lists (helpful when referencing the bug in card or conversation) and strike them through when fixed.

    Now if only I knew someone at ThoughtWorks that might help lobby for adding checkboxes to Mingle :)

  2. Our company uses Trello to manage the tracking of each team’s project, and we use it for Bug Tracking as well. Nice to see Trello getting some extra love!

      • On a general scale, each dept has their own board, and works from cards and lists to drive tasks. When a bug is found, it is added as a new card. Exceptions to this rule occur when testing a new feature, then we use checklists to indicate relevant bugs to the feature being added.

        The logic to this is that a new bug that just “pops up” has no context, and we so we provide the extra info and recreation steps using the card’s features (i.e. labels, markdown, etc). When testing new features, the context is already largely known and a simple description is usually all that is needed, hence why we use checklists. Also gives the dev something to “check off” when complete.

        What would be really nice is to be able to “drill down” into a checklist item as a card in and of itself so that if extra context was needed, it could be added, and so that the card could be “checked off” along with the group of other bugs.

  3. I think you need to track bugs no matter how small. the trick is to have a bug tracking process and tool that is as easy to use as a peice of paper. Tracking them avoids the possibility of cane toads as you suggest. in my first IT job that was very agile i use to show the dev the bug then log a quick bug as a note as he fixed it. It avoided us forgetting bugs when we found them just before lunch or knock off time.

    Good post mate.

  4. I would like to appreciate you the way you have shared the post with us. It is really hard to find the quality post, but you have done this job nicely man

Comments are closed.