KEXIM Home page allows different users such as admin, bank employee, various customers (Individual customers, Corporate customers, International Customers) to login and access the application for further usage and also it provides information about various services offered by KEXIM Bank.

The objective of the KEXIM BANK Admin project is to create new branches, to create the new users and Bankers along with the privileges. Admin is the super user, which has all the privileges for creating the Branches, Users and Bankers and along with all the other privileges.

1.2 Purpose

The purpose of this document is to provide an overview for System Testing (ST) of KEXIM Bank. This document covers the testing scope, Entry-Exit criteria, QA Deliverables, QA Schedule, High Level Test Scenarios, Assumptions & Dependencies, Test Management and Risks & Mitigations.

1.3 Referred Documents

The KEXIM Bank Business Requirements Specifications (BRS)

The KEXIM BANK Functional Specifications document (FRS)

2.0 Scope

2.1 In Scope

Testing the Admin, Banker and Customer (Personal Banking) modules in E-Banking project.
Functional / system testing of all test scenarios mentioned under sec 10.0.
Creation of Test Requirements, Test Cases and Test Sets in Quality center.
Preparation of Test Data for executing the Test Cases.
Test case Execution for 2 cycles and defect Tracking.
Test case execution on the following Operating System Windows2000.
Test case execution using the following browsers - IE 6.0.

2.2 Out of Scope

· Load & Performance testing.

· Unit and Integration testing is not part of this scope.

3.0 Assumptions and Dependencies

3.1 Assumptions

· The main drivers for System Testing are the functionalities contained within the functional specification documents. These will define the scope of the testing and it is assumed that once functionality from these has been tested then full coverage has been achieved.

· Staging server will be accessible.

· Contact details of person(s) concerned with resolving environmental issues will be provided.

· Formal and Intensive Unit and Integration testing will be done by the Dev Team.

· Defects will be dealt with in timely fashion by all teams involved.

· New builds will be deployed in QA environment as per build schedule.

· All identified High-level test scenarios can be simulated in test environment.

3.2 Dependencies

· Knowledge transfer on Functionality as well as Technology to offshore testing team

· Availability of Development environment to validate test scripts.

· Availability of ACL connection to applications from offshore.

· Availability of ACL connection to Databases from offshore.

· Availability of Database schema description to understand the Database Structure.

· Availability of All necessary software and Operating Systems

Test data as specified by the QA team, injected into the stage environment.
All necessary User IDs & passwords provided to the QA team

4.0 Risks and Mitigations

Risk	Likelihood	Impact	Mitigation
Application not accessible or not responding properly during test execution due to environmental issue.	Low	High	Perform an environment sanity check before starting the formal testing Obtain Mobile / Pager numbers of IT team members to escalate P1 environment issues.
Test team does not have adequate knowledge of the application	Low	High	Organize extensive knowledge transfer sessions with offshore team
Development team having less knowledge of Quality center.	Low	High	QA team will provide clarifications to the Development team.
Presence of large number of blocking Defect‘s during test execution, this would prevent or delay testing.	Low	High	Daily defect meeting will be utilized to prioritize defects QA co-ordinator will work closely with the IT team lead to provide
Changes to requirements	Medium	Medium	All new Requirements that arise are initiated through Change Control process

5.0 System Testing Entry and Exit Criteria

5.1 Entry Criteria

The following must be in place prior to the onset of QA System Testing

Business

· The Business Requirements Document is “frozen “

· All new Requirements that arise are initiated through Change Control process

· Daily communication plan in place

· Test Cases Reviewed & signed-off

· Cross-functional, dependent teams & resources identified

· QA Data Requirements identified & all necessary passwords/accesses obtained

· Daily Defect Meeting Day/Time/Attendance established in the execution phase

· All appropriate team members have access to Quality center

· Test cases have been linked to test sets in Quality center

5.2 Exit Criteria

The following must be in place prior to the sign-off of QA System Testing:

· No open P1 or P2 defects

· All P3-P5 (enhancements) defects have a documented resolution plan

· A minimum of 2 test cycles (100% execution) is completed.

· 95% Pass Rate of all test cases

· Regression testing of defects fixed during system testing

· All defects logged in Quality center

· QA sign-off on system test

· System test Close-out report Provided

· Documented list of any outstanding (open) defects

6.0 QA Deliverables

The following items will be delivered:

· System Test Plan

· Test Cases (Maintained in Quality center)

· Daily Test Execution Report

· System Test Exit Report

· Defect Log (Maintained in Quality center)

· Traceability Matrix

· Exit Report.

· Project Metrics.

7.0 QA Schedule

QA Activities	QA Deliverable	Start Date	End Date
Analysis of the Documents	Understanding Document	25/03/2008	26/03/2008
Test Planning	Test plan document	27/03/2008	27/03/2008
Test case preparation and validation	Test cases, Test Data	28/03/2008	31/03/2008
Test case execution and Defect tracking	Complete the execution and defect log maintained in Quality center	02/04/2008	05/04/2008
System Testing Sign-off	Exit report	07/04/2008	08/04/2008

8.0 Build Schedule

New builds will only be deployed in stage environment as per build schedule. Only emergency builds can be deployed on other dates. Each build should have version number. Email to QA coordinator has to be sent after successful installation of build. Sanity test by IT team should be conducted after build installation.

Sl.No	Activity	No of Resources	Start Date	End Date	No of Days
1	Build#1	1	02/04/2008	03/4/2008	2
2	Build#2	1	04/4/2008	05/04/2008	2

9.0 Test Environment

The following list of software will be required in the System Test Environment

QA URLs	KEXIM BANK – http://192.168.1.13/Ebanking
Web Browser	IE 6.0
Test management Tool	Quality center – 8.0 SP2 http://192.168.1.8/tdbin/start.htm Domain: Banking Project: E-Banking
Operating System	Microsoft windows 2000
H/W	Intel (R) Pentium, 2.8 GHZ, 512MB

10.0 High Level Test Scenarios

S#	Test Scenario
Admin Module
0.1	KEXIM Home Page
0.2	Admin Home Page
1	Branches
1.1	New Branch Creation
1.2	Branch Edit
1.3	Branch Delete
1.4	Branch Search
2	Roles
2.1	New Role Creation
2.2	Role Edit
2.3	Role Delete
3	Users
3.1	New User Creation
3.2	User Edit
3.3	User Delete
3.4	User Search
4	Employee (Banker)
4.1	New Employee Creation
4.2	Employee Edit
4.3	Employee Delete
Banker
5	Customer
5.1	New Customer Registration
5.2	Edit Customer
5.3	Delete Customer
6	Receipts
6.1	Cash Deposit
6.2	DD Deposit
6.3	Cheque Deposit
7	Payments
7.1	Cash withdrawal
7.2	Cheque withdrawal
7.3	DD withdrawal
Customer (Personal Banking)
8.0	Accounts Summary
9.0	Money Transfer
10.0	Smart Money Order
11.0	Biils Pay
12.0	Request for Cheque Book

AKHIL REDDY TECHNOLOGIES

Monday, 13 July 2015

BANKING DOMAIN TEST PLAN

Document History

Approvals

1.0 Introduction

1.1 Project Overview