SeaMonkey/QA

Resources
SeaMonkey Homepage
FAQ / Help
Goals
Organization
QA
Supporters
Add-ons
Localization
Reasons
Branding
Release History
Tasks & Projects
IRC Chat Logs
Discussion
Suiterunner

If you are actively triaging bugs, running smoketests, or would like to help out with Bug Days, add yourself to the QA Areas page. At this point, we are particularly interested in getting smoketesters.

SeaMonkey QA Call to Action

As we approach the release of SeaMonkey 1.0.7 and SeaMonkey 1.1, we need to ensure that the suite stays in tip-top shape. To make this possible, we need members of the SeaMonkey community to help with quality assurance by testing current builds to identify and report bugs, and help sorting out bugs that have already been filed.

Testers who wish to test the changes for SeaMonkey 1.0.7, should download and use recent nightly Gecko 1.8.0 branch builds. A 'blocking-seamonkey1.0.7' flag has been set up in bugzilla to help keep track of what needs to be done before SeaMonkey 1.0.7. You can create your own query with this flag, or view the open approved bugs and yet to be approved bugs blocking the release.

Testers who wish to test the changes for SeaMonkey 1.1 should download and use recent nightly Gecko 1.8 branch builds. A 'blocking-seamonkey1.1' flag has been set up in bugzilla to help keep track of what needs to be done before SeaMonkey 1.1. You can create your own query with this flag, or view the open approved bugs and yet to be approved bugs blocking the release.

Testers who wish to test all the latest changes in preparation for the next major release of SeaMonkey (version 1.5) should download and use recent nightly trunk builds. Also, please enable the Talkback Quality Feedback Agent to send information back to developers so they can fix crash bugs. (Note: Talkback is currently working only for trunk builds.) A 'blocking-seamonkey1.5a' flag has been set up in bugzilla to help keep track of what needs to be done before SeaMonkey 1.5a. You can create your own query with this flag, or view the open approved bugs and yet to be approved bugs blocking the release.

If you find a problem in any builds of SeaMonkey, check Bugzilla to see if your bug has already been reported, and (if not) file a new bug in the "Mozilla Application Suite" or "Core" Products (see below). We are particularly interested in regressions (bugs which did not exist in Mozilla 1.7, and bugs in recent trunk builds that do not exist in SeaMonkey 1.0), so mark these bugs with the regression keyword to bring them to developers' attention.

We also need to identify previously reported bugs that need to be fixed before our release. There is a list of recent unconfirmed SeaMonkey bugs and Gecko core bugs that need to be triaged. You should ensure that the bugs are in the appropriate component, and (if enough information is available) confirmed or marked as duplicate, works for me, invalid, or wontfix. If more information is needed, add a comment in the bug asking the reporter for the information needed. Also remember that Gecko/layout bugs need a testcase before they can be confirmed. Once the bugs are properly triaged, we'll be able to see what bugs need to be fixed before the next SeaMonkey release, and what issues need to be reported in the release notes.

SeaMonkey vs. Gecko bugs

There are two major classes of bugs you might find in the SeaMonkey Suite:

• Front-end bugs: These bugs occur in the user-interface part of the code, and might include problems with bookmarks, autocomplete or the download manager. These bugs should be filed under one of the Mozilla Application Suite components.

• Back-end bugs: These bugs occurs in code that operates behind the scenes, and might include problems with web page rendering, networking or printing. These bugs should be filed under one of the core Gecko components, which are shared with other Mozilla applications, including Firefox and Thunderbird.

If you're not sure of the appropriate component or even product, that's ok. We'll move it to the right component, but filing in the right component will speed up the process of getting your bug fixed and save our time, so please try to find the most appropriate component.

Additional QA Tasks

In addition to filing bugs and triaging unconfirmed bug reports, there are other QA areas that need attention.

• Crash bugs are some of the worst bugs and deserve special attention. You can retrieve talkback stacks for specific bugs using the talkback ID at this query page. You can also browse submitted talkback reports to look for common crashes. If you can reproduce the crash based on the information the submitter provided and can't find an existing bug, please file a new bug.

• Smoketests should be run regularly using testrunner to catch serious regressions quickly. If you find a smoketest that fails and can't find an existing bug, please file a new bug with the keyword smoketest and blocker severity. If you run the smoketests regularly, please add your name to the QA Areas page. Please stop by #seamonkey for more about using testrunner.

• Work on an area identified by a developer as needing special attention, as identified on the QA Wanted page.

• Developers flag bugs with the qawanted keyword to indicate that they need help to properly diagnose a problem. This can mean writing a testcase, testing on a specific platform, or just trying to find consistent steps to reproduce a bug. You can search for bugs with the qawanted keyword from the bugzilla query page (advanced search).

• If you find a bug that you believe must be fixed before the next milestone (1.1b), nominate the bug to block release by setting the "blocking-seamonkey1.1b" nomination flag to "?" and add a comment to state why you think the bug is important. Also, please help with any QA needed for the bugs the Council has already decided should block the next milestone.

More QA Resources

• Helping with QA provides a good overview of the various tasks for people getting involved in QA.

• Mozilla's QA Home Page provides more information for QA members, including resources for specific parts of suite (browser, Gecko, mail, etc).

• #seamonkey and #bugs generally have a few developers or experienced QA folks who can help you getting started with bug reporting or triage.

• The SeaMonkey QA blog will contain announcements of any changes in SeaMonkey QA needs.