Software QA FYI - SQAFYI

The Path to Successful Defect Tracking

By: Tim Cares

Summary: One of the challenges all software development organizations face is how to handle the defect-tracking process. Little thought is put into designing and implementing such a system. This white paper describes why a solid defect-tracking system is necessary.

Note: This item was contributed by a StickyMinds member or affiliate. It is offered unedited in its original format.

The Path to Successful Defect Tracking
One of the challenges all software development organizations face is how to handle the defect-tracking (also known as “bug” tracking) process. Unfortunately, often, little thought is put into designing and implementing such a system. Among the reasons that a well-designed defect-tracking system is necessary:

• Traceability – You need to know what areas of the system produce the most defects.
• Accountability – Do you have weaker developers and/or QA engineers? For example: a developer who writes sloppy code will cause more defects, and a QA engineer who lacks attention to detail may miss a critical bug during the testing process.

Choosing a Defect-tracking System
When determining what type of defect-tracking system to choose, you will need to consider several elements:

• Buy or build. Depending on your budget and development resources, you will have to decide between buying a commercially-available defect-tracking system and building your own. While building your own system may be less expensive in the short-run, in the long-run, it may end up costing you more in time and money. a. If you decide to buy…

i. How much are you willing to spend? Basic software packages run from $100/license to more than $2000/license.
ii. What kind of platform do you want to use? A hard-core, commercial database solution using Oracle? Or, a scaled-down, basic system using Access? (Of course, this corresponds directly with your budget.)
iii. Nowadays, many vendors offer hosted solutions. These solutions are ideal for companies who do not have the resources to implement and maintain a system on their own.

b. If you decide to build…
i. Do you have developers who can be dedicated to the task? Depending on the complexity of the system you are going to build, you will need at least one full time developer for an extended period of time.
ii. What programming language will you use? Chances are you will be building a web-based application with a database backend. You can choose any number of languages that work well with databases; for example, Perl and Cold Fusion are two possibilities.
iii. Do you have hardware that can be used to host your application? You will most likely need a web server and a database server.

Prior to Implementation
Once you have purchased or decided to build a system, you will need to answer some basic questions:

1. Who will have access to your defect-tracking system? Which employees will have the ability to add defects? Edit defects? Which users should have the ability to change a defect’s status? These are important questions which should be determined BEFORE implementing the system.
2. How much information should you collect upon initial bug entry? If users outside of the development group (for example, support personnel) are going to enter defects, you will want to limit the required information to that easily known. Also, requiring too much information may lead to reluctance from some employees to enter defects at all. On the other hand, it is important to collect enough information for your developers to be able to research and fix the problem.
3. What should be the basic path of a defect? That is, in most defect systems, bugs are routed through various individuals/groups depending on the status, type of defect, and area of the system affected, among others. A common path of a defect traveling through the systems is as follows:

Full article...

Other Resource

... to read more articles, visit

The Path to Successful Defect Tracking