B2G/QA/Writing A Bug: Difference between revisions
Jump to navigation
Jump to search
(Created page with "= Check for Dups = * Verify that there isn't a bug on it first ** Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected....") |
No edit summary |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
= Check for Dups = | #redirect[[B2G/QA/Bugzilla]] | ||
== Forward == | |||
Note: | |||
* Some of this is a repeat of some of the other documentation we have; others are specific to the project : | |||
** https://developer.mozilla.org/en-US/docs/User:Triona/Bug_writing_guidelines | |||
** https://quality.mozilla.org/docs/bugzilla/starter-kit/how-to-write-a-proper-bug/ | |||
** https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines | |||
* keep in mind that these are guidelines and not hard set rules. | |||
== Check for Dups == | |||
* Verify that there isn't a bug on it first | * Verify that there isn't a bug on it first | ||
** Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected. Getting used to some of the terminology helps out greatly. | ** Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected. Getting used to some of the terminology helps out greatly. | ||
= | == Know your audience == | ||
* who is your audience? | * who is your audience? | ||
# developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find! | # developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find! | ||
| Line 9: | Line 19: | ||
# PMs/EPMs/Releng Managers : They need to understand how critical the bug is to place fixing the bug in the schedule | # PMs/EPMs/Releng Managers : They need to understand how critical the bug is to place fixing the bug in the schedule | ||
= Have a clear title = | == Filing the bug == | ||
=== Product/Components === | |||
=== Title === | |||
==== Have a clear title ==== | |||
* be precise | * be precise | ||
** A title of a bug should describe the issue clearly and a reader can tell what the bug is by just the title alone; this helps with triaging the bug | ** A title of a bug should describe the issue clearly and a reader can tell what the bug is by just the title alone; this helps with triaging the bug | ||
* What, Where, When, Why, How are some questions that should be answered in the title. | |||
=== Build/Platform === | |||
=== Description/STR === | |||
=== Expected Results === | |||
=== Actual Results === | |||
=== Additional information/notes === | |||
=== Attachments === | |||
==== logcat ==== | |||
==== images ==== | |||
==== video ==== | |||
==== crash reports ==== | |||
==== OOM ==== | |||
=== Tags === | |||
=== Examples === | |||
== Filed a Bug? There's more things to do! == | |||
* check if it's a regression | |||
** If it is a regression; tag it with the keywords: "regression" and "regressionwindow-wanted" | |||
*** find out the regression range and remove the regressionwindow-wanted. | |||
* If it's a crash in b2g, whiteboard the bug "[crash-b2g]" keyword the bug "crash" | |||
* If it's a SUMO bug, whiteboard the bug "[SUMO-b2g]" | |||
* If it's a Gaia UI automation test was disabled because of a bug, whiteboard tag "xfail" | |||
Latest revision as of 01:18, 6 November 2013
Redirect to:
Forward
Note:
- Some of this is a repeat of some of the other documentation we have; others are specific to the project :
- keep in mind that these are guidelines and not hard set rules.
Check for Dups
- Verify that there isn't a bug on it first
- Sometimes searching for the bug isn't easy. There's many ways to say what a bug is or how a bug is affected. Getting used to some of the terminology helps out greatly.
Know your audience
- who is your audience?
- developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find!
- other qa : Make it easy for the other QA to reproduce your issue to verify if it's fixed or not
- PMs/EPMs/Releng Managers : They need to understand how critical the bug is to place fixing the bug in the schedule
Filing the bug
Product/Components
Title
Have a clear title
- be precise
- A title of a bug should describe the issue clearly and a reader can tell what the bug is by just the title alone; this helps with triaging the bug
- What, Where, When, Why, How are some questions that should be answered in the title.
Build/Platform
Description/STR
Expected Results
Actual Results
Additional information/notes
Attachments
logcat
images
video
crash reports
OOM
Tags
Examples
Filed a Bug? There's more things to do!
- check if it's a regression
- If it is a regression; tag it with the keywords: "regression" and "regressionwindow-wanted"
- find out the regression range and remove the regressionwindow-wanted.
- If it is a regression; tag it with the keywords: "regression" and "regressionwindow-wanted"
- If it's a crash in b2g, whiteboard the bug "[crash-b2g]" keyword the bug "crash"
- If it's a SUMO bug, whiteboard the bug "[SUMO-b2g]"
- If it's a Gaia UI automation test was disabled because of a bug, whiteboard tag "xfail"