FUNCTIONAL TESTING APPROACH
The focus of the Functional Testing will be as follows:
• Business process Review
• Coverage of Requirements and Integration with various modules (functional, technical, quality)
• Understanding Views and Reports for the application
• Exceptions testing (Boundary checks, Negative tests, etc.)
• Usability (ease of use, navigation, comprehension of application operation)
The Test process used to verify software comprises of five main phases, namely
a) Requirements Validation and Test Planning
b) Test cases Development
c) Test data Development
d) Test Execution preparation
e) Test Execution and Evaluation
Typically, 360-degree approach to testing which helps in maximizing the ROI from such a mature testing framework.
Following section explains the activities involved in Test Strategy formulation.
Below figure depicts high level activities which are followed during Test planning:
Project Kick -Off Meeting
The main agenda of the Project Kickoff meeting will be as follows:
• Setting the objectives of the UAT project
• Introduction of the DeV team and Testing team
• Overview of the UAT Project – Approach, Methodology, and deliverables
• Discussions on Test Plan wrt to the scope, software delivery phases, deliverables, documentations, timelines, and Completion criteria
• Preparation of Project initiation check list
Testing Landscape with Application walkthrough
This phase involves a run through of the application and listing the functionalities to be tested.
• Demo of the entire application
• Outlining the features and functions to be tested as per scope
• Gathering inputs for Test Planning & Test Strategy
• Identifying Roles & Responsibilities of all team members
Test Planning
Following activities are covered in this phase:
• Outlining UAT Plan & Strategy
• Get the overall project plan and software delivery schedule
• Baseline the test plan aligned with overall project plan
• Identifying Deliverables
• Defining Communication, Change management process
• Defining Project status reporting
• Defining Defect Management process
• Defining UAT Acceptance, Entry/ Exit Criteria
• Defining UAT Project Metrics
• Finalizing Templates for all UAT artifacts
Test case Designing
• The Test assets already available at Bank will be reviewed with a view to ensure coverage and completeness based on the Requirements covered in the associated document such as BRD/ SRS. Testing Partner will additionally create new Test Cases and enhance the quality of existing Test Cases.
• Leverage Testing Partner reusable repository of UAT Test Cases to conduct gap analysis and customise to prepare Test cases for bank.
The following activities are undertaken in this phase:
• Ensuring coverage and traceability of the UAT Test cases designed and requirements provided.
• Ensuring completeness in terms of thorough requirement coverage based on feasibility and cost benefit analysis
• Test Scenarios exercising the application use which covers
• End to End User Journey
• Functional level Test Conditions
• Boundary Level Test Conditions
• Data Level Test Conditions
• Audit Trail Test Conditions
• Security Test Conditions
• Establishing Requirements Traceability Matrix
Broad categories of Test Cases
A. Module Level Test Cases Design:
This will cover the test cases related to testing of the business rules specific to any feature or functionality. Each module may be treated as independent component and tested in detail. This will cover all the positive and negative alternate paths in testing for the rules of module / features.
B. Scenario Based Test Cases Design:
This will cover the test cases related to scenario covering multiple requirements and business rules of various modules / features in logical sequence and verifying one or multiple outputs to replicate the real-life business scenario.
C. End to End User Journey:
These UAT cases will cover End to End User journey. These will cover following user perspectives –
1. End User
2. Operations User (Maker), as required
3. Operations User (Checker), as required
4. Other roles as defined in Entitlement matrix (Security access of the system)
During UAT execution, following rounds of UAT execution will be done:
1. Critical Functionality User Acceptance Test
• Checking Environment Readiness for UAT
• Setups and Parameters Readiness on sampling basis
• Ensuring all required sub systems are interfaced
• End to End Functionality Testing.
Bug Fixes and Retesting of Bugs - For CFT Cycle
• Retesting of pending bug fixes and testing of bugs identified in CFT Cycle
2. Comprehensive UAT Cycle 1 (100% coverage) (Cycle 1):
100% execution of all the UAT scenarios and test cases covering agreed scope specified in the scope section for cycle 1:
• Positive and Negative Scenarios
• Critical Field Level Validations
• End to end scenarios (transaction tracing in interfacing systems)
• Critical Business Features and Functionalities
• Configuration of Users / Corporates to replicate the real business situations
• Roles and User Setups as per live
• Retesting all bugs fixed and missing functionalities found during the earlier test cycle
• Defect logging and Identification of nature of defect
Bug Fixes and Retesting of Bugs - For Cycle 1
• Retesting of pending bug fixes and testing of bugs identified in Cycle 1
3. UAT – Code Drop (30% coverage of Round 1) Cycle 2(Regression):
This would be a detailed round of Testing with 30% coverage of Round 1 consisting of:
• Failed cases of UAT Cycle 1
• Block or un-executable cases of Cycle 1
• Positive Scenarios
• End to end Workflow scenarios (Most frequent production scenarios)
• Critical Business Features and Functionalities
• Configuration of Users / Corporates to replicate the real business situations
• Regression Testing (with live interfaces connectivity)
Bug Fixes and Retesting of Bugs - For Cycle 2
• Retesting of pending bug fixes and testing of bugs identified in Cycle 2(Regression)
Defect Management
Defects Management will cover the following activities:
1. At end of each day of test execution, Defects will be collated and reported to all stakeholders.
2. Defects will be categorized based on severity/impact and/or frequency of occurrence in testing
3. Defects will be logged in Defect Tracking Tool – either as an excel sheet, a free ware tool such as Bugzilla or any such tool used at bank.
When a defect is raised in UAT, Testing Partner will provide the following set of information
1) Screen shot of the defect
2) Steps to reproduce the defect
3) Test data conditions
Defect Status
1. New: Defect in New Status Logged by User.
2. Assigned: Issue Assigned to developer by Dev. Lead
3. Resolved: Issue in Resolved status post bug fixing.
4. Re-test Fail: Defect in Re-test Fail status post failure in bug retesting
5. Re-open: Any issue which is re-occurring or failing after defect has been rested and closed may be within the cycle / Cycle or any other next cycle
6. Closed: Defect in Closed status after Retesting of Bug with correct results.
7. Duplicate: Same Defect logged by many Reporters.
8. Reject: If Defect is Invalid then Development Team Lead Can "Reject" the Defect.
9. Change Request: Out of Scope defect or New Requirement.
10. Deferred: Items deferred for next Cycle / Track
11. In-Dispute: Items where BANK need to intervene and take a decision
