|
 |
Home > Detail: Using Bug-Tracking Systems as Idea Repositories
| A StickyMinds.com Original |
|  | |
Using Bug-Tracking Systems as Idea Repositories
By Adam Kolawa
   
Summary: When unnecessary information is entered into bug-tracking systems, they are not as effective as they could be. In this article, Adam Kolawa outlines what type of information should be entered into a bug-tracking system during development and after code freeze, and how to use the information when designing future product versions. | | |
|
|
 |
In my opinion, bug-tracking systems are poorly used. Most commonly, a bug-tracking system is used as a forum that allows the development and quality assurance teams to communicate with one another about product problems. This usually results in a system that is flooded with information about simple bugs that can be detected by the test suite. I believe this approach is misguided. I have found that bug-tracking systems should be used exclusively as a place to store feedback when you cannot immediately modify the code.
Using Bug-Tracking Systems during Development
When the product is in the development stage, developers ideally build test cases as they build code. They start by adding test cases that verify that each piece of code they add or change works correctly. These test cases are collected into a regression test suite that is run on a regular basis (preferably, every night). Each time a bug is found at this stage of the development process, a developer or QA team member develops a test case that verifies whether the bug is fixed, then adds this test case to the regression test suite. Test suites are thus constantly expanded and can be used to ensure that previously detected errors do not resurface as code is modified.
At this stage in the development process, the bug-tracking system should not be used to track defects. Test cases identify each error, so entering this same error information in the bug-tracking system would be superfluous. The bug-tracking system should be used only to store ideas at this point: every time somebody has an idea for a new feature or for a better way to implement an existing feature, this idea should be entered into the bug-tracking system as a feature request.
Using Bug-Tracking Systems after a Code Freeze
Once the product enters the beta testing phase, source code is typically frozen. Because code in this stage cannot be immediately modified to respond to feedback, there is an added need for an information repository. This repository should now include both error reports and feature requests. Many companies try to enter only “real bugs” in their bug-tracking system, and soon find that there is a fine line between bugs and feature requests. While some issues (such as program crashes) are obviously bugs, classification of other “problems” is more difficult. For one person, a program lacking an expected GUI feature might be a high-priority bug; for another, it is just a feature request.
We recommend that instead of being petty and quibbling over definitions, you enter all feedback and change requests in the bug-tracking system so that you can easily access it later. For classification purposes, use “bug” to refer to a product issue that prevents a user from using the product as advertised, and call everything else a feature request.
Change requests should be recorded in the bug-tracking system throughout the code freeze stage—the time span from the initial code freeze to the day you start planning the next release. As you receive feedback, you can track the demand for each feature. The first time a feature is requested, you enter it in the bug-tracking system. Every subsequent time a user asks about that feature, you record another request for that feature. (You can store this information in any variable you like; for example, in Bugzilla, requests can be logged using the “vote” feature.) If you track requests in this manner, it will be easier to separate must-have features from eccentric ones.
Using Bug-Tracking Systems for Release Planning
When you are ready to start designing another version of the product, you can leverage the stored information to improve your product. To start, pull all feature requests from the bug-tracking system, then start prioritizing them. Priority should reflect market feedback, including the number of requests you have received for this feature.
After you have settled on the priority in which the features should ideally be implemented, you start determining the order in which you are really going to implement them. If you cannot realistically implement a feature within the time allotted for the next release, that feature needs to be saved for future releases. You can determine the feasibility of implementing any given feature request by considering how its implementation would impact the existing code base. If implementation of a high-priority feature would require only minor changes to the code base, plan to add it to the next release. However, if implementation of your most highly demanded feature will require you to completely rewrite your code base, you have two choices: save the feature for a later release, or change the release timeline so that it can be implemented.
The moment you decide to implement a feature request, remove the related entry from the bug-tracking system, create test cases that verify whether the feature is implemented thoroughly and functions correctly, then add these test cases to the regression test suite.
Once the feature is implemented, the regression test suite helps you determine whether it meets expectations and is ready to be passed on to customers.
About the Author
Adam Kolawa is the CEO of Parasoft Corporation, a leading provider of software productivity solutions. In 1987, he and a group of fellow graduate students founded Parasoft with the hopes of creating value-added products that could significantly improve software development. Kolawa’s years of experience with various development processes resulted in his unique insight into the high-tech industry and the uncanny ability to successfully identify technology trends. As a result, he has orchestrated the development of several successful commercial software products to meet growing industry needs to improve software quality—often before the trends have been widely accepted. Kolawa has been granted seven patents for the technologies behind these innovative tools. In addition, Kolawa, co-author of Bulletproofing Web Applications (Hungry Minds, 2001), has contributed to and written commentary pieces and technical articles for various leading publications such as Software Development, Java Report and SD Times. Kolawa holds a Ph.D. in theoretical physics from the California Institute of Technology. In 2001, Kolawa was awarded the Los Angeles Ernst & Young's Entrepreneur of the Year Award in the software category.
Back to Top
 |
|
|
|
 | RESOLVE SUPPORT ISSUES from your Desktop!
Minimize downtime with a remote support solution that lets you resolve issues right from the desktop
| | SOLVE SUPPORT ISSUES on the First Call!
REMOTELY CONTROL AND CONFIGURE SYSTEMS. Easily install applications, updates. All from your Desktop!
| | IMPROVE YOUR SUPPORT EFFICIENCY
WebEx lets you remotely control, configure and install applications and updates more efficiently.
| | Web based bug tracking - AdminiTrack.com
AdminiTrack offers an effective web-based bug tracking system designed for professional software development teams.
| | Census: Web-based Bug Tracking and Defect Tracking
Track software bugs, defects, enhancements, support calls, and more. Issue tracking software that is scaleable, fully customizable and integrated with VSS. Includes e-mail notifications, role-based workflow, change history, and Crystal reporting.
|
| | Get your product or service listed here.
| |
|
|
|
|
|
