In your test you'll be giving the test users some things to try to do, and you'll be keeping track of whether they can do them. Just as good test users should be typical of real users, so test tasks should reflect what you think real tasks are going to be like. If you've been following our advice you already have some suitable tasks: the tasks you developed early on to drive your task-centered design.

You may find you have to modify these tasks somewhat for use in testing. They may take too long, or they may assume particular background knowledge that a random test user won't have. So you may want to simplify them. But be careful in doing this! Try to avoid any changes that make the tasks easier or that bend the tasks in the direction of what your design supports best.

Example: Test Users and Tasks for the Traffic Modelling System

We didn't have to modify our tasks for the traffic modelling system, because we used the same people as test users that we had worked with to develop our target tasks. So they had all the background that was needed. If we had not had access to these same folks we would have needed to prepare briefing materials for the test users so that they would know where Canyon and Arapahoe are and something about how they fit into the surrounding street grid.

If you base your test tasks on the tasks you developed for task-centered design you'll avoid a common problem: choosing test tasks that are too fragmented. Traditional requirements lists naturally give rise to suites of test tasks that test the various requirements separately. Remember the phone-in bank system we discussed in Chapter 2? It had been thoroughly tested, but only using tests that involved single services, like checking a balance or transferring funds, but not combinations of services like checking a balance and then transferring funds contingent on the results of the check. There were big problems in doing these combinations.