SlideShare a Scribd company logo

Testing Process

•
•
M
maheshpadwal

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 of 4
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.
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.
• 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
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

More Related Content

Testing Process

  • 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