There should be an agreed schedule and an

There should be an agreed schedule and an understanding of who is conducting
Tests. The responsibilities for providing a test version of the changed system also
need to be understood.
For systems with established support and testing processes it may be useful to go
through a process of confirming any testing requirements and confirming agreement
on the testing process.
Sign-off need not be a significant undertaking.
Preparing Tests, Test Data, and Training
Apart from any new system functions, Test Cases and Scripts should already exist
and these can be reused.
A Test database may already be available. It may be necessary to ‘refresh’ this by
extracting data from the production system. Processes to do this should already
exist.
Training is probably unnecessary as experienced users should be available. There
may be a need to ‘run through’ any new functions with the developer.
Given the minimal workload, it is quite likely that a single person can undertake all
tasks.
Closure
Upon formal acceptance of the revisions, it will be necessary to arrange installation of
the new version of the system with the Information Management Branch in your
Division.

The Acceptance Testing Kit – Part 2
38
Some Cautionary Notes
Test Data Confidentiality
Acceptance Testing often involves the use of confidential data and the production of
real documents, real interface files, generated e-mails, etc.
It is important that during preparation of the Acceptance Test Plan, procedures to
protect the security and confidentiality of data are included.
Interpretation of Business Requirements
Business system requirements may be open to misinterpretation. A system supplier
(either internal or external) may contest the manner in which a system meets the
business requirement. Therefore, the more accurately and specifically that business
requirements are specified, the less open to misinterpretation they become.
Resolution of these issues is a common part of negotiating acceptance of a system.
If the system supplier accepts or endorses the Acceptance Test Plan, then these issues
should arise early in the process, minimising any conflict at a later stage.
System Prototyping
System prototypes are sometimes built during system design and development as
part of an iterative approach to system development. The prototype may be a
working model of a system that will eventually be used and tested and it enables
end-users to experience first-hand the proposed interaction with the system. The
prototype is not a full working model and merely simulates the proposed system’s
behaviour. Any feedback and requested changes are incorporated into the system
and the system trialed again. However, this iterative trialing of a system is strictly
part of the development process of satisfying the system requirements and does not
replace formal Acceptance Testing.