The document discusses the testing process for a core banking project implementation. It explains that after requirements are gathered, the vendor will create a prototype system to demonstrate 75-80% of requirements. User acceptance testing then involves testing scenarios across various products and functions to ensure requirements are met before going live. The stages of testing include individual module testing, integrated testing, and user acceptance testing on both test and live environments.

1. Testing Process
In a Core Banking Project Implementation the phase of Testing and UAT is one
of the most important aspects prior to the launch of the Products for the various
business lines.
On the selection of the vendor post negotiations etc there is a product walk-
through organised by the vendor for the business users as well as the technical
users.
Based on the walk-through the business users prepare a requirement document
comprising of the functionality, the processes, the workflows and other
requirements which could some of the short comings of the existing system
which can be addressed by the new system or enhancement of the new system to
meet the requirements.
This document so prepared is known as the Business Requirement Specifications
(BRS)or Functional Specification Document(FSD).
Since this is a productised approach and the selection of the product vendor has
been done based on the high level specifications it is assumed that almost 75-80%
of the business requirements are met.
Proto-typing.
As stated above that the approach in a productised solution is much different
from a ground-up development solution.
In a proto-type solution approach the BRS or FSD is shared with the vendor and
the vendor actually creates all the masters required and also parameterises the
system to meet the functionality required. This depends upon the flexible design
of the selected system.
In certain cases the vendor might also suggest a work-around to solve a trick
issue to prevent any form of customisation which might work. This might reduce
the coding requirement by another 5-10%
The amount of actual customisation i.e. making changes to the original code or
engine is reduced drastically to a tune of 10-15%.
Once the test bed is created using the Proto-type approach satisfying the
business requirements scenarios are created .These scenarios are known as used
cases or test plans.

2. These test plans or used cases as may be deemed are supposed to do the
following:
Identify the masters and creation of the masters in various permutations and
combinations.
Identify and ability to define product level parameters and also define products
with different properties and logic in order to create product variations e.g. in
Term Deposits it can a simple term deposit or flexi-deposits or Sweep feature,
recurring deposit etc. Saving Bank accounts with different features for children,
normal accounts , accounts created for business men or specific for high profile
customers etc.
♣ Create various scenarios for each of the products and the sub-products
associated with it.
♣ Calculation logic and application of Interest across various products.
Value dated transaction posting etc.
♣ Validation of the data at field level and also drop down lists based on the
functionality of the field.
♣ Customer creation for a centralised CIF operation across the bank.
Relationship definition with multi-ferrous combinations, holding patterns,
limits, cards etc.
Since it is assumed that the Technical architecture and the dataflow, data
integrity and other data-center requirements are taken care by the Bank and only
testing is the key area to be addressed many of the steps will become invalid.
The following gives on a perspective of the various stages that Wipro will be
involved along with ARBIFT.
Business acceptance involves
• Individual Product and Module wise testing-CA, SB, FD etc.
• Functionality Testing
• Reports Generation
• Testing of converted data and results associated with that
• Business Process Workflows.
• Integrated Testing process.
• Generation of P&L and T&L.

3. • Chart of Accounts Mapping and Migration.
• SWIFT Interface and Nostro Reconciliation
• Interface to and from other auxiliary systems to the Core Banking System
Application Testing
• Review Requirements Specification Document
• Create used case definition or test plans
• Review used cases or test plan documents with business users
• Identify permutations and combinations presented in the test case
• Segregate business and technical testing
• Document Test Results
• Identify bugs and gaps.
• Send gaps and anomalies for review and rectification.
• Re-test the application post review or rectification.
• Move the application to a live environment
• Conduct one more round of testing on live environment
• Review test results
• Document the test results
• Purge/Delete test data from live system post backup.
• Go live for the Pilot phase.
Some of the Inputs and outs of the Testing environment at various steps of
implementation is defined below
Requirements Collection
Testing (Delivery)
Purpose To conduct system testing and deliver the software.
Activities System testing of the system as per the system test cases.
Comparison of test results to match the expected results
(include Performance related Test cases).
Recording of results as Test Logs and Test Report.
Verification of System testing to ensure that the
requirements of the system are met.
Delivery of the product source code for User Acceptance
Testing
Techniques Phase Rollout
User Acceptance Testing

4. Purpose To conduct user acceptance test on the delivered
software.
Activities Acceptance testing of the system as per the acceptance
test cases.
Comparison of test results to match the expected results
(include Performance related Test cases).
Recording of results as Test Logs and Test Report.
Verification of Acceptance testing to ensure that the user
requirements are met.
Delivery of the source code for Production
Piloting of the system over a small sample of users
Techniques Beta Testing
Project Deliverables
Work Task System and User Acceptance Test
Deliverables Test Specifications
Completed Acceptance Testing environment
Executable system test environment
Tested application
System Testing completion Report
Move to the Live environment
One round of user Testing on liveenvironment
Acceptance Criteria System is accepted by the user as per acceptance test
plan
Dependencies
Primary ARBIFCT
Responsibility
Secondary Wipro
Responsibility
Acceptance Time-
frame