Test Plan
author
1.0 Purpose
- This plan is designed to ...
2.0 Product Phases
First Release
- State purpose and assumptions of this release milestone
Second Release
- State purpose and assumptions of this release milestone
FCS
- State purpose and assumptions for First Customer Ship.
Bug Management
- State rules and assumptions for bug management (classification and what they mean)
for each project phase.
This is what bug "scrubs" will be based on.
3.0 Test Strategy
Coverage Description
- Show the mapping of major product components to the tests.
Automated Tests
test harness 1
- Describe the test harness and the general layout of the tests.
test harness 2
- you might need more than one, like a command line tester and a gui tester. Or you might have legacy tests that run differently from newer tests
Manual Tests
test type
- describe each test type that will be done manually. overview only
Paper Documentation
On-line Documentation
- README files and the GUI on-line help must be manually checked. For on-line help, not only the content but the links must be checked.
4.0 Test Activities
Test activities fall into two broad categories, test development and release verification.
To build a regression test suite, it is important to have an extensive collection of
automated tests. The items in the section Test Development represent the test development
and debug. Test debug does represent testing of the product.
To verify that a particular set of bits is ready for release, a process of verification
must be performed on those bits. The more stable a release is expected to be, the more
time must be spent in release verification independent of test development.
Test Development
task
- description & time estimate
task
- description & time estimate
First Release Verification
Product Install
- pristine installation testing - x days
- demo - x days
Test Execution
- partial regression of automated tests - x days
- run manual tests - x days
- upgrade testing - x days
- GUI- x days
Product Documentation
Coverage measurement
- what kind of test run? - x days
Purify'd
- what kind of test run? - x days
Bug Fix Verification Status
- which bugs will be checked? - x days
Internal Deployment
- is qe involved in support of internal deployment? - x days
Second Release Verification
5.0 Schedule
- Collect the estimates from Section 4. Group into phases and priorities.
Assign engineers.
6.0 Resource Requirements
Hardware Support
Operating System Support
- Patches?
Compilers
Linkers
People
7.0 Risks and Concerns
- Contention for QE lab machines is starting to become a problem.
- Limited team experience with .
Appendix - Release Criteria
What are the specific criteria for each phase that this product will go through?
Be *very* sure to negotiate these up front to save much grief later.
First Release
Definition
Product Installability
Product Completeness
Test Execution
Product Documentation
Open Defects
Defect Submission Rate
- no new "must" bugs for x days that would violate the "open defect" standards
Source Change Rate
Test Coverage
- PureCoverage target numbers
Purify'd
Bug Fix Verification Status
Internal Deployment
Back to Observations...
Permission granted to use this document in whole or in part.
last update 3/5/98