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.
You've reached the end of your free preview.
Want to read all 96 pages?
- Fall '18
- acceptance testing, Acceptance Test Manager