Bugzilla is an open-source tool used for issues and bugs tracking. It is widely used as a bug-reporting tool for all types of testing functions. It helps the developers and other stakeholders to keep track of outstanding problems with the product.
● It was written by Terry Weissman in TCL programming language in 1998.
● Later, Bugzilla was written in PERL and it uses the MYSQL database.
● Bugzilla can be used as a Test Management tool since it can be easily linked with other test case management tools like Quality Center, ALM, Testlink, etc.
● It provides a powerful, easy to use solution to configuration management and replication problems.
● It increases the productivity and accountability of an individual by providing a documented workflow and positive feedback for good performance.
Following are the key features of bugzilla:
● Bugzilla is powerful and it has advance searching capabilities.
● Bugzilla supports user configurable email notifications whenever the bug status changes.
● It has comprehensive security audit and runs under the Perl's taint mode.
● Bugzilla display the complete bug change history.
● Bugzilla has integrated, product-based, granular security schema that makes it more secure.
● Bugzilla provides inter bug dependency track and graphic representation.
● Bugzilla allows users to attach Bug supportive files and manage it.
● Bugzilla supports a robust, stable RDBMS (Rational Data Base Management System) back end.
● It supports Web, XML, E-Mail and console interfaces.
● Bugzilla has a wide range of customized, user preferences features.
● It supports localized web user interface.
● Extensive configurability as it allows to be configured with other test management tools for a better user experience.
● Bugzilla has a smooth upgrade pathway among different versions.
Bugzilla has the provision of "Cloning" an existing bug. The newly created bug keeps most of the settings from the old bug. This helps in tracking similar concerns that require different handling in a new bug.
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 in Bugzilla.
● 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 properly 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: This 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.
● 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.
● 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.
● 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.
● 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.
● 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.
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.
Following are the fields:
● 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.
● Current Est.: This field shows the current estimated time. This number is calculated from Hours Worked and Hours Left.
● Orig. Est.: This field shows the original estimated time.
● Hours Left: This field shows the Current Est. - Hours Worked. This value + Hours Worked will become the new Current Estimated.
● Hours Worked: This field shows the number of hours worked on the particular defect.
● %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 has a provision of editing an existing bug. A user can edit a bug during the lifecycle of any bug. Most of the fields have an edit hyperlink which can be use for editing. It depends on administrator of Bugzilla to provide edit options with different fields.
There are defect reports in Bugzilla which helps to analyse the current state of the bug. The purpose of a Defect Report is to see the behavior, 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 the key things regarding different reports in Bugzilla:
● Bugzilla supports 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 graphs, bar and pie charts.
● The user provides the preference of vertical and horizontal axis to plot graphs, charts or tables along with filter criteria's like Project, Component, Defect Status, etc.
● Report functionality is based on Search and filter concept, for which the conditions are given by users.
● The user can even choose 3-D reports for tables and images.
Graphical reports are a group of line, bar and pie charts. These Reports are helpful in many ways, for example if a user wants to know which component has the maximum number of defects reported and wants to represent in the graph, then that user can select from the following two options:
● Severity on the X-axis
● Component on the Y-axis
The Tabular Reports represent tables of bug counts in 1, 2 or 3 dimensions as HTML or CSV. To generate Tabular reports in Bugzilla, we have to follow multiple steps.