Bugs in Bugzilla

Now that Bugzilla is up and running with some basic configuration settings, we can begin using it to track project defects. Before there can be bugs and feature requests, there must be a development effort created in Bugzilla. In the following sections we show how Bugzilla represents a development effort, and then we walk through the life cycle of a bug.

Setting Up the Sample Product

In order to demonstrate how you might use Bugzilla on a real project, we will set up a sample product for which to track defects.

The Product

The first step in tracking defects for a software project is to create it in Bugzilla. Bugzilla calls this a product. Bugzilla can store many products. To learn how to have some isolation between the stakeholders of multiple products in the same Bugzilla instance, see the section on security later. In these examples, we'll be able to create a product complete with versions and components and begin entering bugs.

The Component

Bugzilla calls all the pieces of a software development project components. The granularity of a component in Bugzilla deserves some attention. Remember that Bugzilla supports open communication very well, and in an ideal situation end-users and quality assurance professionals will be using Bugzilla to communicate with the software development team. Therefore, it makes the most sense for a component to be a unit of functionality that a non-programmer can relate to and comment on without talking about code. That said, the development team might also wish to create components that are strictly coding constructs so that Bugzilla can help keep track of tasks and defects on those modules. Refer to the table below to get an idea of how to represent components in Bugzilla.

Programmer Components

End-User Components

Build script

Login screen

DB Connection Manager

Update employee records form

JUnit tests

Step 1--Create a Product

Select Products from the list of Edit links, as shown previously. This brings you to a screen showing a list of products in the system. Right now the screen contains only a test product, but there is a link to add a new product. Select that link, and enter the information for our sample product, as shown below.

The Product and Description fields cannot be explained better than their names do. Leave Closed For Bug Entry unchecked so we can enter some defects against some components in this product a little later. And finally, ignore the three settings related to voting for now. An in-depth voting example will be covered later in this appendix. Enter 1.0 in the Version box. This is the only product version we'll need for these examples, but you are free to enter more versions to coincide with important milestones for your real-world products. Click Add to save the product, and move on to Step 2.

Step 2--Create a Component

Return to the product screen and you should now see the newly created Projosdev product. The first column shows Edit Product, and the product name is a hyperlink. Follow this hyperlink and you will see a screen similar to the one shown previously, with some additional options. Near the bottom of the Edit Product area is another hyperlink called Edit Components, which is followed by the red text Missing. Following the Edit Components hyperlink leads to a screen with the heading Select Components Of Projosdev right below the Bugzilla heading. At the right of this table is a hyperlink called Add A New Component. Following this leads finally to another administration screen used to create the details of the component. Enter the data for a login screen, as shown in the next figure.

Since there is currently only one user in the system, enter the administrator e-mail address as Initial Owner of the component. Click the Add button to save the component. Bugzilla confirms that the component was added to Projosdev. Follow the steps above and add another example component to the product. Enter Employee Dependents Page and Administer Family Coverage Information for the Component and Description, respectively.

Entering Bugs

With a product and two child components created in the system, defect tracking can at last begin. Navigate back to the Bugzilla home screen, and take a look at the Actions menu, shown in the next figure. For non-administrative tasks this is where most of the interaction with Bugzilla will take place. Usually you must be logged in to enter bugs. You can also create a login on the fly as you create the bug, and Bugzilla will send a password to the e-mail address entered. Once you use this e-mail address to enter the bug, you will be notified of changes to the bug in the future. If this is not what you want, Bugzilla clearly gives you the option to change the kinds of e-mails you get from Bugzilla when you perform actions.

Select New from the Actions menu. You are greeted with a screen showing the available products in the system. Select Projosdev from the list of available projects to view the bug entry screen. Enter the information as shown in the next figure, and click Commit. Be sure to enter the administrator e-mail address you used to set up Bugzilla in the Assigned To field.

There are a few other interesting parts to this screen other than the bug entry itself. At the top are three links of interest:

The bug entry fields on this screen should be fairly self-explanatory. Select the product and version on which the bug was encountered, and fill in the rest of the information. The most important fields are the Summary and Description fields. These will help developers supporting the product re-create and eventually fix the bug. Once you select Commit, the page redirects you to the screen shown below, where you can enter more detailed information about the defect.

Once the bug has been created there are more options here. Try creating two or three more bugs for both of the components defined under our Projosdev project. Leave them assigned to the default owner for now. With the default settings, Bugzilla will not send any e-mail based on the bugs created here because they are assigned to the default user. However, if you change these settings or use Bugzilla on a project where bugs are being assigned to you, Bugzilla will send you e-mail. Here is an example Bugzilla e-mail: 

Date: Mon, 26 Jan 2004 22:33:20 -0500 From: bugzilla-daemon@localhost.localdomain To: your@bugmenot.com Subject: [Bug 3] New: Icons http://www.yourbugzilla.com/bugzilla/show_bug.cgi?id=3
 Summary: Icons
 Product: Projosdev
 Version: 1.0
 Platform: PC
 OS/Version: Windows XP
 Status: NEW
 Severity: enhancement
 Priority: P5
 Component: Employee Dependents Page
 AssignedTo: you@bugmenot.com
 ReportedBy: someone-else@bugmenot.com Can we change the color of the icons to Cornflower Blue?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You reported the bug, or are watching the reporter.

The e-mail contains a summary of the bug parameters entered. Below the ReportedBy field is the description the bug reporter entered when creating the bug.

Maintaining Bugs--The Lifecycle of a Bug

Each new bug in Bugzilla is assigned to a user in the system or the administrator if the bug enterer did not choose another user to assign the bug to. The recipient then receives an e-mail from Bugzilla with the bug summary shown above. From this point, there are three main phases that a bug goes through in Bugzilla. First, the bug enters an investigation phase, where the project team determines what to do with the bug. Next, the bug enters its active phase, during which a resolution is sought for the defect. Finally, the bug enters the resolution phase, where the bug is put to rest and notes are taken as to the solution to the defect:

  1. Once a bug has been entered, the assignee investigates the bug. The assignee may know immediately that the bug is invalid or that it has already been reported as another bug. One of several things will occur in the investigation stage:
    • The assignee determines that the bug has already been reported. The assignee edits the bug definition, changing its status to Duplicate of Bug # X.
    • The assignee determines that the bug may or may not be valid, but another person on the project team is best equipped to answer that question. The assignee chooses either to reassign the bug giving the e-mail address of the person best able to handle it or, if the owner of the component is not known, to select Reassign Bug To Owner Of Selected Component upon determining which component of the product the bug deals with. The new assignee is notified and begins investigating the bug.
    • The assignee accepts responsibility for the defect, and the bug enters the active phase.
  2. The active phase of a bug is really the time during which the assignee attempts to resolve the defect. This may require fixing code, clarifying requirements, or proving that the bug was never really a bug in the first place. Also during this phase, voting can occur. We discuss voting in detail a little later.
  3. The bug is resolved when the assignee feels that a conclusion has been reached regarding the defect. The most obvious way to resolve a bug is to change some code and verify that the undesired behavior no longer exists. This may be the most common solution. Assignees do have at their disposal other ways of responding to defects entered. The assignee can resolve the bug as INVALID, meaning the bug isn't a bug-perhaps it's a feature? Upon investigation the assignee can also resolve the bug as status WONTFIX, meaning that for some reason he has no intention of ever addressing the defect. A status of LATER indicates the problem is real but may be intended to be addressed in the future; the same goes for REMIND. Last, the status WORKSFORME indicates that the bug may or may not be valid but was unable to be reproduced by the assignee.

When the resolution status of a bug changes, interested parties such as the original bug parties have a chance at recourse. When the status of a bug is changed to RESOLVED, that does not necessarily mean its life is over. Rather, the bug resolution is awaiting approval of some sort. The bug can be reopened, indicating to the assignee that the resolution was unsatisfactory. The bug would then reenter the bug life cycle, most likely in the active phase. The status of the bug can also be changed to VERIFIED, indicating that the solution was satisfactory and the bug is dead.

You control the lifecycle of the bug by changing its status near the bottom of the Show Bug page (see the previous figure).

Searching for Bugs

There are several ways to search for bugs in Bugzilla. Some are easy, and some, like the full query screen shown in the next figure, can be quite daunting. In this section you will learn how to look for bugs in Bugzilla.

By Bug Number

This is the easiest method. If you already know the bug number because you have been working with it before, go to the Actions menu pictured in previous figures, and enter the bug number to bring up the screen containing all the necessary data.

The Full Query Screen

At first sight the Bugzilla Search for Bugs screen can be somewhat daunting because of the number of fields. It is easy to master this screen by deconstructing it into its components (see the last figure). Here is a brief explanation of the search fields.

One question may arise by looking at all of these fields: Is this a large AND query or a large OR query? The answer is both. All of the query options are ANDed together to create the Bugzilla search. Multiple-select fields such as Status and Resolution are appended as AND parameters created as aggregates of all selected values. So, to get a feel for how Bugzilla is going to search, navigate to the query screen shown in the following figure. If you enter a product of Projosdev, a component of Login Page, a Status of NEW, ASSIGNED, and REOPENED, and a Severity of Critical and Trivial, you can expect the query logic to look something like the following query pseudocode: 

Select * from bugs where product='projosdev' AND component='LoginPage' AND (status='NEW' OR status='ASSIGNED' OR status='REOPENED') AND (severity='critical' OR severity='trivial')

Any fields left out won't be included; so in the example shown in the next figure, bugs would be returned for all versions of Projosdev and so on. Following the hyperlink in the ID column will lead to the bug maintenance screen for that bug.

By Preset Queries

Bugzilla allows you to save this query to be used again in the future from the query.cgi page. This allows you to create a shortcut to avoid the hassle of entering all the search criteria again. By default, Bugzilla installs one preset query titled My Bugs. This query returns all bugs of any open status for all products, components, versions, etc. that belong to the currently logged-in user.

When would you want to create more preset queries? Any particularly evil set of criteria is worth saving a query for. Also, if you are responsible for mentoring other developers and keeping track of their progress, you could save a preset query for their bugs. The same is true for tracking bug traffic for an entire product you might be responsible for.