The Test Management Plan is an artifact that should be produced for all projects at First Niagara Bank. The following guidance should be considered to develop the plan. Refer to the "Test-ManagementPlan" template for more information.

Synopsis: Describe the synopsis in 2 or 3 sentences related to the project for which the plan is being developed.

Document Status: Current status of the document.

Author: Name of the person who developed the plan.

Version: Version number to track changes.

Date: Date when the plan is developed or modified.

Table of Contents: This Test Management Plan should contain Table Of Contents as listed below. For more information, please refer to the example.

Introduction

Project Information

Test Activities

Test Environments

Reporting

Go Live Criteria

Staff Requirements

Introduction: The Introduction section should contain the following sub categories.

Distribution List:

Name - Name of the person.

Role - Job title/role of the person.

Location - Physical location of the person.

Document history:

Version - The version number of the document to track changes.

Date - Document creation or modified date.

Author - Name of the author who is developing the plan.

Changes - Listing of the changes at high level.

Reference Documents:

Listing of any documents and their locations that can be used as reference for the project.

Document - List the name of the document.

Description - High level description of the document.

Location - Location of the file. Provide the url/link if possible.

Outstanding issues:

Listing of any outstanding issues that can have any potential impact on the project.

Reference# - Listing of any reference numbers like defect#, BRD# etc. that could have an impact on this project directly or indirectly.

Issue - Brief description of the issue. Provide link/url if possible.

Purpose of document - Describe briefly the purpose and intention of the document.

The purpose of this document is to describe the QA Test Strategy for the project. This document is intended to outline all QA activities, the approach to testing, aid in achievement of project quality objectives, to ensure the successful delivery and provide visibility into testing activities throughout the project.

Project Information:

Project Scope: Describe briefly the QA scope for the project.

This plan should detail the types of testing which will be conducted and covers Unit, System, Data, Performance, Functional, Operability and Content Testing. This plan should also cover the overall testing approach for the project.

Associated Projects and Dependencies:

List any external and internal dependencies which will be outlined in project plan on SharePoint, maintained by the Release Manager.

Assumptions:

Listing of QA assumptions for the project. Assumptions may include staffing, environments related, requirements related etc.

Risks and Issues:

Listing of any risks and issues that relate specifically to testing.

Context - List the context. Ex: Late addition of new requirements, QA staff availability etc.

Risks - Brief description of the risk.

Level - List the risk level. Ex: High, Medium and Low.

Impact - Brief description of the business or functional impact.

Owner - List the owner of the risk item. Ex: QA Manager, Business analyst etc.

Mitigation - Brief description of the risk mitigation.

Requirement Reviews:

The purpose of this section is to capture the information about who and when requirement reviews are done.

Functional Area - List the functional area for which the requirements were developed..

Reviewer - Name and Title of the person who reviewed the requirements.

Date Completed - The date when the requirements review is completed.

Test Activities:

Test Objectives: Provide a brief description of the objective.

This objective should be focused on providing information to other groups and stakeholders to enable them to make decisions about the quality of the project.

Test Phases:

Phase - List the name of the test phase. Ex: Unit, System and Regression etc.

Objective - Describe briefly the objective of the test phase.

Owner - Accountable - Name of the department/group accountable for.

Owner - Responsible - Name of the department/group responsible for.

Test phases must include the following for any project:

Unit(For in-house development)

System/Feature

Regression

Installation/Configuration

Data Quality

Performance

Documentation (Training material, Release notes etc.)

Overall Test Approach/Strategy:

Briefly describe the overall testing approach and strategy for the given project based on the functionality and requirements. In addition, the following must be covered for every project.

Achieving optimum test coverage - ALL test phases.

To establish a high level of confidence in the product as early as possible in the software development lifecycle - ALL test phases

To verify the business and functional requirements have been developed according to specification - ALL test phases

To mitigate the level of business risk associated with implementing new software - ALL test phases.

Continue to improve, optimise and innovate the test process as the release/project evolves - ALL test phases.

Identify test-related risks and issues providing appropriate recommendations - ALL test phases.

To ensure that the system can operate at optimum levels under the predicted business volumes - Performance test phase.

Development Testing:

Unit Testing - To ensure that the components of each part of the solution work in isolation or when run against test harnesses. To ensure that code/configuration is peer reviewed. This is done by Development team and test cases & Unite test report should be produced towards end of this phase. This may not be applicable if development is done by a vendor.

Functional Testing:

SIT/Feature Testing - To ensure that the system functions as expected. Newly developed functionality will formally enter QA following a successful demo to QA and Product/Business Teams.

SIT/Feature testing will begin before the fully functional system is available. This will allow completed features to be verified, giving an early view of quality. This occurs after code complete. Test scripts, Defect reports and QA Report should be produced towards end of this phase.

Regression Testing - To ensure that existing functionality has not been affected by changes.Running prioritized tests from the regression test suite will ensure existing functionality continues to work as expected following the implementation of new functionality. The extent and scope of regression will be determined by the completion date of the system test phase, although some testing may run in parallel. Test cases will be prioritized by QA, Product and Development teams dependent on business priority and perceived risk. This occurs after code freeze. Test scripts, Defect reports and QA Report should be produced towards end of this phase.

Installation and Rollback Testing - To ensure that the installation and rollback process is documented, accurate and repeatable. This test phase will test the installation process and ensure the rollback procedure is reliable. A small subset of functional tests will be scheduled to prove the install/configuration of the systems. Proven installation and rollback procedure with accompanying documentation should be produced towards end of this phase and this is typically done by Development team,

UAT - To ensure that clients can verify the new functionality in the release. This is done by clients/users and QA will assist as needed to help complete UAT. Users/clients should sign off on the project/product after the UAT so it can be moved to Production.

Non-Functional Testing:

Data Validation - To ensure that all required fields are delivered and validated. Typically, this is concurrent with System and Regression testing. Defects report and Data quality test report should be produced towards end of this phase.

Performance Testing - To ensure that the system can operate at the predicted business volumes. There should be no known defects that will reduce the validity of the testing or limit its scope.

Documentation - To ensure that the documentation (user guide, release notes etc.) is fit for purpose. QA should review and sign off on the documentation.

Operations Acceptance Testing (OAT) - To confirm alerting functionality, resiliency and performance in an Operational Environment. This may not be applicable if the environment is hosted by the vendor.

User Acceptance Testing (UAT) - To test the delivery, and to gain the acceptance from Business/Product teams. The UAT phase should designate the time window that follows the ex-QA date of the product or project delivery phase and is after the Fitness for Launch (FFL) review. During this phase, the product or project is made available on the production or pre-production environment to potential users. A select group of business users will be given access to the product and requested to give feedback after a certain period. QA will assist with UAT as needed. UAT test report and Test Completion Certificate should be produced towards end of UAT phase.

Test Environments:

Environment Owners - Configuration and Integration Owner (Release Manager) is responsible for ensuring that changes to environments are logged and system configuration is as close to the production environment as practically possible. Environments configuration should be tracked and documented.

If there is no environment is dedicated for QA, STAGING environment will be used for both QA and Dev purposes for now. The assumption is that STAGING environment will be isolated during QA activities and no coding/configuration changes will be allowed during that time to ensure the quality.

Environmental Variances - All QA and User Acceptance environments should be configured as closely as possible to Production wherever possible. Any differences should be documented and presented to the stakeholders.

Reporting:

Quality Reports - Weekly Quality Updates will provide a more comprehensive and consolidated view of QA progress and will also provide detailed information on the quantity and severity of defects raised.

Any showstoppers previously raised in past reports that were fixed over the current reporting period should be noted.

The QA Report should be distributed on completion of the Feature/System Integration and Regression phases. This report should summarize coverage against the areas defined in the Test Plan. The Performance

Test Report will summarize system performance against those tests defined in the Performance Test Scope(if applicable to the project).

Defect Reports - All defects found during Feature/System testing of the components should be logged by the appropriate teams. Defect reports should be available to FNFG QA management. Defects found in development testing should be logged in ALM as well. Reports should be prioritised and assigned to a release during the defect triage meetings.

The frequency of defect triage meetings should be determined once the QM has a view of the code quality. Daily meetings will be held if this is deemed appropriate and meetings should be at least weekly.

Weekly QA Meetings - All members of the QA Teams should meet at least once per week to discuss QA progress and issues.

Weekly Project Meetings - On a weekly basis, the Team should meet to discuss weekly status. This meeting should review project progress and issues, and make appropriate priority calls if required.

Go-Live Criteria: The following criteria should be fulfilled prior to delivery of the Project/Release into production.

Functional Sign-off - Formal sign off on functionality by the Product/Business Team(s). This can be a certificate, email or by any other practise.

Test execution and Defect review - All specified test cases have been executed and results recorded. All Blocker and Critical defects have been addressed. All Major defects have been addressed or waived by the

Product/Business Team(s) during triage calls. Test Reports have been distributed, reviewed and approved.

Non-Functional Sign-off - Formal sign-off on non functional testing(if any) by the Product/Business team. This can be a Test Completion certificate from application owners.

Risks and Deficiency Management - Any outstanding defects/issues should be reviewed and approved by the Product/Business, Dev and QA Teams. Risks and Issues Log should be updated, reviewed and approved by the Product/Business Team(s).

Documentation - All documentation should be received and reviewed by the appropriate stakeholders.

Installation and Rollback - Installation/Configuration and rollback tests should be successfully performed on the final release candidate. The Install and Rollback Guide should be reviewed and signed off.

Staff Requirements:

QA Team - Identify and list the QA resources that are required for this project.