Use A Defect Tracking System

You need a defect tracking system to control and monitor the progress of your software development at addressing issues over time.

Any piece of software has a fixed number of defects at a particular point in time. This number changes as development occurs. Each defect is either known or unknown. Both classes are waiting to hit unsuspecting users, but at least your testing has uncovered the known ones. Lack of a given necessary feature is a defect, possibly due to poor stakeholder requirements evaluation. As development proceeds, defects are removed as features are added and bugs are fixed; and other defects called regressions are added unintentionally. Defects in a piece of software fall into two classes: known and unknown. You should track all known defects in a defect tracking system, and do sufficient testing to find as many unknown defects as possible.

Your defect tracking system should be integrated with your source control system. Not all defect tracking systems integrate with all source control systems; but there are sufficient well-supported configurations that it should be easy to pick a pair that work well together. Generally, all defect tracking systems have the same basic features and it is the source control systems which vary more significantly; so it makes sense to chose the most suitable source control system first, and then pick an existing defect tracking system that integrates with it. If your source control system of choice doesn't integrate with readily available defect tracking systems, then revise your choice; all the good ones I'm aware of have some basic level of integration. You want an integrated system that allows you to answer questions like “what source files changed in fixing this defect?” and “what was the rationale behind this source code change?” easily.

In very early stages of development, you don't want to get in your developers' way by restricting the changes they make to the product source tree. But as development proceeds, you will reach a point at which it should only be possible to make a source code change when there is an associated entry in the defect tracking system describing the bug being fixed or the feature being implemented by this change. You are well past this point once the first version of a product is released.

Avoid the temptation to write your own defect tracking system; there are a plethora of freely available open-source ones out there. I even suggest avoiding spending time customizing settings, like devising your own custom tracking state names. Most defect tracking systems already support the states that you need; it's unlikely your needs are truly unique in this regard. Customization can also break integration with your source control system, since they are generally separate databases with an integration harness that needs to identify well-known state names in both databases. What you really want is something that just works right out of the box, and almost all defect tracking systems will do this unless you're trying to impose an unconventional process. Avoid trying to do that. Pick a tool that already supports the process you want to use.

One really well integrated source code and defect tracking system I have used in the past is the combination of Perforce and Jira.

---

Social Bookmark this page: