Test Plan FAQ

What a test plan should contain?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.  

A test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied to the testing of each item, and describes the test environment.  

A test plan should ideally be organisation wide, being applicable to all of organisations software developments.

The objective of each test plan is to provide a plan for verification, by testing the software. The software produced fulfils the functional or design statements of the appropriate software specification. In the case of acceptance testing and system testing, this generally means the Functional Specification.

The first consideration when preparing the Test Plan is who the intended audience is – i.e. the audience for a Unit Test Plan would be different, and thus the content would have to be adjusted accordingly. 

You should begin the test plan as soon as possible. Generally it is desirable to begin the master test plan as the same time the Requirements documents and the Project Plan are being developed. Test planning can (and should) have an impact on the Project Plan. Even though plans that are written early will have to be changed during the course of the development and testing, but that is important, because it records the progress of the testing and helps planners become more proficient.

What to consider for the Test Plan:

1. Test Plan Identifier
2. References
3. Introduction
4. Test Items
5. Software Risk Issues
6. Features to be Tested
7. Features not to be Tested
8. Approach
9. Item Pass/Fail Criteria
10. Suspension Criteria and Resumption Requirements
11. Test Deliverables
12. Remaining Test Tasks
13. Environmental Needs
14. Staffing and Training Needs
15. Responsibilities
16. Schedule
17. Planning Risks and Contingencies
18. Approvals
19. Glossary
 

IEEE Standards for Software Test Plans

Several standards suggest what a test plan should contain, including the IEEE.

IEEE standards:  829-1983 IEEE Standard for Software Test Documentation  1008-1987 IEEE Standard for Software Unit Testing  1012-1986 IEEE Standard for Software Verification & Validation Plans  1059-1993 IEEE Guide for Software Verification & Validation Plans

IEEE Standards for Software Development

610.12-1990  Standard glossary of software Engineering Terminology

1233-1996     Guide for developing of System Requirements Specifications

1058.10-1987 Standard for software Project Management plans

1074.1-1995     Guide for developing software life cycle process

730.1-1995     Guide for software Quality Assurance plans

1008-1987 IEEE Standard for Software Unit Testing

1063-1987 Standard for software User Documentation

1219-1992     Standard for software Maintenance