Chapter 1

TEST PLAN (TP) TEMPLATE

Version 1.1, October 2013

FOREWORD
This template was created to provide system and software development projects with a model Test Plan
(TP) document template. The template is based on IEEE 829 Format. It has been edited and updated by
Dr. Clint Jeery for use in UI CS 383.
The TP template begins on the next page. Just throw away this page and enter your project specications
into the following template. Don't forget to change the headers and footers as necessary. The following
conventions are used to guide you in developing your TP:
[ Text ] Replace this text with your project design text.
text in italics Notes/instructions to the author. Delete in your nished document.
TEST PLAN (TP)
FOR
[ state program/system name here ]

Version [[insert version number]]

[[insert date]]

Prepared for:
[ state customer name(s) here ]

1
 Prepared by:

[insert your name(s)]

University of Idaho

Moscow, ID 83844-1010

CS383 TPD

Test Plan Page 2

 RECORD OF CHANGES (Change History)

Change Date Location of change A Brief description Approved Date

Number com- (e.g., page or gure M of change by
pleted #) D (initials) approved

A - ADDED M - MODIFIED D  DELETED

[ put program /system name here ]

Test Plan Page 3

 TABLE OF CONTENTS
Section Page

Test Plan Page 4

 1 IDENTIFIER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 TEST ITEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5 SOFTWARE RISK ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
6 FEATURES TO BE TESTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
7 FEATURES NOT TO BE TESTED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
8 APPROACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
9 ITEM PASS/FAIL CRITERIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
10 SUSPENSION CRITERIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
11 TEST DELIVERABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
12 REMAINING TEST TASKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
13 ENVIRONMENTAL NEEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
14 STAFFING AND TRAINING NEEDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
15 RESPONSIBILITIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
16 SCHEDULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
17 PLANNING RISKS AND CONTINGENCIES . . . . . . . . . . . . . . . . . . . . . . . . . . 4
18 APPROVALS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
19 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
20 APPENDIX A. [insert name here] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
21 APPENDIX B. [insert name here] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 TEST PLAN IDENTIFIER

Some type of unique company generated number to identify this test plan, its level and the level of software
that it is related to. Preferably the test plan level will be the same as the related software level. The number
may also identify whether the test plan is a Master plan, a Level plan, an integration plan or whichever
plan level it represents. This is to assist in coordinating software and testware versions within conguration
management.
[Insert text here.]

2 REFERENCES

List all documents that support this test plan. Refer to the actual version/release number of the document
as stored in the conguration management system. Do not duplicate the text from other documents as this
will reduce the viability of this document and increase the maintenance eort.
[Insert text here.]

1
3 INTRODUCTION

State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the
executive summary part of the plan.

4 TEST ITEMS

These are things you intend to test within the scope of this test plan. Essentially, something you will test, a
list of what is to be tested. This can be developed from the software application inventories as well as other
sources of documentation and information.
[Insert text here.]

5 SOFTWARE RISK ISSUES

Identify what software is to be tested and what the critical areas are, such as:
ˆ 1. Delivery of a third party product.
ˆ 2. New version of interfacing software
ˆ 3. Ability to use and understand a new package/tool, etc.
ˆ 4. Extremely complex functions
ˆ 5. Modications to components with a past history of failure
ˆ 6. Poorly documented modules or change requests
[Insert text here.]

6 FEATURES TO BE TESTED

This is a listing of what is to be tested from the USERS viewpoint of what the system does. This is not a
technical description of the software, but a USERS view of the functions.
[Insert text here.]

7 FEATURES NOT TO BE TESTED

This is a listing of what is NOT to be tested from both the Users viewpoint of what the system does and a
conguration management/version control view. This is not a technical description of the software, but a
USERS view of the functions.
[Insert text here.]

8 APPROACH

This is your overall test strategy for this test plan; it should be appropriate to the level of the plan (master,
acceptance, etc.) and should be in agreement with all higher and lower levels of plans. Overall rules and
processes should be identied.
ˆ Are any special tools to be used? What are they?
 ˆ What metrics will be collected for this test?
ˆ How many congurations/platforms are to be tested?
ˆ How will elements in the design deemed "untestable" be processed?
[Insert text here.]

9 ITEM PASS/FAIL CRITERIA

What are the Completion criteria for this plan? This is a critical aspect of any test plan and should be
appropriate to the level of the plan. [Insert text here.]

10 SUSPENSION CRITERIA AND RESUMPTION REQUIRE-

MENTS

If the number or type of defects reaches a point where the follow on testing has no value, it makes no sense
to continue the test; you are just wasting resources.
Specify what constitutes stoppage for a test or series of tests and what is the acceptable level of defects
that will allow the testing to proceed past the defects. [Insert text here.]

11 TEST DELIVERABLES

What is to be delivered as part of this plan?

ˆ Test plan document
ˆ Test cases
ˆ Relevant error logs or problem reports
One thing that is not a test deliverable is the software itself that is listed under test items and is delivered by
development. [Insert text here.]

12 REMAINING TEST TASKS

If this is a multi-phase process or if the application is to be released in increments there may be parts of
the application that this plan does not address. These areas need to be identied to avoid any confusion
should defects be reported back on those future functions. This will also allow the users and testers to avoid
incomplete functions and prevent waste of resources chasing non-defects. [Insert text here.]

13 ENVIRONMENTAL NEEDS

Are there any special requirements for this test plan, such as:
ˆ Special hardware such as simulators, static generators etc.
ˆ How will test data be provided. Are there special collection requirements or specic ranges of data that
must be provided?
[Insert text here.]
14 STAFFING AND TRAINING NEEDS

Training on the application/system.

Training for any test tools to be used. [Insert text here.]

15 RESPONSIBILITIES

Who is in charge?
This issue includes all areas of the plan. Here are some examples:
ˆ Selecting features to be tested and not tested.
ˆ Ensuring all required elements are in place for testing.
[Insert text here.]

16 SCHEDULE

Should be based on realistic and validated estimates. If the estimates for the development of the application
are inaccurate, the entire project plan will slip and the testing is part of the overall project plan.
[Insert text here.]

17 PLANNING RISKS AND CONTINGENCIES

What are the overall risks to the project with an emphasis on the testing process? Specify what will be done
for various risk events.
[Insert text here.]

18 APPROVALS

Who can approve the process as complete and allow the project to proceed to the next level (depending on the
level of the plan)?
[Insert text here.]

19 GLOSSARY

Used to dene terms and acronyms used in the document, and testing in general, to eliminate confusion and
promote consistent communications.
[Insert text here.]
20 APPENDIX A. [insert name here]

Include copies of test examples, etc. supplied or derived from the customer. Appendices are labeled A, B,
. . . n. Reference each appendix as appropriate in the text of the document.
[ insert appendix A here ]
21 APPENDIX B. [insert name here]

[ insert appendix B here ]