f. How to help with testing - Nonprogrammer version

Q: Step 1. Finding the resources

A:

• Test servers are located here: http://test.openacs.org/
• When you find a bug you need to record it in Bugtracker: http://openacs.org/bugtracker/openacs/
• Its often much easier if you can ask questions. We encourage bug testers to come to the IRC channel that is the official OpenACS chat room. Instructions on how to join the IRC channel: http://openacs.org/irc/

Q: Step 2. Check your old bugs

A: If you have ever tested before please go to the bugtracker click on "My bugs" and see if any of your previous bugs need checking and closing.

Q: Step 3. Decide what to test?

A: Here are some ideas on how to choose which functionality you want to test.

• Test a package that is part of your current system.
• Test a package you are considering adding to your current system.
• Ask on IRC and see if someone there is a package "owner" and would like you to test his/her package.

Q: Step 4. Start Testing

A: Go to the testing server and find the functionality you have decided to test and try it out. If you find problems ask about them in IRC and record them in bugtracker. Read Writing a good bug report

Q: Step 5: Test Smarter

A: Yes there is more to a through test then just messing around. Once you have an idea of how the functionality works try:

• Reading the documentation for the package: http://openacs.org/doc/. Check if the functionality matches the documentation and to what extent the documentation covers the functionality. A problem with the documentation is a bug. Please record it in bugtracker.
• Try out different roles, user/administrator, or in dotLRN, student/prof and see if it works according to expectation. Check if users can do or see more then they should based on their role/permissions.
• Test on both Oracle and PostgreSQL installations.
• Test on both straight OpenACS and dotLRN if applicable.
• Ask on IRC if there is any specific functionality or tests you should try.
• Check on bug tracker for open and closed bugs for the package and check that the closed ones are in fact fixed.
• Compare the functionality to other systems and submit suggestions.
• Give suggestions on improving look, usability and page flow.

Q: Step 6. Move from Tester to Contributor

A: Help write/edit documentation: If you looked at the documentation and help for a package you almost certainly found ways to improve it. Most package owners (and all of the orphan packages without owners) appreciate help in especially in the area of user level documentation.

Does this package do something cool and useful? Write a marketing piece describing the features of this package. Adoption is our life blood, and right now its very hard for a potential new user to know what OpenACS is capable of. The only way to solve this problem is one package at a time. Why not start right now with the package you just tested?

Q: Thank You!

A: Thank you for your help testing the next release of OpenACS and welcome to our Open Source community.