Page 246 -

8.4 User testing 229

Test Test Test Testing
Criteria Plan Tests Results Report

Define Plan Derive Run Negotiate Accept or
Acceptance Acceptance Acceptance Acceptance Test Results Reject
Criteria Testing Tests Tests System

may be a selected group of customers who are early adopters of the system.
Figure 8.11 The
acceptance testing Alternatively, the software may be made publicly available for use by anyone who is
process interested in it. Beta testing is mostly used for software products that are used in
many different environments (as opposed to custom systems which are generally
used in a defined environment). It is impossible for product developers to know and
replicate all the environments in which the software will be used. Beta testing is
therefore essential to discover interaction problems between the software and fea-
tures of the environment where it is used. Beta testing is also a form of marketing—
customers learn about their system and what it can do for them.
Acceptance testing is an inherent part of custom systems development. It takes
place after release testing. It involves a customer formally testing a system to decide
whether or not it should be accepted from the system developer. Acceptance implies
that payment should be made for the system.
There are six stages in the acceptance testing process, as shown in Figure 8.11.
They are:

1. Define acceptance criteria This stage should, ideally, take place early in the
process before the contract for the system is signed. The acceptance criteria
should be part of the system contract and be agreed between the customer and
the developer. In practice, however, it can be difficult to define criteria so early
in the process. Detailed requirements may not be available and there may be sig-
nificant requirements change during the development process.
2. Plan acceptance testing This involves deciding on the resources, time, and
budget for acceptance testing and establishing a testing schedule. The accep-
tance test plan should also discuss the required coverage of the requirements and
the order in which system features are tested. It should define risks to the testing
process, such as system crashes and inadequate performance, and discuss how
these risks can be mitigated.
3. Derive acceptance tests Once acceptance criteria have been established, tests
have to be designed to check whether or not a system is acceptable. Acceptance
tests should aim to test both the functional and non-functional characteristics
(e.g., performance) of the system. They should, ideally, provide complete cover-
age of the system requirements. In practice, it is difficult to establish completely
objective acceptance criteria. There is often scope for argument about whether
or not a test shows that a criterion has definitely been met.