In the context of discussions about How to Have Fewer Bugs in Tiki, this is a checklist to evaluate how and what should be tested during a Tiki packages release to insure minimum viability and somehow a control on what is tested.
This can be done in complement with Admins_first_moves
This should be use by volunteer joining the test phase of a package release. From experience those test are really quick and mainly check the package from source forge extract properly and end with seeing the Tiki welcome page. However if we help to optimise this first review we can allow the volunteers to do a little more by spending 5 to 10 more minutes testing a basic area.
All packages should be tested and depending of the number of volunteer during the release session the burden is to be split among people. (https://sourceforge.net/projects/tikiwiki/files/)
On a environment which respects the Requirements perform a fresh install with a new database (upgrading a database can be performed if extra time of course)
- Copying the file in a web directory
- Opening the Tiki website URL and follow the install process like described here : https://doc.tiki.org/Installation#Install_a_downloaded_release_package
From here scenarios depend of the availability of the volunteer but 2 areas should test in priority; Administration and User utilisation.
- Go to the Admin page and check the general setup
- Browser title (save & check)
- Admin mail (save & test) - (just the simple action, may be server related)
- Setup logo and Tiki title (save & check)
- Change theme (random or specific checking ?)
- Set up menu
- Set up module
- Change file storage from database to directory
- Edit the homepage (save & check)
- Create a new page (save & check)
- Add some contents
- Upload an image
- Use help system to add a plugin or two
- File gallery
- Create a gallery
- Upload an image