Bug Tracking System in an Agile enviornment

Question

I have been doing alot of research into Agile Testing including reading Agile Testing: A Practical guide... and it seems that the consensus is BTS(Bug tracking systems) are bad for Agile teams because they use valuable time logging bug reports that can sometimes turn up as duplicate issues that the dev team has already uncovered. Another con is that they put up a wall of communication between the QA and Dev team. Now i think there are alot of positives in terms of documentation and review and my boss(Team lead) seems to think it is needed.

I wanted to get feed back from the community on the opinion of BTS and how often if ever used in the Agile community. We currently use Fogbugz which is a great system in my opinion.

Answer 1

In all of the agile projects I have participated in, we have used the same mechanism to track defects as we did stories. In many, but not all of the agile projects I worked in, we did not track defects for stories in the current iteration, instead we would note the defects in the story and push it back to developing. If we found a defect outside of the stories in the current iteration, we would create a defect and it would be placed in the backlog to prioritize along side the stories.

Another approach that I haven't tried but I know is common, is to have a 0 defect policy at the end of each iteration, so if defects come up, they push out any stories and need to be addressed immediately, or are closed. This way, the backlog doesn't get filled up with minor defects that may or may not ever get prioritized. The idea is, if it is low enough priority to be postponed, that it may as well just be closed. All defects are either fixed immediately, or closed.

I think both of these approaches were relatively successful. Using a defect tracking system that is not integrated with the way you are tracking stories can make it difficult to handle defects within the same agile process.

Answer 2

Bug, story, feature request, dupe - it is hard to tell them apart when you are entering them.

So you enter them and triage them.

Quite often you may have some bugs you plan to fix, but are rare enough (affecting small minority of your customers) and minor enough that you do not want to postpone release because of them. But you still need to track those.

BTS in our organization keeps everyone on the same page, and is institutional memory - 5 years later you can see why certain decision was made.

Might also depend on the size of your team. If you have big project and big team (say, 30 developers, 10 analysts, two dozen local expert non-programmers, 5 testers, and 50-60 internal users helping 1000 external users) - will you still insist that everyone just need to sit together and talk, no BTS needed? We could not do it without BTS.

Or maybe you say that such project cannot, or should not, try to go agile?

Answer 3

I think there are two aspects when it comes to agile testing.

First of all, a modern bug tracking system must be able to adjust to your agile testing needs. We use Usersnap as our main bug tracking system and it works great with our agile approach. It allows us to have a kanban-style bug list and keep clear overview on open bugs.

And the second part is the overall agile development. As a second core system we currently rely on Trello for user stories, product roadmaps, and daily standups. Everything of those things is managed via Trello. The great thing about both solutions is that they work perfectly fine together. This means: We can manually (or automatically) send bug reports from Usersnap to Trello.