Defect Management

Defects are the project's dirty laundry. Nobody wants to admit they'll happen, nobody wants to look at them when they do, and nobody wants to be the poor sucker who has to fix them.

Small teams may find that the simplest thing that could possibly work is to write all defects found during acceptance testing (note: not unit testing; those defects must be fixed immediately by the programmer who discovers them) on a whiteboard and check them off when they're done.

This works if your entire team is in one room and if you're doing an excellent job with collective ownership, test-first coding, and refactoring. In that case, if you find a bug during acceptance testing, your team writes an automated test for it (a unit test if possible), fixes it, and it never happens again so you never need to remember what fixed it.

If your project is large, has teams in multiple geographical locations, or has not yet been successful in mastering some XP practices such as test-first coding, you need a central way to track who's working on a bug, a history of what was done to fix it, and what module was checked into the code base when it was fixed. You might need a way to help the customer track and prioritize problems, identifying issues that must be fixed before release.

Large, complex organizations may have their defect tracking and source-code control tightly integrated, making it difficult to get a fix into a code base without using a tracking tool.

Here's an experience Lisa might like to forget:

I worked on a team developing software for an external client a large corporation. We had to use two separate bug-tracking systems. One was used during development, when most of the defects were found and fixed. During the corporation's post-development acceptance test and staging phases, which were tied to a separate source-code control system, we had to use a completely different defect management system. Having two source-code control tools and two separate bug-tracking systems required careful coordination and a lot of extra time.

Avoid this situation if you can, but if you can't, plan carefully and brainstorm ways to mitigate the risks. For example, Lisa's team decided to transfer any defects left after development was complete to the post-development defect-tracking system and track all defects for that release in one place