QA SoftVision Team/Desktop

Management and Communication

Meetings

• Weekly Waverly meeting

Tuesdays, 8am PT / 4pm GMT
Dial in: 800-707-2533
password 369, conference #245

IRC

• #qa on irc.mozilla.org
• #firefox on irc.mozilla.org
• #tabcandy on irc.mozilla.org
• #devtools on irc.mozilla.org

Mailing Lists

• Use internal Waverly mailing list to communicate active work to managers

Bug watchers

• the list of watches from Bugzilla can be found here

Spreadsheets

• Unconfirmed bug triage - link
• Exploratory work (testcases) - link
• Fixed bugs verification - link
• Updated testcases - link

Blogs

• most contributers have blogs and a lot of information can be found out by watching these blogs
• list of most important blogs:
  • Planet Mozilla – http://planet.mozilla.org
  • QMO Community - http://quality.mozilla.org/community
  • QMO News - http://quality.mozilla.org/category/qmo-news/
  • Planet Firefox - http://planet.firefox.com/

Ramp-up and testing environment

First Steps

• Ramp-up document - link

Hardware and Operating Systems

• Hardware (minimum requirements)
  • CPU: P4 3.0GHz
  • RAM: 2GB
  • Video card: MSI Nvidia Geforce N210
• Operating systems
  • Windows XP
  • Windows 7 x86, x64
  • Ubuntu 11.04 x86, x64
  • Mac OS X 10.6, 10.7
  • Windows Vista
  • Win 2000

Tasks

Weekly

	Channel	Links
Bug triage	Nighly	Spreadsheet link
Fixed bugs verification	Nightly/Aurora	Spreadsheet link
Exploratory testing	Aurora	Spreadsheet link
Update testcases	NApp	Spreadsheet link

Bug triage

• the validation or invalidation of unconfirmed bugs logged by community testers (the link with the bugzilla query can be found in the spreadsheet, in the date header)
• bugs are to be commented and their resolution set accordingly to one of the resolutions: RESOLVED – WFM, INCOMPLETE, DUPLICATE, INVALID, WONTFIX or to NEW
• each bug that is set to NEW has to have a regression window - http://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/

Fixed bugs verifications

• the verification of fixed bugs -issues should be commented and resolution set to either RESOLVED FIXED or REOPENED
• verification is performed across all platforms against which the bug was logged

Exploratory testing

• ad-hoc testing on specific/error proned areas of the browser
• testcases are to be created during this kind of testing and written down in the specific spreadsheet
• Litmus FFTs/BFTs can be used as a starting point for the exploratory
• each NEW bug has to have a regression window - http://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/
• Logged bugs should respect the best practices presented here:
  • http://quality.mozilla.org/docs/bugzilla/starter-kit/how-to-write-a-proper-bug/
  • http://quality.mozilla.org/docs/bugzilla/starter-kit/how-to-write-a-proper-bug-part-2/

Update testcases in Litmus

• based on the Litmus Unclear, Broken / Fail reports, testcases should be kept up-to-date
• all modifications are to be registered in the created spreadsheet

Periodically

Beside the weekly activities there are also specific tasks that are performed before the channels are merged and a new release is launched (Aurora, Beta, Final). These are as follow:

Pre Aurora, Pre Beta, Pre Release specific tests:

• Smoketests
• BFTs (Mozmill and Manual)
• Features owners sign off
• Ad-hoc testing

Ownerships

• an ownership guideline can be found here

Firefox features

• the list of owners can be consulted here

Litmus

• the list of owners and subgroups can be found here

Additional Information

• please add info