BugzillaForDevelopers.pdf

Bugzilla for Developers What is Bugzilla? Definition: Bugzilla is a web-based bug-tracking tool that helps software development teams track and manages bugs and issues in their projects. Purpose: It’s designed to keep track of reported software bugs, their status, and their pro...

Bugzilla for Developers What is Bugzilla? Definition: Bugzilla is a web-based bug-tracking tool that helps software development teams track and manages bugs and issues in their projects. Purpose: It’s designed to keep track of reported software bugs, their status, and their progress from identification to resolution. Here is the Bugzilla dashboard overview: New – Create new bugs from the tester's dashboard. Browser - Redirect the user to the product list. Search - Find a specific bug by entering words that describe it. Two types of search – 1) Simple Search 2) Advance Search Reports – We can create a Tabular, Graphical, or Duplicate Format. Preference - Users will be able to update their own bugs from the Preference. Administration - "Administration rights" refer to special permissions given to certain users, typically administrators or admins. These rights allow them to manage and configure the Bugzilla system. Admins can perform tasks such as creating and managing user accounts, configuring system settings, defining permissions for users, and customizing the Bugzilla instance according to organizational needs. How to Add Products in Bugzilla– Navigate the Bugzilla homepage header bar where you find the Administration option, click on it then click on the Product tab to add a new project. Add product: Let’s understand how we can add a project and default assignee, component & their description in Bugzilla. Add Description - Write a one- or two-paragraph explanation of what the project aims to accomplish. Open for bug entry - It means that users can report new bugs or issues related to that specific product in Bugzilla. Version: Different versions or releases of the product. This helps in tracking bugs specific to particular versions. Add Components: Sub-categories within a product. Components allow you to break down a product into smaller, more manageable parts, each with its own set of bugs. Component Description: A brief description of the component, providing an overview of what it is and its purpose. Default Assignee: The user (typically a developer or team) who will be automatically assigned to new bugs for this product. Default CC List: A list of users who will be automatically copied on all bugs for this product. These users receive notifications about changes and updates. Let’s understand how the Tester File A Bug: For filing a bug tester needs to click on one of these buttons/hyperlinks to open the bug entry page. After clicking on the “New” or “File a bug” hyperlinks it will take testers to the Project list page where the tester can choose in which project he/she found the bug for bug filing and click on it. Product: The product in which the bug was found. This helps categorize the issue within a larger system or suite of software. Component: A specific part or module of the product where the bug was observed. For instance, if the product is a web browser, components might include "UI", "Networking", or "Rendering". Version: The version of the product in which the bug was found. This helps in identifying if the bug is present in a specific release or if it has been fixed in newer versions. Platform: The operating system or hardware on which the bug was observed. This can include options like Windows, macOS, Linux, etc. OS Version: The specific version of the operating system. For example, Windows 10 Summary: A brief, concise title for the bug. This should summarize the issue in a few words to quickly convey what the problem is. Description: A detailed explanation of the bug, including steps to reproduce it, what the expected behaviour is, and what actually happened. This section helps developers understand the issue and how to address it. Severity: An indication of how critical the bug is. This can range from minor annoyances to major issues that prevent the product from functioning. Priority: How important it is to fix the bug. This often reflects the urgency or impact on users, and can be influenced by factors like business needs or user complaints. Assigned To: The person or team responsible for addressing the bug. If you're not sure who should handle it, this might be left unassigned. Status: The current state of the bug report. Common statuses include "NEW" (bug has been reported but not yet reviewed), "ASSIGNED" (someone is working on it), "RESOLVED" (a fix has been made), and "CLOSED" (the fix has been verified and the issue is resolved). Keywords: Tags that help categorize the bug or associate it with specific areas of interest, like "security" or "performance". CC: Email addresses of people who should be notified about updates to the bug report. Attachments: Files or screenshots that provide additional context or evidence for the bug. This might include log files, screenshots, or other relevant documents. Result: After filling in all the above information regarding the bug, the tester will click on the Submit button to submit the bug. After clicking on the submit button email will go to the default assignee and the CC members who can see or modify the bugs. What will Developers do? Developers need to find out the bugs which are assigned to them. Developer needs to click on one of the highlighted options in below image: Let’s understand how to see all the bugs of a specific product at a time instead of searching one by one. For this, I am going to use the search option which big Icon is shown in the dashboard. Choose Status: Select status according to what you want to see like only open bugs, closed, or All bugs. Choose Product: Select a product to see product bugs based on the status selected above. Click the search button: after selecting the fields, click the search button to see the list of bugs based on your selection. See the below image for how the result will display: To open a bug as a developer, you need to click on the bug ID to see the entire bug details. You need to go to the Status field and update the status based on your bug resolution/solution. After updating the status email will automatically be sent to the respective bug reporter and CC members. Using your status as a guide, the tester will retest the issue and mark it as resolved if it has been fixed, or reopen it if it hasn't. Common terminology that developers should know about the Status Options: NEW Bug: The bug has been reported and is awaiting triage or assignment. No action has been taken yet. ASSIGNED: The bug has been assigned to a developer or team member who will work on resolving it. VERIFIED: The fix for the bug has been tested and confirmed by QA or the reporter. The bug is considered fully resolved. CLOSED: The bug has been resolved and verified, and no further action is required. This is the final status in the bug's lifecycle. RE-OPEN: Bug Not Fixed Resolution: What was done to address the bug? This could include statuses like "FIXED", "WONTFIX", "DUPLICATE", etc., explaining how the issue was resolved or why it won’t be addressed. RESOLVED: The bug has been addressed. This status often requires specifying a resolution type, which explains how the bug was handled. Common resolution types include: FIXED: The bug has been fixed. INVALID: The bug report was not valid. WONTFIX: The bug will not be fixed. This decision is typically made when the issue is not considered important enough to address or if fixing it is not feasible. DUPLICATE: The bug is a duplicate of another bug already reported.