This is the 4th part of the series that presents a test similar to The Joel Test: 12 Steps to Better Code, but for developers rather than companies.  Previous entries: part 1, part 2, and part 3.

The Joel Test:
4. Do you have a bug database?

The Big Swinging Developer Test:
4. Can you recommend at least 2 pieces of software for your team to create a bug database?

Defect tracking has come a long way since Joel posed his question more than 8 years ago.  His company, Fog Creek Software, makes a great one called FogBugz.  There are many others such as open source Bugzilla, HP’s Quality Center (formerly Mercury Quality Center), and one of my favorites: trac.

Just like recommending an automated build solution,  recommending a bug database comes down 2 things: What have you used?  Why do you like it?  This is an area where open source and free trial periods really shine.  If you’ve used bug databases before, but never set one up, I recommend that you give it a shot.  In general the installation is a breeze, or in the case of hosted solutions it’s non-existent.  Post-installation is where the real fun begins.

Configuring a bug database is really an exercise in designing a QA process.  What severity levels will you use?  What categories do you break things into?  Do you segregate defects, enhancements, and feature requests?  Other than Open and Closed, what states will you put a record in?  I’ve said it many times, but I’ll keep repeating it throughout these posts: It’s not about the tools and technology, it’s about the process and behaviors.  Sure, it’s helpful to know about the platforms and integration points of a handful of bug databases available so you’re ready when the time comes.  The real value, however, is in having thought through the defect process and being able to recommend something that fits the need, not just the requirement.