1) Resuming after suspend, with LAIM (leave application in memory when suspended) on and off, without hanging or crashing.
2) Restarting the system to test if results will resume in proper, as per 1).
..a) do not return to the beginning (zero progress, when for instance the task was at 40%)
..b) start running without needing manual intervention, beyond what the client would schedule in order when there are other tasks in "waiting to run" state.
3) Progress is recorded in the client, and sticks after any of the above.
... (Does progress oscillate, retreating, progressing, retreating...)
4) If checkpoints are recorded at intervals set in the client (the "no more than" frequency rule)
5) If tasks run much longer, never ending.
6) If [average] CPU time use is per client settings (e.g. 100% orof spare cycles).
7) If the tasks in anyway impair use of computer (brand new "anonymous" betas in particular).
8) If the graphics window comes up (Beta does not have the full production graphics though)
9) If progress shows in 8)
10) If graphics window closes correctly
11) Any very extraneous RAM/VM/Swap file memory use, not warned for by the technicians
12) Any extraneous disk IO, not warned for by the technicians
.... (operators of e.g. Process Explorer look for Large Paging Fault delta's)
13) Any errors (not warnings) logged in the event/message log.
14) Any Result log errors, not the benign warnings that show in every task result output.
.... (close up watchers can monitor the stderr.txt file in the task slots\xx for up to the minute detail)