Plans and projects .LRN Project Site .LRN 1.0 Testing
This document outlines the test plan for dotLRN 1.0 and includes test instructions for testers. dotLRN 1.0 is the first public release of dotLRN. Our goal is to release dotLRN on March the 17th 2003.
Two test servers hosted by Collaboraid have been setup by Peter Marklund of Collaboraid and Bart Teeuwisse of the Code Mill. One Oracle installation and one PostgreSQL setup. Each server will be tested by a team of volunteer testers.
Teams consist of testers each acting a specific role in a dotLRN community such as professor, student or staff. Thru role acting testing should closely match actual use of dotLRN.
Testing will be done in cycles of one week. Teams have a week to explore dotLRN and hunt for bugs following the test instructions for their role below. Patches for the bugs will be applied at the end of the week at which point the test servers are reset to the same basic configuration as at the beginning of that week.
Bug can be reported in the OpenACS bugtracker and will be attended to by a team of developers. Useful bug reports are ones that get bugs fixed. A useful bug report normally has two qualities:
To help you create useful bug reports keep the following guidelines in mind:
A useful bug report consists of the following 3 basic elements:
Most important when reporting a bug is to provide step-by-step instructions how to repeat the steps that lead to the bug.
E.g. I visited the home page of the dotLRN installation while I was not yet logged in as user.
Describe what your intentions were.
E.g. I expected to see the dotLRN graphics in the context bar.
Describe what you encountered. If the system reported an error include it here.
E.g. None of the graphics where there. However they were visible after logging in.
Yes, the example is simple. Nevertheless it is a real bug. If the bug report simply said "Don't see any graphics in the context bar" the developers might never find it when the are always logged in as a user. By telling what you asked for, what you expected to get, and what you actually got, bug fixers don't have to guess.
The odds are good that if you've found a problem, someone else has found it, too. If you spend a few minutes of your time making sure that you're not filing a duplicate bug, that's a few more minutes someone can spend helping to fix that bug rather than sorting out duplicate bug reports.
This is a fine line to walk. But there are some general guidelines:
If you have encountered two bugs that don't appear to be related, create a new bug report for each one. This makes it easier for different people to help with the different bugs.
Only report bugs pertaining to dotLRN 1.0 and OpenACS 4.6.1. Be sure to record the correct version number when you file your bug reports.
The test servers are setup for specific teams and consist of a small number of terms, classes, forums, clubs, etc. to start with. Testing is done in weekly cycles at the end of which the test servers are re-installed from the current code base including all bug fixes of the past week. At which points the servers are re-set to their initial basic setup and a new cycle begins.
Volunteers who like to help out while a test cycle is already in progress can register at a test server of their choice. The admin of that server can grant them access and utilize them as he/she sees fit. New members to the test teams will be added to the setup scripts to recreate their accounts at the beginning of the next cycle.
Cycles start at midnight GMT each Sunday and end midnight GMT the following Sunday.
dotLRN 1.0 testing cycles Cycle # Start End Status 1 Sunday February 16, 2003 Sunday February 23, 2003 Completed 2 Sunday February 23, 2003 Sunday March 2, 2003 In progress 3 Sunday March 2, 2003 Sunday March 9, 2003 Not yet started 4 Sunday March 9, 2003 Sunday March 16, 2003 Not yet started
Two teams will be testing dotLRN 1.0. One team per installation. The European team tests the Oracle installation while the US team tests the PostgreSQL installation. The teams are centered around similar time-zones as team members will need to interact with each other. E.g. A student might be waiting on a professor to comment on an assignment. With team members in the similar time-zones dead will be minimized.
In addition to the volunteers who signed up, each server also facilitates casual testers who can long in as student John White or professor John Cameron.
The US team tests the PostgreSQL version of dotLRN. This to take advantage of Deirdre Kane's extensive knowledge of the Oracle version. Of all people she will be able to best spot differences between the two database versions. Whether in performance terms or functionality.
Most of the US team members are from SLOAN plus a few OpenACS community members. If you would like to give them a hand you can login to the PostgreSQL server as student John White or professor John Cameron.
The US team consists of:
US/PostgreSQL team members Member Role Access Guest Organization Al Essa Professor Full No SLOAN Deirdre Kane Admin Full No SLOAN Glenn Johnston Staff Full No SLOAN Jennifer Wrynn Student Full No SLOAN Julie Bergfeld External Limited No SLOAN Len Jacobs Staff Full No Mandala Designs Samir Joshi Professor Full No M. S. University Baroda, India Stan Kaufman Student Full Yes Virginia Gifford Student Full No SLOAN
The European team tests the Oracle version of dotLRN.
If you would like to give them a hand you can login to the Oracle server as student John White or professor John Cameron.
The European team consists of various volunteers from the OpenACS community, many of which are connected to the University of Heidelberg:
EU/Oracle dotLRN team members Member Role Access Guest Organization Aldert Nooitgedagt Admin Full No Carl Robert Blesius Professor Full No University of Heidelberg Christine Schupp Student Full No University of Heidelberg Daniel Waterkamp External Limited No University of Heidelberg Fabian Lorenzen Staff Full No University of Heidelberg John Norman Professor Full No University of Cambridge Koen de Jonge Professor Full No Procolix Marco Roos External Full Guest University of Heidelberg Mohan Pakkurti Staff Full No pakkurti.com Oliver Emmler Student Full No University of Heidelberg Simon Carstensen Student Full Yes
Core of the test plan is for team members to act out a specific role in the dotLRN community. Each role comes with different responsibilities and access privileges. See the description of each role for more detail.
Besides having role specific test instructions all roles have the following test instructions in common.
Check if the label of the button or link makes sense. E.g. would the button labeled 'Add' be more clear if it was labeled 'Change'?
Test pages for double click problems. Double click problems can occure when the same page is requested a second time before the first request has been completed. Most often this involves duplicate entries in the database or data related errors as it tries to create a second entry.
The best candidates for double click problems are pages that submit information filled out on the page to the server for further processing. Test for double click problems by submitting the same page for a second time as soon as you have submitted the first request.
Read the dotLRN 1.0 User and Administrator Handbook before you start your tests.
Login to your test server and perform the following tasks/steps in both a class and a community:
Developers working on dotLRN and ready to fix bugs include:
