B2G/QA/Writing A Bug

< B2G‎ | QA
Revision as of 22:40, 9 October 2013 by Nhirata (talk | contribs) (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....")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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.