E-Banking Test Plan QA103 v 1.0

SystemTestPlan __________________________

RANFORD Bank 1.0

Prepared by: Krishna Rao

Document History Version 0.1 1.0

Revision Date 02/07/2010 21/07/2010

RANFORD Bank System Test Plan Mind Q Systems, Internal Use Only

Name Rajamohan Krishna Rao

Modification Summary Initial Draft Updated the QA schedules and Build schedules.

Page 1 of 12

Approvals Name Suresh Babu

User Id Suresh.b


Role Project Manager

Date 21/07/2010

Page 2 of 12

Table of Contents

Document History........................................................ ................................................................................................... ........................................... ....... .......... ...1 1 Approvals................................................ ........................................................ ........................................................................... ...................2 2 1.0 Introduction............................................... ........................................................ .................................................................. ..........4 4 1.1 Project Overview................................................... ................................. ....... ............... ............ ....4 1.2 Referred Documents ........................................................ ................................................................................... .................................. ............... ........ 4 2.0 Scope............................................... ..................................................... ............................................................ ............... ............... .......... ...4 4 2.1 In Scope................................................ ............................................... ....... ............... .............. ...... 4 2.2 Out of Scope ................................................... ....................................... ....... ............... ............. ..... 4 3.0 Assumptions and Dependencies ..................................................... .................................................................................. .............................5 5 3.1 Assumptions..................................................... .................................................................................... ....................................... ............... .............. ........... .... 5 3.2 Dependencies ...................................................... .................................................................................................. ............................................ ........ ........... ...5 4.0 Risks and Mitigations ............................................... ...................................... .............................................. ............. .....5 5 5.0 System Syst em Testing Entry and Exit Criteria ................................................. ........ ............... ........... .... 6 5.1 Entry Criteria........................................................ ......................................................................................... ................................. ....... ............... ............ ....6 5.2 Exit Criteria Criteria..................................................... .................................................................................... ....................................... ............... .............. ........... .... 6 6.0 QA Deliverables....................................................... ........................................................................................ ........................................ ............... ............ ....7 7 7.0 Build Schedule....................................................... ........................................................................................................ ................................................. ..... .....7 7 8.0 Test Environment .......................................................................................................7 .......................................................................................................7 9.0 High Level Test Scenarios....................................................... ..................................................................................... .................................... ......7 7 10.0 Test Approach ....................................................... .................................................................................................. ........................................... ....... .......... ...8 8 10.1 Test Preparation.................................................. ........................................ ....... ............. ......8 10.2 Test Execution.................................................... ..................................................................................... ................................. ....... ............... ............ ....9 Appendix A........................................................ ................................................................................................................ ............................................................... .........9


Page 3 of 12

1.0 Introd Introduct uction ion 1.1 1.1

Proj Projec ectt Over Overvi view ew

Ranfor Ranford d Home Home page page allows allows differ different ent users users such such as admin, admin, bank bank employ employee, ee, variou various s customers customers (Individu (Individual al customers customers,, corporate corporate customers customers,, Internatio International nal Customers Customers)) to login and access the application for further usage and also it provides information about various services offered by Ranford Bank. The objective of the RANFORD BANK Admin module in 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. The Objective of the RANFORD BANK Banker module in project is to register and manage the customers of the bank and to book the day-to-day transactions in the bank such as deposits and withdrawals etc. The Objective of the RANFORD BANK Customer module in project is designed for the registered customers to perform various activities such as Accounts Summary, Money Transfer, Smart Money Order, Online bill payments and online request for chequebook etc., Purpose The purpose purpose of this this docume document nt is to provid provide e an overvi overview ew for System System Testin Testing g (ST) (ST) of RANF RANFORD ORD Ba Bank nk.. This This docu docume ment nt cove covers rs the the test testin ing g scop scope, e, Entr Entryy-Ex Exit it crit criter eria ia,, QA Deliverables, QA Schedule, High Level Test Scenarios, Assumptions & Dependencies, Test Management and Risks & Mitigations. 1.2 1.2

Refe Referr rred ed Docu Docume ment nts s

The RANFORD Bank Business Requirements Specifications (BRS) The RANFORD BANK Functional Specifications document (FRS) 2.0 2.0 Scop Scope e 2.1

In Scope •

• • • • • •

2.2

Testing the Admin, Banker and Customer (Personal Banking) modules in 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 e xecuting the Test Cases. Test case Execution for 2 cycles and defect Tracking. Test case execution on the following Operating System Windows2003. Test case execution using the following browsers - IE 6 .0. Out of Scope

•

Load & Performance testing.

•

Unit and Integration testing is not part of this scope.


Page 4 of 12

E-

3.0 Assumption Assumptions s and Dependencies Dependencies 3.1

Assumpt mptions The main drivers for System Testing are the functionalities contained within • the functional functional specifica specification tion documents documents.. These These will define the scope of the testing testing and it is ass assume umed d that that once once functi functiona onality lity from these these has been tested tested then full 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.

3.2

•

Defects will be dealt with in timely fashion by all tea ms 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.

Dependencies ies •

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

•

Availability of Testing Testing environment to validate test scripts. scripts.

•

Availability of connection to applications from offshore.

•

Availability of connection to Databases from offshore.

•

Availability of Database schema description to understand the Database Structure.

•

Availability of All necessary software’s and Operating System’s

• •

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

4.0 Risks and Mitigat Mitigations ions Risk Application not accessible or not respondin responding g properly properly during during test execution execution due to environmen environmental tal issue. Test team does not have adequate knowledge of the application Develo Developme pment nt team team having having less less knowledge of Quality Center.

Likelihood Low

Low

Impact High

High

Mitigation Perform an an en e nvironment sa sanity ch c heck before starting the formal testing Obta Obtain in Mo Mobi bille number mbers s of IT team eam memb member ers s to esca escala late te P1 envi enviro ronm nmen entt issues. Organize ex extensive kn knowledge tr transfer sessions with offshore team

Low

High

QA team will provide clarifications to the Development team.

Pres Presen ence ce of larg large e numb number er of Low bloc blocki king ng Defe Defect ct‘s ‘s duri during ng test test execution, this would prevent or delay testing. Changes to requirements Medium

High

Daily de defect me meeting wi will be be ut utilized to to prioritize defects QA co-ordinator will work closely with the IT team lead to provide All new Requirements that arise are initiated through Change Control process


Medium

Page 5 of 12

5.0 System System Testing Entry Entry and Exit Criteria Criteria 5.1 5.1

Entry try Cri Crite teri ria a

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

QA • • • • •

• •

5.2 5.2

Daily communication plan in place Test Cases Reviewed & signed-off 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

Exit Crite riteri ria a

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


Page 6 of 12

6.0 QA Deliver Deliverabl ables es The following items will be delivered: • • • • • • •

System Test Plan Test Cases (Maintained in Quality Center) Daily Test Execution Report Defect Log (Maintained in Quality Center) Traceability Matrix Exit Report. Project Metrics.

7.0 Build Build Sched Schedule ule 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 a fter successful installation of build. Sanity test by IT team should be conducted after build installation. Sl.No 1 2

Activity

No of Resources 1

Build#1 Build#2

1

Start Date 16/10/201 0 20/10/201 0

End Date 16/10/201 0 20/10/201 0

No of Days 3

Build Schedule will be send to you later… 8.0 Test Environme Environment nt The following list of software will be required in the System Test Environment QA URLs

RANFORD BANK –“ http://localhost”

Web Browser

IE 6.0 Quality Center – 8.0 SP2 http://localhost:8080/qcbin/start.htm

Test management Tool

Domain: Banking

Project: E-Banking

Operating System

Microsoft windows 2003

H/W

Intel (R) Pentium, 2.8 GHZ, 501MB

9.0 High Level Level Test Test Scenario Scenarios s S# 0.1 0.2 1 1.1 1.2 1.3

Test Scenario Admin Module Ranford Home Page Admin Home Page Branches New Branch Creation Branch Edit Branch Delete


Page 7 of 12

1

1.4 2 2.1 2.2 2.3 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3

Branch Search Roles New Role Creation Role Edit Role Delete Users New User Creation User Edit User Delete User Search Employee (Banker) New Employee Creation Employee Edit Employee Delete Banker

5 5.1 5.2 5.3 6 6.1 6.2 6.3 7 7.1 7.2 7.3 8.0 9.0 10.0 11.0 01.0 10.0 10.0

Customer New Customer Registration Edit Customer Delete Customer Receipts Cash Deposit DD Deposit Cheque Deposit Payments Cash withdrawal Cheque withdrawal DD withdrawal Customer (Personal Banking) Accounts Summary Money Transfer Smart Money Order Biils Pay Request for Cheque Book Test Test Approa proac ch

10.1 Test Preparatio Preparation n The QA Team will prepare Test Scenarios and Test Requirements based on all the project related documents provided by the project team.

•

The QA Team will prepare the system test cases to validate each Test Scenario and Test requirement. •

The system test cases will check the application functionality by supplying a set of valid and invalid inputs.

•

The The syst system em test test case cases s will will be revi review ewed ed by the the deve develo lopm pmen entt PL. PL. The The Test Test Lead/Analyst will approve the document. The test cases will be stored in Quality Center from the draft stage itself. The test coordinator will export the test cases in excel format for ease of review. •


Page 8 of 12

SQL queries will be attached attached to the relevant steps of the test scripts scripts to validate the information on the screen will be validated against the information contained in the database. •

10.2 Test Execution Execution The test scripts will be executed manually. The results will be validated against the expected results listed in the test scripts. Any defect found in this process will be logged in Quality Center. The application development team will review defects raised by the QA team. The • test tester er will will prov provid ide e all all nece necess ssar ary y info inform rmat atio ion n abou aboutt the the defe defect ct in Qual Qualit ity y Cent Center er.. Attach Attachmen mentt tab of Qualit Quality y Center Center will be used used for providin providing g any screen screen shots, shots, files required for investigating the defects. After the completion of the testing run, the peer team member of the Testing • Team Team reviews reviews the result results. s. The The test test result results s are report reported ed to the projec projectt PL who will approve the test results. This process may repeat till the number of bugs found is within the acceptable limits and the test exit criteria previously determined is achieved. There will be at least six complete cycles of tests executed. The last cycle should • go through without any P1 or P2 defects. If there are P1 and P2 defects are found in the last cycle, more testing cycles will be executed until all P1 and P2s are removed. •

Appendix A 1 Test Pl Planning 1.1 1.1 Quali uality ty Cente nter Test cases, test sets and defects will be stored and maintained in the RANFORD BANK (Domain – E-Banking) domain in Quality Center, http://localhost/qcbin/ Quality Center: Requirements - Requirements Requirements will be documented documented in the Requirements Requirements module and associated with applicable test cases. Qualit Qua lity y Center Cent er : Test Plan P lan - Test cases will be written in the Test Plan Plan tab. Test cases will be organized by subject subject (or function/ function/ use case). At this time, all test cases are written for manual execution. Qualit Qua lity y Center Cent er: Test Tes t Lab - Test Sets containing test cases to be executed during System Test will be created created in and executed executed from the the Test Lab tab. Test cases cases will be executed executed manually. Quality Qualit y Center : Defects - The The Quali Quality ty Cent Center er Defe Defect cts s tab tab will will be used used to log log and and communicate status of defects. defects. If a test case does not meet meet the expected result, the the test case will be “failed” and a defect will be logged identifying the problem. 2

Defect Ma Management

2.1 2.1 Prio Priori riti tizat zatio ion n of of Def Defec ects ts During During system, system, business, business, and user-accep user-acceptance tance testing, testing, defects defects will be logged logged in Quality Quality Center and assigned assigned a status and priority. priority. Any “show “show stopper” stopper” issues will be assigned assigned a priority of P1. P1. Issue priorities priorities are defined as follows: P1– High - affects core functionality; prevents availability or interrupts testing; no workaround available. Must be resolved ASAP.


Page 9 of 12

P2 – Medium High - affects core functionality; interrupts testing; workaround available. Must be resolved within 2 business days. P3 – Medium - interrupts isolated test cases; UI problems; workaround available. Resolution pending schedule. P4 – Medium Low - affects isolated test cases; nice-to-haves; UI enhancements; workaround available. Resolution pending schedule. P5 – Low – Cosmetic defects; workaround available.

Resolution pending schedule.

P6 – Very Low – Deferred for future releases 2.2 2.2 Ente Enteri ring ng Defe Defect cts s Befor Before e ente enteri ring ng a new new defe defect ct,, be sure sure to chec check k for for simi simila larr defe defect cts s to avoi avoid d logg loggin ing g duplic duplicate ates. s. If you find find a potent potential ial defect defect that that is within within the functi functiona onality lity of anothe anotherr track/mod track/module, ule, be sure to work work with the appropriat appropriate e member of your your QA team. A daily defect meeting will be scheduled and is mandatory if you have any defects opened by you or assigned to you that are not of the status Closed. Appropriate developer(s) developer(s) and Business team members will also attend this meeting. When logging a new defect for this track/module, field values should be set as follows: Field Assigned To Browser

Required Yes Yes

Created Date Defect ID Defect Status

N/A N/A Yes

Description Detected By Detected in Version Modified Priority

Yes N/A Yes N/A Ye s


Values Firefox Internet Explorer Konquerer Mozilla Multiple Browsers Netscape Safari

New Open Fixed Rejected Reopen Deferred Duplicate Closed Pending

P1 P2 P3 P4

-

High Med High Medium Med-low

Page 10 of 12

Field

Required

Values P5 - Low P6 - Very Low

Project Subject

Yes Ye s

CR - Cross Reference Actual Fix Time Closed in version Closing Date Comments Estimated Fix Time Fix Date OS

No No N/A N/A No No No Ye s

Planned closing Version Reproducible Re-work Counter Root Cause

No N/A No No

CR Type

No

drop down values automatically will be populated through the requirements tab For UAT – The Use cases have been listed in Subject for each build

Linked to Version defined

Operating System – Windows 2000, Windows XP, Macintosh and Linux Linked to Version defined in the requirement y-n field = when NO, Status will be closed Should be behind the scenes Boundary System Duplicate Caused by Environment Design Issue Development Issue New Requirement Changed Requirement Deleted Requirement Not in Use Case Prod/ Env. Issue Not Reproducible Pre Existing User Training Not a bug Cosmetic/Grammatical Database Issue Data Issue In/Out Cycle

2.3 2.3 Defe Defect ct Stat Status us Wo Work rkfl flow ow An email will automatically be created and sent to the person in the Detected By field as well as the person in the Assigned To and Biz Owner field each time an issue is created or updated within Quality Center. Center. As many many “Closed “Closed”” issues as possible will be included in the regression regression testing testing to occur in the production production environm environment ent (pre-go-liv (pre-go-live). e). Daily, Daily, crosscrossfunctional defect meetings will be held to ensure proper prioritization of all defects. The following table lists the status values available for a defect, who a defect with each status should be assigned to, which Quality Center Fields require updating when the status is updated, and any notes regarding the status. Status New

Assign To Dev Lead


TD Fields to Update All required

Notes IT Track leads listed above.

Page 11 of 12

Status Open

Assign To Developer, IT QA Analyst, Analyst, Business Business QA, Business Owner

TD Fields to Update Statu atus, Assign to, R&D Comm Commen ents ts,, Esti Estima mate ted d Fix Fix Time

Fixed

QA team lead

Closed

User defect

Reopen

Dev Lead

Defe Deferr rred ed

Busine Busi ness ss PM/ PM/ Bus Busin ines ess s Owner

Status, R&D Comments, Actual Fix Time Status atus,, R&D R&D Com Commen ments, ts, Closing Date, Closed in Build, Closing Reason Status, Assign to, R&D Comments Statu atus, Assign to, R&D Comments, Deferral Reason, Planned Closing Version

who

closed


Notes Develo Developer pers s shoul should d resolv resolve e P1 issues prior to P2, P3, or P4 issues issues.. Open Open stat status us is used for assigned, rese resear arch chin ing, g, in-p in-pro rogr gres ess, s, etc. tasks. Coding Coding comple completed ted and unit unit testing passed.

Include test scenario details during re-test. Business review and appr approv oval al requ requir ired ed for for this this stat status us.. Biz Biz owne owners rs list listed ed above.

Page 12 of 12

E-Banking Test Plan QA103 v 1.0

Recommend Documents