From MozillaWiki
Jump to: navigation, search

<< Back to Thunderbird Testing

Welcome to the Thunderbird Bug Day wiki!

Join us to improve the bug reports in Thunderbird's bug database.

You might also visit Planning for bugdays, and other Thunderbird wiki pages for information about the state of Thunderbird, Thunderbird planning, ways you can help the project, and offer your opinions.



In contributing to improving Thunderbird's quality, you will feel that the Thunderbird you use every day is little bit better, and a bit more "yours". Rub elbows with other contributors as you take a break from your boring everyday routine.

Anyone (this means you) can participate and be a valuable contributor - no coding and no experience required. The information below will help you get started. Plus, there are people are available to assist you.


Making Thunderbird better by resolving bugs is the goal. And before bugs can be resolved they often need cleaning and improvement:

  • some are in a state that makes them hard to fix
  • some might not be real bugs and need testing to determine what, other than Thunderbird, caused them
  • some are poorly worded
  • users do not have the technical skills or understanding to accurately describe the problem

Bugdays help newcomers join with experienced people to clean up the database and drive down the red (UNCONFIRMED) line in this chart. another chart view


Staffed sessions allow you to participate, day or evening, at any location in the world. Attend all sessions, or just part of one. Or just drop in between sessions - someone might be hanging out who can help you. Can't participate today? We invite you to participate in a future bugday, or work on any bug, any day or time See Where about getting help.

Click in a UTC link below to get the session start time for your point on the globe.

Timezone Session 1
13h-15h UTC
Session 2
19h-21h UTC
Session 3
02h-05h UTC
Los Angeles, USA   (PDT=UTC-8+1) Wed 06h-08h Wed 12h-14h Wed 19h-22h
New York, USA   (EDT=UTC-5+1) Wed 09h-11h Wed 15h-17h Wed 22h-01h
São Paulo, Brazil   (UTC-4+1) Wed 10h-12h Wed 16h-18h Wed 23h-02h
UK   (BST) Wed 14h-16h Wed 20h-22h Wed 03h-06h
Berlin, Germany   (CEST=UTC+1+1) Wed 15h-17h Wed 21h-23h Thu 04h-07h
Moscow, Russia   (UTC+3+1) Wed 17h-19h Wed 23h-01h Thu 06h-09h
Beijing, China   (UTC+8) Wed 21h-23h Thu 03h-04h Thu 10h-13h


#tb-qa IRC channel is the place to get help. If no one is there ask in #maildev. General information about IRC: [1], about mozilla IRC, [2]. Ways to connect to IRC include:

Also, on any non-bugday you can get help at #tb-qa or #qa.


Need help? Get on IRC and post a note in the tb-qa IRC channel.

New to bugzilla?

  • Searching in bugzilla can be tricky. Quicksearch tricks and Advanced Search may help you produce more accurate and smaller search results.
  • If you cannot change a bug field, please add a bug comment detailing what should be changed and why, and then inform someone in the IRC channel.
  • See Bug triage about how to get upgraded privileges to change bug fields.


  1. Get an account - easily created at bugzilla account.
  2. Protect - Backup your data. Use a test profile esp. if bugs might cause dataloss (see next point).
  3. Make a test environment (optional) - You can create and use a profile just for testing. (For gory detail see Testing_pre-release_versions and Profile manager describe to how test and not disturb your production setup.)
  4. Get a build - Testing is best done with "Daily" builds, the trunk is where Thunderbird is currently in development and it has the latest fixes. Trunk/Daily also has the greatest risk of problems, so if you cannot use Daily, please try to use Earlybird or Beta. Worst case, please use the the last released version.
  5. Pick bugs - current bugday "Focus" suggests which bugs to work on.
  6. Work bugs - test the problem. For UNCONFIRMED bugs, mark as "confirmed" if you are able to reproduce and the steps to reproduce are well documented and easily followed, and the problem exists in trunk build. If you are not running trunk but can replicate with current release, please comment but do not set to confirmed.

Other good things to do:

    • Clarify bug report without distorting or changing the original problem.
    • Change the summary at the top of the bug page to be more accurate for the problem being reported, and remove words so summary is less chatty - a summary should not read like a book, nor a syntactically correct sentence. The shorter the better.
    • Close bug report as resolution WORKSFORME, INVALID, or INCOMPLETE as is appropriate.
    • Ask bug reporter or someone else to provide missing information that will help you to replicate, and ultimately help some else to fix the bug. Set the "Need more information from" field.
    • Set a more appropriate Thunderbird component or MailNews component for the problem being described.
    • Cite what version(s) of Thunderbird you have used in your testing.
  1. Give feedback (see feedback heading below)
For more helpful information see:

Give us feedback

Please post a note in #tb-qa about your experience, whether it be to just say hello or post problems, questions, or ideas to improve documentation. We really appreciate your help today and your feedback is very valuable.


Thanks so much for your help. Your efforts help us to improve Thunderbird. We could never do this without you and the entire volunteer community.