Bugzilla
- What is Bugzilla?
- Benefits of using Bugzilla
- How Bugzilla works
- Setting up Products and Components
- How to work with bugs
- Bug Assignment Tips
- Bug Resolution Cycle
- General Bugzilla Tips
- Anatomy of a Bug
- Do I need to use Bugzilla?
- Where can I learn more?
What is Bugzilla?
Bugzilla is a web-based task and bug tracking system, also known as a Defect Tracking System, which is used for managing software development. The technology behind Defect Tracking Systems allows customers and professionals to effectively keep track of outstanding project tasks and bugs.
Entering and changing items in Bugzilla will trigger an automatic email to a list of people, keeping everyone up-to-date on progress.
Bugzilla is especially useful for medium and large teams, where managers need to distribute project tasks to a group of workers, but it is recommended for all projects.
Benefits of using Bugzilla
Bugzilla offers several benefits to oDesk customers and professionals
Customer Benefits
- Manage distributed teams by assigning ownership of various tasks
- Track the status of tasks anytime
- Notify relevant team members of task or status changes
- Improve overall quality assurance
Professional Benefits
- Keep the customer informed of your progress
- Manage your activities
- See what your teammates are working on
- Improve customer satisfaction
How Bugzilla works
Bugzilla categorizes task in a 2-tier structure – products and components. Products are the top-level category, and each product can have multiple components.
Products are the broadest category in Bugzilla, and tend to represent real-world shipping products. For example, if your company makes computer games, you should have one product per game.
Components are subsections of a Product. It makes sense to divide Components in Bugzilla according to the parts of your project. Each component has an owner and, optionally, a QA Contact. The owner should be the primary person who fixes bugs in that component. The QA Contact should be the person who will ensure the bugs are completely fixed. The Owner, QA Contact, and Reporter will get email when new bugs are created in this Component and when these bugs change.
The bug lifecycle has 3 primary steps:
- Bugs typically start with a New status when they are first reported by any team member, then when a programmer takes ownership of fixing the problem, the bug has been Assigned.
- Later, after the programmer believes the bug has been fixed, they can change the status to Resolved.
- Once a bug reaches the resolved status, it should be reviewed by Quality Assurance and either accepted or rejected.
Setting up Products and Components
To get started, log into your Bugzilla account at https://secure.odesk.com/bugzilla using the credentials provided to you.
The overall administration of Bugzilla consists of two main parts: products and components. Before you can do anything else in Bugzilla, you must create a Product.
How to create a Product
- Select Products from the footer.
- Select the Add link in the bottom right of the screen.
- Enter the name of the product and a description. The Description field may contain HTML.
Next, you should create some number of components as subsections of your Product.
How to create a Component
- Select the Add link in the bottom right of the screen.
- Fill out the Component field, a short description, the Initial Owner and Initial QA Contact (if enabled.) The Component and Description fields may contain HTML; the Initial Owner field must be a login name already existing in the database.
How to work with bugs
Let’s say that you’ve reviewed an application and discovered a bug that you would like resolved by your development team.
- Go to the main page on Bugzilla page, and click on Enter a new bug.
- Enter details about the platform, priority, operating system, and severity of the bug.
- Assign the bug to either the default component owner, or anyone else on your team. If relevant, add a URL, and be sure to provide a clear summary and description of the bug that you’re inputting.
- Click Commit. The bug has been now been entered with a status of New. An email notification will go to all individuals that are related to the component or bug. The bug has begun its lifecycle.
- If you have bug ownership, query the new bug by clicking Query in the footer.
- Select the general product, and use the default search to find all new, Assigned, and re-opened bugs.
- Select the latest bug, add a comment, and then select Accept Bug near the bottom of the form.
- Click Commit to change the status of the bug to Assigned. Again, this will send email notifications to all appropriate people.
- Assuming the bug has been fixed, the assignee should go back to the bug by either querying the bug or selecting bugs in the footer.
- Then add comments describing how the bug was fixed.
- Select Resolve bug, and change resolution to Fixed. Then commit the changes and the bug will be updated and emails sent once again.
- Now that the bug has been resolved, return to the main page of Bugzilla. Here you will also be able to edit the email preferences by following the Prefs link, or view summary reports of all bugs by clicking the Reports link in the footer.
Bug Assignment Tips
- Submission of a bug in Bugzilla assigns it to the default person for that component. The bug status is initially New.
- When a developer starts fixing a bug, he must Accept the bug (or change status to Assigned) so the engineering team is aware of who does what and overlapping work is avoided. The bug status is then Assigned.
- As long as a task is in New status, it can be considered as not been Assigned to somebody in particular. That’s why it is imperative that before a developer starts fixing a bug he Accepts it, changing its status from New to Assigned (and eventually to Fixed) so that everybody in the team knows what is going on and by whom and overlapping work is avoided.
- Don’t work on fixing a bug while its status is New.
- Proceed to accept a bug only when you are ready to actually start work on it. Until then, leave it as New so the whole team is aware of the progress of work.
- There should never be a bug with New status after someone has started working on it.
- There should never be a bug with Assigned status before somebody starts working on it or after work is considered complete and only QA/verification is needed.
- Change of status to Fixed signals that QA work can begin by the tasks QA contact so that the task fixing becomes Validated.
Bug Resolution Cycle
- Once a bug is resolved as Fixed, the QA Contact should try to reproduce the bug, test the new functionality, verify that the affected functions still work as expected, based on what the bug says in Bugzilla.
- If the bug description is not enough, the QA Contact person should talk with the Reporter to understand what exactly he had in mind. These clarifications should also be added as bug comments.
- If everything is OK, the QA Contact marks the bug in bugzilla as Verified.
- If you see a problem, describe it on the bug comment area and reopen it.
General Bugzilla Tips
- All team members should use the comments/annotation/file attachment capability of Bugzilla to keep information centralized. For bug and task tracking, encourage all team members to put comments in the bug, or put bug number in email subject.
- When you login to Bugzilla, you see the query page with a footer. The preset query My Bugs will display all bugs owned by you, sorted by importance.
- Other commonly used queries can be named and saved. The query will then be available in the page footer of the logged-in user. To do that, enter your query parameters as usual in the query page, and before clicking on the Search button, make sure to check the radio button (located near the bottom of the query page):
- Remember this query, and name it: QueryMnemonicGoesHere and put it in my page footer
- Make a habit to sort results by Importance in your queries. The default sort order is by ID (which in effect is the chronological order bugs were submitted) and consequently does not reflect the prioritization of bugs in any way.
Anatomy of a Bug
1. Product and Component: Bugs are divided up by Product and Component, with a Product having one or more Components in it.
2. Status and Resolution: These define exactly what state the bug is in - from not even being confirmed as a bug, through to being fixed and the fix confirmed by Quality Assurance. The different possible values for Status and Resolution on your installation should be documented in the context-sensitive help for those items.
3. Assigned To: The person responsible for fixing the bug.
4. URL: A URL associated with the bug, if any.
5. Summary: A one-sentence summary of the problem.
6. Status Whiteboard: (a.k.a. Whiteboard) A free-form text area for adding short notes and tags to a bug.
7. Keywords:The administrator can define keywords which you can use to tag and categorize bugs - e.g. The Mozilla Project has keywords like crash and regression.
8. Platform and OS: These indicate the computing environment where the bug was found.
9. Version: The "Version" field is usually used for versions of a product which have been released, and is set to indicate which versions of a Component have the particular problem the bug report is about.
10. Priority: The bug assignee uses this field to prioritize his or her bugs. It's a good idea not to change this on other people's bugs.
11. Severity: This indicates how severe the problem is - from blocker ("application unusable") to trivial ("minor cosmetic issue"). You can also use this field to indicate whether a bug is an enhancement request.
12. Target: (a.k.a. Target Milestone) A future version by which the bug is to be fixed. e.g. The Bugzilla Project's milestones for future Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not restricted to numbers, thought - you can use any text strings, such as dates.
13. Reporter: The person who filed the bug.
14. CC list: A list of people who get mail when the bug changes.
15. Attachments: You can attach files (e.g. test-cases or patches) to bugs. If there are any attachments, they are listed in this section.
16. Dependencies: If this bug cannot be fixed unless other bugs are fixed (depends on), or this bug stops other bugs being fixed (blocks), their numbers are recorded here.
17. Votes: Whether this bug has any votes.
18. Additional Comments: You can add your two cents to the bug discussion here, if you have something worthwhile to say.
Do I need to use Bugzilla?
Use of Bugzilla is optional for customers. Professionals must use whatever task-tracking system is chosen by the customer.
- Customer use: Bugzilla is an optional tool that oDesk offers to help customers manage their remote workers. oDesk recommends the use of Bugzilla for customers with 3 or more oDesk Professionals. Customers use Bugzilla to define tasks, assign tasks, and monitor progress.
- For professionals: Professionals are required to use whatever task tracking system is chosen by the customer, such as Bugzilla or any in-house system provided by the customer. Professionals typically use Bugzilla to review tasks, comment on specific tasks, and report on progress. Many professionals also enter the Bugzilla task number into their workmemo in oDesk Team. This makes it easier for customers to track time per task.
Where can I learn more?
This covers the basics of Bugzilla. You can learn quite a bit more by reading the official Bugzilla documentation at http://www.bugzilla.org/docs/