Information Technology Reference
In-Depth Information
requested. This should be the preferred scenario to avoid distraction by daily
business.
The supplier should be asked to provide development resources for the func-
tionalities in question for the duration of the tests—at least in stand-by mode.
Furthermore, the presence of the internal quality management of the supplier is
essential in case amendment patches or hot fixes are to be introduced during
acceptance testing.
System specialists covering different competences should be named and sched-
uled for the operation of the test environment.
If not already defined by the intrinsic structure of the implementation project
itself, escalation paths and instances have to be defined and this for three reasons:
To make decisions in case of conflict regarding classification of errors,
To decide on the abandonment or continuation of acceptance procedures, if
serious disruptions occur (system problems, software breakdown, bottlenecks
regarding personnel resources etc.),
To serve as addressee of the final acceptance report.
3.3.3 Coordination of Test Scripts and Test Data
Test scripts emanate from three sources:
Functional specifications
Technical specifications
Business processes.
All three depend on each other. One should assume that functional specifications
are always drafted on the basis of documented business processes. Those in turn
serve as the basis for the technical specifications to be written by developers. This is
the theory. Only, when these preconditions are met can test scripts finally be drafted
on the sole basis of business processes. Unfortunately only in few companies
comprehensive and up-to-date documented business processes are to be found.
Regarding specific functions, that may have been developed, possibly driven even
by ad-hoc insights during the usage of existing software, this is even less the case.
Therefore one has to assume a rather heterogenic document history, when suddenly
and under time pressure acceptance tests become urgent.
The supplier will always take the latest version of the technical specifications as
a reference for his billing. From a legal point of view this is quite in order. However,
the end user will give his approval only in case the new functions support his
business processes in such a way as he deems appropriate. This last criterion has
priority. To avoid conflict all parties concerned should be permanently consulted. If
necessary, compromises have to be agreed upon, if differences arise in spite of all
the communication during the drafting process of the specifications. Fact is: the
software has arrived by now.
