QA:Triage Policies and Procedures

Common QA Troubleshooting Tips

• [01:06am] smorgan: Clean profile is supposed to be a narrowing down tool, not a magical remover of bugs. Only corrupt/invalid profiles that appear to be caused by users mucking around should be consider ignorable.
• http headers (browser and server)
  • curl -I 'foo'
  • the JS bookmarklet to catch server response:

  javascript:document.location.href%20=%20'http://webtools.mozilla.org/web-sniffer/?url='%20+%20escape(document.location.href)

  • NSPR http logging for more complex cases
• http://kb.mozillazine.org/Standard_diagnostic_%28Firefox%29 (we need a Camino version; see User:Sardisson/To_Do

Searching for Duplicate Bugs

• QA:Bugzilla:Searching For Dupes

Confirming Bugs

• Don't confirm RFEs (bugs with severity set to enhancement, or enhancement requests misfiled with some other sort of bug severity, which are very common, particularly if another browser provides such a feature) until there has been discussion among the triage team and, in some cases, with the project lead(s). This helps combat feature creep and keeps Camino from having a kitchen sink.

• Don't confirm any bug that looks like it has the potential of being a Core bug (anything that has to do with the content area, or with certain app features whose underlying implementation is tightly linked with the Core, e.g. the pop-up blocker, session or global history); see Moving Bugs to Other Products and Components below for more about moving bugs to Core components.

• Don't confirm bugs that look like they might be resolved DUPLICATE, INVALID, or WONTFIX. Perform a search of old Camino bugs with these resolutions before confirming bugs (especially the latter two; a request or bug may have been WONTFIXed before you began QA work, but that doesn't mean the project lead(s) have changed their opinion. See QA:Bugzilla:Searching For Dupes for more on search for duplicates, including duplicates of WONTFIXed and INVALID bugs.

• If the bug has a clean report and is clearly a real bug in the Camino application UI, then by all means confirm the bug. Otherwise, proceed more cautiously, seek additional opinions, etc., before confirming a bug.

• When you confirm a Camino bug, you should also do the following:
  • When to set priority and target milestone
  • Fix other fields (Camino component and QA contact, branch, mis-filed severity)...
  • CCing developers if appropriate; see their areas of expertise in Development:Reviewing
  • Tagging bugs that only appear in one or more major Mac OS X versions...
  • Adding keywords
  • Adding to [meta] trackers, blocks/depends management

Moving Bugs to Other Products and Components

• Be sure to check the box to reset the assignee and QA contact to the defaults for the new component
• Status (UNCO vs. NEW; what's required)
• Testcases (esp. for Core:Layout and Core:Printing; link to bugathon doc)
• Moving to Tech Evangelism product
  • What qualifies as a TE bug
  • TE summary field format (Item 10)
• Core:General component, for bugs you're sure are Core bugs but unsure of the proper component
• Setting and Using Flags
• Setting Milestone, Priority, and Severity [link to bugzilla page on severity]
• Adding keywords and status whiteboard info
• http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html covers a lot of this

Regression Windows

• Old nightlies on ftp.m.o
• Older nightlies on archive.m.o
• Bonsai queries (module Camino vs. directory mozilla/camino), branch vs. trunk

“CLOSEME”

• Dealing with old UNCOs

Using Talkback

• Filing bugs based on topcrashers: Talkback_Topcrash_Analysis

General Mozilla Policies

• links to QA docs, bugzilla etiquette
  • http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html (ask pink for privs in Camino; exisiting QA will vet you)
  • https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
  • https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html