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
• 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
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
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:
... to read more articles, visit http://sqa.fyicenter.com/art/