Name of Best Practice

ID no.
Date changed
Description of contents

Type of document
ASL Processes
Comments

ASL BiSL Foundation

PO-box 9769
3506 GT UTRECHT

Test Plan Template

029_BP_N
30/08/2005
This template is used to record all activities involved in the testing of a specific system by the
project team. This test plan is related to the application management plan or quality plan and
is a particularization of the testing method
Template
Testing

T: +31 (0) 30 753 1424

F: +31 (0) 30 755 1502
Chambre of Commerce Utrecht and surroundings:

I: www.aslbislfoundation.org
E: info@aslbislfoundation.org
08106817

IName
www.
of branch
.

Test Plan Template

Place of branch
Address

Report template

P.O. Box
Postal code Place

Place
Date
Author
Status

T +31

Place
13 April 2011
Author
Draft 0.1

F +31

Test Plan Template

13 April 2011
2/12

Table of contents
1

Preparation of Test Plan..............................................................................5

1.1
1.2

Introduction............................................................................................. 5
Test plan model.......................................................................................5

Test plan model explanation.......................................................................7

2.1
Introduction............................................................................................. 7
2.2
Formulation of the engagement..............................................................7
2.3
Reporting................................................................................................ 7
2.4
Organization........................................................................................... 7
2.4.1
Definition.......................................................................................... 7
2.4.2
Tasks and responsibilities................................................................8
2.4.3
Overview of products, quality requirements and stop criteria..........8
2.4.4
Documentation.................................................................................9
2.4.5
Equipment and accommodation......................................................9
2.4.6
Test environment.............................................................................9
2.4.7
Version Management.....................................................................10
2.4.8
Test techniques and tools..............................................................10
2.4.9
Training.......................................................................................... 11
2.4.10 Test management..........................................................................11
2.4.11 Scheduling.....................................................................................12

Test Plan Template

13 April 2011
3/12

Version Management
Version Date
0.1

Author
Author

Description
Initial document

Distribution List
Version Date
0.1

To

Test Plan Template

13 April 2011
4/12

1Preparation of Test Plan

1.1

Introduction

The testing process begins with the preparation of a test plan.

The test plan crystallizes the quality agreements between the client and <software
developer> recorded in the DAP by means of selected test process specifications
such as test types, techniques, required depth and documentation. This makes
every testing process different.
This test plan establishes exactly which activities will involved in the testing of
a specific system by the project team. This test plan is related to the application
management plan or quality plan and is a particularization of the testing method
as described in this handbook for a specific system.
The user formulates a separate test plan in consultation with the department where
the system will later be put into operation. The user test plan may, in so far as
applicable, be the same as the model described below. Support from the project
team is advisable in the organization of a user test.
The test plan covers a variety of subjects, including the following:
- The test environment.
- The test organization.
- The required facilities.
- Version management.
- Training.
- The test environment.

1.2

Test plan model

A model of the test plan is provided below. The model is a general default set-up
that can be used in most situations. However, deviations can be made for each
individual system depending on their specific requirements.
The majority of the above-mentioned information is always included in the test plan,
regardless of whether it concerns a management of development environment.
An exception is made for the more dynamic, time-dependent aspects.
In a development situation, which is characterized by project organization with
a beginning and end, the test plan covers the full range of static, dynamic and
other aspects.

Test Plan Template

13 April 2011
5/12

Once a system has been accepted and put into production, the management
situation primarily shows static aspects: the system is tested (monitored) in order
to detect and undo undesired changes. In this stationary situation the test plan
can suffice by dealing with the time-dependent aspects of testing, such as the
organization, the agreements made, the project standards, etc. A new test plan
will only be prepared if this data should change (new quality requirements,
organizational changes).
The more dynamic aspects of each system change (maintenance procedure),
namely the scheduling and test processes, are dealt with in a supplement
to the test plan.
All issues are covered in the included test plan model. The subjects covered
in the test plan and those that will be dealt with by way of the supplement
project are determined on an individual project basis.
The project manager is responsible for preparing the test plan. A test coordinator
can be appointed to take over the responsibilities of the project manager for larger
projects.
The test plan is prepared as early as possible (see section 2.2) so that the required
training can be organized, the parties involved can familiarize themselves with
the relevant tools, the test management can be organized in a timely manner, etc.
The test plan model is arranged according to the following table of contents.
TABLE OF CONTENTS
'1. Introduction
'2. Formulation of the engagement
'3. Reporting
'4. Organization
'4.1
Definition
'4.2
Tasks and responsibilities
'4.3
Overview of products, quality requirements and stop criteria
'4.4
Documentation
'4.5
Equipment and accommodation
'4.6
Test environment
'4.7
Version Management
'4.8
Test techniques and tools
'4.9
Training
'4.10
Test management
'4.11
Scheduling

Test Plan Template

13 April 2011
6/12

2Test plan model explanation

2.1Introduction
The introduction contains a brief outline of the situation and the status of the
test plan, i.e. draft/final version.

2.2Formulation of the engagement

The formulation of the engagement describes the following:
- The test assignment.
- The test objectives.

2.3Reporting
The necessary reporting lines are established.
The following questions must be answered in this regard:
- Which parties are reported to (project manager, test coordinator, principal)?
- What information is required (e.g. progress, problem notifications,
time registration)?
- Which parties report (project manager, test coordinator)?
- What is the reporting frequency (daily, weekly, bi-weekly)?

2.4Organization
2.4.1Definition
A brief description of the system that is to be tested and the relevant test
environment.
- Establishment of the test criteria and methods.
The test phases and the test types to be performed are established.
- The system is divided as much as possible so that specific components
or aspects can be tested, taking into account the requirements imposed
by management (see section 2.5). This division can vary from the division
into subsystems.
It is important that the chosen products requiring a separate test design are
not too extensive, i.e. not one system test design for a system comprising
multiple processes, but one system test design per process.
One criterion that can be applied in this respect is criterion is the degree of change
in the various parts of a system, i.e. the more often changes are made, the greater
the reason for a separate testing component.
Test Plan Template
13 April 2011
7/12

2.4.2Tasks and responsibilities

The organizational structure is determined. The tasks and responsibilities are
determined and assigned. Who performs the various tests, who is responsible for
team management, who deals with the problem notifications, and who processes
the change requests?
Formal procedures are established to enable monitoring of tasks and responsibilities.
The responsibilities in relation to problem notification processing and the formal
approval of the products in particular must be clear.
Principal-principal relationship procedures are included in the DAP.
2.4.3Overview of products, quality requirements and stop criteria
The products that are to be tested are determined, followed by the related quality
requirements and stop criteria (when to stop).
Examples of products for testing:
- JCL
(from the JCL program in the program test to fully procedures in the system test).
- Program.
- Subsystem.
- Conversion software.
- Recovery software.
- Single-use software.
Quality requirements for each system, product type or individual product are
determined by the principal in consultation with management and the project
manager (see section 2.4).
Prior consideration and agreements regarding the extent to which testing should
be continued before termination:
- 100% error-free.
- Non-removal of minor errors.
- Non-removal of situations that will not necessarily occur in the current situation.
- Balanced consideration of limits.

Test Plan Template

13 April 2011
8/12

2.4.4Documentation
In the test dossier the documents are stored under the test products (see section
2.3).
Decisions are made as to which documents will and will not be included in the
test dossier.
In this situation the following criteria can be applied:
- From a quality assurance perspective it must always be clear what has been
tested and how.
- The chosen quality level (see section 2.4).
- The test cases must be reusable in subsequent test cases. This results in
high maintainability requirements for the test cases in terms of structuring
and transparency (see section 2.5).
Project standards are established for the various documents, such as program,
integration, system test designs and problem notifications. See [Mors] for
examples of documents.
2.4.5Equipment and accommodation
The equipment and software (PC, word processing package, connection to the
network), disk space, etc. required for the different test phases are determined.
The accommodation (rooms, desks, chairs, cupboards and telephones) is also
arranged.
2.4.6Test environment
In order to be able to guarantee that the correct version of a product is tested and
combat interfering environmental factors, the test team and preferably each
individual tester will require their own test environment.
In any case, the test environment used for the system test will have to be as similar
as possible to the future production environment. Certain aspects of a production
environment, such as the quantity of stored data, cannot always be reproduced,
but can in some cases be simulated. The aim is a realistic test situation. Only then
can agreements be made regarding operation in a production situation.

Test Plan Template

13 April 2011
9/12

2.4.7Version Management
Version management comprises all activities connected with the management
of the different versions of specifications, products for testing and test products
that can be created during the course of a project.
There must always be explicit clarity as to:
- the different versions of the specifications used for testing.
- the different versions of the products for testing.
- the version components, e.g. which programs comprise a subsystem.
- the different versions of the test products.
- the locations of the different versions.
- which version of the product for testing has been tested and with which
version of the test products.
Sound version management and an efficient test process are always important.
It is essential that well-founded statements can be made regarding the quality
of a tested product. Version management can only be performed if every new
version of specifications, a products for testing or test product is officially delivered.
Official delivery involves the registration of the product as such, and its transfer
to a secure environment by the party responsible for version management in order
to prevent changes being made to the product after its delivery.
Information regarding version management tools is available from the facilities
coordinator of the Quality Management departments.
2.4.8Test techniques and tools
This handbook and [Mors] cover techniques and tools that can be used in testing.
The techniques and automated tools that are to be used must be determined in
time so that the necessary experience can be acquired at an early stage. The choice
of techniques and tools can vary for each system and product because of the
variability of system and product quality levels. The required documentation and
maintainability play a particularly important role.
Efforts are made to ensure that test sets, testing, test evaluation and test
management are realized using automated tools.
Information regarding the tools used is available from the facilities coordinator
of the Quality Management departments.

Test Plan Template

13 April 2011
10/12

2.4.9Training
After the test techniques and tools have been chosen, the staff contributing to the
preparation and execution of the test are assessed to establish whether they
possess all the necessary knowledge and skills. In most cases they will already
fulfill these requirements to an extent, depending on their training, interest and
practical experience.
The knowledge skills required for testing are determined for each individual; position.
Each member of staff is assessed to determine his or her knowledge and skills.
Depending on its nature, a lack of knowledge and skills can be compensated for
by means of:
- participation in a testing course.
- a period working under the supervision of an experienced tester.
- self-study.
2.4.10Test management
Test management is geared towards the use and reuse of test products.
This requires measures and activities relating to the following:
- people and resources.
- responsibilities and authority.
- the accessibility and maintenance of documentation in the test dossier.
- the storage of the other test products.
The documents are archived and the location of the other test products (test files,
backups) is determined in the test dossier (see section 4.4. of the test plan) This
ensures that previously acquired knowledge and developed test products can be
used as much as possible in the event of retesting or changes to the tested
product.
Monitoring procedures that ensure that the test dossier is kept up to date will
be required for continued guaranteed reusability. In the event of urgent changes
(when are changes anything other than urgent?), paperwork is often neglected!
in order to ensure test efficiency and reliability, it is vital that tests can be reproduced.
Tools are purchased and procedures are established to ensure that this requirement
is met.

Test Plan Template

13 April 2011
11/12

2.4.11Scheduling
The complete test is scheduled in advance. The required capacity and resources
are compared with the relationships between the activities, thereby creating a network
schedule. This schedule is then used to determine the throughput time and
completion dates.
It is clear that the test process schedule depends on the overall project schedule.
The following are taken into account in the schedule:
- The order in which system components and changed system components
become available.
- The interrelationships between functions.
- The anticipated number of retests.
- The priority that can apply to a part of the system.
As mentioned above, the time aspect of a test plan will play a role in the
development situation in particular. In a management situation, it will only
be possible to address the dynamic aspects to a limited extent in the test plan.
These aspects are dealt with as part of a schedule prepared for each individual
maintenance phase.
In order to ensure that the test can be performed as early as possible, its preparation
will have to coincide with the development or management activities.
Prerelease testing can also be commenced prior to the completion of the system
enabling errors to be resolved at the earliest possible stage. The later an error
is detected, the more expensive it is to resolve! This in no way affects the normal
execution of the individual tests.
The complexity of the information system and the availability of testing tools
are a major determining factor in the required capacity and the required testing
capacity is often underestimated. For example, the building of the test sets
is a particularly time-consuming activity.
In practice it has emerged that approximately 20% of the total amount of development
time for new information systems is devoted to testing, while an average of
approximately 30% of the overall maintenance activities are involved in the
operation of an existing system (NGGO report on Information system testing).
Considering the value of historical figures in scheduling, it is important that progress
is monitored so that relevant key figures can be acquired with regard to the test
process. The project plan provides the information.

Test Plan Template

13 April 2011
12/12