QA/Triage: Difference between revisions

QA/Triage (view source)

Revision as of 12:50, 27 September 2007

1,482 bytes removed , 27 September 2007

→‎Intro

Mw22

Confirmed users

486

edits

@@ Line 6: / Line 6: @@
 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 ==

QA/Triage: Difference between revisions

QA/Triage (view source)

Revision as of 12:50, 27 September 2007

Navigation menu

Search