B2G/QA/Writing A Bug: Difference between revisions

From MozillaWiki
< B2G‎ | QA
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 =
== 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.
* 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:

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?
  1. developers : Make it easy for the developers to understand how to reproduce the bug; they are the ones fixing the bug you find!
  2. other qa : Make it easy for the other QA to reproduce your issue to verify if it's fixed or not
  3. 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'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"