Test Strategy Template

Test Strategy

<<Work request #>>

Author: Authorized By: Status: Owner: Version: Last Updated:

http://www.teststrategics.com/%00%E5%A1%B9%EF%92%81%E1%B4%BB%E4%A1%BF%E2%B2%AF%E5%B6%82%E8%97%84%E6%8C%A7%00%00%EA%AE%A5

<<Work Request>>Test Strategy

1. Amendment History

Version Date Created

Created/Amended By

Approved/ Reviewed By

Change Detail

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 of 21


Name Role Date Signature

3. Table of Contents

Release Notices.................................................................................................................................1

1. Amendment History................................................................................................................22. Distribution..............................................................................................................................23. Supporting Documentation & Reference..............................................................................24. Test Strategy Document Sign-Off.........................................................................................33. Table of Contents................................................................................................................... 3



5. Glossary of Terms..................................................................................................................56. Introduction.............................................................................................................................57. Test Approach.........................................................................................................................58. Test Techniques...................................................................................................................119. Test Objective and Coverage...............................................................................................1310. High Level Project Timeline.................................................................................................1511. Resources.............................................................................................................................1712. Test Environment................................................................................................................. 1913. Configuration Management.................................................................................................2014. Incident Management...........................................................................................................2015. Test Status Reporting...........................................................................................................2316. Issues & Risks...................................................................................................................... 2317. Communications...................................................................................................................2318. Roles and Responsibilities..................................................................................................2419. Appendix.................................................................................................................................26



5. Glossary of Terms

Acronym/Abbreviation

Description/Definition

6. Introduction

7. Test Approach

TEST FRAMWORKTesting 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.



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’sAccountable - Development ManagerResponsible – DevelopersDeliverables – 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 ManagerResponsible – DevelopersDeliverables – 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



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 LeadResponsible – Test Analyst and Business AnalystDeliverables – Test Criteria, Sign off and ExecutionNote: 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 LeadResponsible – 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.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 LeadResponsible – DeveloperDeliverables – 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 LeadResponsible – 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.

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>>

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 StrategyEffort required in

days To be commenced To be completed

Test Strategy

Non Functional System TestingEffort required in


Non Functional System Test Plan<<work request>> Test Strategy – not ready for release

of 21


Test Criteria Document

Non Functional Test execution

Smoke TestingEffort required in


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 TestingEffort required in


Functional System Test Plan

Test Scenario Matrix

Test Scripts

Functional Test Execution

Business Acceptance TestingEffort required in




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

Test Execution

Resource skill for Execution No. Required Date Required StatusTest LeadCode Integration Testing


Resource skill for Preparation No. Required Required StatusTest LeadCode Integration TestingDevelopers Test Analyst Smoke TestingBusiness AnalystTest AnalystDevelopersFunctional TestingTest AnalystsBusiness AnalystsNon Functional TestingDeveloperTest AnalystBusiness Acceptance TestingBusiness AnalystUsers


Developers Test Analyst Smoke TestingBusiness AnalystTest AnalystDevelopersFunctional TestingTest AnalystsBusiness AnalystsDevelopersNon Functional TestingDeveloperBusiness AnalystTest AnalystBusiness Acceptance TestingBusiness AnalystTest AnalystDeveloperUsers

Hardware Required

Software Required

Browsers

Vist

a

Win

dow

s O

ffice

Mac

into

sh

LAN

Co

nnec

tion

ADSL

Co

nnec

tion

Dia

lup

Conn

ecti

on56

.6K

Scre

en

Reso

luti

on

1024

x 7

68



11. Test Environment

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

Test Phase<<work request>>

Unit Test ExecutionCode Integration Test ExecutionFunctional (E2E) System Test Execution inc. regressionNon Functional System Testing ExecutionBusiness Acceptance Testing Execution

12.Configuration Management

13. Incident Management



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 DefinitionThe following table provides a guideline for classification of incidents found during the course of testing.

SEVERITY 1

Syst

em fa

ilure

The application or an essential part of it is totally unavailable (major system 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 fixing the problem. It is expected that the problem will be rectified within 24 hours.

SEVERITY 2

Func

tion

failu

re

The application or an essential part of it is not working or is working with 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 fixing the problem. It is expected that the problem will be rectified within 2 days.

SEVERITY 3

Req

uire

men

t fa

ilure

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 fixing the problem. It is expected that the problem will be rectified within 5 days.



SEVERITY 4M

inor

di

scre

panc

y

A minor problem exists in the application, no effect on the business.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


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 meetingsMeeting Objective

Attendees

FrequencyDurationAgenda

Meeting Name Cross Project DependenciesMeeting Objective

An opportunity for all test leads to get together to communicate AttendeesFrequencyDuration


Agenda

17.Roles and Responsibilities

Role ResponsibilityTest Manager Escalation point for Test Lead

Provide Sign off of test strategy and planTest 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. Communicate issues and risks to the Test Lead. Support BAT environment and lab during BAT phase.

T Project Manager

Log any testing issues into the Project Issues/Risks register log. 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 Manager

Ensure Unit Testing is undertaken and the results formally 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.



18.Appendix


Test Strategy Template

Documents

Transcript of Test Strategy Template