Bugzilla

Go back to Tutorial

Bugzilla is an open-source issue/bug tracking system that allows developers to keep track of outstanding problems with their product. It is written in Perl and uses MYSQL database. Bugzilla is a Defect tracking tool, however, it can be used as a test management tool as such it can be easily linked with other Test Case management tools like Quality Center, Testlink etc.

This open bug-tracker enables users to stay connected with their clients or employees, to communicate about problems effectively throughout the data-management chain.

Key features of Bugzilla includes

• Advanced search capabilities
• E-mail Notifications
• Modify/file Bugs by e-mail
• Time tracking
• Strong security
• Customization
• Localization

Bugzilla System Requirements

Bugzilla is a freeware and the installation includes certain procedure. It basically requires:

• Perl
• Database Engine (MySQL, Postgre SQL. Oracle)
• Web server (Any web server that can run CGI scripts)
• Bugzilla Files
• Perl Modules
• Mail Transfer Agent

Bugzilla Installation

The Bugzilla GIT website is the best way to get Bugzilla. Download and install GIT from the website − https://git-scm.com/download and Run it.

git clone –branch release-X.X-stable https://github.com/bugzilla/bugzilla

C:\bugzilla

Where, “X.X” is the 2-digit version number of the stable release of Bugzilla (e.g. 5.0)

The another way to download Bugzilla is from the following link − https://www.bugzilla.org/download/ and move down to the Stable Release section and select the latest one from the list.

Bugzilla comes as a ‘tarball’ (.tar.gz extension), which any competent Windows archiving tool should be able to open.

PERL Modules – Bugzilla requires a number of Perl modules to be installed. Some of them are mandatory, and some others, which enable additional features, are optional. In ActivePerl, these modules are available in the ActiveState repository, and are installed with the ppm tool. Either it can use it on the command line or just type ppm and the user will get a GUI. Install the following mandatory modules with the following command.

ppm install <modulename>

Sample Web Application

The Bugzilla installation requires several technical aspects to start with. A few websites provide the Bugzilla web application – Landfill: The Bugzilla Test Server is one of these. https://landfill.bugzilla.org/bugzilla-2.16.11/ this is the testing and demonstration website.

Landfill is a home for test installations of the Bugzilla bug-tracking system. If you are evaluating Bugzilla, you can use them to try it. They are also useful if you are a developer and want to try to reproduce a bug that somebody has reported. Once you navigate to the above-mentioned URL, the Bugzilla home page

New Account Creation

The process of creating an account is similar to any other web based application like Facebook, Gmail, etc. Following are the steps to create an account −

Step 1 − Go to https://landfill.bugzilla.org/bugzilla-5.0-branch/

Step 2 − On the Bugzilla home page, click the New Account link placed on the header

Step 3 − Enter the email address and click on Send.

Step 4 − Within moments, the user will receive an email to the given address. This Email should have a login name and a URL to confirm the registration.

Step 5 − Once the registration is confirmed, Bugzilla will ask the real name (optional, but recommended) and ask the user to type their password and confirm their password. Depending on how Bugzilla is configured, there may be minimum complexity requirements for the password.

Step 6 − Once the details are filled, click on Create, a successful message of account creation displays on the screen, else it will display an error message. Correct the error and then click on Create.

Login to Bugzilla

To login into Bugzilla, we have to follow the steps given below.

Step 1 − Click on the Log In link on the header of the homepage.

Step 2 − Enter the Email Address, Password and click on Log In

Step 3 − The user will be logged in successfully; the users can see their user id in the header section.

Step 4 − The user can see open bugs assigned to him, reported by him and requests addressed to him at the left bottom section.

Logging a New Bug

The procedure of filling a new bug is quite simple and has been explained below.

Step 1 − Click on the ‘New’ link, present on the header or the footer or Click on the File a Bug button on the home page.

Step 2 − Now, select the product group in which the bug is noticed.

Step 3 − After selecting the Product, a form will appear where the user should enter the following details related to the bug −

• Enter Product
• Enter Component
• Give Component description
• Select version
• Select severity
• Select Hardware
• Select OS
• Enter Summary
• Enter Description
• Attach Attachment

The above fields vary as per the customization of Bugzilla. The Mandatory fields are marked with a red asterisk (*).

Step 4 − Once the user starts typing in the Summary, Bugzilla filters the already logged in defects and displays the list to avoid duplicate bugs.

Step 5 − Click on the Submit Bug button to log the bug.

Submit Bug

Step 6 − As soon as the user clicks on the Submit bug button, a Bug Id is generated with the details that of bug as that were entered.

Generated Details

Step 7 − The Deadline and the Status will be shown. A user can also add additional information to the assigned bug like URL, keywords, whiteboard, tags, etc. This extra-information is helpful to give more details about the Bug that is created.

• Large text box
• URL
• Whiteboard
• Keywords
• Tags
• Depends on
• Blocks

Bug Details in Bugzilla

The main feature or the heart of Bugzilla is the page that displays details of a bug. Note that the labels for most fields are hyperlinks; clicking them will take to context-sensitive help of that particular field. Fields marked * may not be present on every installation of Bugzilla.

• Summary − It is a one-sentence summary of the problem, which is displayed in the header next to the bug number. It is similar to the title of the bug that gives the user an overview of the bug.
• Status (and Resolution) − These define status of the bug – It starts with even before being confirmed as a bug, then being fixed and the fix being confirmed by Quality Assurance. The different possible values for Status and Resolution on installation should be documented in the context-sensitive help for those items. Status supports Unconfirmed, Confirmed, Fixed, In Process, Resolved, Rejected, etc.
• Alias − An Alias is a unique short text name for the bug, which can be used instead of the bug number. It provides the unique identifiers and help to find the bug in case of Bug ID is not handy. It can be useful while searching for a bug.
• Product and Component − Bugs are divided by Products and Components. A Product may have one or more Components in it. It helps to categorize the bugs and helps in segregating them as well.
• Version − The “Version” field usually contains the numbers or names of the released versions of the product. It is used to indicate the version(s) affected by the bug report.
• Hardware (Platform and OS) − These indicate the tested environment or the operating system, where the bug was found. It also gives out the details of the hardware like RAM, Hard Disk Size, Processor, etc.
• Importance (Priority and Severity) − The Priority field is used to prioritize bugs. It can be updated by the assignee, business people or someone else from stakeholders with the authority to change. It is a good idea not to change this field on other bugs, which are not raised by a person. The default values are P1 to P5.
• Severity Field − The Severity field indicates how severe the problem is—from blocker (“application unusable”) to trivial (“minor cosmetic issue”). User can also use this field to indicate whether a bug is an enhancement or future request. The common supportive severity statuses are – Blocker, Critical, Major, Normal, Minor, Trivial and enhancement.
• Target Milestone − It is a future date by which the bug is to be fixed. Example – The Bugzilla Project’s milestones for future Bugzilla versions are 4.4, 5.0, 6.0, etc. Milestones are not restricted to numbers though the user can use any text strings such as dates.
• Assigned To − A Bug is assigned to a person who is responsible to fix the bug or can check the credibility of the bug based on the business requirement.
• QA Contact − The person responsible for quality assurance on this bug. It may be the reporter of the bug to provide more details if required or can be contacted for retest the defect once it is fixed.
• URL − A URL associated with the bug, if any.
• Whiteboard − A free-form text area for adding short notes, new observations or retesting comments and tags to a bug.
• Keywords − The administrator can define keywords that can be used to tag and categories bugs — for e.g. crash or regression.
• Personal Tags − Keywords are global and visible by all users, while Personal Tags are personal and can only be viewed and edited by their author. Editing those tags will not send any notifications to other users. These tags are used to keep track of bugs that a user personally cares about, using their own classification system.
• Dependencies (Depends On and Blocks) − If a bug cannot be fixed as some other bugs are opened (depends on) or this bug stops other bugs for being fixed (blocks), their numbers are recorded here.

Dependency Tree Link

Clicking on the Dependency tree link shows the dependency relationships of the bug as a tree structure. A user can change how much depth to show and hide the resolved bugs from this page. A user can also collapse/expand dependencies for each non-terminal bug on the tree view, using the [-] / [+] buttons that appear before the summary.

• Reported − It is the Time and Date when the bug is logged by a person in the system.
• Modified − It is the Date and Time when the bug was last changed in the system.
• CC List − A list of people who get mail when the bug changes, in addition to the Reporter, Assignee and QA Contact (if enabled).
• Ignore Bug Mail − A user can check this field if he never wants to get an email notification from this bug.
• See Also − Bugs, in this Bugzilla, other Bugzilla or other bug trackers those are related to this one.
• Flags − A flag is a kind of status that can be set on bugs or attachments to indicate that the bugs/attachments are in a certain state. Each installation can define its own set of flags that can be set on bugs or attachments.
• Time Tracking − This form can be used for time tracking. To use this feature, a user has to be a member of the group specified by the timetrackinggroup parameter.
• Est. − This field shows the original estimated time.
• Current Est. − This field shows the current estimated time. This number is calculated from Hours Worked and Hours Left.
• Hours Worked − This field shows the number of hours worked on the particular defect.
• Hours Left − This field shows the Current Est. – Hours Worked. This value + Hours Worked will become the new Current Estimated.
• %Complete − This field shows how much percentage of the task is complete.
• Gain − This field shows the number of hours the bug is ahead of the Original Estimated.
• Deadline − This field shows the deadline for this bug.
• Attachments − A user can attach files (evidence, test cases or patches) to bugs. If there are any attachments, they are listed in this section.
• Additional Comments − A user can add comments to the bug discussion here, if user/tester has something worthwhile to say.

Bugzilla Reports

A report helps to analyse the current state of the bug. The purpose of a Defect Report is to see the behaviour, communication, analysis and the current stage of a defect at any stage of the defect lifecycle. Defect reports are even useful after closing the defect and analysis the product and development quality.

Following are some of the important points to consider regarding the various Bugzilla reports.

• Bugzilla supports those Tabular Reports that have HTML or CSV reports.
• Tabular reports can be viewed in 1-Dimensional, 2-Dimensional or 3-Dimensional ways.
• The most common type of report supported by Bugzilla are the Graphical Reports.
• Graphical Reports contain line graph, bar and pie charts.
• Report functionality is based on Search and filter concept, for which the conditions are given by users.
• The user provides his preference of vertical and horizontal axis to plot graphs, charts or tables along with filter criteria’s like Project, Component, Defect Status, etc.
• The user can even choose 3-D reports for tables and images.

Navigating the Reports Section – For navigating the reports section in Bugzilla, we should follow the steps given below.

Step 1 − Click on the Reports link in the header of the homepage.

Step 2 − Bugzilla displays the Reporting and Charting Kitchen page. It has two sections to generate different type of reports – Tabular Reports and Graphical Reports.

Other links like −

• Search − It will navigate the user to the standard search page.
• Duplicate − It will display the most frequently reported bugs.

Bug Lists

A bug list is a group of searched bugs based on the user input. A Bug list is nothing other than filtered bugs based on different conditions in a Standard Search or an Advanced Search. The format of the list is configurable. For example, it can be sorted by clicking the column headings. Other useful features can be accessed using the links at the bottom of the list, which are −

• Long Format
• XML (icon)
• CSV (icon)
• Feed (icon)
• iCalendar (icon)

Go back to Tutorial