Test Plan Overview

Creating test plans is no different from creating plans for any other part of a computing project. A plan enables you to decide in advance:

  • How a project’s objectives will be met,
  • With the resources available,
  • To the time scales required,
  • To the quality desired,
  • While controlling the risk.

A test plan is a specific version of a project plan with clauses that meet these requirements. The main characteristics of a project plan are described in the article Basics of Project Management. The international standard IEEE Std 829-1998 gives advice on the various types of test documentation required for testing including test plans, and details of these are in the IEEE 829 article. The test plan section of the standard defines 16 clauses. This article gives guidance on how the IEEE 829 standard maps against the requirements of a project test plan.


Project Plans and IEEE 829

The 16 clauses of the IEEE 829 test plan standard are:
1. Test plan identifier.
2. Introduction.
3. Test items.
4. Features to be tested.
5. Features not to be tested.
6. Approach.
7. Item pass/fail criteria.
8. Suspension criteria and resumption requirements.
9. Test deliverables.
10. Testing tasks.
11. Environmental needs.
12. Responsibilities.
13. Staffing and training needs.
14. Schedule.
15. Risks and contingencies.
16. Approvals.
These can be matched against the five characteristics of a basic plan, with a couple left over that form part of the plan document itself.



Scope clauses define what features will be tested. An aid to doing this is to prioritise them using a technique such as MoSCoW.
3. Test Items: The items of software, hardware, and combinations of these that will be tested.
4. Features to Be Tested: The parts of the software specification to be tested.
5. Features Not to Be Tested: The parts of the software specification to be excluded from testing.



Resource clauses give the overall view of the resources to deliver the tasks.
11. Environmental Needs: What is needed in the way of testing software, hardware, offices etc.
12. Responsibilities: Who has responsibility for delivering the various parts of the plan.
13. Staffing And Training Needs: The people and skills needed to deliver the plan.



Time clauses specify what tasks are to be undertaken to meet the quality objectives, and when they will occur.
10. Testing Tasks: The tasks themselves, their dependencies, the elapsed time they will take, and the resource required.
14. Schedule: When the tasks will take place.
Often these two clauses refer to an appendix or another document that contains the detail.



Quality clauses define the standard required from the testing activities.
2. Introduction: A high level view of the testing standard required, including what type of testing it is.
6. Approach: The details of how the testing process will be followed.
7. Item Pass/Fail Criteria: Defines the pass and failure criteria for an item being tested.
9. Test Deliverables: Which test documents and other deliverables will be produced.
The associated article on test documentation gives details of the IEEE 829 documentation.



Risk clauses define in advance what could go wrong with a plan and the measures that will be taken to deal with these problems. An outline of risk management is in an associated article.
8. Suspension Criteria And Resumption Requirements: This is a particular risk clause to define under what circumstances testing would stop and restart.
15. Risks And Contingencies: This defines all other risk events, their likelihood, impact and counter measures to over come them.


Plan Clauses

These clauses are parts of the plan structure.
1. Test Plan Identifier: This is a unique name or code by which the plan can be identified in the project’s documentation including its version.
16. Approvals: The signatures of the various stakeholders in the plan, to show they agree in advance with what it says.



The IEEE 829 standard for a test plan provides a good basic structure. It is not restrictive in that it can be adapted in the following ways:

  • Descriptions of each clause can be tailored to an organization’s needs,
  • More clauses can be added,
  • More content added to any clause,
  • Sub-sections can be defined in a clause,
  • Other planning documents can be referred to.

If a properly balanced test plan is created then a project stands a chance of delivering a system that will meet the user’s needs.