Bugzilla Basics

An Introductory User Guide to Bugzilla

September 2006 Version 1.0

Prepared by Kelly Batstone, Content and Usability The Benefit Bank Solutions for Progress

Table of Contents
1. Introduction............................................................................................................................. 3 2. What is Bugzilla? ................................................................................................................... 4 3. Getting Started ....................................................................................................................... 5 3.1. Accounts........................................................................................................................... 5 3.2. Logon Names and Passwords.................................................................................... 5 3.3. Logging On to Bugzilla................................................................................................. 5 3.4. Changing Your Password ............................................................................................ 6 4. Searching for Bugs ............................................................................................................... 9 4.1. Search Existing Bug Reports...................................................................................... 9 4.1.1. Find a Specific Bug .............................................................................................. 10 4.1.2. Advanced Search.................................................................................................. 11 4.1.2.1. Top..................................................................................................................... 11 4.1.2.2. Middle ............................................................................................................... 16 4.1.2.3. Bottom .............................................................................................................. 24 4.2. Search ............................................................................................................................. 25 4.3. Reading the Search Results...................................................................................... 25 4.3.1 What Happens Next? ............................................................................................ 27 5. Reporting Bugs .................................................................................................................... 28 5.1. The Enter Bug Page..................................................................................................... 28 5.2. The Enter Bug: Product Page ................................................................................... 29 5.3. Following Up on Bugs You Report.......................................................................... 34 6. Managing Bugs Assigned to You.................................................................................... 35 7. Bugzilla Etiquette................................................................................................................. 39 Appendix 1: Steps to Bug Reporting (in Brief) ................................................................ 41 Appendix 2: Steps for Managing Your Bugs (in Brief)................................................... 42 Appendix 3: Lifecycle of a Bug ............................................................................................ 43 Index ............................................................................................................................................ 44 List of Figures ........................................................................................................................... 46

Bugzilla Basics
1. Introduction
Bugzilla is the free program that The Benefit Bank uses to report and keep track of errors in its software. This document outlines only a few of Bugzillas features, from the perspective of someone who has never used Bugzilla before. While it does not cover all of Bugzillas features, it provides enough information for the average The Benefit Bank employee to successfully use the program. Bugzilla Basics covers information on setting up an account, logging on, searching bug reports, reporting bugs, managing bugs, and Bugzilla etiquette. Along with the very detailed sections on searching, bug reporting, and bug managing, there are also cheat sheet sections (added as appendices) that summarize the steps involved in bug reporting and managing. In this way, if you are already familiar with Bugzilla but need a reminder of appropriate procedure, you do not need to read the whole guide. In addition, a useful chart, Lifecycle of a Bug, is included to demonstrate what happens with a bug from the moment it is created until it is closed. If you are interested in learning more about Bugzilla and its other features, visit the Bugzilla website at http://www.bugzilla.org. Please send any comments or suggestions regarding Bugzilla Basics to Kelly Batstone (Content and Usability): kbatstone@thebenefitbank.com. Please send any comments regarding the Bugzilla software itself to the Systems team at The Benefit Bank, particularly Thomas Thurman: tthurman@thebenefitbank.com.

2. What is Bugzilla?
Bugzilla is the free program that Solutions for Progress uses to report problems, called bugs, with The Benefit Bank online software. It allows you to report bugs in a detailed, organized way to the people who can fix them. Bugzilla also lets you track the status of bugs that have been reported, search for reported bugs, and work collaboratively where necessary to fix problems.

3. Getting Started
3.1. Accounts
To use Bugzilla, you need a Bugzilla account. To receive an account, contact Yashar Rafi (yrafi@thebenefitbank.com). He will set up an account for you.

3.2. Logon Names and Passwords

You can access your account using your logon name and password. Your logon name follows the same format as your other The Benefit Bank logon names: firstinitiallastname@thebenefitbank.com Your pre-assigned password is: default. For example, John Does logon information is: Logon name: jdoe@thebenefitbank.com Password: default You should change your password when you first logon to Bugzilla (see section 3.4. Changing Your Password for information on how to change your password).

3.3. Logging On to Bugzilla

Once your account has been created, you can logon to Bugzilla using your logon name and default password. To do this:
Figure 1: Bugzilla Homepage

1. Type the TBB Bugzilla homepage address (http://bugzilla.tbb/cgi-bin/bugzilla/index.cgi) into the address bar of your web browser 1 , as in Figure 1 (to the left).

2. Hit Enter on your keyboard. You will be taken to The Benefit Banks Bugzilla Main Page, which looks like this:

Microsoft Explorer is the web browser used in all examples.

Figure 2: Bugzilla Main Page: Logging On

1 2

3. Locate the Login and Password fields on the screen. They are labeled 1 in Figure 2 above. 4. Type your logon name in the Login field, and your password in the Password field (see section 3.2. Logon Names and Passwords for information on how to get a logon name and password). 5. Click the Login button. It is labeled 2 in Figure 2 above. You are logged onto Bugzilla now.

3.4. Changing Your Password

The first time you logon to Bugzilla, you should change your password so no one else can access your account. To do this, go to the Bugzilla Main Page (see Figure 3).

Figure 3: Bugzilla Main Page: Changing Password

1. Click on the Change password or user preferences link. It is labeled 1 in Figure 3 above. You will be taken to the User Preferences page, which looks like this:
Figure 4: Bugzilla User Preferences Page

2. Follow the on-screen instructions to change your password. 3. Click the Submit Changes button. It is labeled 1 in Figure 4 above. 4. You will see the User Preferences (see Figure 4 above) again. It will look exactly as it did before, except it will say The changes to your account preferences have been saved in red, above the Account Preferences title, like this (the new text is circled in blue in Figure 5 below):
Figure 5: Bugzilla User Preferences Page Confirmed Changes

5. Your new password has been saved. (Note: To get back to the Bugzilla main page from the User Preferences page, click on the Home link at the bottom of the screen. See Figure 4; the Home link is at the bottom left of the figure.)

4. Searching for Bugs

Once you are logged on to Bugzilla and have changed your password, you are ready to use the program to report bugs. There are several steps to bug reporting. See Appendix 1 for a summary of the bug reporting process. If you think you have found a new bug, the first thing you need to do is search Bugzilla to make sure that no one else has already reported it. On the Bugzilla Main Page there are two places where you can begin to search through existing bug reports: Search existing bug reports (near the top-left of the screen; indicated in a red circle in Figure 6 below) and Search (at the bottom of the screen; indicated in a green square in Figure 6 below):
Figure 6: Bugzilla Main Page Search Options

4.1. Search Existing Bug Reports

Selecting Search existing bug reports will take you to a tabbed search page, where you have the options of Find a Specific Bug or Advanced Search. The page looks like this, with Find a Specific Bug as the default option:

Figure 7: Bugzilla Find a Specific Bug

4.1.1. Find a Specific Bug

Find a Specific Bug is the basic search tool. It allows you to look for bugs based on key words that may appear in the bug report, in conjunction with what sections of The Benefit Bank the bug may appear in. As you can see in Figure 7 above, there are three fields that you can alter to search for bugs: Status, Product, and Words. 1. Status

Figure 8: How to Search Using Find a Specific Bug 1. Select the Status and Product that you want to search under. 2. Enter the key words you want to search for in the Word field. 2. Click the Search button (see Figure 7).

Status defines what state a bug is in whether its a new bug, You will go to a page of search right up to whether it has been fixed and confirmed as fixed. results. Looking at the results While on other pages of Bugzilla you can choose more specific should be able to tell you if a bug statuses for bugs (such as New, Assigned, Invalid, and so on), report already exists for the bug for the Find a Specific Bug you found. See section 4.3. page, you have the option Figure 8: Status Options Menu Reading the Search Results for of searching for bugs in one an explanation of how to read the of only three broader search results. statuses. Clicking on the small arrow next to the status field displays your three choices (see Figure 8). Open: Bugs that are in the open status have been reported, and have not yet been closed by the person who assigned them. They may or may not have been fixed. Choosing Open lets you search for only bugs in the open status. Closed: Bugs in the closed status have been reported, dealt with, verified as done, and then closed. Choosing Closed lets you search for only bugs in the closed status. All: Choosing All lets you search through all the bugs, whether open or closed. Tip: If you are looking for a bug for the first time to see if its been reported already, it is best to choose the All option.

10

2. Product Product defines which part or version of The Benefit Bank you want to look in to find the bug. You can search in a few different products. Clicking on the small arrow next to the product field displays your choices (see Figure 9).
Figure 9: Product Options

All: Choosing All lets you search through all the different products. Master List: Choosing Master List lets you search through the master list of bugs. SfP Website: Choosing SfP Website lets you search for all bugs reported for the Solutions for Progress (SfP) website. You will not find bugs related to The Benefit Bank software by searching SfP Website as the product.

TBBv1: Choosing TBBv1 lets you search for bugs reported with The Benefit Bank version 1 (TBBv1) as the product. TBBv1 is no longer in active development, so its unlikely that you will have to search for an existing bug in this product. TBBv2: Choosing TBBv2 lets you search for bugs reported with The Benefit Bank version 2 (TBBv2) as the product. TBBv2 is in active development. You will probably search for bugs in this product often. Translation TBBv2: Choosing Translation TBBv2 lets you search for translation bugs related to The Benefit Bank version 2 (TBBv2). Tip: If you are unsure what product your bug may be in, it is best to choose All.

3. Words The Words field is where you type search terms, or keywords, for your bugs.

Tip: Some of the best search terms are identifying numbers, like BNode, GQ, or CQ numbers. Search using the last three- to five digits of these numbers, since they always have the same format (for example, to search for CQ000-001-421, search for CQ1421).

4.1.2. Advanced Search

The Advanced Search tab, the other option when you choose Search existing bug reports on the Bugzilla Main Page, lets you provide much more detail in your bug searches, and lets you search through means other than Words, Status, or Product. Because of this, the page is much more detailed than the Find a Specific Bug page. The page is divided into three different parts, which we will call informally Top, Middle, and Bottom. All three parts work together to help you define your search. The three parts are separated on-screen by a line. Below are descriptions of the features of each of the different parts.

4.1.2.1. Top
The top of the Advanced Search screen looks like this (the different features are numbered from 1 to 8, in red):

11

Figure 10: Bugzilla Advanced Search Page Top

1 2 3 4

5 6 7 Here is an explanation of each feature. The numbers refer to the same numbers in the picture above: Here is an explanation of each feature. Numbers correspond to the numbers in red in Figure 10. 1. Summary
Figure 11: Summary Drop-Down Menu

Summary refers to the short summary of the problem that the bug reporter wrote in their bug report (see section 5.2., p. 32 for details on what information a summary should contain). By selecting one of the eight options from the Summary drop-down menu (see Figure 11; clicking on the small arrow reveals the dropdown menu) and typing words into the empty field beside it, you can search the summaries of bug reports. The summary options are: Summary Option contains all of the words/strings Means Your search will return bugs that have all of the words that you enter in their summaries, as well as all the strings (a string is a specific group of letters that occur in a specific order), regardless of the order in which the words or strings appear in the summaries.

Example: means that your search will return bugs that have both the words clarifying and question, along with the string wr (for example, as in the word wrong) in their summaries.

contains any of the words/strings

Your search will return bugs that have at least one of the words or strings that you enter in their summaries.

Example:

means that your search will return bugs that have at least one (but not necessarily more than one) of the words clarifying or question, or the string wr (for example, as in the word wrong).

12

contains the string

Your search will return bugs that contain any words with the string you specify in them.

Example:

means that your search will return bugs that have the words containing wr in that specific order (such as wrong, written, write, etc.) in their summaries.

contains the string (exact case)

This is like choosing contains the string, except the search will pay attention to the case (whether or not words are capitalized) that your text is in.

Example:

will return only bugs that have the string wr in their summaries, with both letters lower-case. It will not include any bugs that have the same string, except with either the w, the r, or both capitalized. So, it will return bugs with wrong in them, but not Wrong, WRONG, wRong, etc.

will return only bugs that have the string Wr in their summaries, where the w is upper-case but the r is lower-case. It will not include any bugs that have the same string, except with the w in lower-case, or the r in upper-case. So, it will return bugs with the word Wrong in them, but not wrong or WRONG or wRong

contains all of the words

Your search will return bugs that have all of the words that you enter in their summaries, regardless of the order in which those words appear in the summaries. Unlike contains all words/strings, It will not search for strings

Example:

will return bugs with the words clarifying, question, and in in their summaries (such as a summary that says: Clarifying question is in the wrong place). It will not return bugs with the words clarifying, question, and in, where in is meant as a string in their summaries (such as a summary like: Clarifying question is inside the BN, not the GQ).

contains any of the words

Your search will return bugs that have at least one (but not necessarily more than that) of the words that you enter in their summaries.

Example:

will return bugs with both the words clarifying and question in their summaries, along with bugs containing the word clarifying but not the word question, and bugs containing the word question but not the word clarifying.

13

matches the regexp

Regexp is short for regular expression. Regular expressions describe a set of strings. They are written in their own special way, using parentheses to group things, and different characters to indicate how to search. If you do not know the syntax conventions for regular expressions, it is probably best not to search using this option.

Example:

will return bugs whose summaries contain either the word color, the word colour, or both.

doesnt match the regexp

Your search will return bug reports whose summaries do not contain matches for the regular expression you enter (see matches the regexp above to learn more about regular expressions). If you do not know the syntax conventions for regular expressions, it is probably best not to search using this option.

2. Product Product defines which part or version of The Benefit Bank you want to look in to find the bug. There are five different products you can search in: Product Master List Choosing it lets you search for bugs in the Master List of bugs

SfP Website

bugs reported with the Solutions for Progress (SfP) Website as the product. These bugs should only be related to the Solutions for Progress website, and not for The Benefit Bank software.

TBBv1

bugs reported with The Benefit Bank version 1 (TBBv1) as the product. TBBv1 is no longer in active development, so its unlikely that you will have to search for an existing bug in this product.

TBBv2

bugs reported with The Benefit Bank version 2 (TBBv2) as the product. TBBv2 is in active development. You will probably search for bugs in this product often.

Translation TBBv2

translation bugs related to The Benefit Bank version 2 (TBBv2).

You can choose to search in only one product, or in more than one. To choose more than one product, hold down the Ctrl key on your keyboard while using your mouse to select the other products you want to include. Tip: If you are unsure what product the bug may be in, it is best to select all of them.

14

3. Component Component defines the specific module of The Benefit Bank in which the bug occurs. You can search for a bug in any module of The Benefit Bank. For example, if you were looking through the 2005 Pennsylvania Property Tax or Rent Rebate Module when you found your bug, you would choose PA Rebate 2005 as the component when you search to see if a report for your bug already exists. As new modules develop, the component list grows. Tip: If you are unsure which component you see the bug in, select more than one, or even all, of the components by holding down the Ctrl key on your keyboard while you use your mouse to select components. 4. Version Version is which version of The Benefit Bank you were working in when you found the bug. Three items are listed under version: Version Other What it is any version of The Benefit Bank other than the current version in development

Unspecified

no specific version

v2

Version 2 of The Benefit Bank. This is the version that is currently in development, and thus will probably be the version you report most bugs in.

As The Benefit Bank grows, the options under Version will grow with it as necessary. Tip: If you are unsure which version you see the bug in, select more than one, or even all, of the versions by holding down the Ctrl key on your keyboard while you use your mouse to select versions. 5. A Comment Like searching in Summary (see 1. Summary above), you can search for specific words inside the comments of a bug report to see if your bug already exists. The comments are the places where people describe the problem they have found, and where the assignee, and possibly others, address the issue or add further information. You can search the comments for the same things you search summaries for strings, words, and regular expressions. Please see 1. Summary (above) for information on what each of the search options will do. 6. A URL Like searching in Summary (see 1. Summary above), you can search for specific words inside the URL (Universal Resource Locator; it is the address of a webpage) of a bug report to see if your bug already exists. Not all bug reports have URLs; only reports where the reporter indicated one have them. You can search the URLs for the same things you search summaries for strings, words, and regular expressions. Please see 1. Summary (above) for information on what each of the search options will do. 7. Whiteboard Like searching in Summary (see 1. Summary above), you can search for specific words inside the whiteboard of a bug report to see if your bug already exists. The whiteboard, or status whiteboard, is a

15

place where people can write short notes about a bug. The whiteboard is not used very often within The Benefit Bank bug reporting, so you may not find it very useful for searching. However, you can search it for the same things you search Summaries for strings, words, and regular expressions, if you want to. Please see 1. Summary (above) for information on what each of the search options will do. 8. Search button This is one of two Search buttons on the Advanced Search page. After entering or selecting all of your search criteria, click on the Search button. Bugzilla will do the search for you, and return search results (for information on how to read search results, see section 4.3. Reading the Search Results).

4.1.2.2. Middle
The middle of the Advanced Search page can be seen in Figure 12. The different features are numbered from 9 to 19, in red, and explained below.
Figure 12: Bugzilla Advanced Search Page Middle

10

11

12

13

14

15

16

17 18 19 9. Status Status defines what state a bug is in. Unlike in the Search for a specific bug option, though, in the Advanced Search option you can search for bugs in a wide range of statuses. See the sidebar for information on what the different statuses are. You can search by one or more statuses. To search for multiple statuses, hold down the Ctrl key on your keyboard while selecting the different status options you would like to search under. Tip: When searching by status to see if a bug you have found already exists, its usually best to select all the status options.

Bug Statuses UNCONFIRMED: This status is not used in TBB. NEW: Bug added to assignee's bug list, but not accepted or fixed. ASSIGNED: Bug assigned to the proper person but not fixed. REOPENED: Bug fixed, but fix was deemed incorrect. RESOLVED: Bug fixed; reporter must verify the fix and close the bug. CLOSED: Bug is dead, the resolution is correct.

10. Resolution Resolution indicates what happened to the bug. Only bugs that have been dealt with show a resolution; bugs in the New, Assigned, or Reopened statuses are not considered having been dealt with, so they show no resolution. Bugs in other statuses (Resolved, Verified, Closed) can have one of several resolutions:

16

Resolution FIXED

What it Means The bug has been fixed and tested by the assignee.

INVALID

The problem described is not a bug.

WONTFIX

The problem described is a bug which will never be fixed.

LATER

The problem is a bug, but for some reason the assignee cannot deal with it now, and will revisit the issue later. Bugs can be marked as LATER if, for instance, the fix requires updates based on research that is not yet available.

REMIND

This option is not used in TBB bug reporting, so do not choose it.

WORKSFORME

The bug assignee could not reproduce the bug, and looking through the code provides no clues as to why the described behavior in the bug should occur. If more information appears later, the bug can be reopened.

As with other search features, you can search by one, some, or all of the resolutions. To search for multiple resolutions, hold down the Ctrl key on your keyboard while selecting the different resolution options you would like to search under. Tip: When searching by resolution to see if a bug you have found already exists, its usually best to select all the resolution options. 11. Severity Severity describes the degree to which the bug causes problems. There are seven different levels of severity: Severity Blocker When to Use It Bugs that prevent development and/or testing work from proceeding

Critical

Problems like website crashes, data loss, or severe memory leaks

Major

Loss of function on a large scale (but not as severe as critical or blocker)

Normal

The average bug

Minor

Problems that cause slight loss of function, or other problems with easy solutions

Trivial

Cosmetic problems, such as misspelled words or misaligned text, that do not prevent people from using the software

17

Enhancement

Requests to improve things that already work without causing problems, but could be done better, or requests for new functionality

As with other search features, you can search by one, some, or all of the degrees of severity. To search for multiple statuses, hold down the Ctrl key on your keyboard while selecting the different severity options you would like to search under.

Tip: When searching by severity to see if a bug you have found already exists, its usually best to select all the severity options. 12. Priority Priority describes the importance of a bug, and the order in which it should be fixed. There are five priority levels (P1 to P5); P1 is highest priority, and is used to describe bugs with a severity of Blocker. P5 has the lowest priority. Most bugs have a priority of P3. As with other search features, you can search by one, some, or all of the levels of priority. To search for multiple statuses, hold down the Ctrl key on your keyboard while selecting the different priority options you would like to search under. Tip: When searching by priority to see if a bug you have found already exists, its usually best to select all the priority options.

13. Hardware Hardware describes what type of computer the bug reporter was using when the bug occurred. There are three different platforms (PC, Macintosh, and Other), and you can search under one or more of these platforms, or select the All option to search all of them. Tip: When searching by hardware to see if a bug you have found already exists, its usually best to select the All option.

14. OS OS stands for operating system. It describes what operating system the reporter was using when they found their bug. You can search in five different OS options: Operating System All Lets You Search for Bugs Reported For: all operating systems

Windows

the Windows operating system

Mac OS

the Mac operating system

18

Linux

the Linux operating system

Other

any other operating system

Tip: When in doubt about which operating system to search in, use the All option. It may be best to use this option when looking to see if a bug already exists anyway.

15. Email and Numbering The Email and Numbering option (see Figure 13) lets you search peoples email addresses, or a specific range of bug numbers, for information. Searching Email Addresses You can search the email addresses of various different people, based on things that are included in those email addresses. It is useful to remember that all email addresses for people at The Benefit Bank follow the format: firstinitiallastname@thebenefitbank.com For example, John Does email address would be his first initial (j) followed by his last name (doe), all in lower-case letters, like this: jdoe@thebenefitbank.com You can search in the following peoples email addresses: the bug assignee: The person the bug is assigned to. the reporter: The person who reported the bug. a CC list member: When people assign bugs, they can carbon copy (CC) people on the bug. Usually the people CCed are those who can provide input into the bug, or other people, besides the assignee, affected by the bug. A person CCed on a bug is a CC list member. a commenter: Anyone can look at bugs and comment on them using Bugzilla, regardless of who the bug is assigned to or who is on the CC list. People should only comment on bugs when they have something useful to add to the discussion, such as additional information about the problem. Assignees often comment on bugs too, to let the reporter know the status of the bug and the steps taken to fix it. The people who add comments to bugs are called commenters. To search the email addresses of any of these people, select the box next to the person whose email address you want to search.
Figure 13: Advanced Search Email and Numbering

You can search the addresses using different options. Clicking on the arrow next to the field that says contains gives you these options.

19

Option contains

What it Means You are searching the email address of the person you selected for the specific words you type in the empty field below the contains list.

Example You want to search for all bugs assigned to Jane Doe, but dont know how to spell her last name. Your search can look like:

What the Example Says Your search literally says: The email address of the bug assignee contains jd. Your search will look for email addresses for bug assignees that contain jd, such as jdoe. Note that it will return email addresses for all bug assignees that contain jd (and not just jdoe).

is

You are searching for a specific email address.

You want to search bugs assigned to Jane Doe. Your search will look like:

This literally says: The bug assignee is jdoe@thebenefitbank.com Your search will look only for bug assignees with this email address.

matches regexp

Regexp is short for regular expression. Regular expressions describe a set of strings. They are written in their own special way, using parentheses to group things, and different characters to indicate how to search. You can search for email addresses that contain specific regular expressions by using this option. Unless you are familiar with the syntax of regular expressions, its probably best not to search using this option.

doesnt match regexp

Regexp is short for regular expression. You can search for email addresses that do not contain specific regular expressions by using this option. Unless you are familiar with the syntax of regular expressions, its probably best not to search using this option.

20

Using Both Columns There are two columns for searching email addresses. You can use the two columns in conjunction with one another to find information in more than one email address. For example, if you want to search for all bugs assigned to Jane Doe, reported by John Smith, you can use the two columns to search both, like this:
Figure 14: Searching Using Both Email Columns

This literally says: The bug assignee is jdoe@thebenefitbank.com and the bug reporter is jsmith@thebenefitbank.com. Searching Bug Numbers When a bug report is created in Bugzilla, it is assigned its own unique identification number. In the Email and Numbering part of the Advanced Search page you can search bugs of specific numbers. You do that using the part of Email and Numbering that looks like this:
Figure 15: Searching Bug Numbers

If you are searching for whether or not a bug report already exists for a problem you found, you probably will not use this feature. However, it is useful for other searches. Clicking on the small arrow next to Only include shows you the options you can use: Option only include What it Means You are searching only in the specific bugs whose numbers you list. You can include one bug number or many, but if you include many, you must separate them by commas. Example You want to search in bug numbers 9905 to 9908, and no others. Your search will look like:

exclude

You are searching only in the bugs that you do not specify. You can include one bug number or many, but if you include many, you must separate them by commas.

You want to search in all bugs except those numbered 9905 to 9908. Your search will look like:

Tip: You cannot search ranges, such as 9905-9908 or 9905 to 9908. You must list each bug number individually.

21

Figure 16: Advanced Search Bug Changes

16. Bug Changes You can search for bugs that have been changed (see Figure 16). You can search based on the date range of the change, which part of the bug changed, and what the part changed to. If you are looking to see if a bug report already exists for a problem you found, you probably will not use this feature often, but it is useful in other situations (such as to check if a bug has been reassigned, for instance). To specify a date range for bug changes, use the Only bugs changed between option. You can search using specific dates in the year/month/day format, or the relative date Now.

For example, to search for bugs changed between January 1, 2006 and now (assuming now is September 5, 2006), your search can look like A or B:

Note that Now seems to be the only relative date that works. To specify what changed in the bug you want to search for, select one (or more) options from the list under where one or more of the following have changed (see Figure 16). There are several options; not all of them are actively used in The Benefit Banks Bugzilla system. Options on the list that are not actively used in TBBs Bugzilla are not explained below, and include Alias, CC list accessible?, Deadline, Ever confirmed?, Keywords, QA Contact, Reporter accessible?, Target milestone, and Votes. The options used within The Benefit Bank are: Option [Bug creation] Use it to Search For Bugs: created within a specific time period.

Assignee

whose assignee has changed within a specific time period (see section 4.1.2.2. Middle, p. 19 for a definition of assignee).

URL

whose URL field has changed within a specific time period (see section 4.1.2.1. Top, p. 15 for an explanation of URL).

Severity

whose severity has changed within a specific time period (see section 4.1.2.2. Middle, p. 17 for an explanation of severity).

Status

whose status has changed within a specific time period (see section 4.1.2.2. Middle, p. 16 for an explanation of status).

22

Component

whose component has changed within a specific time period (see section 4.1.2.1. Top, p. 15 for an explanation of component).

OS

whose operating system has changed within a specific time period (see section 4.1.2.2. Middle, p. 18 for an explanation of operating system).

Priority

whose priority has changed within a specific time period (see section 4.1.2.2. Middle, p. 18 for an explanation of priority).

Product

whose product has changed within a specific time period (see section 4.1.2.1. Top, p. 14 for an explanation of product).

Hardware

whose hardware has changed within a specific time period (see section 4.1.2.2. Middle, p. 18 for an explanation of hardware).

Reporter

whose reporter has changed within a specific time period. The Reporter is the person who first created a bug report for a specific bug.

Resolution

whose resolution has changed within a specific time period (see section 4.1.2.2. Middle, p. 16 for an explanation of resolution).

Summary

whose Summary has changed within a specific time period (see section 4.1.2.1. Top, p. 12 for an explanation of summary).

Whiteboard

whose whiteboard has changed within a specific time period (see section 4.1.2.1. Top, p. 15 for an explanation of whiteboard).

Version

bugs whose version has changed within a specific time period (see section 4.1.2.1. Top, p. 14 for an explanation of version).
Figure 17: Advanced Search Bug Changes Example

In addition to specifying what changed, you can specify what it changed to using the and the new value was field (see Figure 17). For instance, if you want to search for a bug that originally had a severity of normal, but whose severity changed to critical, sometime between September 1 and September 5, 2006, your search would look like Figure 17. 17. Sort Results By
Figure 18: Advanced Search Sort Results By

in

You can choose to have your search results appear a specific order using Sort results by (See Figures 12 and 18).

Clicking on the small arrow at the right of the Sort results by box shows you the list of orders you can choose (see Figure 18).

23

Sort Option Reuse same sort as last time

How it Sorts This will sort your search results in the same way you sorted them the last time you performed a search.

Bug Number

This will sort your search results by bug number (lowest to highest).

Importance

This will sort your search results by severity (see section 4.1.2.2. Middle, p. 17 for an explanation of severity). Results will be listed from most important (Blocker) to least important (Enhancement).

Assignee

This will sort your search results by the name of the assignee, in alphabetical order. Remember that assignees are identified by their email addresses, which follow the format: firstinitiallastname@thebenefitbank.com So, the alphabetical order used is based on the first initial of the assignee, not on their last name.

Last Changed

This will sort your search results based on changes in bugs. The bug most recently changed (regardless of the change) will appear first in your search list, while any unchanged bugs will appear at the end of the search list.

18. Search button Once you have entered or selected all of the criteria you want to use for your search, click on the Search button (see Figure 12). Bugzilla will do the search for you, and return results. Remember that there is more than one Search button on the page; there is another one in the Top section of the Advanced Search page too. See section 4.3. Reading the Search Results for an explanation of how to read the search results. 19. and remember these as my default search options If you check the box next to and remember these as my default search options (see Figure 12), Bugzilla will remember all the different search criteria you entered. The next time you open the Advanced Search option in Bugzilla, all the different criteria you entered will appear as your selections, without you having to re-select or re-enter your search criteria.

4.1.2.3. Bottom
The bottom of the Advanced Search screen looks like this:
Figure 19: Advanced Search Using Boolean Charts

Unless you are familiar with Boolean Charts, you may not want to use this search option. For information on Boolean Charts and Bugzilla, visit http://www.bugzilla.org/docs/2.20/html/query.html.

24

4.2. Search
Earlier, we said that there were two ways to search for bugs from the Bugzilla Main Page Search existing bug reports and Search as labeled in Figure 6 (reproduced here):
Figure 6: Bugzilla Main Page Search Options

Section 4.1. dealt with the Search existing bug report option. Selecting Search (outlined in a green box in Figure 6 above) takes you to the Advanced Search page discussed in detail in section 4.1.2. Advanced Search. Please see this section for information on using the Advanced Search.

4.3. Reading the Search Results

Here is an example of a page of search results:
Figure 20: Bugzilla Search Results

25

The search returned two bugs, and the page gives a basic eight-column summary of each of those bugs. Each column tells you specific information about the bugs. Column ID Sev What It Means The unique identification number automatically assigned to a bug when it is first created. You can click on the ID number to view the bug report in its entirety. Short for Severity; it describes the degree to which the bug causes problems. The levels of severity are: Blocker: prevents development and/or testing work from proceeding Critical: describes problems like website crashes, data loss, or severe memory leaks Major: loss of function on a large scale (but not as severe as critical or blocker) Normal: the average bug Minor: causes slight loss of function, or other problems with easy solutions Trivial: cosmetic problems, such as misspelled words or misaligned text, that do not prevent people from using the software Enhancement: requests to improve things that already work without causing problems, but could be done better, or requests for new functionality Short for Priority; it describes the importance of a bug, and the order in which it should be fixed. There are five priority levels (P1 to P5); P1 is highest priority, and should be used to describe bugs with a severity of Blocker. P5 has the lowest priority. Most bugs have a priority of P3. Short for Platform; it describes what platform/type of computer the bug reporter was using when the bug occurred. There are three different platforms, describing three different types of computers: PC, Macintosh, and Other. the person responsible for the bug. Defines what state a bug is in. The different statuses are: UNCONFIRMED: This status is not used within TBB Bugzilla. NEW: The bug has been added to the assignee's list of bugs, but hasnt been accepted by the assignee or fixed yet. ASSIGNED: The bug is assigned to the proper person but hasnt been fixed yet. REOPENED: The bug was fixed, but the fix was deemed incorrect. RESOLVED: The bug has been fixed, and is waiting for the person who reported the bug (or Quality Assurance) to verify that someone checked the fix and that it is correct. VERIFIED: This status is not used within TBB. CLOSED: The bug is considered dead, the resolution is correct. Indicates what happened to the bug. Bugs in the New, Assigned, or Reopened statuses are not considered as having been dealt with, so they show no resolution. Bugs in other statuses (Resolved, Verified, Closed) can have one of the following Resolutions: FIXED: The bug has been fixed and tested by the assignee. INVALID: The problem described is not a bug. WONTFIX: The problem described is a bug which will never be fixed. LATER: The problem is a bug, but for some reason the assignee cannot deal with it now, and will revisit the issue later. Bugs can be marked as LATER if, for instance, the fix requires updates based on research that is not yet available. REMIND: This resolution is not used within TBB Bugzilla. WORKSFORME: The bug assignee could not reproduce the bug, and looking through the code provides no clues as to why the described behavior in the bug should occur. If more information appears later, the bug can be reopened. shows the short summary of the problem that the bug reporter wrote in their bug report. See section 5.2. Enter Bug: Product Page, p. 32 for details on what information a summary should contain.

Pri

Plt

Assignee Status

Resolution

Summary

Looking at these different columns, particularly the Summary column, should give you the information you need to determine if a bug report already exists for the problem you found. If you need more information than what the screen provides, select the Bug ID number to view the full bug report, where you can see all the information about the bug.

26

4.3.1 What Happens Next?

Option 1: Bug Report Already Exists If a bug report for the problem you found exists already, you dont have to do anything, unless you have new information to add that will be beneficial to the bug assignee. If this is the case, please see section 6. Managing Bugs Assigned to You, p37 for information on how to add information to a bug report. Option 2: No Bug Report Exists If a bug report does not exist for the problem you found, you need to create one. See section 5. Reporting Bugs for information on how to do this.

27

5. Reporting Bugs
Once you have identified a unique bug that has not been reported, it is time to create a bug report so the problem can be dealt with properly. There are two ways you can create a new bug report: i. ii. Select the Enter a new bug report link on the Bugzilla Main Page Select the New option, found at the bottom of every page in Bugzilla.

In Figure 21 below, the Enter a new bug report link is outlined in a red circle, while the New option is outlined in a green box.
Figure 21: Bugzilla Entering New Bugs

5.1. The Enter Bug Page

Selecting either the Enter a new bug report link or the New option takes you to the Enter Bug page (see Figure 22).
Figure 22: Bugzilla Enter Bug Page

On this page, you must choose which The Benefit Bank product your bug belongs to. There are four different products: Master List: The Master List of bugs. SfP Website: Choose this to enter a bug that you found on the Solutions for Progress (SfP) website. TBBv2: The Benefit Bank version 2 (TBBv2) is the version of The Benefit Bank that is in active development now. Choose this product to enter a bug that has to do with any aspect of The Benefit Bank software (except translation). This will be the product you choose most often, probably.

28

Translation TBBv2: Choose this product to enter any translation bugs related to The Benefit Bank version 2 (TBBv2).

5.2. The Enter Bug: Product Page

The Enter Bug: Product Page (where Product is the product that you chose on the Enter Bug page) is where you actually enter a bug. The page looks like this (with the different sections numbered in red):
Figure 23: Bugzilla Enter Bug: Product

2 3 6 7 10 11 13 15 12

4 5

14

16 17 18 19

Here is an explanation of each section of the page, corresponding to the numbers in the picture. 1. Enter Bug: TBBv2: This section shows you which product (in this case, TBBv2) you are entering your bug for. The product is based on the product choice you made on the Enter Bug page. 2. Reporter: The reporter is the person reporting the bug. Because you are creating the bug report, your The Benefit Bank email address should be the one listed here. 3. Version: Version is automatically selected for you. It is which version of the product you want to enter a bug for. The product in this case, TBBv2, does not have another version, so other is automatically selected.

29

4. Product: As in 1. Enter Bug:TBBv2, this section shows you which product you are entering a bug for. 5. Component: Component defines the specific module of The Benefit Bank in which you found the bug. For instance, if you noticed a bug in the 2005 Pennsylvania Property Tax or Rent Rebate module, you would select PA Rebate 2005 as the component. As new modules develop, the component list grows. 6. Platform: Platform describes what platform/type of computer you were using when the bug occurred. There are three different platforms: PC, Macintosh, and Other. Although a platform is automatically selected for you, you can choose another one if the platform given is incorrect. You can also choose the All option, if you observed that your bug occurs in multiple platforms. 7. Priority: Priority describes the importance of a bug, and the order in which it should be fixed. It is a very important field for the person who sees your bug, since it helps that person decide how important it is for them to deal with the bug. There are five priority levels (P1 to P5); P1 is highest priority, and is used to describe bugs with a severity of Blocker. P5 has the lowest priority. Most bugs have a priority of P3. See 9. Severity (below) for a description of bug severities. 8. OS: OS stand for operating system. It describes what operating system you were using when you found the bug. You can choose between five different OS options: Operating System All Use for Bugs Reported For: all operating systems (only if you see the problem in all operating systems)

Windows

the Windows operating system

Mac OS

the Mac operating system

Linux

the Linux operating system

Other

any other operating system

9. Severity: Severity describes the degree to which the bug causes problems. There are seven different levels of severity, and its important for you to choose the correct severity for your bug. Like the priority level, the severity rating helps the person fixing your bug know how important it is and when they should fix it.

The levels of severity are: Severity Blocker When to Use It Bugs that prevent development and/or testing work from proceeding

Critical

Problems like website crashes, data loss, or severe memory leaks

30

Major

Loss of function on a large scale (but not as severe as critical or blocker)

Normal

The average bug

Minor

Problems that cause slight loss of function, or other problems with easy solutions

Trivial

Cosmetic problems, such as misspelled words or misaligned text, that do not prevent people from using the software

Enhancement

Requests to improve things that already work without causing problems, but could be done better, or requests for new functionality

10. Initial State: All newly reported bugs are given an initial state the first state the bug appears in of New. The state, or status, of the bug will change as the bug is dealt with. See section 4.1.2.2. Top, p. 16 for more information on the different bug statuses, and section 6. Managing Bugs Assigned to You to learn when and how the status of a bug changes. 11. Assign to: This field lets you choose who to assign the bug to. Each product or module has a default owner; when you select a specific product, the Assign to field is filled in automatically with the default owners email address. For modules, the default owner is usually the analyst assigned to the module. However, if you know that the bug you are reporting should not be dealt with by the default owner you should submit it to the person who will be responsible for dealing with it. For example, assume you found a spelling error on a page of the 2005 Pennsylvania Property Tax or Rent Rebate Module. A spelling error is a Content and Usability problem, but the default owner for that module is cfurnas@thebenefitbank.com, an analyst. You should change the Assign to field to the appropriate Content and Usability persons email address (in this case, kbatstone@thebenefitbank.com). If you do not know the different people responsible for the different parts of any given product, do not change the default assignee. The default assignee will know who should see your bug, and will reassign it as needed. 12. CC: CC stands for carbon copy. You can assign your bug to one person using the Assign to field, but using the CC field, also send a copy of the bug to others who may be interested in the bug or may be able to contribute to its solution. Enter the email addresses of the person you want to CC on your bug, separated by commas, like this: jdoe@thebenefitbank.com, jsmith@thebenefitbank.com You can CC as many people as you want, but do not CC people who cannot contribute to the bug or will have no interest in it. Also, do not CC yourself. As the reporter, you will get emails about the bug report anyway; if you CC yourself, youll get duplicates of those emails.

13. URL: URL stands for Universal Resource Locator. A URL is the address for a webpage. Not all bugs will be associated with a URL (although some, such as bugs on the Solutions for Progress website, will be). However, do not leave the URL field blank. If there is no URL associated with your bug, enter the BNode number from the bottom left of the The Benefit Bank page you found your bug on.

31

14. Summary: The summary is a one-line description of the problem you discovered. It must be detailed yet concise, giving enough information for the assignee to understand what your problem is. A summary should always include: The BNode number of the BNode you were on when you saw the problem; and The GQ:MQ number, if the problem occurs in a specific GQ:MQ; and The CQ number, if the problem occurs in a specific CQ; and An informative sentence describing the problem.

ID numbers must follow the format: resource type followed by the ID number, minus extra zeros and hyphens. For example, the BNode ID for BNode 000-001-234 should be written as: BN1234 Here is an example of a bad summary: Bad text There are several reasons why this summary is not acceptable. First, it does not tell the assignee where the bad text occurs what is the BN number? The GQ number? The CQ number? Where on the page does the problem occur? It also does not say what is bad about the text is something misspelled? Is the reading level too high? Is it in the wrong place? Is it formatted poorly? A much better example of a summary is: BN7324 has accept misspelled in first paragraph. This summary explains the problem in context, in one sentence. Bug assignees have the right to assign back to you any bug you submit that does not contain the information they need to solve the problem. Without the proper information that will allow them to find the problem you are describing, bug assignees cannot see the problem, and thus cannot fix it. It is your responsibility to make summaries clear enough for the bug assignee to deal with your bug. If a bug assignee reassigns a bug to you because of lack of information, the assignee must tell you what information is missing. 15. Description: The description is very, very important, since it describes the problem you found in detail to the bug assignee. . Descriptions must include all the information below, in this order: User name: password Include the user name and password of the client you were using when the bug occurred, not your own user name and password. BNode/GQ:MQ/CQ numbers Include the BNode, GQ:MQ, and/or CQ numbers of The Benefit Bank page where you found your error, even though youve already included this information in the summary. ID numbers must follow the format: resource type followed by the ID number, minus extra zeros and hyphens. For example, the BNode ID for BNode 000-001-234 should be written as: BN1234

32

Site The Benefit Bank has many different sites. Some are set aside for testing, others for other purposes. Here is a list of the sites, their URLs, and what they are used for: QA: used for testing (http://qa.fig.tbb/tbb/authentication) Dev: used for testing (http://dev.fig.tbb/tbb/authentication) Training: used by training to train new counselors (http://training.thebenefitbank.com/tbb/authentication) Live: used by actual clients (https://secure.thebenefitbank.com/tbb/) If you did not find the error while using one of these sites, you probably found it while using a client in your own sandbox (if you do not know what a sandbox is, dont worry about it it means you dont use one). Instead of listing the site, state that you were in your sandbox when you found the problem. Scenario If you are doing Quality Assurance and are running a scenario provided by the TBB Research Team, list the scenario used. Description of the problem Your description should be concise but informative. Explain the problem, where it appears, and what you were doing when you found it. Try to avoid really long, convoluted explanations. Note that if the problem you are reporting is that the application died, report the BNode you were on directly before you saw the Proxy Error or technical difficulties page. Also, in your browser select View (at the top-left of your screen), and then Source. A window will pop up with detailed error information. Find where it says the application has died and select and copy everything from there down (in Mozilla Firefox, this text will all be green). Paste that copied material into the bottom of the description. You may not understand what it says, but the person who will fix your bug probably will. Bug assignees have the right to assign back to you any bug you submit that does not contain the information they need to solve the problem. Without the proper information that will allow them to find the problem you are describing, bug assignees cannot see the problem, and thus cannot fix it. It is your responsibility to make descriptions clear enough for the bug assignee to deal with your bug. If a bug assignee reassigns a bug to you because of lack of information, the assignee must tell you what information is missing. 16. Depends on: Fill in this field if the resolution of your bug depends on the resolution of another. Put the bug identification number of the bug that needs to be fixed before yours can be fixed in the space provided. If your bug depends on no other bug, leave this field blank. 17. Blocks: Fill in this field if your bug prevents another from being resolved. For instance, while many modules are in development they have a master bug that cannot be closed until all other bugs for the module have been fixed and closed. If your bug prevents the master bug (or any other bug) from being dealt with, put the bug identification number of the bug yours blocks in the space provided. If your bug does not block any other bug, leave this field blank. 18. Commit button: Click on the Commit button when you have finished filing your bug report. When you do this, the bug report is saved, and you, the assignee, and anyone CCed on the bug will receive an email from Bugzilla about the bug. 19. Remember values as bookmarkable template: This feature is not normally used within Bugzilla for The Benefit Bank.

33

5.3. Following Up on Bugs You Report

Your responsibility for your bug does not end with reporting the bug. While someone else is responsible for fixing the bug you reported, it is up to you to make sure that the person does fix it, and fixes it properly. To check on bug reports: Periodically search for bugs that you reported. See section 4. Searching for Bugs for detailed instructions on how to search bug reports. Read the comments and questions that other people have added to the bugs to bring yourself up to speed with the issue. If a bug you reported has a resolution of FIXED or WORKSFORME, you must verify that the bug was fixed. To do this, try to reproduce the problem. o If the problem still is not fixed, add a comment to the bug explaining that you are still seeing the problem and in what context, and change the status of the bug to REOPEN. See section 6. Managing Bugs Assigned to You, p. 37 below for information on how to comment on and change the status of a bug report. o If the problem is fixed, change the status to CLOSED. Be sure to include a comment too. See section 6. Managing Bugs Assigned to You, p. 37 below for information on how to comment on and change the status of a bug report. If a bug you reported has a resolution of INVALID or WONTFIX, dont get angry. INVALID means that what you reported as a bug is not actually a bug read the comments left by the assignee to find out why. WONTFIX means that while you have pointed out a legitimate bug, the assignee will never fix it. Again, read the comments left by the assignee to find out why. Unless you have new information to add to a bug report marked either INVALID or WONTFIX that will affect the assignees ability to fix the bug, do not change the status of the bug to REOPEN. The assignee has final say over the resolution of the bug, whether you like it or not. If a bug you reported has a resolution of LATER, and it has been awhile since the bug was dealt with, comment on the bug to bring it back to the attention of the assignee.

34

6. Managing Bugs Assigned to You

When a bug is assigned to you, you have the responsibility of managing the bug. Visit the bug report (there should be a direct link to it in the email Bugzilla sends you to tell you a bug has been assigned to you). A completed bug report looks like this (with some of the features numbered in red):
Figure 24: Bugzilla Bug Report

1 2 3

35

Many of the features of the bug report page should be familiar to you by now, such as bug, product, hardware, OS, component, version, status, priority, resolution, severity, URL, summary, status whiteboard, description, and the commit button. As the bug assignee, you have the power to change many of these fields. You will also notice a few new fields and features, numbered in red. Here is a description of each of those features: 1. Reporter: This indicates the name and email address of the person reporting the bug. 2. Add CC and CC: CC stands for carbon copy. You can send a copy of your bug report to anyone. However, you should only send copies of bug reports to people who can provide useful information in fixing the bug or who have a strong interest in the bug. To add people to the CC list, type their email addresses, separated by commas, into the space next to Add CC:. It will look something like this:
Figure 25: Add CC

After you are finished modifying the bug report and select the Commit button, Bugzilla will send an email to the people you CCed, about the bug. You can also remove people from the CC list by selecting their names in the CC list menu and checking the box next to Remove selected CCs:
Figure 26: Remove CC

When you select the Commit button, the people you removed will not get an email from Bugzilla, and will receive no further communication from Bugzilla regarding the bug. 3. Assigned to: This indicates the name and email address of the person the bug is assigned to. Bugs assigned to you should have your name and email address here. 4. Attachment: The Attachment box lets you include extra information, such as screen shots or Cryo clients, for instance, with the bug report. To create a new attachment, click the Create a New Attachment link:
Figure 27: Create a New Attachment Link

It will take you to a screen that looks like this (see Figure 28):

36

Figure 28: Create a New Attachment Page

To create the attachment: i. ii. Enter the name of the file you want to attach in the File field, or use the Browse button to find the file on your computer and enter it. Include a brief description in the Description field of what you are attaching. All other fields on the page are optional. However, it is useful to add a comment in the Comment field, so that people other people who look at the bug will know that you added the attachment. In Content Type, choose the type of attachment you are including. If you are not sure what type of file your attachment will be, you can select the auto-detect option. Select the Submit button at the bottom of the page. Youll be returned to the full bug report.

iii. iv.

5. Additional Comments: This is the place where the assignee explains what steps they are taking to solve the bug, and where reporters or others can add new information about the bug if necessary. Any time any changes are made to a bug report, whether it be to add an attachment, change the severity, change the status, reassign it, etc., a comment should be added to the bug report to keep people informed of what is happening with the bug. There are some general guidelines for commenting in bugs though. Please see section 7. Bugzilla Etiquette for more information. 6. Changing Status: As the bug assignee, you can change the resolution, and thus the status, of a bug report. When you first receive a new bug report, the resolution section will look like this (see Figure 29):

37

Figure 29: New Bug Resolution Options

You have three options: 1. Accept bug This means that you accept responsibility for the bug. When you select the Accept bug option, the status of the bug will change to ASSIGNED. Include a comment in the bug report saying that you are taking responsibility for the bug. 2. Reassign bug to This means that you dont think it is your job to fix the bug, and you are sending the bug to the person who can fix it. Select the Reassign bug to option, and write the email address of the person to whom you are reassigning the bug in the empty field beside that option. Include a comment in the bug report explaining who you are sending the bug to and why. 3. Resolve bug, mark it as a duplicate of bug # If you find that a bug assigned to you is a duplicate of a bug already reported, you can select this option, and include the bug number that the new bug duplicates in the empty field provided. Dont forget to include a comment in the bug report explaining that the report is a duplicate. Then, select the Commit button to make your change. Once you have accepted a bug, the resolution options change to look like this:
Figure 30: Accepted Bug Resolution

Bug Resolutions
FIXED: You fixed and tested the bug. INVALID: You dont think the problem described is a bug. WONTFIX: While you acknowledge that the problem described is a bug, you will not fix it. LATER: You acknowledge that the problem is a bug, but you cannot deal with it now, and will revisit the issue later. REMIND: Not used in TBB. WORKSFORME: You could not reproduce the bug, and looking through the code provided no clues as to why the described behavior in the bug should occur. As the bug progresses and action is taken on it, you can change the status of the bug by changing the resolution. Only bugs that have been dealt with show a resolution; bugs in the NEW, ASSIGNED, or REOPENED statuses are not considered having been dealt with, so they show no resolution. Bugs in other statuses (RESOLVED, VERIFIED, CLOSED) can have one of several resolutions. Please see the sidebar for a description of the resolutions. Remember, if you change the resolution or status of a bug, you must include a comment in the bug report explaining what you did and why. After you are finished making changes to a bug report, select the Commit button to make your changes.

38

7. Bugzilla Etiquette
Just because Bugzilla lets you report bugs without you having to see someone face-to-face doesnt mean you can behave any way you want to when bug reporting. Here is some basic etiquette to keep in mind when writing and responding to bug reports. 1. Commenting No personal abuse.

When you submit a bug, explain the problem you are having, with all the relevant information the assignee needs to understand what you are talking about and fix the problem, and thats it. When you are responding to a bug report, explain what you can or cannot do, and why, and thats it. Do not personally attack anyone no rudeness, no name-calling, no refusing to deal with bugs for reasons such as you do not like the person reporting, or do not know that person. Be professional. No pointless comments.

Do not comment on a bug unless you have something useful and constructive to say (or are invited to contribute). This is particularly true if a bug is being debated strongly; if you have nothing new to add to the discussion, keep out of it. Remember, the bug assignee has been reading the reports and comments too, is aware of the issues involved, and will deal with the bug accordingly. Reiterating other peoples points without adding anything new does nothing but annoy already-busy people and give them more email to read. No private email.

Unless youve been specifically asked by the bug assignee to send you information via email, include everything relevant to the bug in the bug report. Do not send extra information via email. Having all the bug-related information in one place means the people dealing with the issue have all the information together too. This is especially important if the bug needs to be reassigned. 2. Changing Fields Dont mess with other peoples bugs.

Unless you are the bug assignee, or have some say over the use of the assignees time, never change the priority or severity field of a bug. If you arent sure if you have some say over someones time, you probably dont. Its best to follow the rule of not changing the fields of bugs you do not own. Instead, add a comment to the bug report, suggesting the change, and let the assignee deal with it. Dont complain about the bug assignees decision.

The assignee has final say over the resolution of the bug, whether you like it or not. If the assignee marks a bug as a INVALID or WONTFIX and explains why, the decision stands, even if you do not like it. Someone filing another duplicate of the bug does not change this. Unless you have new, important evidence why a bug should be reopened, do not reopen it or post a comment stating that it should be reopened. Additionally, do not approach the assignee personally about the bug report, whether over email or face-to-face, except for clarification. Say what needs to be said when you report your bug, and in subsequent comments, keeping the No personal abuse rule in mind. It is your responsibility to make your bug reports clear enough for the assignee to deal with them. Trying to force people to change decisions about bugs after the decisions have been made is manipulative and unprofessional. 3. Reporting Dont report more than one bug in a report.

39

Each bug should be in its own report. Even if you see several problems on one BNode, report each problem individually in its own report. This makes it easier for the assignee to keep track of what needs to be done, and also ensures that the right person sees your bug. For example, if you notice a spelling error and a field that is not populating on the same BNode, but only submit one bug report, you have a problem the spelling error is a Content and Usability problem, while the field issue is an Analysis, or possibly Systems, problem. You can only assign a bug to one person at a time, so youll have to choose whether to send the bug to a Content or Analysis person. Minimally youve created work for the bug assignee, who will have to deal with their part of the problem and then reassign the bug appropriately. More importantly, you risk having one of the issues you bring up left not dealt with at all. Its also impossible to prioritize a bug report if it contains more than one problem if the problems are of different severities. Dont sacrifice clarity for humor.

While its tempting to give your bug a cute or funny title or summary, if you do so at the expense of giving a clear, concise description of the problem you will annoy people. Bug assignees will be upset if they have to open up full bug reports to see what the problem is because your fun summary failed to describe the problem adequately enough for them to either find or understand it easily and quickly. Frankly, they dont have time to dig through your wit to find out what they need to do to solve the problem youre reporting.

40

Appendix 1: Steps to Bug Reporting (in Brief)

Step 1
Search Bugzilla to see if a report already exists for the bug. See section 4. Searching for Bugs for more information.

Things to Remember When Creating Bug Reports

* Summaries should be clear and concise. * Summaries and descriptions must contain the ID number of the BN, GQ:MQ, CQ, etc. if relevant, in the following format: ID + 4- or 5-digit ID number For example: BNode 000-001-234 should be written as: BN1234 * Include which site you found the error on, and the client login and password in the description. * If you are reporting a site crash, your description must include the source code for the crash, the animal number, and error code.

Step 2
If a bug report already exists, do nothing, or add a comment to the report stating that you saw the bug too, in what context, with what user, and on what site. See 6. Managing Bugs Assigned to You, p. 37 for information on adding comments to an existing bug report.

Step 3
If a bug report does not already exist, create one. See section 5. Reporting Bugs for information on how to create a bug report.

Step 4

Follow up on your bug. The usual process after you report your bug is that the assignee deals with the issue somehow and gives the bug a resolution. Use the following table to determine what action you should take, depending on the resolution: If the resolution is FIXED You should Check to make sure the bug was fixed. If it wasnt fixed, change the status to REOPEN and comment on the bug. If it was fixed, change the status to CLOSED. Comment on the bug in both cases. Check to make sure the bug is no longer occurring. If it is still happening, change the status to REOPEN and comment on the bug. If it is not still happening, change the status to VERIFIED, and then to CLOSED. Comment on the bug in both cases. Hold your temper and read the comments from the assignee. Remember that the assignee has final say over the resolution of the bug, whether you like it or not. Hold your temper and read the comments from the assignee. Remember that the assignee has final say over the resolution of the bug, whether you like it or not. Bring the bug back to the assignees attention by commenting, if its been awhile since it was addressed.

WORKSFORME

INVALID

WONTFIX

LATER

See section 5.3. Following Up on Your Bugs for detailed information on how to follow up on your bug.

41

Appendix 2: Steps for Managing Your Bugs (in Brief)

For detailed instructions on how to manage your bugs, see section 6. Managing Bugs Assigned to You.

Step 1
When a new bug is assigned to you, within 24 hours either: i. Accept the bug ii. Reassign the bug as necessary iii. Mark the bug as a duplicate of another bug if appropriate

Step 2
Once you have accepted a bug, fix it and change the resolution appropriately. The resolutions mean: Resolution FIXED Means You have fixed and tested the bug.

INVALID

You dont think the problem described is a bug.

WONTFIX

While you acknowledge that the problem described is a bug, you will not fix it.

LATER

You acknowledge that the problem is a bug, but you cannot deal with it now, and will revisit the issue later. Bugs can be marked as LATER if, for instance, the fix requires updates based on research that is not yet available.

REMIND

This is not used in TBB.

WORKSFORME

You could not reproduce the bug, and looking through the code provided no clues as to why the described behavior in the bug should occur.

Step 3
Follow the bug and respond to it as appropriate.

42

Appendix 3: Lifecycle of a Bug

This diagram, adapted from Figure 6-1 of The Bugzilla Guide - 2.20.2 Release, shows an overview of bugs, from the time they are reported until they are closed.

43

Index
[
[Bug creation] 22

E
Email and Numbering 19 Enhancement 18, 24, 26, 31 Enter a new bug report link 28 Enter Bug page 28, 29 Enter Bug Product Page 29

A
account 5 Additional Comments 37 Advanced Search 9, 11, 16, 24, 25 and remember these as my default search options 24 Assign to 31 ASSIGNED 26, 38 assignee 15, 17, 19, 20, 21, 22, 24, 26, 27, 31, 32, 33, 34, 36, 37, 39, 40, 41 Attachment 36

F
Find a Specific Bug 9 FIXED 17, 26, 34, 41, 42

H
hardware 18, 23, 36 Home 8

B
Blocker 17, 18, 24, 26, 30 blocks 33 Boolean Charts 24 Bug Changes 22 Bug Report Already Exists 27 Bugzilla 4 Bugzilla Etiquette 39 Bugzilla Main Page 5

I
Initial State 31 INVALID 17, 26, 34, 39, 41, 42

L
LATER 17, 26, 34, 41, 42 Lifecycle of a Bug 43 Linux See operating system, See operating system, See operating system, See operating system Login button 6 logon name 5 logon to Bugzilla 5

C
CC 19, 22, 31, 33, 36 Change password or user preferences link 7 change your password 6 Changing Status 37 check on bug reports 34 Choosing Translation TBBv2 11 CLOSED 26, 34, 38, 41 closed status 10 commenter 19 comments 3, 15, 19, 34, 39, 41 component 15, 23, 30, 36 contains all of the words 12, 13 contains all of the words/strings 12 contains any of the words 12, 13 contains any of the words/strings 12 contains the string 13 contains the string (exact case) 13 Create a New Attachment link 36 Critical 17, 26, 30

M
Mac OS See operating system, See operating system Major 17, 26, 31 managing the bug 35 Master List 11, 14, 28 matches the regexp 14 Minor 17, 26, 31

N
NEW 26, 38 No Bug Report Exists 27 Normal 17, 26, 31

D
depends on 33 description 30, 32, 33, 36, 37, 38, 40 doesnt match the regexp 14

O
open status 10 operating system 18, 19, 23, 30

44

P
password 5 Plt See platform Pri See priority priority 18, 23, 26, 30, 36, 39 product 11, 14, 23, 28, 29, 30, 31, 36

status 10 Status 16 status whiteboard See whiteboard summary 9, 12, 13, 23, 26, 32, 36, 40

T
TBBv1 11, 14 TBBv2 11, 14, 28, 29, 30 Trivial 17, 26, 31

R
Reassign bug to 38 regexp See matches the regexp Remember values as bookmarkable template 33 REMIND 17, 26, 42 REOPENED 26, 38 reporter 12, 15, 18, 19, 21, 26 Reporter 22, 23, 29, 31, 36 Reporting Bugs 27, 28 resolution 16, 23, 26, 33, 34, 36, 37, 38, 39, 41, 42 Resolve bug, mark it as a duplicate 38 RESOLVED 26, 38

U
UNCONFIRMED 26 URL 15, 22, 31, 36 User Preferences page 7

V
v2 15 version 11, 14, 15, 23, 28, 29, 36

S
search 9 Search button 16, 24 Search existing bug reports 9 search results 16, 23, 24, 25 Searching Bug Numbers 21 Searching Email Addresses 19 Sev See severity severity 17, 18, 22, 23, 24, 26, 30, 36, 37, 39 SfP Website 11, 14, 28

W
whiteboard 15, 16, 23, 36 Windows See operating system, See operating system, See operating system, See operating system WONTFIX 17, 26, 34, 39, 41, 42 Words field 11 WORKSFORME 17, 26, 34, 41, 42

45

List of Figures
Figure 1: Bugzilla Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: Bugzilla Main Page: Logging On . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 3: Bugzilla Main Page: Changing Password . . . . . . . . . . . . . . . . . . . . . Figure 4: Bugzilla User Preferences Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 5: Bugzilla User Preferences Page Confirmed Changes . . . . . . . . . . . Figure 6: Bugzilla Main Page Search Options . . . . . . . . . . . . . . . . . . . . . . . . . Figure 7: Bugzilla Find a Specific Bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 8: Status Options Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 9: Product Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 10: Bugzilla Advanced Search Page Top . . . . . . . . . . . . . . . . . . . . . . Figure 11: Summary Drop-Down Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 12: Bugzilla Advanced Search Page Middle . . . . . . . . . . . . . . . . . . . Figure 13: Advanced Search Email and Numbering . . . . . . . . . . . . . . . . . . . . Figure 14: Searching Using Both Email Columns . . . . . . . . . . . . . . . . . . . . . . Figure 15: Searching Bug Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 16: Advanced Search Bug Changes . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 17: Advanced Search Bug Changes Example . . . . . . . . . . . . . . . . . . Figure 18: Advanced Search Sort Results By . . . . . . . . . . . . . . . . . . . . . . . . . Figure 19: Advanced Search Using Boolean Charts . . . . . . . . . . . . . . . . . . . . Figure 20: Bugzilla Search Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 21: Bugzilla Entering New Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 22: Bugzilla Enter Bug Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 23: Bugzilla Enter Bug: Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 24: Bugzilla Bug Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 25: Add CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 26: Remove CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 27: Create a New Attachment Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 28: Create a New Attachment Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 29: New Bug Resolution Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 30: Accepted Bug Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 7 7 8 9, 25 10 10 11 12 12 16 19 21 21 22 23 23 24 25 28 28 29 35 36 36 36 37 38 38

46