Confirmed users
2,816
edits
QA/Desktop Firefox/Triaged Bug List: Difference between revisions
QA/Desktop Firefox/Triaged Bug List (view source)
Revision as of 18:09, 8 September 2014
, 8 September 2014updated whiteboard tags to current set of flags
m (→Triage Meetings: Removed outdated meeting info) |
m (updated whiteboard tags to current set of flags) |
||
| Line 1: | Line 1: | ||
= QA+ Triage Strategy for Bug Verifications = | = QA+ Triage Strategy for Bug Verifications = | ||
* | We use this dashboard for triaging the current versions of Firefox: | ||
https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/qa/ | |||
Mark bugs for verification with the qe-verify flag. | |||
* qe-verify?: More information is needed for QA to decide on qe+/- | |||
** if a bug is missing a testcase or steps to reproduce | ** if a bug is missing a testcase or steps to reproduce | ||
** if a bug is hard to understand, too complex | ** if a bug is hard to understand, too complex | ||
** Canned Response: | ** Canned Response: | ||
*** | *** qe-verify?: We need more information to verify this bug. | ||
* | * qe-verify+: QA needs to verify the fix | ||
** the test case to verify the fix should be clearly defined | ** the test case to verify the fix should be clearly defined | ||
** Canned Response: | ** Canned Response: | ||
*** | *** qe-verify+: tracking to verify fix (indicate branches needed for verification) | ||
* | * qe-verify-: QA can/will/need not verify the fix | ||
** build config bugs | ** build config bugs | ||
** code-cleanup bugs | ** code-cleanup bugs | ||
| Line 20: | Line 22: | ||
** bugs with the assertion keyword | ** bugs with the assertion keyword | ||
** Canned Response: | ** Canned Response: | ||
*** | *** qe-verify-: nothing for QA to verify | ||
* | * qe-verify!: QA has done all it can to test this bug | ||
** verified across all affected branches and platforms | ** verified across all affected branches and platforms | ||
** made a reasonable effort reaching out to domain experts or bug reporters who, in the absence of clear steps to reproduce or test cases, can verify the bug | ** made a reasonable effort reaching out to domain experts or bug reporters who, in the absence of clear steps to reproduce or test cases, can verify the bug | ||
(Out of date?) | |||
* qa^: QA would like higher prioritization on this bug from dev: | * qa^: QA would like higher prioritization on this bug from dev: | ||
** qa has seen this bug and triaged but the bug has not been dev prioritized | ** qa has seen this bug and triaged but the bug has not been dev prioritized | ||
| Line 29: | Line 33: | ||
** This is mostly used for the mobile team, as dev prioritizes the bugs with dev priority using the priority field. | ** This is mostly used for the mobile team, as dev prioritizes the bugs with dev priority using the priority field. | ||
== Bug Query Mechanics == | |||
You can use the dashboard at https://crash-analysis.mozilla.com/rkaiser/crash-report-tools/qa/ | |||
Or... | |||
Go to the pushlog page and query for the last 2 weeks worth of bugs depending on how recently you have had a triage session. Then apply the "collect buglinks" bookmarklet to get a list of bugs from the pushlog, and go through those. | Go to the pushlog page and query for the last 2 weeks worth of bugs depending on how recently you have had a triage session. Then apply the "collect buglinks" bookmarklet to get a list of bugs from the pushlog, and go through those. | ||