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.

• Orig. 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.

In the next chapter, we will learn how to edit a bug.