B2G/QA/Triage

Overview

This document provides a summary of how we manage requests for QA support through bugzilla, more specifically for the B2G QA team.

Summary of Keywords

Note: Only one keyword should be used optimally to represent what is needed by QA.

steps-wanted

When reproducible steps to reproduce are needed for a certain bug.

testcase-wanted

When a reduced test case is needed for a certain bug.

regressionwindow-wanted

When a regression range is necessary to identify a first good build and first bad build for a particular bug.

verifyme

When a verification of a bug is needed to ensure that the patch on the bug actually fixed the problem.

qawanted

When QA support is needed on the bug, but none of the above keywords apply. When this keyword is used, the person flagging qawanted needs to indicate what QA support is needed.

QA Contact

The use of QA contact field should be set optimally when the person is actively investigating something in relation to the bug, usually in connection to one of the keywords above. The QA contact field should aim to only be set by the person who is planning on working on the bug for some piece of QA. There are some exception cases to this rule however stated below.

• An explicit owner is known up front for a component who actively manages the bugs - in this case, the default QA contact will be used to address QA needs for the bugs.
• An high need is raised to find an owner for a bug in triage - in this case, triagers should first consider setting the QA contact to the QA representative in triage to find an QA owner to address QA needs for the bug. If no QA representative is available in the triage meeting, then one of three sheriffs should be set as the QA owner:
  • Gaia: Naoki Hirata
  • Platform: Geo Mealer
  • Apps: Jason Smith

Priorities

Describe priorities for the bugs flagged with the keywords above

Queries

List off the major relevant queries for b2g