QA/QMO/BugWritingGuidelines

Bug Writing Guidelines

Purpose

• There are bug writing guidelines already created via Bug Writing Guidelines @ MozDev and on Bug Writing Guidelines @ Bugzilla, but the one we currently have on QMO just doesn't seem to have the right flow for someone that's sent to Bugzilla. So, my plan is to use the MozDev page as a template and give it a QA feel.

Bug Validity Checklist

Verify the problem you found is a New Bug

• To verify if what you've found is indeed a new software bug in one of Mozilla's products, go through the following checklist to make sure it's something worth creating a new bug report for.
  • Make sure it's a software bug. It should be either an error, flaw, mistake failure of fault in the browser that produces an incorrect and/or unexpected result.
  • See if it's an already known bug by looking at your particular version's release notes
  • Make sure that no one has already fixed the problem
    • Check the bug against the latest trunk nightly located here
  • Make sure there isn't a duplicate bug already created by using this handy guide to search through Bugzilla for your problem

• If you're lost and not sure what to do always check out the IRC channel, #qa, at irc.mozilla.org and ask there. If no one answers, try posting to our Bugzilla forums.
• Otherwise if you haven't found your software bug, its time to write a bug report!

The Bug Report

Where do I go to create a bug?

• Mozilla's main tracking tool for reporting, investigating and fixing bugs is located here. The first step in order to log a bug, is to register an account. To do that, go to Bugzilla's home page and click on the "New Account" hyperlink at the top of the page.
• After registering and then logging into your new account, go back to the Bugzilla home page and click on the "New" hyperlink at the top of the page. Click the product that the bug is found in and fill out the resulting form. If you have any issues with finding the product you want to file the bug for, go to the #qa channel at irc.mozilla.org and ask for help from our very friendly MozQA community.

What does the community want to see in a bug report?

• There are a couple of principles that should be taken into account when creating a bug. They would be the following:
  • Keep the Description and Summary clear and concise
  • Only report one issue in a bug report
  • Report only facts in your bugs and remove any assumptions you might have

General Outline of a Bug Report

• Summary: How would you describe the bug in less than 60 characters? It should quickly and uniquely identify a bug report as well as explain the problem, not your suggested solution.
  • Good: "Cancelling a File Copy dialog crashes File Manager"
  • Bad: "Software crashes"
  • Bad: "Browser should work with my web site"
• Component: In which sub-part of the software does it exist?

  • • This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, highlight the "General" component.
• OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)

  • • If you know the bug happens on more than one type of operating system, choose "All". If your OS isn't listed, choose Other.
• Description: The details of your problem report, including:
  • Overview: This is a larger detailed restatement of the summary.
    • Drag-selecting any page crashes Mac builds in the NSGetFactory function.
  • Build Id: To find this either go to [about:] via the location bar or, if you have MozQA's Nightly Tester Tools extension, then go to Tools | Nightly Tester Tools and select the option that contains the output of the build Id.
    • It should look something like this "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3".
  • Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable).
    • It should look something like this "Doesn't Occur On Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20081107 Firefox/3.1b2"
• Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. If they're necessary, make sure to include any special setup steps.
  • A good example of this would look like the following:
  • 1) View any web page. (I used the default sample page, http://www.google.com/)
  • 2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.)
• Actual Results: What the application did after performing the above steps.
  • i.e. The application crashed.
• Expected Results: What the application should have done, were the bug not present.
  • The window should scroll downwards. Scrolled content should be selected.
  • (Or, at least, the application should not crash.)