The document is to help anyone that's interested in QA at Mozilla to learn techniques on how to help bugs go along their way. It will help important bugs get fixed faster and optimize our community's Bugzilla efficiency. Before we get into the details, it's important to know what the Triage does as well as why its important.

What is Triaging?

Bug Triaging is the process of moving bugs logically from state to state, so they get resolved in an efficient and easy-to-comprehend manner. In Mozilla, QA must not only test and then file their own bugs, but must also help harness the incoming flow of community bugs for valid problems.

Why would you want to help?

Bugzilla is the heart of the Mozilla project, as every Mozilla product tracks its software defects and enhancements in BMO. There is nothing in the project quite as central or as important as BMO. Triaging is required to ensure that all the defects reported on Bugzilla get responded to. A backlog of bugs in any state, especially the UNCONFIRMED state, affects our ability to react to your important issues quickly and efficiently. Thus, our bug triagers are incredibly vital to our product development.


Get Set Up

Bugzilla Permissions

Creating Search Queries on Bugzilla

Bugzilla offers a couple of ways for a user to find bugs on its database. There is a simple search option and an advanced search option. Each one offers a unique way of searching that allows the user some flexibility in how they want to perform their search. A simple search will only restrict search parameters to any currently not-fixed bug that match the string input by the user. Meanwhile, the advanced search form allows the user the ability to really cut down on any glut found through a simple search. But it can be a bit confusing. So, Bugzilla offers a "Give me Some Help" hyperlink located in the top left portion of the form that reloads the page with hover-enabled tool-tips to guide you through each module. This link also give you more information about searching in Bugzilla.

Persistent Queries and how to Manage them

Tracking Components

If you want something more immediate, you can choose to track a component, such as Disability Access. This is possible via your Bugzilla preferences using the "Component Watching" option. Make sure to track the relevant component in both Core->Disability Access APIs and in the products you care about, such as Firefox (Firefox->Disability Access) or Thunderbird.

Clean incoming Bugs

Why is it Important?

Ensuring bugs are properly marked helps make sure they don't get ignored. For example, if a bug that really affects all platforms is marked "Solaris" because the original bug author was on a Solaris machine, most developers will ignore it. Other common issues include major bugs that are marked normal, bugs with a confusing summary, etc. So, ensuring that the bug is properly marked is very helpful in getting the attention it deserves.

What would Speed Up the Process?

Each time you submit changes to the bug it creates extra Bugmail, so it's better to do the following steps in batches, if possible.

Steps to Reproduce

Sometimes, a bug report contains no steps to reproduce or steps that only work for very few people. In that case, it is extremely difficult for a developer to debug and fix the reported issue. Most of the time, these bug reports (and crash reports, where applicable) will contain multiple clues or variations of steps and it is needed for someone to work through them and narrow down reliable steps to reproduce. Here are a few guidelines for narrowing down those steps:

Minimal Test Cases

Reporters usually add to their bug reports the links for the web pages they saw issues on. Some of these pages are very complex, making it quite difficult to realize where or why the bug happens. To help investigate and debug a issue with a complex web page, you first need to reduce it to a minimal test case (i.e. a test case that contains the minimum set of elements that reproduces the issue). Here are some steps for using the process of elimination to create a minimal test case:

Hopefully you'll be left with a file that has only 1-5 HTML elements in it, but still reproduces the bug. At this point you can actually try to start stripping out irrelevant attributes as well You may end up with something like: <label for="myfile">Enter file name:</label><input id="myfile" disabled="disabled" type="file"> ...instead of 50k worth of HTML. When finished, attach the minimal testcase, mark the bug with keyword testcase, and change the bug summary if necessary. For example, "No borders in tables at" can become something much more precise such as "tables with rowspans do not get borders". If it doesn't affect the test - add a title so it can be referred to, e.g <title>Testcase #1 for bug 123456. Also, add the bug number in the filename of the testcase. You have to understand that people from different parts of the world will be reading this, so making concise and direct sentences are much appreciated. For example, if the bug involves line wrapping, then the width of the window and the font size may impact the results. In this case, you can ensure that your reduced testcase will work for everyone by using "font-family: monospace;" and a width specified in "ch" units.

What do I take away from this?

This can all be rather intimidating for people who haven't been playing around with different web technologies such as AJAX, JS, or XML for a long time, but the most important thing to take away from this page is that there's a backend to the bugs you find when interacting with any software, hardware, or general product. Make sure to take that into account when writing your next bug or triaging a host of incoming bugs on Bugzilla! Continue reading all about Finding a Regression Window.

Original document information