[sakai2-tcc] Test plans for sakai 2.8

[Jean-Francois Leveque]

I do.

J-F

Aaron Zeckoski a écrit :
> I think this is worth considering as part of the release process and
> at least warrants discussion. Keeping help files and/or test plans up
> to date seems like it deserves a line item in the release process at a
> minimum. Does anyone else agree?
> 
> -AZ
> 
> 
> On Fri, Sep 3, 2010 at 9:20 AM, Berg, Alan <A.M.Berg at uva.nl> wrote:
>>  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.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> 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
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc