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

User:Tsk/Docs/QA Plan (view source)

Revision as of 14:36, 5 February 2009

1,550 bytes added , 5 February 2009

no edit summary

Tsk

canmove, Confirmed users

1,343

edits

@@ Line 1: / Line 1: @@
-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.
+Gross Initial QA plans/ Thoughts which needs to be correlated with all the other bits and pieces floating around [[MailNews:Home_Page]] 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 ==
@@ Line 5: / Line 5: @@
 * Triagge new bug
-* Follow old bugs
+* Follow-up on old bugs
 * Clean up the database which contains very old bug that were never being taken care of.
@@ Line 17: / Line 17: @@
 === 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.
+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. Ideally I would like that each bug that gets entered on a daily basis get some attention and love.
 === 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.
+=== Test days ===
+Test days are here to test new features. Might also be a great way to improve coverage by adding some tests into litmus while some testing is happening. So two things would be happening during bug days, coverage would get bigger in our TC management tools and testing and bugs would be filled.
 === Bugzilla Clean Up ===
@@ Line 26: / Line 29: @@
 == Tooling / Test Cases/ Reports ==
+=== Tooling ===
+Playing with Litmus and QMO. Litmus is slow but has some stuff in it. Need to get more information on what's the mozilla plan for that.
+=== Test Cases ===
+We definitively need more TC, and some of them are dups - (I also need to spend a lot more time in litmus) - Need to get some information on Mozilla's qa plans for litmus in 2009 and act accordingly. Also need to groups TC - Initial Idea would be something like - can't ship without - Shouldn't ship without. We could also group based on what the candidate is - Testing needed for beta, testing needed for RC, testing needed for etc ....
+Would also be nice to know against what server the test is being run - ie Zimbra, Gmail etc ...
+Nice to have would be where to file the bug in bugzilla - ie if TC 1234 fails -bugzilla xxx where the component is already selected.
+I need to figure out how much % we cover of he application.
+=== Reports ===
+* We needs stats on bugs - (make sure to save those URLs)
+* We needs stats on Coverage and what has been covered for a particular release.
+* Stats on memory usage - need to figure out how to exploit them
 == Automation ==