-=The Testing Process (PRELIMINARY)=-
In most cases, testing of TikiPro release candidates (RC) for release, will be an iterative process. Each iteration is called a testing cycle.
#Developers agree on the scope of changes for a release branch (in cvs)
#Developers make changes to the TikiPro code base to fix bugs and add enhancments
#Developers collectively agree that all planned changes and enhancements have been made to a planned release code branch.
#Developers have performed due diligence in testing their changes and enhancements and believe that the new / altered TikiPro is ready for release to users (customers).
**Testers are not lackeys for developer superstars. Developers should do their own “engineering testing” and do their best to make their changes “ready for prime time”
**Testers may (and often will be) developers. Try not to test your own work. If you can think of a test case for your fix / enhancement, why wouldn’t you have already coded for it?
#Developers and the test coordinator agree on the scope of the testing effort and develop some sort of test plan that will limit testing to a scope appropriate to for the changes made to the code base.
#Just before a round of release candidate testing has started (RCnn),
##The cvs development branch is labeled to reflect the release candidate’s version and RC number
##The TikiPro testing.site ( [http://testing.tikipro.org] ) is configured to provide a shared a testbed for testers to validate correct TikiPro behavior (as well as demonstrate / verify anomalous behavior).
***Cvs updates are performed manually just before testing each candidate release and is not updated again until just before a subsequent candidate release
***Testing.tikipro.org is a linux / postgres – based resource provided for RC testers
***Because TikiPro is operated on multiple server platforms and operated from multiple browser clients, testing effort is multiplied by the number of web servers, web browsers, and database management systems on which it is to be supported.
***If you are providing your own hardware for testing a release candidate, create a separate, pure cvs “sandbox” used only for testing purpose (just like for [http://testing.tikipro.org] )
#Armed with the test plan, the testing coordinator coordinates RC testing efforts by whatever means deemed effective by him / her. Suggested communication methods include:
##Announcement of an RC testing cycle / delivery freeze via development mailing list email (includes pleadings for testing effort participation)
##Creation of an RCnn signup / status wiki page on www.tikipro.org
##Coercion or of any / all people in the #tikipro IRC channel
#If and when testing reveals a failure to behave as intended, a failure report is generated and communicated back via the TikiPro ))SourceForge(( Bug web page ( [http://sourceforge.net/tracker/?group_id=101599&atid=630083] )
#The lead developer monitors RC bug reports on ))SourceForge(( and assigns them to the appropriate developer.
#Testing continues until one or more of the following occur:
**The nature of the fix to a reported bug is so extensive that it threatens to invalidate further testing without a cvs update
**The fix of a reported bug is in a piece of shared code (e.g.: library) that is shared by numerous packages
**The test plan is executed to the end (with some bugs reported)
**The test plan is executed to the end without exception (no bugs)
#If there were bugs, the next release candidate test cycle begins again at step #5, above (RC number increments).
#If there were no bugs, then the successful release candidate is labeled by version.

Page History
13 Dec 2004 (04:43 UTC)
Added web/root/user Install combinations.
Current • Source
Lee LaMont Bell Jr.
View • Compare • Difference • Source