Difference between revisions of "QA:Triage Policies and Procedures"

Revision as of 14:04, 15 June 2006

[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)
Blocked cookies (either too restrictive a global setting or some domain set to deny; many sites require cookies from multiple seeminly-unconnected domains in order to function).
- This is sometimes the case when something works in one browser but inexplicably doesn't work in Camino; users often have more restrictive cookie settings in their main browser but don't mess with the cookie prefs in alternate browsers.

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 searching 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.

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

@@ Line 7: / Line 7: @@
 ** [http://www.mozilla.org/projects/netlib/http/http-debugging.html 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]])
+* Blocked cookies (either too restrictive a global setting or some domain set to deny; many sites require cookies from multiple seeminly-unconnected domains in order to function).
+** This is sometimes the case when something works in one browser but inexplicably doesn't work in Camino; users often have more restrictive cookie settings in their main browser but don't mess with the cookie prefs in alternate browsers.
 == Searching for Duplicate Bugs ==