SeaMonkey/QA
 | ||
| SeaMonkey QA | ||
|---|---|---|
| SeaMonkey Homepage | ||
| QA Homepage | ||
| Activity Areas | ||
| Bug Triage Manual | ||
| Fix Checkin Tracking | ||
| ||
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.
Contents
SeaMonkey QA Call to Action
Testers who wish to test the changes for new SeaMonkey releases should download and use latest beta release or even unofficial latest buildfrom wg9s. You test on your own risk!.
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 for the "SeaMonkey all-in-one internet application suite" or "Core" Products (see below). We are particularly interested in regressions (bugs which did not exist in latest stable SeaMonkey), 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 SeaMonkey 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 components of products shared with Firefox, Thunderbird, etc.; the main ones of these products are Core, MailNews Core and Toolkit.
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.
Before you will submit "Web Page does not work in SeaMonkey Browser" Bugs please check with Error Console whether it's related to Custom Elements. It's known that this function needs to be backported to SM, no need to file additional bugs currently.
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.
- Talkback, a closed-source third-party extension, has now been retired in favour of the Breakpad client and the Socorro server, which are built from Mozilla code and therefore open-source. With all currently supported versions of SeaMonkey, you can browse your own crash events at about:crashes and crash reports submitted to Mozilla at http://crash-stats.mozilla.com/.
- 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, nominate the bug to block release by setting the appropriate blocking-seamonkey nomination flag (as described above) 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 IRC generally have a few developers or experienced QA folks who can help you getting started with bug reporting or triage.
