Defect tracker for Agile?

Tools linked to process, and process linked to tools, are always grist for debate in the agile space. Defect tracking is one of those processes that begs the question: to engage with a tool or not? Many say: put the defect on a card, put the card on a wall in the war room, and work it into the backlog as a form of requirement that is commonly labeled "technical debt".

 

For sure, that's one way to handle it. Of course, the cards are perishable. Many say: so what? Once fixed, there's no need to clutter things up with a bunch of resolved fixes.

 

Lisa Crispin and Janey Gregory, writing in their book "Agile testing: A practical guide for testers and Agile teams", have a few other ideas. From their experience, there are these reasons to use an automated tool to capture and retain trouble reports:

 

• Convenience: "If you are relying only on cards, you also need conversation. But with conversation, details get lost, and sometimes a tester forgets exactly what was done—especially if the bug was found a few days prior to the programmer tackling the issue.If you are relying only on cards, you also need conversation. But with conversation, details get lost, and sometimes a tester forgets exactly what was done—especially if the bug was found a few days prior to the programmer tackling the issue."

• Knowledge base: Probably the only reason to keep a knowledge base is for the intermittent problems that may take a long time and  a lot of context to work out. The tracker can keep notes about observations and test conditions

• Large or distributed teams: It's all about accurate communications. A large or distributed team can not use a physical war room that's in one place

• Customer suport: If a customer reports the defect, they're going to expect to be able to get accurate status. Hard to do with a card hanging on the wall if the customer isn't physically present. 

• Metrics: Agile depends on benchmarks to keep current and up to date team velocity.

• Traceability: It's always nice to know if a particular test case led to a lot of defects. Obviously, many defects will not come from a specific test; they'll be found by users. But it never hurts to know.

Of course, there a few reasons to be wary of a database-driven DTS tool.  Number one on my list is probably one that makes everyone's list:

• Communications: It's not a good idea to communicate via notes in the DTS. Communications belongs first face-to-face, and then in email or text if a record is needed. DTS is for logging, not for a substitute for getting up and talking to the counter-party.

• Lean: All tools have a bit of overhead that does not contribute directly to output. Thus, maximum lean may mean minimum tooling.

Bottom line: Use the tool! I've always had good results using tracking tools. It just take a bit of discipline to make them almost transparent day-to-day

Bookmark this on Delicious