Test Strategy

<<Work request #>>

Author:
Authorized By:
Status:
Owner:
Version:
Last Updated:
 <<Work Request>>
Test Strategy
1. Amendment History

Version Date Created/ Approved/ Change Detail

Created Amended By Reviewed By

2. Distribution

Recipient Role/Team

3. Supporting Documentation & Reference

Reference Name Author Date Version

4. Test Strategy Document Sign-Off

<<work request>> Test Strategy – not ready for release

Page 2 of 21
 <<Work Request>>
Test Strategy
Name Role Date Signature

3. Table of Contents

1. Amendment History......................................................................................................................2
2. Distribution....................................................................................................................................2
3. Supporting Documentation & Reference....................................................................................2
4. Test Strategy Document Sign-Off................................................................................................2
3. Table of Contents....................................................................................................................3
5. Glossary of Terms.........................................................................................................................5
6. Introduction....................................................................................................................................5

<<work request>> Test Strategy – not ready for release

Page 3 of 21
 <<Work Request>>
Test Strategy
7. Test Approach ..............................................................................................................................5
8. Test Objective and Coverage.......................................................................................................9
9. High Level Project Timeline .....................................................................................................10
10. Resources ................................................................................................................................12
11. Test Environment ....................................................................................................................14
12. Configuration Management......................................................................................................14
13. Incident Management ..............................................................................................................14
14. Test Status Reporting...............................................................................................................17
15. Issues & Risks .........................................................................................................................17
16. Communications.......................................................................................................................17
17. Roles and Responsibilities ....................................................................................................18
18. Appendix ..................................................................................................................................20

<<work request>> Test Strategy – not ready for release

Page 4 of 21
 <<Work Request>>
Test Strategy

5. Glossary of Terms

Acronym/Abbrevia Description/Definition
tion

6. Introduction

7. Test Approach
TEST FRAMWORK
Testing of project <<work request>> will following the <<company name>> testing framework
outlined below. The detailed test approach for this project will be identified and documented in the
Details test plan.

<<work request>> Test Strategy – not ready for release

Page 5 of 21
 <<Work Request>>
Test Strategy

TEST MODELS

Test Types

Below are the types of testing cycles required to verify the performance of the product

 Unit Testing
Unit testing is a test that validates that individual units of code are working as planned. The goal
of unit testing is to isolate each part of the program and show that the individual parts are
correct. This test will be conducted by the developer on their individual machines and will test
individual components of given IT deliverables. Upon completion of the unit test the
Development manager will provide the IT test team with the unit test results.
Approach – This testing will be completed during development on development PC’s
Accountable - Development Manager
Responsible – Developers
Deliverables – Execution

 Code Integration Testing

Code Integration testing is a test where individual software modules are combined and tested as
a group. The overall idea is a "building block" approach, in which verified assemblages are
added to a verified base which is then used to support the integration testing of further
assemblages.
Approach – Code Integration testing will be completed after development of each requirement.
When the requirements have been developed and tested they will be released to the test team
to commence functional testing. It is a possibility parallel development and functional testing
may be needed. This will be identified upon completion of the work break down structure
Accountable - Development Manager
Responsible – Developers
Deliverables – Test Plan, Test Criteria, Test Status reporting, Sign off and Execution
Note: Sign off will be provided by Development Manager with the CIT exit criteria to be met.

• Smoke Testing

<<work request>> Test Strategy – not ready for release

Page 6 of 21
 <<Work Request>>
Test Strategy
A smoke test is a validation test performed by the business analyst and test analyst after code
integration testing but before functional system testing and then again after functional system
testing but before business acceptance testing. This test provides the business analyst and test
analysts with the ability to review the developed solution before the next phase of
comprehensive testing commences.
Approach – This testing is executed after all development has been completed, the smoke
testing will be executed after code integration testing but before functional testing. The smoke
testing will need to be executed on each requirement when made available for functional testing.
This test is to be completed prior to functional testing of the requirements commence.
Accountable – Test Lead
Responsible – Test Analyst and Business Analyst
Deliverables – Test Criteria, Sign off and Execution
Note: Sign off will be provided by the Test Lead.

• Functional System Testing including E2E

Functional system testing will be conducted by a Test Analyst. Functional system testing will be
based on the signed off version of the Functional Specification Document. This phase of testing
is to ensure the functions of the developed <<work request>> solution are as per the FSD.
A key focus of this phase is the end-to-end (E2E) and regression testing which provides a full
examination of the system under test. This is generally undertaken prior to the BAT phase to
ensure the majority of key defects have been adequately resolved and the system stabilised.
Accountable – Test Lead
Responsible – Test Analyst
Deliverables – Test Plan, Test Matrix, Test Scripts, Test Status reporting, Sign off and
Execution
Note: Sign off will be provided by the Test Lead.

• Non Functional System Testing

Performance testing is the process of determining the speed or effectiveness of the ING DIRECT
applications (eg. web and middleware) and is executed by a developer. This test involves
measuring the response time even the number of instructions per second at which the
application functions.
Load/Stress testing is the process of subjecting ING DIRECT applications to their breaking point,
testing beyond the normal operational capacity and is executed by a developer.

<<work request>> Test Strategy – not ready for release

Page 7 of 21
 <<Work Request>>
Test Strategy
Security Testing will verify the security of the application, looking at the external interfaces as
well as the internal interfaces. The ability to disrupt services, perform fraudulent transactions or
intercept private information will be tested. This testing is executed by the security team and/or
an external ethical hack vendor.
Accountable – Test Lead
Responsible – Developer
Deliverables – Test Plan, Test Criteria, Test Status reporting, Sign off and Execution
Note: Sign off will be provided by the Test Lead and the Development Manager.

• Business Acceptance Testing

BAT is executed formally by business users and/or Business Analyst acting as a proxy of the
business user performing business operational testing to enable them to determine whether to
accept a system based on the Business Requirements document.
Accountable – Test Lead
Responsible – Business users and/or business analyst (still to be decided)
Deliverables – Test Plan, Test Criteria, Test Status reporting, Sign off and Execution
Note: Sign off will be provided by the Test Lead and the Business.

Entry and Exit Criteria

The entrance and exit criteria specified by the Test Lead should be fulfilled prior to commencing the
particular testing phase. In the event, that any criterion has not been achieved, the testing may
commence if the steering committee and test lead are in full agreement that the risk is manageable.

In the event that the testing is suspended, a resumption criterion will be specified and testing will not
re-commence until the software reaches this criteria.

The exit, entry and resumption criteria for each phase of testing will be outlined in the detailed test
plans.

<<work request>> Test Strategy – not ready for release

Page 8 of 21
 <<Work Request>>
Test Strategy
Upon entry into a phase of testing a testing certificate will be released to all business and IT
stakeholders advising that testing has formally commenced. This certificate will be sent by email and
will contain the entry information that has been satisfied.

8. Test Objective and Coverage

The objective of testing the <<work request>> solution is to ensure each element of the application
integrates and meets the functional, design and business requirements:

Note: testing will cover positive, negative and regression

• To identify defects and issues in the functionality and impacted systems that will adversely
affect the <<work request>> project
• To assist in the repair and mitigation of issues and defects by reporting them in a timely and
accurate and retesting when fixed
• To verify and validate that deliverables behave according to stated objectives
• To verify the quality of the release against the functional and business requirements
• Ensure impacted system components and business processes are regressed and work end-to-
end
• Report to Management and Stakeholders the status of testing during the execution phase
• Guide and assist stakeholders in performing the Business Acceptance Testing so they are able to
accept the release with an appropriate degree of confidence
• Ensure a managed and coordinated testing effort across the <<work request>>
• Verify the changes are accurately reported on

Business Requirements <<work

request>>

<<work request>> Test Strategy – not ready for release

Page 9 of 21
 <<Work Request>>
Test Strategy
No. Name

This table provides a visual of the applications, systems and services that will be used to test and will
be tested by the <<work request>>.

9. High Level Project Timeline

The project time line for project <<work request>> can be found in the project folder:

The following tables outline the high level effort estimates from IT and business that will be required for
each test deliverable including the execution of these phases. The estimates given are in days and will
be spread across working days Monday to Friday.

The main purpose for the business effort during test planning and preparation is to review and feed into
the test documentation deliverables. During execution they will be required to prepare and perform
Business Acceptance Testing.

Please note that the following estimates are high level and are based on the Business Requirements
Document. Upon completion of the FSD the testing effort will be re-estimated and distributed.
Note:

Test Strategy
Effort required in
To be commenced To be completed
days
Test Strategy
<<work request>> Test Strategy – not ready for release
Page 10 of 21
 <<Work Request>>
Test Strategy

Non Functional System Testing

Effort required in
To be commenced To be completed
days
Non Functional System Test Plan

Test Criteria Document

Non Functional Test execution

Smoke Testing
Effort required in
To be commenced To be completed
days
Smoke Test Criteria to move to Functional Testing

Smoke Test Execution to move to Functional Testing

Smoke Test Criteria to move to BAT

Smoke Test Execution to move to Functional BAT

Functional System Testing

Effort required in
To be commenced To be completed
days
Functional System Test Plan

Test Scenario Matrix

Test Scripts

Functional Test Execution

Business Acceptance Testing

Effort required in
To be commenced To be completed
days

<<work request>> Test Strategy – not ready for release

Page 11 of 21
 <<Work Request>>
Test Strategy

10. Resources

Human

The following table outlines the Human resources that will be required for test preparation and
execution of the <<work request>> solution. The resources identified in this test strategy are at a high
level but will provide and initial view of what will be required.

Note: The date required is estimated and will most likely change, these date will be confirmed with in
the detailed test plan.

Test Preparation

Resource skill for Preparation No. Required Required Status

Test Lead
Code Integration Testing
Developers
Test Analyst
Smoke Testing
Business Analyst
Test Analyst
Developers
Functional Testing
Test Analysts
Business Analysts
Non Functional Testing
Developer
Test Analyst
Business Acceptance Testing
Business Analyst
Users
Test Execution

Resource skill for Execution No. Required Date Required Status

Test Lead
Code Integration Testing
Developers
Test Analyst
<<work request>> Test Strategy – not ready for release
Page 12 of 21
 <<Work Request>>
Test Strategy
Smoke Testing
Business Analyst
Test Analyst
Developers
Functional Testing
Test Analysts
Business Analysts
Developers
Non Functional Testing
Developer
Business Analyst
Test Analyst
Business Acceptance Testing
Business Analyst
Test Analyst
Developer
Users

Hardware Required

Software Required
ConnectionADSL

Connection

Resolution 1024
LAN Connection
Windows Office

Dialup
Macintosh

Screen

x 768
Vista

Browsers
56.6K

<<work request>> Test Strategy – not ready for release

Page 13 of 21
 <<Work Request>>
Test Strategy

11. Test Environment

The following table outlines the regions that will be utilised throughout testing of <<work request>>

Test Phase
<<work request>>
Unit Test Execution
Code Integration Test Execution
Functional (E2E) System Test Execution inc. regression
Non Functional System Testing Execution
Business Acceptance Testing Execution

12. Configuration Management

13. Incident Management

<<work request>> Test Strategy – not ready for release

Page 14 of 21
 <<Work Request>>
Test Strategy
This section identifies how the incidents will be documented and managed. It is the responsibility of
each phase of testing to assign their defects a severity.

Incidents will be classified according to a severity of 1-4 where 1 will be given the highest priority to
resolve and 4 will be given the lowest priority. Each phase of testing will be assigned an acceptable
number of incidents classified by Severity as Entry and Exit Criteria.

Generally an incident will be assigned a Severity according to guidelines set out in this document;
however, the working group will review the incidents on a regular basis to determine if a change in the
severity is needed.

All defects will be channeled through the Test Analyst and/or Test Lead as defect coordinator for
Functional, Non Functional and Business Acceptance Testing phases

Severity Definition
The following table provides a guideline for classification of incidents found during the course of testing.

The application or an essential part of it is totally unavailable (major system

System failure

failure) and is causing testing to stop pending problem resolution. No feasible

workaround is available for the problem.
Response should be given within 2 hours including an estimate of time for
SEVERITY 1
fixing the problem. It is expected that the problem will be rectified within 24
hours.

The application or an essential part of it is not working or is working with

Function failure

reduced or incorrect functionality; however it is not seriously impacting

testing because there is a feasible workaround.
Response should be given within 4 hours including an estimate of time for
SEVERITY 2
fixing the problem. It is expected that the problem will be rectified within 2
days.
Requirement

A non - essential function is not working or is working with reduced or

incorrect functionality. The business impact is small.
Response should be given within 12 hours including an estimate of time for
failure

SEVERITY 3 fixing the problem. It is expected that the problem will be rectified within 5
days.

<<work request>> Test Strategy – not ready for release

Page 15 of 21
 <<Work Request>>
Test Strategy

discrepancy
A minor problem exists in the application, no effect on the business.

Minor
SEVERITY 4 Response should be given within 24 hours including an estimate of time for
fixing the problem.

Defect Triage

A brief paragraph around how you intend to manage the flow of defects

<<work request>> Test Strategy – not ready for release

Page 16 of 21
 14. Test Status Reporting

What status reports will be generated

15. Issues & Risks

Any issues and risks identified during test planning and execution will be reported to the IT project
manager

Dependencies

Assumptions
•

16. Communications

Meeting Name IT <<work request>> Test Team meetings

Meeting Objective
•
Attendees
•
Frequency
Duration
Agenda
•

Meeting Name Cross Project Dependencies

Meeting Objective
• An opportunity for all test leads to get together to communicate
Attendees
Frequency
Duration
Agenda
•
 <<Work Request>>
Test Strategy

17. Roles and Responsibilities

Role Responsibility
Test Manager • Escalation point for Test Lead
• Provide Sign off of test strategy and plan
Test Lead • Accountable for follow-up on testing progress and status as well as
reporting on exit and entry criteria for Non Functional, Functional
and Business Acceptance testing
• Provide formal sign-off of Non Functional, Functional and Business
Acceptance Testing
• Creation of Test Plan for Non Functional, Functional and Business
Acceptance Testing
• Provide project with appropriate test resources
• Support responsible Business Analyst during BAT
• Raise testing issues which may affect delivery dates, quality, and
functionality deviations to ITPM and Test Manager.
• Report test execution progress during execution of Non functional,
Functional and Business Acceptance testing
• Escalation point for Test Analyst.
• Oversee the test planning and execution and ensure test procedures
are followed
• Assist with resolution of issues and risks during the testing lifecycle
• Test Lead is testing stakeholder and working group member

Test Analyst • Creation of Test Scenario Matrix and Scripts for Functional System
Testing
• Organise and complete a review of test scenarios and priorities with
business and project team
• Perform functional test execution
• Produce test data to be used for Functional System Testing
• Produce test results/evidence as specified in test scripts.
• Store test results/evidence for audit purposes.
• Contribute to the test status report
• Log and retest defects.
<<work request>> Test Strategy – not ready for release
Page 18 of 21
 <<Work Request>>
Test Strategy
• Communicate issues and risks to the Test Lead.
• Support BAT environment and lab during BAT phase.

T Project • Log any testing issues into the Project Issues/Risks register log.
Manager • Review Test Deliverables.
• Provide regular status reports on progress of testing to key IT and
business stakeholders.
• Sign Off all IT Deliverables.
• Sign off Production Readiness of all IT Deliverables.
• Sign off Production Implementation for all IT deliverables.
Developer • Ensure Unit Testing is undertaken and the results formally
Manager documented.
• Ensure Code Integration Testing is undertaken and the results
formally documented.
• Raise development issues which may affect delivery dates, quality,
and functionality deviations to the IT Project Manager.
• Ensure issues arising out of Non Functional, Functional System
Testing and BAT are corrected.
• Work with the Test Lead to have all defects resolved throughout all
phases of testing.
Business Analyst • Document all change requests raised by the Business.
• Review Test Deliverables.
• Prepare for and coordinate BAT (including the preparation of the BAT
test criteria).
• Validate incidents raised against the BRD and or FSD.
• Clarify issues with the business.
• Coordinate business users during BAT (If business users are
available).
• Assist Business Users with the creation of the test criteria document
• Plan, prepare and coordinate production verification
Developers • Plan and perform Unit, Code Integration and Non Functional Testing.
• Fix incidents and update Incident Management tool with resolution
details.
• Support the test lead and test analyst on a day to day basis during
the different phases of testing.

<<work request>> Test Strategy – not ready for release

Page 19 of 21
 <<Work Request>>
Test Strategy

18. Appendix

<<work request>> Test Strategy – not ready for release

Page 20 of 21