Test Plan Template

Application Test Strategy Template
ITA – Premium: Implement & Integrate

Introduction: How to Use This Template
An application test strategy is a crucial input into the testing effort for software implementation projects. A test
strategy is a document that defines the scope, approach, and schedule of the planned testing activities. It identifies,
at a high level, the items that require testing along with the resources who will execute the testing. For further
information on test planning, read the ITA Premium research note, “Five Fundamentals of a Successful Application
Test Strategy.”

The template contains six sections that should be updated with information applicable to the software being tested.
Complete the relevant sections:

1. Test Overview
2. Test Schedule
3. Test Resources
4. Test Environment
5. Defect Tracking
6. Test Metrics

1


Cover Sheet
Notes on Usage: In order to use this template effectively, overwrite text that is in italics and colored grey with the
enterprise’s own information.

Prepared for: Insert company name
Prepared by: Insert creator’s name
Insert address
Insert phone # and contact info

Date Created: Insert today’s date
Date Last Revised: Insert applicable date

2


1. Purpose
The purpose of the test strategy document is to inform project management and project sponsors of the approach
that will be taken with testing. This document strives to ensure that the budget, start up time, facilities, and
resources are anticipated and approved prior to the start of the testing phase.

Describe additional reasons for having a test strategy this section. The purpose should include project statements
or link s to other project documents like the charter. The testing effort should be described in the context of the
purpose of the overall project with link s to external information that not all people may be aware of.

2. Test Overview
2.1 Test Objectives
The following are the objectives of the test strategy document.

The test objectives should include information such as a summary of the products being tested, testing aims and
goals, high-level schedule, etc.
 Example: The overall test effort will commence on DD/MM/YYYY and will be executed for a period of X
months. The test effort is scheduled for completion on DD/MM/YYYY.
 Example: All high priority requirements must pass through 2 rounds of successful application testing prior
to sign-off.

2.2 Test Approach
The following specifies the testing phases that will be integrated in the overall testing effort and estimates the
required effort and duration for each.

Refer to ITA Premium research note, “Set Your Sights on the Six Software Testing Targets” to understand the six
types of testing recommended to achieve a high quality end product: Unit Testing, Functional Testing, System
Testing, Regression Testing, System Integration Testing, and Acceptance Testing.

 Example: The testing effort will involve six phases of testing to be executed in the following order: unit
testing, functional testing, system testing, regression testing, system integration testing, and acceptance
testing.
 Example: The unit test phase will commence on DD/MM/YYYY and will run for 4 week s throughout the
development effort.

3


2.3 Test Scope
The test strategy scope defines the high-level items that will be tested and also details items excluded from
testing. The scope should include applications and systems that are in scope and out of scope. If major functions
or process are known those should also be included.

Items included in test scope
 Example: Functional capabilities including: accounts receivable, accounts payable, contact management
 Example: Performance testing, load testing, data conversion testing

Items excluded from test scope
 Example: Functional capabilities including: service requests, sales force automation

4


3. Test Schedule
The test schedule outlines the dates during which each phase of testing is planned to take place. In addition, it
includes key milestones for each testing effort and specifies the milestone date.

3.1 Key Assumptions for Test Schedule

In this section, discuss points regarding how testing will be scheduled taking into consideration the way the project
is being run.
 For example, the project may involve multiple releases and the overall release testing schedule could be
included in this section.
 Alternately, the project may be using an iterative approach and it may be necessary to state that testing for
one iteration overlaps the requirements/design piece of the next iteration.

Table 1 describes the known start and end dates of the various phases of testing. It also includes key milestones
and their corresponding dates.

Table 1. Test Schedule
The test schedule should list all known dates for the various phases of testing. Maintain the overall test schedule
within the test strategy document as dates become available further into the project.

Test Phase Start Date End Date Duration Key Milestones Milestone Date
Example: DD/MM/YYYY DD/MM/YYYY 70 work days Complete Draft DD/MM/YYYY
Overall Test Test Plan
Effort Achieve Test DD/MM/YYYY
Plan Sign-off
from Project
Management
Example: Unit DD/MM/YYYY DD/MM/YYYY 15 work days Complete Unit DD/MM/YYYY
Testing Test Plan
Unit Test major DD/MM/YYYY
components
A,B, and C

5


4. Test Resources
The following resources will be completely or partially dedicated to the testing effort. The roles each will play in the
testing phase are as follows:

List the people that will be executing testing and the role(s) each will play. Specify which testing phase the resource
will tak e part in.

Table 2. Test Resources

Resource Test Assignment Test Phase
Resource 1 GUI layout, font consistency, Color usage, style, Unit Test, Functional Test, System Test,
size System Integration Test, Regression Test,
Acceptance Test
Resource 2 Stress test, load test, volume limits System Integration Test, Regression Test

Resource 3 Installation, On-line user documentation System Test, System Integration Test,
Regression Test

.

6


5. Test Environment
The following criteria must be met to fulfill the test environment requirements.

5.1 Hardware Requirements
Identify the hardware required to build a testing environment. Examples include:
 Computers
 Network s
 Printers
 Mainframe access

5.2 Software Requirements
Identify the software required to complete testing activities. Examples include:
 Software in addition to what is being tested
 Test management software
 Automated testing software
 External databases

5.3 Logistical Requirements
Identify the testing environment logistics. Examples include:
 Office space needs
 Seating assignments
 Office furniture
 Disaster recovery site
 Testing lab
 Remote site

5.4 Publications Requirements
Identify all documents, manuals, and user guides that are required to support the testing team. Examples include:
 Use cases
 Application requirements
 Out-of-the-box application guides
 Application design specifications

7


6. Defect Tracking
The following process defines how to raise, track, and resolve defects found throughout testing.

Describe how defects will be raised, tracked, communicated, and resolved. Where possible, us e a process flow
diagram to describe how the various teams involved in testing will interact to reach issue resolution.

When raising a defect, include the following information:

 Date Raised – specify the date the defect was raised
 Raised By – specify the resource who raised the defect
 Issue Description – a description of the defect. Include detailed steps on how to reproduce the issue.
 Testing Phase – specify the phase in which the defect was raised i.e. functional test, system test, etc.
 Severity – assign a severity to the defect
 Priority – assign a priority to the defect
 Assigned To – specify the developer which the defect is assigned to for resolution.
 Sign-off Date – specify the date the developer fixes and signs-off the defect back to the tester
 Sign-off Description – the developer provides a description of what was done to fix the issue.

A defect priority level can be used along with severity to help determine the urgency in fixing the defect. When
assigning a severity or priority to a defect, the following scale can be used to help assigning rankings:

 Severity Scale
o High: A major issue where a large piece of functionality or major system component is completely
brok en. There is no work around and testing must halt.
o Medium: A significant issue where a large piece of functionality or major system component is not
work ing properly. There is a work around, however, and testing can proceed.
o Low: A minor issue that imposes some loss of functionality, but for which there is an acceptable
and easily reproducible work around. Testing can proceed without interruption.
 Priority Scale
o High: This has a major impact on the customer. This must be fixed immediately.
o Medium: This has a major impact on the customer. The problem should be fixed before release of
the current version in development, or a patch must be issued if possible.
o Low: This has a minor impact on the customer. The flaw should be fixed if there is time, but it can
be deferred until the next release.

8


7. Test Metrics
Test metrics provide a vehicle to communicate testing progress to the project team. The following information will
be collected from test results to develop testing metrics.

In the table, list the information that should be recorded for metric calculations.

Examples:
 Functional Metrics: Number of requirements verified (may be broken down by testing phase, component,
testing resource or all of the above)
 Code Metrics: Percent of code executed (may be broken down by test and/or component)
 Problem Metrics: Problems found per day, problems found per component
 Schedule Metrics: Percent of tests completed
 Estimated days to completion
 Time to complete testing by component

Table 3. Metric Collection Details

Metric Purpose Required Information

9


8. Test Strategy Sign-Off
The sign-off below indicates that the following person(s) have reviewed the test strategy document and approve of
the content.

The Test Strategy Sign-off section allows the person(s) acting as the Test Manager, Project Manager and Business
Sponsor to indicate they have reviewed the strategy and approve the content. The person(s) who are required to
review the document and sign-off should be established during the initial project planning phase.

1. Name_________________________ Role_____________________ Sign-off Date_________________




_____________________________________________________

Info-Tech Research Group tools and template documents are provided for the free and unrestricted use of
subscribers to Info-Tech Research Group services. Use this document either in whole or in part as a basis and
guide for document creation. To customize this document with corporate marks and titles, simply replace the Info-
Tech Information in the Header and Footer fields of this document.

10

Test Plan Template

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Test Plan Template

Ähnlich wie Test Plan Template (20)

Mehr von H2Kinfosys

Mehr von H2Kinfosys (17)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Test Plan Template