SeaMonkey/QA
 | ||
| Resources | ||
|---|---|---|
| SeaMonkey Homepage | ||
| FAQ / Help | ||
| Goals | ||
| Organization | ||
| QA | ||
| Supporters | ||
| Add-ons | ||
| Localization | ||
| Reasons | ||
| Branding | ||
| Release History | ||
| Tasks & Projects | ||
| ||
| 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, we need to ensure that the suite is 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.
In preparation for the release of SeaMonkey 1.0, we need as many testers as possible to download and use recent nightly Gecko 1.8 branch builds. Testers who wish to test all the latest changes in preparation for the next major release of SeaMonkey 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. If you find a problem, check Bugzilla to see if your bug has already been reported, and (if not) file a new bug. 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 on the 1.8 branch), 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 SeaMonkey 1.0, 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.0a), nominate the bug to block release by setting the "blocking-seamonkey1.0a" 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.