[sakai2-tcc] Test plans for sakai 2.8

[May, Megan Marie]

Responses inline.

From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Berg, Alan
Sent: Friday, September 03, 2010 10:21 AM
To: sakai2-tcc at collab.sakaiproject.org
Subject: [sakai2-tcc] Test plans for sakai 2.8

  Hi TCC,

In the 2.7 QA push there was inconsistent coverage of the functionality by test plans (if you can define great holes in the coverage inconsistent).  Worse still some of the plans were out of date or incorrect. Test plan generation is a burden for hard working developers and I assume the generation is seen as an unwelcome task or an optional extra. I also noticed that some of the context help was starting to drift as features changed.

I want to be realistic and find a middle ground that allow functional testers to do their job without me nagging the project leaders and that is not overly costly. I have the following suggestions for debate.

The minimum


1)    1) Any Test plans that still work from the 2.7 cycle are pointed at by the relevant project leads in a QA page on confluence. The page is finished by the alpha beta tagging boundary.
The schedule indicated that  ALL test plans were finalized.




2)    2) At the alpha beta boundary help is up to date qua any feature changes. Help can then be used as a basis for Goal orientated tests such as make an assignment, add a grade book etc. Simple plans of less than a paragraph pointing to help links are made by the projects and are updated in a page under QA on confluence. Links to testing resources such as zip files point into subversion. This naturally forces help to remain current.
This is what the schedule indicates.




3)      3) Any new feature changes (from 2.7 to 2.8) are documented in a thorough test plan. For example of what is acceptable, see the test plan from BasicLTI in subversion.

I'm lazy and I'd bet a lot of other people are, too.   Link to BasicLTI test plan?





If the TCC can help enforce this as a standard especially when it comes down to the alpha beta boundary then the functional testers will have enough information for wide coverage of testing. I would even strongly suggest we cannot go to beta without specifics of what to test.


I still consider the work of automated Functional testing via Hudson and perhaps selenium worth driving, but others need to develop the specifics of this effort due to time constraints.

Please have an opinion it improves the quality of QA itself.

Alan

Alan Berg
QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100907/bf8ef65c/attachment-0001.html