This forms a part of User Acceptance Tests. The trial run should be carried out by the users, to establish the functionality of the product vis-à-vis their expectations. Further, the various cross links and parameters set up during database design and inputs are tested. This is a crucial phase since the sign-off from the customer depends on the successful completion of the trial run. Another objective of the trial run is to help the end-users get familiar with the system.
It is essential that the test plan of the trial run is prepared and executed by the users. The implementation team from Oracle Financial Services should only assist the users in this exercise. This assistance should be restricted to providing guidance in formulating the test plan, the procedure to be followed during the trial run and the documentation that is necessary. All aspects of the trial run should be documented. This document is the basis for the sign-off from the users and their auditors. It should contain the following information:
The number of days over which the trial run should be spread should be decided based on the number of modules that have to be implemented. The results should be documented daily, along with any problems and solutions provided.
This section contains the following topics
The trial run should be conducted on a separate scheme containing the static database as maintained after the database design and input. In some cases system trial run may be carried out in the pre-shipped maintained database. However, it is advisable to carry out the test in the actual database set-up for the bank.
The test plan for the trial run should be a representative of the real life situation in the bank. All conditions, those that occur during the course of a normal day and those that are critical but may happen rarely should also be covered in the test plan. As far as possible multiple features should be tested using a single transaction so as to keep the number of actual transactions to a minimum. It is easier to control and review the results when the number of transactions is less.
The trial run plan should ideally contain the detailed test plan, schedule for the trial run and responsibilities. The following people should be involved in the system trial run:
The trial run should establish the following:
All types of transaction in a specific module should be included. Care should be taken to include transactions that may occur rarely also, along with samples of transactions that are entered more often. Volume testing should be a part of the test plan.
The test plan should contain the list of output messages that have to be generated for the transactions.
The system dates for the trial run should cover End of Day, End of Month, End of Month of February (29th) for a leap year, End of Year and Beginning of Day processing.
An Error Control Log (Test Incidence log) should be opened in which all the errors encountered during the trial run have to be registered. Each error should be allotted a number. The following details should be recorded for an error:
The errors should be monitored on a daily basis and solutions provided within the time frame agreed upon. This time frame should depend on the nature of the problem and its impact on conversion.
The System Trial Run has three distinct but concurrent phases. Each phase should emphasize on testing a certain set of system features. The recommended schedule is described in the following sub-sections. This schedule can be modified to suit the requirements of a site.
Phase One should focus on the features of the hardware, the operating system and the various controls. Besides these the functionality of Core subsystems should be tested Core should include the following sub-systems:
The features to be tested for the Operating System are as follows:
For system controls, the features to be tested are:
The tests for hardware should be to ensure the following:
All the relevant reports must be checked and findings of End of Day run should be recorded.
Phase Two should include tests to establish the functionality of the all the front-end modules
During Phase Three, transactions in all the sub-systems modules that may occur on a day have to be input. The End of Day operations should be carried on and reports checked. This exercise will establish the proper functioning of the system under real-life conditions.
It should be noted that the three phases are only for the purpose of proper focusing. These are not sequential phases. Depending on the number of resource personnel available, Roles can be assigned to each person to focus on the critical features of each of the phases.
Note
The list of features that has been prepared for the standard Product Test Plan, is available as a part of the release. It can be used as a reference while preparing the test plan for the trial run.