User:Tsk/Docs/QA Plan: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(New page: Community / triage / testing Tooling / Test Cases/ Reports Automation)
 
(plans first thoughts and draft.)
Line 1: Line 1:
Community / triage / testing
Gross Initial QA plans/ Thoughts which needs to be correlated with all the other bits and pieces floating around [[MailNews]] and [[Thunderbird]] wiki pages. I need to start somewhere so here are the thoughts I've been having on how the QA should be done for Thunderbird. There are three main areas  in which the QA effort should be divided.


== Community / triage / testing ==
Triagging bugs making sure that each bugs is being taken care of is a huge taks when many bugs are being filled daily. In order to keep the bug database clean we need more man power to be able to do the following tasks :


Tooling / Test Cases/ Reports
* Triagge new bug
* Follow old bugs
* Clean up the database which contains very old bug that were never being taken care of.


And for this there is no automatic alternative It can only be done by hand (the other choice being to force the bug closure for bugs prior to date XX/XX/XXXX - but some of those bugs might still be valid - this is for now not an option for me). In order to get more people we need to tell them that we are in the need for people willing to spend time reading, commenting and changing bugs.


Automation
* for that we can use the actual mechanism -> blog post, newsgroup post ... (and at some point we should)
* Interact with other communities that might have an interest in the product :
** Linux people -> OpenSuse and Ubuntu are good candidates
** Extension users : people using Lightning, people using enigmail
** OpenSolaris, as solaris ships with Gnome and moz apps as defaults.
 
=== Daily triage ===
So triagge is done in many different ways. Some people do it per component - some people do it once in a while. Would be nice to come up with a team that would be big enough to make sure that all bug entered in a single day would get some attention, and be triagged right away. To do so we need more people and we need to train them.
 
=== Bug days ===
Will not change until we reach a community of people doing QA that would be big enough for the bug days to become training days for new comers or for triagging the left overs untriagged bugs that are in bugzilla.
 
=== Bugzilla Clean Up ===
Bugzilla is full of old bugs related to old releases of thundrbird this needs to be cleaned up - this also means that you needs people that understand the product enough to do it. This is not High priority at the moment.
 
== Tooling / Test Cases/ Reports ==
 
 
== Automation ==

Revision as of 14:51, 3 February 2009

Gross Initial QA plans/ Thoughts which needs to be correlated with all the other bits and pieces floating around MailNews and Thunderbird wiki pages. I need to start somewhere so here are the thoughts I've been having on how the QA should be done for Thunderbird. There are three main areas in which the QA effort should be divided.

Community / triage / testing

Triagging bugs making sure that each bugs is being taken care of is a huge taks when many bugs are being filled daily. In order to keep the bug database clean we need more man power to be able to do the following tasks :

  • Triagge new bug
  • Follow old bugs
  • Clean up the database which contains very old bug that were never being taken care of.

And for this there is no automatic alternative It can only be done by hand (the other choice being to force the bug closure for bugs prior to date XX/XX/XXXX - but some of those bugs might still be valid - this is for now not an option for me). In order to get more people we need to tell them that we are in the need for people willing to spend time reading, commenting and changing bugs.

  • for that we can use the actual mechanism -> blog post, newsgroup post ... (and at some point we should)
  • Interact with other communities that might have an interest in the product :
    • Linux people -> OpenSuse and Ubuntu are good candidates
    • Extension users : people using Lightning, people using enigmail
    • OpenSolaris, as solaris ships with Gnome and moz apps as defaults.

Daily triage

So triagge is done in many different ways. Some people do it per component - some people do it once in a while. Would be nice to come up with a team that would be big enough to make sure that all bug entered in a single day would get some attention, and be triagged right away. To do so we need more people and we need to train them.

Bug days

Will not change until we reach a community of people doing QA that would be big enough for the bug days to become training days for new comers or for triagging the left overs untriagged bugs that are in bugzilla.

Bugzilla Clean Up

Bugzilla is full of old bugs related to old releases of thundrbird this needs to be cleaned up - this also means that you needs people that understand the product enough to do it. This is not High priority at the moment.

Tooling / Test Cases/ Reports

Automation