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.
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:
- They secrete toxic poison affecting their surroundings; and
- 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:
- Causes other issues by secreting toxic poison; and/or
- 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.