following these techniques you will help the important bugs get
fixed, as well as optimize precious developer time.
Mozilla is an amazing project. Bugs come in from just about
anywhere -- end users, developers, and QA teams scattered
across many organizations. The great benefit is that the various
products are extremely thoroughly tested on a day to day basis and
everyone benefits from the resulting quality. New regressions are
often noticed right away before other new fixes are built on top of
the problematic code. A diversity of opinions often allows the
right solution to bubble to the top, and old bugs that are still
important often come back to the surface instead of being
forgotten.
Unfortunately, even with all of this useful information, there is a
lot of noise. The less experienced community members often file invalid, duplicate, already fixed, improperly filed, and relatively incomplete bugs.
That said, community bugs are an invaluable source of information, as
the testing coverage would not be nearly as wide without it. In
Mozilla, a QA must not only test and then file their own bugs, but
must also help harness the incoming flood of community bugs for
valid problems, putting these issues on track to be addressed.
In addition, new Mozilla QAs are coming into a very complex
project which may not operate in a way similar to projects they've
worked in before.
How does the QA community harness the flood of filed bugs into
better quality for Mozilla while maximizing productivity for
developers? Let's take a look... there's <i>a lot</i> you can do without coding.
== How to Track Relevant Incoming Bugs ==
