QA/Cleaning Bugs

From MozillaWiki
< QA
Jump to: navigation, search

Why is it Important?

Ensuring the bugs are properly marked up helps make sure they don't get ignored. For example, if a bug, marked as "Solaris", really affects all platforms, most developers will ignore it because they need to focus on bugs that affect the most people. Also, if a bug is reported to the wrong component it can also end up getting stuck in no man's land where it's ignored for the rest of eternity.

Another common issue is if truly major bugs are marked normal, or have a confusing summary. So, ensuring that the bug is properly marked up is very helpful for getting it attention as well as keeping it from being ignored by appropriate queries that developers and other QAs run.

What would Speed Up the Process?

Each time you submit changes to the bug it creates extra Bugmail, so it's better to do the following steps in batches, if possible.

  1. Find the Inherent Issue: Read very carefully to try and understand what they're talking about. For a guide on how to simplify test cases, go here.
  2. Look for duplicates: A lot of bug reporters mistakenly assume their bug haven't been filed yet. Search for previously filed bugs by searching for keywords in the summary in the bug. For example, if the bug is about the control key, try spelling it ctrl as well.
  3. Ask for more information from the reporter: If you don't understand the bug or can't reproduce the bug, ask the reporter for more information, until you have enough to try it yourself. If they did not provide build information, get that right away, because many bug reports are for older versions that have long been fixed.
    Some other information you could ask for:
  4. Ensure appropriate hardware/platform tests: most bug filers will only have tested on one platform. If bug was filed for a particular platform, see if it's a bug on another platform. If it's been reproduced on at least 2 platforms that aren't both Unix/Linux, then go ahead and mark it All/All ((Hardware/OS). If you don't have the capability to test across multiple platforms, going to the #qa channel on irc.mozilla.org is an excellent way to find people that can verify your bug on other platforms.
  5. Ensure a concise and precise summary: The summary should be 60 characters or less and allow the bug to be reachable via an accurate simple search.
  6. Ensure Proper Severity: Go to this link and scroll down to the "Severity" section for a handy guide. If you feel like the listed severity on the bug report is not accurate, make sure to comment why the bug should be changed and change the state.
  7. Change Product, Component and owner: Many bugs get marked "Firefox" when they are really bugs in the core engine. If it's a basic XUL, HTML or layout bug that affects multiple products, send it to Core. After you submit a Product change to the bug, Bugzilla will allow you to change the Component as well. When changing Product and/or Component you usually want to select the radio button "Reassign bug to default assignee and QA contact of selected component ".
  8. Add Keywords -- here are just a few of the important ones the full list of keywords is here).
    • "access": mark accessibility bugs with the keyword "access". This allows accessibility bugs to not be tied to the "Disability Access" or "Keyboard navigation" components, but to the actual component with the problem. For example, the developers for Places should really be responsible for accessibility bugs in Places, but adding the keyword "access" makes sure
    • "regression": mark regressions with "regression". Was this ever not a bug? For example, did it work in Firefox 1.5? See below for more important information on how to deal with regressions.
    • "crash": pretty obvious :)
    • "dataloss": this bug will cause users to lose data
    • "hang": freezes or locks up the application
    • "testcase": indicates that a simplified testcase is included (see below)
Retrieved from "https://wiki.mozilla.org/index.php?title=QA/Cleaning_Bugs&oldid=137556"