Awash bank QA strategic and plan

<PROJECT NAME>

Test Strategy and Plan document

Version <1.0>
<mm/dd/yyyy>

VERSION HISTORY
Version Implemented Revision Approved Approval Reason
# By Date By Date
1.0 <Author name> <mm/dd/yy> <name> <mm/dd/yy> <reason>

Contents
1. Introduction.......................................................................................................................................3
Awash bank QA strategic and plan

1.1 Overview....................................................................................................................................3
1.2 Scope of The Test Plan............................................................................................................3
1.3 Assumptions, Dependencies and Constraints.......................................................................3
2. User Acceptance Testing Objective...............................................................................................4
3. Scope for User Acceptance Testing................................................................................................4
3.1 Areas and Features to be tested............................................................................................4
3.2 In Scope......................................................................................................................................4
3.3 Out of Scope..............................................................................................................................5
4. Testing Methodologies.....................................................................................................................5
4.1 Acceptance Testing Approach.................................................................................................5
4.2 Measures and Metrics...............................................................................................................6
4.3 Entry Criteria for UAT.............................................................................................................7
4.4 Defect Severity and Priority Definitions...............................................................................8
4.5 User Acceptance Testing Exit Criteria..................................................................................9
5. Testing related activities Schedule.............................................................................................10
6. Environment and Resource Needs................................................................................................10
6.1 Testing Tool.............................................................................................................................11
7. Personnel.........................................................................................................................................12
8. Hardware Requirements................................................................................................................12
9. Software Requirements.................................................................................................................12
10. Test Environments......................................................................................................................12
11. Communication Approach.........................................................................................................12
11.1 Bug Reporting and tracking...................................................................................................13
11.2 Meetings...................................................................................................................................13
11.3 Reports.....................................................................................................................................13
12. Deliverables.................................................................................................................................13
12.1 Critical Success Factors..............................................................................................................14
13. Appendix A: Test Strategy and Plan Approval.......................................................................15
Appendix B: References.........................................................................................................................15
Awash bank QA strategic and plan

1. Introduction

1.1 Overview

This is the Test Plan document for [Project Name.]. This document shall be
completed and used by the project test team to guide how testing will be managed
for this project. The test effort will be prioritized and executed based on the
project priorities as defined in the Project Plan and Requirements Specification. This
is a living document that may be refined as the project progresses. The QA Lead/,
Test Team Lead, Functional and technical team leads, and Project Manager, etc.
shall review and approve the final version of the Test Strategy document.

1.2 Scope of The Test Plan

The Test plan applies to the UAT phase of the project. It primarily outlines the
testing objectives, approaches, resources, and schedules.

1.3 Assumptions, Dependencies and Constraints

 Resources must be assigned full time to the test team in order to carry out
the intended test cycles.
 Resources other than the Test team will be the Development Staff, Product
manager, Research and additional testers if available from other areas within
the company.
 Institutionalized knowledge of the XXXX application by some test team
members is critical for successful testing.

2. User Acceptance Testing Objective

Some objectives of the UAT testing of Project Name.] could be
 Ensure the Application Under Test conforms to functional and nonfunctional
requirements
 Ensure the AUT meets the quality specifications defined by the client
 Bugs/issues are identified and fixed before go live

3. Scope for User Acceptance Testing

The scope for User Acceptance Testing (UAT) outlines the boundaries and extent of
testing activities that will be conducted during this crucial phase of the project. It
delineates what aspects of the application will be subjected to testing and what will
be excluded

The scope of the test covers the functional and nonfunctional tests for Project
Name.]. The test levels which will be used in the testing are system integration and
user acceptance manual tests. From the technical perspective, the test areas which
Awash bank QA strategic and plan

will be employed in the test are validation, error handling, security, user interface,
report layout, screen layout tests and from the functional perspectives the below
areas and Features will be tested.

3.1 Areas and Features to be tested

In this section, we outline the specific areas and features that will be subjected to
testing during the User Acceptance Testing (UAT) phase. The scope of testing
encompasses various functional and non-functional aspects of the project.

3.2 In Scope

The following table provides an overview of the features and areas that are included
in the scope of UAT. Each feature is categorized by priority (High, Medium, or Low)
and marked as either "Yes" (in scope for testing) or "No" (out of scope for testing).
Comments may be added for further clarification.

Sr. Feature Priority Tested (Yes / No) Comments

1 Feature 1 High Yes

2 Feature 2 Medium Yes

3 Feature 3 Medium Yes

4 Feature 4 High Yes

5 Feature 5 Low No Out of scope

3.3 Out of Scope

Defining the out-of-scope areas is essential for clarifying the boundaries of our QA
efforts. This ensures that resources and efforts are channeled effectively, and
responsibilities for different aspects of the project are appropriately assigned to the
relevant teams and stakeholders.
[Out of Scope defines the features, functional or non-functional requirements of the
software that will NOT be tested]
Awash bank QA strategic and plan

4. Testing Methodologies

4.1 Acceptance Testing Approach

The User Acceptance Testing (UAT) phase is a critical milestone in our project.
During this phase, different functional and non-functional units will be responsible
for conducting acceptance testing based on the specific requirements and test cases
aligned with their respective areas of expertise. The following outlines our approach
to conducting UAT:

 Functional Testing: Functional teams will focus on ensuring that the

application under test (AUT) conforms to the functional requirements
outlined in the project documentation. This includes validating that the
software performs the intended tasks accurately and efficiently.
 Non-Functional Testing: Non-functional teams will assess the non-
functional aspects of the AUT, such as usability, performance,
accessibility, and security. These assessments ensure that the
application meets quality specifications and provides an optimal user
experience.
 Test Case Development: The testing team will begin by writing test
cases using the provided template. These test cases will be
comprehensive, covering various scenarios to validate the functionality
and non-functional aspects of the AUT.
 Test Case Verification: Each test case will undergo verification by the
assigned QA member. This verification process ensures that test cases
are clear, complete, and aligned with the project requirements.
 Test Case Registration: Once verified, the test cases will be registered
in our Test Management System. This central repository will be used to
track and manage all test-related activities, including test execution,
defect reporting, and test results.

4.2 Measures and Metrics

Awash bank QA strategic and plan

To assess the progress and effectiveness of our testing efforts, we will employ the
following measures and metrics:

Test Execution and Progress

 Number of Tests Cases Executed vs. Test Cases Planned: This metric
tracks the progress of test case execution compared to the planned test
cases. It provides insight into the testing team's efficiency in
completing test scenarios.
 Number of Test Cases Passed, Failed, and Blocked: Monitoring the
number of test cases in each category (passed, failed, blocked) helps us
understand the overall health of the testing phase and identifies areas
that require attention.
 Total Number of Test Cases Passed by Test Item / Test Requirements:
This metric provides a granular view of which specific test items or
requirements have been successfully validated.
 Total Time Spent on Execution vs. Planned Time: Tracking the time
spent on test execution compared to the planned schedule ensures that
testing remains on track and within the allocated timeline.

Bug Analysis

 Total Number of Bugs Raised and Closed per Test Run: This metric
measures the number of defects identified during testing and tracks
how many of them have been successfully resolved and closed.
 Total Number of Bugs Closed vs. Total Number of Bugs Reopened: It is
important to monitor how many closed bugs are subsequently reopened.
This indicates the stability of the application and the effectiveness of
defect resolution.
 Bug Distribution Totals by Severity per Test Run: Categorizing bugs by
severity (e.g., critical, high, medium, low) helps prioritize their
resolution and assesses the impact on the application.
 Bug Distribution Totals by Test Item by Severity per Test Run: This
metric provides a detailed breakdown of where defects are
concentrated, allowing targeted testing efforts and focused resolution.
 These metrics will serve as key indicators of our progress throughout
the UAT phase, enabling us to make informed decisions, allocate
resources effectively, and ensure the successful delivery of a high-
quality product.

4.3 Entry Criteria for UAT

 Before commencing the User Acceptance Testing phase, certain entry

criteria must be met to ensure a productive and efficient testing
process. These criteria include:
 Complete Requirements: All project requirements, including functional
and non-functional specifications, must be fully documented and
Awash bank QA strategic and plan

approved. Any ambiguities or gaps in requirements should be addressed

before UAT begins.
 Complete Test Scripts: Test scripts for both functional and non-
functional test cases should be created and reviewed for accuracy and
completeness.
 Basic Functionality/Modules Deployed: The application's basic
functionality and modules must be deployed in the test environment,
ensuring that testers have access to a representative version of the
software.
 Test Cases Registered in the Test Management System: All test
cases, including those for functional and non-functional requirements,
should be registered and organized in the Test Management System for
efficient test execution and tracking.
 Quick and Accurate Defect Resolution: A mechanism for logging,
tracking, and promptly resolving defects identified during testing
should be in place. This ensures that any issues can be addressed in a
timely manner.
 Availability of Resources: Adequate resources, including testing
environments, hardware, software, and personnel, should be available
as per the defined project schedule.

Meeting these entry criteria is essential to initiate UAT effectively and

ensure that testing activities progress smoothly.

4.4 Defect Severity and Priority Definitions

In the course of UAT, defects may be identified. To facilitate effective

communication and prioritization, we use the following definitions for
defect severity and priority:

Severity

1 – Critical: Defects categorized as critical render the application,

system, or business procedure non-functional, with no workarounds
available. These issues prevent further testing and are considered
must-fix items for "go-live."

2 – High: High-severity defects indicate that the application, system, or

procedure is unusable, with potential workarounds that are considered
Awash bank QA strategic and plan

unacceptable. While they impact functionality, they allow testing to

continue in other areas. High-severity issues are also considered must-
fix items for "go-live."

3 – Medium: Medium-severity defects denote that a portion of the

application, system, or procedure does not function correctly.
Workarounds are possible and have been deemed suitable. While they
impact testing, they do not hinder "go-live" and may be reviewed for
fixing in the current version.

4 – Low: Low-severity defects refer to minor cosmetic faults within the

application, system, or procedure that do not require workarounds.
These issues have no impact on testing or functionality and may be
addressed as enhancement requests for the current or future versions.

Priority

Priority 1: Indicates defects that require immediate attention and

resolution. These defects significantly affect the application's
functionality or usability and must be addressed promptly.

Priority 2: Represents defects that are important but do not require

immediate resolution. These issues should be fixed as part of the
normal development cycle.

Priority 3: Denotes defects that are minor or cosmetic in nature. They

have minimal impact on functionality or usability and may be addressed
in a future release.

By defining severity and priority levels, we can efficiently prioritize and

address defects, ensuring that critical issues are resolved promptly
while non-critical ones are appropriately managed.

4.5 User Acceptance Testing Exit Criteria

To determine when User Acceptance Testing is complete, the following exit criteria
have been established. These criteria pave the way for the preparation of "go-live":

 Completion of All Planned Testing Activities: All testing activities, including

functional and non-functional tests, must be completed to agreed-upon levels,
achieving 100% coverage of planned test scenarios.
 Pass Rate for UAT Items: A specified percentage of test items, categorized by
severity (e.g., High and Critical items, Medium and Low priority items), must
achieve a pass status.
 Identification of Unexecuted Planned Tests: Any planned tests that remain
unexecuted must be identified and documented, along with reasons for non-
execution.
Awash bank QA strategic and plan

 No Outstanding Assigned, Acknowledged, Feedback, or Resolved Items: All

assigned, acknowledged, feedback, and resolved items should be reviewed and
documented, with none remaining in an open or unresolved status.
 Review and Acceptance of Test Completion Report: The Test Completion
Report, along with test results, must be reviewed and accepted by the Project
Manager, who will provide sign-off.
 Completion of the Test Summary Report: A comprehensive Test Summary
Report summarizing the testing phase, including results, issues, and overall
readiness for production, will be completed.
 Resolution of High-Priority Bugs: All high-priority bugs must be fixed,
retested, and successfully passed, ensuring that no critical issues remain
unresolved.
 Absence of Open Defects: No defects should be left in an open and unresolved
status, indicating that all identified issues have been addressed.

These exit criteria serve as a clear indicator that UAT has been
successfully executed, all critical testing activities have been
completed, and the application is prepared for the "go-live" phase.

5. Testing related activities Schedule

Testing Activity Schedule:

Sr Project Milestone Scheduled Actual Commen

. Date Date t

1 Development of Test Plan

2 Design and development of UAT Test

Cases
Awash bank QA strategic and plan

3 Registration of Test Cases in Test link

4 Execution of Test Cases

5 Reporting of Problems

6 Developing Test Summary Report

7 Documenting Test Summary Report

6. Environment and Resource Needs

The following detail the environmental and resource needs required for the testing
of the application.

6.1 Testing Tool

S
. Tool
r Category Tool Responsibility and Ownership Url

1 Test TestLink Test case management, http://10.10.12.170:81/testlink/

Management execution, test planning. index.php
(Ownership: QA Lead/Test
Awash bank QA strategic and plan

Lead)

2 Managing and organizing

project documentation.
Document SharePoin (Ownership: Documentation https://portal.awashbank.com/
Management t Specialist) SitePages/Home.aspx

3 Creating and running

performance tests.
Performance (Ownership: Performance
Testing JMeter Tester) In progress

4 Recording, tracking, and

managing software defects. http://10.10.12.170:90/mantis/
(Ownership: QA Lead/Team login_page.php?return=%2Fmantis
Bug Tracking Mantis Lead) %2Fmy_view_page.php

7. Personnel
Describe the number of people needed, their roles and responsibilities and what skill
sets are required. If training is needed for them, then the resources needed to train
them should be mentioned here. Details of time requirements to be mentioned
under section ‘Detailed Testing Schedule’

8. Hardware Requirements
Describe the number of workstations needed for the testing team and their
configurations.
Awash bank QA strategic and plan

9. Software Requirements
Describe the operating systems needed for workstations and other generic software
like MS word etc excluding the testing tools software which will be mentioned in the
next section.

It mentions the minimum Software requirements that will be used to test the
Application. Following software is required in addition to client-specific software.

Windows 8 and above

Office 2013 and above

MS Exchange, etc.

10.Test Environments
Describe the environment configuration in which product will be installed and how
many such instances are needed for testing. Most products need Database and
Application servers. Their hardware and software configurations need to be
mentioned here. How many product instances will be maintained and which instance
will be used for what, need to be mentioned here. For example, one instance can be
used for testing, another instance can be maintained to check bug fixes before
applying it on the testing instance.

11.Communication Approach
Describe how the testing team will report the bugs to the development, how it will
report the testing progress to management, how it will report issues and concerns to
higher ups.

11.1 Bug Reporting and tracking

Describe how bugs will be reported to development and how they will be tracked to
closure.
Awash bank QA strategic and plan

11.2 Meetings

Describe what type of meetings will be held, their purpose, their participants, their
schedule and their expected duration.

11.3 Reports

Describe what types of reports will be generated, their content, their purpose and to
whom they are intended to and whether they will be generated daily or weekly etc.

12.Deliverables
Here mention all the Test Artifacts that will be delivered during different phases of
the testing lifecycle. Here are the sample deliverables
This acceptance criterion for the testing task deliverables will be measured by the
completion and sign-off of each deliverable which has been listed. Deliverables for
test scripts and test results will be subject to quality reviews.

 Test Strategy and Test Plan

 Test Cases
 Bug Reports
 Test Metrics
 UAT Sign Off

12.1 Critical Success Factors

Critical Success Factors
The success of our Quality Assurance (QA) efforts depends on various factors that
must be diligently managed throughout the project lifecycle. These critical success
factors are pivotal in ensuring the quality and effectiveness of our QA process:
Awash bank QA strategic and plan

Clear Requirements this Responsible for Business Analysts, Requirements

Engineers
Adequate Resources This Responsible for Project Manager, QA Lead
Effective Communication This Responsible for Project Manager, QA Lead
Test Automation Strategy This Responsible for Automation Engineers, QA Lead
Comprehensive Test Data This Responsible for Data Analysts, QA Team
Efficient Defect Management This Responsible for QA Lead, Test Team
Members
Adherence to Standards This Responsible for QA Lead, Test Team Members
Continuous Improvement This Responsible for QA Lead, Project Manager
Client Collaboration This Responsible for Project Manager, Business and
technical TEAM LEAD

13.Appendix A: Test Strategy and Plan Approval

The undersigned acknowledge they have reviewed the <Project Name> Test Strategy
Document and agree with the approach it presents. Changes to this Project Quality
Assurance Plan will be coordinated with and approved by the undersigned or their
designated representatives.
Awash bank QA strategic and plan

Approved By Signature Date

Appendix B: References

The following table summarizes the documents referenced in this document.

Appendix 1: Test Cases Templates

Appendix 2: Mantis + Test link

Document Name Description Location

<Document Name and [Provide description of <URL or Network path where

Version Number> the document] document is located>

BRD Business Requirement Share Point

Document

Appendix C: Key Terms

The following table provides definitions for terms relevant to this document.
Awash bank QA strategic and plan

Term Definition

AU Application Under
T Test

UA User Acceptance Test

T

QA Quality Assurance