Here are some guidelines to follow if you want to help with verifying resolved bugs (using Bugzilla) found in the MailNews product.

General Info
In every bug report, there is a QA Contact field. The QA contact can be any one of the folks found on this page. The QA contact is responsible for:

• Gathering additional information or working with the reporter and the developer to reproduce a bug
• Updating the bug with any new information
• Verifying the bug once the bug is in a resolved state (fixed)

• It's a good idea before you help verify a bug that if the steps of the bug are fairly involved, you make sure that you were able to reproduce the bug in the first place. This will ensure that you are testing the bug fix correctly and that the bug had, at one time, manifested itself on your system.
• If you want to help verify a bug, please email the QA contact person for the bug to let him/her know you wish to do so. This avoids duplicate efforts and overlap of work.
• Once you and the QA contact agree, the QA contact field should be changed to show your email address.
• Mozilla is developed cross-platform and often requires that verifications of bug fixes be done on at least Windows, Mac, and Linux platforms. If you don't have access to all platforms and the bug requires a cross-platform verification, it would still helpful to note that the problem is fixed on a particular platform in the bug report. Or, if you have access to one or two platforms and you are the QA contact, you can often visit #mozillazine on IRC and find a "platform partner" to help verify on the platform(s) which you do not have.
• Often, if you are the reporter of a bug or the bug requires specific configurations to reproduce, you would be a good candidate to verify the bug fix.

• If the bug is not specific to a platform, you need to verify the bug on at least Windows, Mac, and Linux platforms using the most current builds of the product.
• If there are other bugs marked a duplicate of the bug you are verifying, you need to view those duplicate bugs (the bug numbers will be shown in your bug report) and also test/verify the cases outlined in them.
• You should also make sure to test "around" the area of the fix. Some examples:
• If the bug was reported with new message functionality, also try the reply functionality when testing the fix.
• If the bug was reported with the html compose window, also try the plain text compose window when testing the fix.
• If the bug involves multiple steps, try the exact steps and then vary the order of the steps a little when testing the fix.
• There are many more variations that can be tried, but you should get the idea now!
• If you have emailed the QA contact, but can only verify a bug on one platform, you may want to note in the bug that you've done so (include the platform and build number), but leave the bug in a resolved (unverified) state so that the QA contact can continue to verify on the remaining platforms.

• All resolved bugs sorted by QA contact