Test strategy

Project name
Project number (PN) Project manager name

Date
Version number Status

Document ID: <Document ID> Project ID: <Project Name>

Table of contents
2. Test scope and objectives 3. Testing approach 4. Test activities and deliverables 5. Test organisation and resourcing 6. Communications approach 7. Test environment, infrastructure and tools 8. Schedule 9. Assumptions, constraints and dependencies 10. Issues and risks 4 5 6 7 8 9 10 11 12

Overview

Using this template If you are using a solution development methodology (for example, Adaptive ESP, Six Sigma) in parallel with Knight Errant Projects, you may use the template from your solution development methodology instead of this template. If your project comprises multiple streams/sub-projects, each using a different solution development methodology, you may use this template to summarise/consolidate the information from the various streams/sub-projects.

1.1 Document purpose

This document outlines the high-level test strategy for the project. The test strategy provides the framework for estimating the duration and cost of the total test effort and the scope and objectives on which these estimates are based. Note that the test strategy is a planning tool not a living document; it will provide the starting point for test planning. Following completion and sign-off of the Test Strategy, any changes to, risks, issues, resource needs, etc, should be managed through the standard planning and tracking processes.

The purpose of this document is to outline the high-level test strategy for the <project name> project, defining the preliminary test scope, high-level test activities, and organisation, together with test management for the project. The test strategy provides the framework for estimating the duration and cost of the testing effort at the required confidence level for the business case. This test strategy is a planning tool that will provide the starting point for detailed test planning during the Execute stage.

1.2 Definitions
Include the definitions of any terms used in this document that do not appear in the project methodology glossary.

The following terminology is introduced in this document: Abbreviation / term Definition

test_strategy.doc Version <V#> dated <version date>

Page 2 of 13

Document ID: <Document ID> Project ID: <Project Name>

Abbreviation / term

Definition

1.3 Referenced documents

Provide a list of documents referenced in this document or provided input into this document. Identify each document by title, report number if applicable, date, and publishing organisation. Specify the sources from which the references can be obtained.

The following documents are referenced in this strategy: Document reference <details here> Version Date File location

test_strategy.doc Version <V#> dated <version date>

Page 3 of 13

Document ID: <Document ID> Project ID: <Project Name>

2. Test scope and objectives

2.1 Overview of solution to be implemented
Include an overview of the future operational environment and the components of the future operational environment that will be tested. This is documented in detail in the Future operational environment template, therefore provide summary level information here and refer to the future operational environment document for your project.

<text here>

2.2 In scope
The scope of the testing must describe all aspects of the project deliverables that are in scope for the test effort. This may include new and/or changed business processes, technology components, training materials and learning aids, user documentation and so on. It is important at this stage of the project also to identify the boundaries of the testing as they relate to the affected business and system processes.

<text here>

2.3 Out of scope

List the areas of business and systems, processes and activities that have been excluded from the testing effort.

<text here>

2.4 Testing objectives

List the high-level test objectives that are major items to be proven as an outcome of the testing. If different types of testing are to be conducted then list the objectives for each of the different types of testing.

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 4 of 13

Document ID: <Document ID> Project ID: <Project Name>

3. Testing approach
Using the solution development methodology and lifecycle selected earlier determine the approach to testing, including the approach to: Solution testing, which tests that the solution has been verified prior to user acceptance testing.. For example: o For a process improvement project, solution testing may include desk checks and walk throughs of the improved processes o For a technology project, solution testing may include system testing, system integration testing and performance testing. User acceptance testing, which proves that the solution meets the business requirements so that the users can accept the solution. For example: o For a process improvement project, user acceptance testing may include process simulation o For a technology project, user acceptance testing may include Business process simulation, end to end testing, functional testing and usability testing. In planning the testing approach include the components of the future operational environment that will need to be tested. For example: Business processes, controls and templates - desk top reviews, useability testing Training procedures and training aids - review and testing in a controlled environment by an external organisation that specialises in training The whole solution (eg building infrastructure project) - compliance testing and certification by an external/regulatory body at various stages of the project eg OH&S, electrical compliance plumbing etc Technology solutions - unit, system, integration, end-to-end, user acceptance, customer acceptance, interface testing Other tests activities such as stress and volume, performance, useability testing, external customer acceptance testing (via focus groups), compliance testing (SOX, Basel)

3.1 Solution testing

<text here>

3.2 User acceptance testing

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 5 of 13

Document ID: <Document ID> Project ID: <Project Name>

4. Test activities and deliverables

Describe all planned test activities that are to be carried out by the project to support the chosen testing approach. For example: Set-up of test environment Set-up of test data Perform testing Monitoring and collating results Initiating rework Obtaining user acceptance. List all the artefacts that shall be delivered from testing by the project. These tables below list some sample items that should be delivered as part of testing. Remove or add deliverables as required for the type of testing to be executed. Describe the documentation structure in terms of the testing organisation i.e. the specific deliverables for each application or team.

4.1 Solution testing

High level test activities
Preparation Preparation Recording results

Deliverables
Test management plan Test case plan Test observation reports

Responsibility
Project manager Test manager Test manager

<text here>

4.2 UAT (User acceptance testing)

High level test activities
Preparation Preparation Recording results

Deliverables
Test management plan Test case plan Test observation reports

Responsibility
Project manager Test manager Test manager

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 6 of 13

Document ID: <Document ID> Project ID: <Project Name>

5. Test organisation and resourcing

5.1 Structure
Describe the test organisation. Include all participating teams as well as other organisational groups that have a role in the planning and execution of testing or may have an approval role.

<text here>

5.2 People requirements

List the roles depicted in the test organisation by business area. Include how the role will be resourced (eg resourced internally or via external supplier) and the number of resources required. Provide estimated resource assignment duration for each phase and each application, ensure that all aspects of testing are covered eg Test management, Test planning, Test design, Test data set-up, Test execution, Test execution support, Test environment development and Test environment support. Identify any third party resource requirements to ensure all resource costs are identified.

<text here> Business unit

<Business unit name> <role>

Role

Internal / external supplier

<resourced internally or external supplier name>

Number of resources required

<number of FTE resources required for this role>

Duration of assignment
<elapsed days assigned to project>

<Business unit name> <Business unit name> <Business unit name> Technology Finance Risk

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 7 of 13

Document ID: <Document ID> Project ID: <Project Name>

6. Communications approach
Describe the mechanisms and forums to be used in communicating progress and resolving issues across all participating groups throughout the testing lifecycle. This may be a reference to an overall project communications plan if available. For technology components, the applicable solution development methodology and lifecycle may include a test observations management process that could be used.

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 8 of 13

Document ID: <Document ID> Project ID: <Project Name>

7. Test environment, infrastructure and tools

7.1 Facilities and infrastructure requirements
List the facilities and infrastructure and physical office space/room requirements for the conduct of the testing.

<text here>

7.2 Test environment and tools

For technology projects, identify requirements for the test environment, specialised test devices and tools. Describe at a high-level the target test environments for each of the test phases and for each application. Note that at this stage there may be insufficient detail to articulate precisely the technical test environment needs, but the objective of this section would be to identify significant new requirements to spin-off the necessary design and procurement activities, and to ensure that the associated costs are included in the business case. Cover specialised test devices and tools that require lead time to procure and commission. State any assumptions as to the availability of critical testing infrastructure, including assumed hours of operation and support.

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 9 of 13

Document ID: <Document ID> Project ID: <Project Name>

8. Schedule
8.1 High-level test schedule
Using the test approach, and activities and deliverables defined earlier, develop the high-level work plan covering all phases and applications, showing start and end date of all major test activities. Prepare a high-level test schedule, including key milestones, covering the test activities (planning, execution, documentation) and their dependencies and sequence. This provides background information for the approvers and the subsequent audience. Additionally, it provides the starting point to validate the projects timeline and ensure they are reasonable given the scope of testing. The schedule can be documented as a simple list of activities or milestones with corresponding dates, or can be presented as a high-level Gantt chart.

<text here> Test activity / milestone Start date End date

8.2 Schedule dependencies

Document any external dependencies the milestone schedule relies upon, For Example: Other projects delivery schedule Previous systems release completion Third party solution delivery

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 10 of 13

Document ID: <Document ID> Project ID: <Project Name>

9. Assumptions, constraints and dependencies

9.1 Assumptions
State any assumptions made in developing the test strategy, eg test resources will be provided in-house.

<text here>

9.2 Constraints
State any constraints of the test strategy, eg test resources must all be housed in the same physical location.

<text here>

9.3 Dependencies
Document any dependencies the test strategy relies upon eg re-use of the test infrastructure from another project

<text here>

test_strategy.doc Version <V#> dated <version date>

Page 11 of 13

Document ID: <Document ID> Project ID: <Project Name>

10. Issues and risks

10.1 Issues
List the key issues relating to the test strategy and the resolution plan for each. These issues should be documented in the project issue register. Include a reference to the project issue register. Refer to the Knight Errant Projects Manage issues process for more information about managing issues.

Issue description

Resolution plan

Project issue register reference

10.2 Risks
List the key risks relating to the test strategy and the risk rating and treatment plans for each. These risks should be documented in the project risk register. Include a reference to the project risk register. Refer to the Knight Errant Projects Manage risks process for more information about managing risks.

Risk description

Risk rating High Medium Low

Treatment plan

Project risk register reference

test_strategy.doc Version <V#> dated <version date>

Page 12 of 13

Document ID: <Document ID> Project ID: <Project Name>

Document control
If you have any queries regarding the information in this document, please forward details to: Contact point Title Phone Email <name> <title> <phone number> <email address>

Document history Date Version Author Comments

Distribution Version Date Issued Recipient(s)

Commitment / acceptance Title Business Unit Name Date Signature

test_strategy.doc Version <V#> dated <version date>

Page 13 of 13