Bug Tracking Made Simple
While malicious computer viruses and Trojan horses grab headlines, humble software bugs innocently wreak havoc on software users and cost the economy billions of dollars. Luckily, the science of bug tracking has kept pace with the times.
In this article, we'll show you the need for bug tracking tools, what bug tracking software is, and take you step by step through the bug tracking process. We'll conclude with a checklist of what to look for in a bug tracking tool. By the time you finish this article, you should have a good understanding of the process and know what to look for in a product.
To begin with, vendors are under pressure to get products to market quickly, and software bugs have become an accepted cost of doing business in the technology world. However, what's less acknowledged is what a big financial drain bugs can be. A federal study, for example, estimated that software bugs cost the US economy nearly $60 billion annually with more than a third of the cost borne by developers and the remainder by end users and vendors1.
The study, commissioned in 2002 by the National Institute of Standards and Technology (NIST), also found that while not all the costs could be eliminated, a significant $22.2 billion could be removed by an improved testing structure that provides earlier and more effective identification and removal of software defects.
How do you provide a structure that allows you to do just that?
The good news is that there are systematic ways to eliminate software bugs—before a product is released. Over the last few years, bug tracking tools have emerged; they provide a rigor to the development process and that has resulted in less bug-ridden software.
Bug tracking done right is a process for insuring that bugs that are identified don't get lost as a result of poor reporting and tracking.
Up until four years ago, many companies did not use any bug tracking software because most of the tools were very expensive and required installation of software and additional hardware like Web and database servers as well as ongoing continuous maintenance. A large company could easily spend $100,000 on bug tracking software. Instead, most companies jerry-rigged their own tracking products using an Excel spreadsheet or Word document or developers simply e-mailed one another about bugs.
The difficulty with these improvised methods is that bugs got lost. There was no closed loop process to insure that every bug identified got fixed. It was all too easy to e-mail someone about a bug and then quickly forget about it.
Enter Web-Based Bug Tracking
About four years ago, Web-based bug tracking products first appeared. Suddenly, what had once been prohibitively expensive was now within reach of most companies. A typical Web-based bug tracking product retails for under $50 a month and allows unlimited users. Web-based products are normally much less expensive than licensed software because they require no server or database, installation, or maintenance. In addition, many do not charge a per user fee.
An Effective Bug Tracking Process
Here is a step-by-step look at how bug tracking works. Figure 1 shows the close-looped nature of the process.
Figure 1: The bug tracking process
A testing team that bears responsibility for fixing software bugs is created. Internal releases are sent to the team by R&D, which runs tests on them to identify bugs. Bugs that are discovered are logged into a bug tracking tool. It's very important that each bug be identified as a separate issue and be given a unique ID number. That way, each bug can be identified easily and assigned to a particular person to be fixed. New bugs are assigned with a 'Open' or 'New' status.
A product manager or team leader reviews the new bugs and assigns them to R&D members to fix. The manager also classifies each bug by its priority and severity, as shown in Table 1. Those with the highest priority and severity are fixed first, as shown in Table 2.
Table 1: Priority table
|1||Immediate||The bug should be resolved immediately.|
|2||High||This bug should be resolved as soon as possible in the normal course of development activity, before the software is released.|
|3||Medium||This bug should be repaired after serious bugs have been fixed.|
|4||Low||It can be resolved in a future major system revision, or not be resolved at all.|
Table 2: Severity Table
|1||Critical||The bug causes a failure of the complete software system, subsystem, or a program within the system.|
|2||High||The bug does not cause a failure, but causes the system to produce incorrect, incomplete, or inconsistent results, or impairs the system usability.|
|3||Medium||The bug does not cause a failure, does not impair usability, and does not interfere with the fluent work of the system and programs.|
|4||Low||The bug is an aesthetic, is an enhancement, or is a result of non-conformance to a standard.|
R&D, using the bug tracking system, creates a report of all open bugs assigned to them and fixes them according to the priority and severity set by the product manager. Once a bug is fixed, R&D changes its status in the bug tracking database to 'Fixed'. It is very important that R&D not be given the option to close a bug. That eliminates the temptation to close a bug without fixing it.
R&D releases a new internal product version with the identified issues fixed and with new features.
The testing team, using the bug tracking tool, creates a report of all fixed bugs. It checks its report against the new release to be sure that all identified bugs have been fixed.
The testing team changes the status of all fixed bugs to 'Closed'. Any bugs that haven't been fixed are changed to 'Open'. Return to Step One.
Page 1 of 2