QA:Triage Policies and Procedures

From Camino Wiki
Jump to navigation Jump to search

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)
  • http://kb.mozillazine.org/Standard_diagnostic_%28Firefox%29 (we need a Camino version; see User:Sardisson/To_Do

Searching for Duplicate Bugs

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

General Mozilla Policies

Retrieved from "http://wiki.caminobrowser.org/index.php?title=QA:Triage_Policies_and_Procedures&oldid=5672"