Test Plan Template
Release Information
Project: |
|
Internal Release Number: |
1.0 |
Related Documents: |
LINKS TO RELEVANT STANDARDS
LINKS TO OTHER DOCUMENTS
|
Process impact: This document
specifies "why" and "when" the testing will be done for this project. The "how" is described in the individual Test Cases
that this Test Plan links to.
Introduction
- Why is this Test Plan needed?
- A Test Plan is needed to provide intelligent focus of limited project testing resources and expertise on the highest risk areas of the
application and the "bread and butter" functionality of the system. A Test Plan is also needed to determine when the testing
is done.
- What Test lessons were learned in previous releases?
- None yet. This is the first release.
Test Plan Synopsis
- Testing objectives and their rationale (risk, requirements, etc.)
- Scope and Limitations
- Testing strategy
-
Testing Strategy Chessboard
- Sources of business expertise for test planning, test case development, and tet execution
- Sources of development expertise for test planning, test case development, and test execution
Test Plans for XXX Phase
- Sources of test data for XXX Phase testing
- XXX Phase test environments and their management
- How can you tell when you are ready to start XXX Phase testing ?
- How can you tell when you are finished XXX Phase testing ?
- Testing schedule during Analysis
- This schedule represents the master schedule of testing activity that the test team must
manage.
- This schedule is the composite of all test case documentation, execution, and reporting
schedules for all development phases.
Each schedule entry represents one Test Case -> link to Test Case Suite
Each entry: test case id, name, status(w=written,as=attempted,successful,au=attempted,unsuccessful,c=corrected,crt=corrected, retested),status date,execution date
Test Case execution results analysis and reporting schedule
- This schedule extends the test execution schedule to include time to analyze and report
test results.
- Usually, there is some analysis time and minimal report drafting time associated with
each test execution so that the testers can begin to see the nature of the testing
outcome early in the test execution schedule. Then if adjustments need to be made in
the test execution to accommodate surprises, there is test execution schedule remaining
for the tactical adjustments.
- A first allotment of analysis and reporting time can range from a half day to a couple
of days per test case.
- A second allotment of time is made for analysis of results across multiple test case
executions for more pervasive trends and completion of the drafted report. This
second allotment of time can range from two to four weeks depending on the size and
complexity of the testing project.
Test Case summary list (ID, title, brief description)
- This list replaces test-suite in the ReadySET standard templates.
- This is the summary list of test cases that you curently think are needed to adequately
cover all the testing situations in this development phase.
- Each Test Case ID in this table should ultimately point to a .html file of the same name.
- This list is refined a number of times as more details about the application design
become available.
- Consider using a Test Case ID naming standard like [devel phase]-[test approach]-[sequence number].
This naming standard will cause the test case .html files to be sorted first by development
phase, next by test approach (functional, structural, performance), and finally by sequence.
That does allow sequence numbers to be reused across development phases.
XXX Module Testing Schedule
SND = Successful, no defect correction required
UNS = Unsuccessful, awaiting defect correction
SAD = Successful after defect correction
Test Case ID: Title |
Date to Write : done? |
Date to Attempt : done? |
Test Result Code |
... | ... | ... | ... |
Test Case NN.0 | ... | ... | ... |