Thunderbird:Testing/bugzilla

Quality through tracking defects

Tracking defects and making sure they are know, analyzed, is the best way to make a product better.

Introduction

Bugzilla is the place where :

• Developer track their work
• Where the community can let the dev team know of bugs

The testing effort can not cover all the combinations of servers, protocols, use case and third party installs. At the time of this writing there are 5800+ bugs alone for Thunderbird that need attention (NEW+UNCO). We have different needs They are explained below and sorted by how much time you'll need to invest yourself.

To help in this area, you need a bugzilla account and some time.

Running queries on Thursdays

Every Thursday we have virtual meetups where we work on bugs present in bugzilla. We try to make sure that :

• The bug is still valid with current supported versions
• Try to make the bug move forward :
  • Can we reproduce the bug ?
  • Can we figure out specifics that trigger the bug ?
  • Is that bug a potential duplicate from another one ?
  • Is it a regression , when did it regress ?
  • Did we ask question in the past that never got answered ?

Here are a few link to find bugs to work on :

• XX
• YY
• ZZ
• TT

This activity let's us work with the already filed bugs and make sure we didn't miss anything worth missing. The idea behind the virtual meeting is that we'll make sure to try to be available for you if you have questions and don't what to do on a given bug.

Following a component

We've noticed that when a bug is taken into account very shortly after it's creation, bug openers where following the bug more closely. We would like to be more responsive - as in answer initial bug reports faster. Following a component is juts following a subset of bugs in bugzilla. And interacting with the bug reporters.

How do easily deal with new bugs

• Error console
• safe -mode
• local versus / imap folders

Docs

various flags we use

closeme dupme

and explanation on how we use them.