Defect Tracking System

This topic is an overview of the defect tracking system used by the CLforJava project in the CS department at the College of Charleston.

Implementation

This system uses the Bugzilla bug tracker found at the Mozilla site. Access to the CLforJava project in the Bugzilla data base requires registration at http://clforjava.cs.cofc.edu/Bugzilla/index.cgi using an email address and original Twiki password. We ask that you use the same email address that you used to register with Perforce. The password can be changed in the preferences section of your account after you are logged on. Specific details about reporting a bug can be found at the HowTo topic under "Bug Reporting with Bugzilla". But before trying to enter or search for a bug in the CLforJava project, it's important to understand the basic attributes of one first.

Anatamony of a Bug

• Product and Components: Our project is CLforJava , components will be listed as they are created.

• Status: Status types can be UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, VERIFIED or CLOSED. An UNCONFIRMED bug is one which has not been verified as an actual bug. Once confirmed, the bug is usually changed to NEW and ASSIGNED to a programmer to fix. A REOPENED bug is one which was once reolved, but the resolution was determained to be incorrect. For instance, a bug could be marked as WORKSFORME when the programmer assigned to fix it cannot reproduce the bug. Then, at a later date, the bug is reproduced and REOPENED or RESOLVED.

• Resolution: The resolution field indicats what happened to this bug. The options for this field are: NO RESOLUTION YET, FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, or WORKSFORME. Most of these options are self-explanatory. The WONTFIX option is chosen when it is decided that the bug is not worth the trouble of fixing at the present time.

• Assigned To: This field will assign the bug to the default programmer unless another programmer's email address is entered in this field.

• Summary: Describe the bug in 60 characters or less. A good summary should quickly and uniquely identify the bug. Keywords can be used that will help identify the bug in a search that can be conducted at a later time.

• Platform: Note the hardware platform on which the bug was reported.

• Operating System: Note the operating system on which the bug was reported.

• Version: Designate the product version on which the bug was found.

• Priority: The priority describes the importance and order in which a bug should be fixed. These range from P1 to P5, P1 being the most important.

• Severity: This vield describes the impact of the bug. Types include: BLOCKER, CRITICAL, MAJOR, NORMAL, MINOR, TRIVIAL, or ENHANCEMENT. It is important to choose the Priority and Severity fields wisely. A bug of type BLOCKER should not have P5 priority.

• Other Attributes of a Bug: The other fields in the bug report, such as reporter and CC list, are self explanatory. It is important to note that attachments can be made to the report. These can be in the form of test code or other imformation that would help the assigned programmer find the bug. The Additional Comments field should be used to clearify anything. It should also be used if a programmer has made any changes to the fields of a submitting programmer's report. Specific changes should be listed and reasons given for making these changes.

Searching for Bugs

At the bottom of every page there are Action fields which allow the user to submit new bugs as well as search for ones that have already been submitted. It is suggested that before a new bug is submitted, a search is made to see if another programmer has already submitted the bug. A Bug Query form is available for easy searches, not all the fields have to be chosen and, if the form is submitted in the default mode, all the bugs in the project will be shown.

Bug Queries

As was noted earlier, bugs can be edited by anyone with the correct status. When another programmer's bug is editied, make sure to note the fields that were changed as well as the reason for changing them.

Updating Bugzilla

From time to time, one may find it necessary to update Bugzilla. This must be done with caution, since the future integration of Bugzilla and Perforce requires one to use a supported Bugzilla version. A listing of these can be found at the http://www.perforce.com/perforce/products/p4dti.html site. Information on upgrading the system can be found at http://www.bugzilla.org/docs/tip/html/upgrading.html.

Final Tips

1. Describe your bug explicitly, but directly and to the point.
2. Clarity is especially important.
3. Only one bug is submitted per report.
4. And, lastly, no bug is too trivial to report.

For further information, go to http://clforjava.cs.cofc.edu/Bugzilla/bugwritinghelp.html

Official Bugzilla documentation can be found at http://www.bugzilla.org/docs/3.0/html/index.html

-- JerryBoetje - 09 Jul 2003

Standards and Practices

Bugzilla, like many programs, has a set of standards and practices that bug submitters should follow and administrators should adhere to. These good habits can be exhibited by a walk-through of proper bug submission.

Principles

• Be precise
• Be clear - explain it so others can reproduce the bug
• One bug per report
• No bug is too trivial to report - small bugs may hide big bugs
• Clearly separate fact from speculation

Preliminaries

1. Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
2. Search Bugzilla, to see whether your bug has already been reported.

Reporting a New Bug

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

1. Choose "Enter a new bug"

2. Select the product in which you've found the bug

3. Fill out the form. Here is some help understanding the form:

Component: In which sub-part of the software does it exist? This field is required. Click the word “Component” to see a description of each component. If none seems appropriate, look for a “General” component.

OS: On which operating system (OS) did you find it? (Linux, Windows XP, Mac OS X.) If you know the bug happens on more than one type of operating system, choose "All". If your OS isn't listed, choose Other.

Summary: How would you describe the bug, in approximately 60 or fewer characters? A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.

• Good: "Canceling a File Copy dialog crashes File Manager"
• Bad: "Software crashes"
• Bad: "Browser should work with my website"

Description: The details of your problem report, including:
Overview: More detailed restatement of summary. Drag-selecting any page crashes Mac builds in the NSGetFactory? function.

Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.

1. View any web page. (I used the default sample page, resource:/res/samples/test0.html)
2. Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.)

Actual Results: What the application did after performing the above steps. The application crashed.

Expected Results: Were the bug not present what should the application have done? The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.)

Build Date & Platform: Date and platform of the build in which you first encountered the bug. Build 2006-08-10 on Mac OS 10.4.3

Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable). For Example: “Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2)”

Additional Information: Any other useful information.

Crashing Bugs

• Windows: Note the type of the crash, and the module that the application crashed in (e.g. access violation in apprunner.exe).
• Mac OS X: Attach the "Crash Reporter" log that appears upon crash. Only include the section directly below the crashing thread, usually titled "Thread 0 Crashed". Please do not paste the entire log!

Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in the Bugzilla database. After the bug has been submitted, users have the option to discuss the problem or propose solutions.

How to initiate a discussion on Bugzilla

• Any user or administrator can post an issue on Bugzilla, discuss it on Bugzilla and resolve it on Bugzilla.
• When a new issue is posted, Bugzilla automatically send a notification to all the members of Bugzilla distribution list.
• It is responsibility of the admin to have at least one person assigned to Bugzilla distribution list.
• Bugzilla automatically keep all the discussions on it and send their notifications to all the members of Bugzilla distribution list. The issue to be posted has to be specific and appropriate to Bugzilla and its description has to be clear. Otherwise, it will not be ‘assigned’ and remain ‘new’ after it is posted.

How to put a proposed resolution on Bugzilla

• After an issued becomes ‘assigned’, any users and administrators can post a proposed resolution, otherwise specified.
• The days given for reviewing are usually 28 calendar days after it is posted, but may change depending on the issue.
• Deadline should be stated by a calendar day in terms of GMT. o Anyone who is not satisfied with the proposed resolution can post a counter proposed resolution.
• Another 28 calendar days should be given also to the counter proposal.

Several Notes

For any issue that is not resolved yet, anyone who thinks that the issue is inappropriate to be resolved on Bugzilla can raise an opposition, then the issue cannot be resolved on Bugzilla but the discussion on it can be continued on Bugzilla. For any issue whose resolution procedure was initiated by the administrator but not yet resolved, anyone who thinks that the resolution procedure is inappropriate can raise its change proposal to the editor, then the editor has to consider the proposal.