Last night, I was digging through some old documents, when I stumbled across a diskette containing this Test Plan Template. It was given out as part of a presentation I did during a Users Conference back in 1994.
These days, I generally use a less-formal Test Plan format, although I still occasionally use something like this when warranted.
An oldie but goodie?
Test Plan Template
Test Suite Name
Application: Name of the Application
Version: Version of the Application
Developers: Developer Name
Test Plan Author: Plan Author Name
Date of the Original Test Plan: Month dd, 19xx
Current Revision Date: Month dd, 19xx
Document File Name: TESTPLAN.DOC
Related Documentation for this Test Suite:
Requirements Specifications: Title
Author: Author name
Revision Date: Revision date
Relevant Pages: Relevant pages
Design Specifications:
Author:
Revision Date:
Relevant Pages:
Development Plan:
Author:
Revision Date:
Relevant Pages:
User Documentation:
Author:
Revision Date:
Relevant Pages:
Standards Manual:
Author:
Revision Date:
Relevant Pages:
Other:
Source:
Revision Date:
Relevant Pages:
Application Overview
Overview of Component Functionality
An overview of the relevant application components and their functionality is described here. This helps to guide the thought process and place this test suite in the correct application context. copyrightjoestrazzere
Other Applications/Components Impacted
Any other applications and/or components that may be directly or indirectly affected are discussed here. The Test Suites which will be used to perform testing on those components may also be referenced.
Standards Requirements
When the testing process requires checking the application against any pre-defined standards, those standards are described here.
Performance Requirements
The performance requirements against which this application will be measured are described here.
Defect Tracking System Codes
When defects in the application are found, this section describes how they will be categorized and entered into the defect tracking system.
Scheduled Availabilities
Application Version: The version to be tested.
Build Date: The expected date for the following features.
Features to be included in this build: The features delivered on this date.
Build Date: The expected date for the following features.
Features to be included in this build: The features delivered on this date.
Build Date: The expected date for the following features.
Features to be included in this build: The features delivered on this date.
Test Suite Overview
General Testing Strategy
The overall approach to implementing this test suite is described here.
Test Environment:
Hardware
The hardware environment in which the tests will be executed is described here.
System Software
The system software environment in which the tests will be executed is described here.
Databases/Files
Any databases and files required to execute this test suite are described here.
Utilities/Tools
Any utility programs required to execute this test suite are described here.
Test Suite Summary
It is often useful to have a naming convention to use when naming test cases.
Name of Test Case Brief Description
1. Name of test case here Description of test case here.
2.
3.
4.
5.
Test Case Specification - 1. Name of Test Case One
Overview:
This section describes, in some detail, what is to be accomplished with this test case (i.e., what particular assertion will be tested).
Prerequisites
Any prior tasks which must be accomplished before this test case can be executed are detailed here.
Any advance preparation of the hardware or software environment is detailed.
Utilities and Files used:
Any utilities, database, and files required to execute or validate this test case are detailed here. In addition, their version and location is described.
Test Sequence:
The high-level steps required to execute this test case are described here. This is often the longest portion of the individual Test Case.
Expected Results:
This section describes what results are expected when the above test sequence is executed.
Verification Procedure:
The process for determining if the expected results were achieved is described here.
Script(s):
Any scripts (either written or automated) which aid in execution of this Test Case are listed here.
Time Estimates:
Preparation: The expected amount of prep time required.
Execution: The expected amount of execution time.
Verification: The expected amount of verification time.
My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://strazzere.blogspot.com/. |
Why the names of the developers and not the testers?
ReplyDeleteGood question! This is a very old template, but if I recall correctly, the test plan Author was assumed to also be the (sole) tester.
Delete