Open-Source Bug Tracking with Bugzilla
Bug Tracking Systems (BTS) have their origin in software development, but they can serve as important and useful tools in every team environment. For this reason the names Issue Tracker or Ticket System have become more appropriate.
BTS may function as a central point of communication for any team. They can increase the productivity and accountability of each employee dramatically by providing a documented work flow and allowing for positive feedback on good performance. They usually reduce downtime and production costs while increasing efficiency and, most importantly, customer satisfaction.
The open-source project Bugzilla, for example, provides an easy to use, easy to maintain and cost effective solution with a rich feature set that easily can compete with its proprietary counterparts. Bugzilla's Web interface allows cross-platform use while the XML and e-mail interfaces enable automatic error reporting. Not only can the automatic error reporting be included in the development of a new product, but it also can be integrated easily into an existing product.
This article provides an overview of how introducing Bugzilla can help your team work together and communicate more efficiently. Bugzilla uses the term bug, so I will stay with this notation throughout the article, but don't forget, it's not only about bugs, You can use Bugzilla for any task you need to track.
Bug trackers aid the whole product life-cycle. In the case of software development environments, this usually consists of software design, implementation and testing. From testing, the work flow takes it course either back to design or on to implementation for bug fixing. In the best of all worlds, at some point an error-free product leaves this cycle and gets shipped to a customer. In all other worlds, the customer is part of the development cycle and submits bugs.
Everyone in the team needs to effectively keep track of upcoming issues. Designers and developers need to be notified about new bugs and reminded of existing ones. Managers need a means to distribute upcoming bugs to the right developer and quickly acquire the status of the project. Integrators and testers need to know which issues already have been resolved and therefore require consideration in the next build and test cycle. Customers want to be able to rapidly report bugs and receive an update of their status, while help desk operators need to be able to respond quickly to such customer demands.
Most companies come to the point where they start to track those issues by way of e-mail or spreadsheet lists—some even use sticky notes. At some point, the number of issues outgrows these approaches and the number of forgotten or unresolved issues demands a better solution. Let's follow one of those teams on their path to introducing Bugzilla as its in-house BTS.
As with every software product, the introduction of a BTS in an existing work flow requires initial thought and planning. The goal is for all participants to accept and use the new system, meaning that its introduction should have only a positive impact on their daily work.
As with most BTS, bugs in Bugzilla concern a component, which belongs to a product. A bug also may have a version and a milestone attached. Before introducing the new system, thought must be put into how its structure fits in to your daily work flow. All possible upcoming issues in your work flow should have a set place, including problems with Bugzilla itself. It often makes sense to include even trivial organizational issues that can have a large impact on development. If having sufficient blank CDs in your office is critical, you may include a shortage as a bug in Bugzilla.
Products are the main category and usually represent actual shipping products or services. You also should have a number of special products that reflect your internal work groups, like System Administration or Office Supplies.
Components are sub-sections of a product. Among others, a software product may have GUI and Database components. Your special product, system administration, may have the components Intranet Web Site, Shared Drive and Printers, to mention a few. Each component has at least one designated user that receives the error reports. Naturally you want to ensure that the workload is distributed evenly.
Versions refer to the version of your product where the bug occurred, while milestones represent target times for a bug to be fixed by. This does not necessarily need to be a date; it can be something like “When boss returns from holiday”.
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- The True Internet of Things
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- Build a “Virtual SuperComputer” with Process Virtualization
- My Network Go-Bag