Post
by tvn » Thu 02 Dec, 2010 3:05 pm
How to Write a Test Plan
By paigeturner, eHow Member
A test plan is a detailed hardware or software verification document that provides specifics on how the validator will test all aspects of the hardware or software design. Test plans are test specifications used as guides for writing test case suites for design validation in both the hardware and software engineering fields. Typically a test plan is written by a test or validation engineer. A test plan contains a description of product functionality, a description of test cases to be written for each function, and a description of the testing platform to be used. For hardware testing, test plans are needed for pre-silicon and post silicon validation.
Instructions
1. Review the Product Design Specification that the Test Plan is based On
Review every aspect of the product design specification. Flag any constraint or functionality omissions with the specification document. The hardware/software architect or owner of the product design specification document should be responsible for fleshing out any missing details in the design specification. Go through as many review iterations as necessary until all your questions have been answered. Your test plan will be based on the design specification so this step is extremely important.
2. Write the First Draft of Your Test Plan
Your test plan should contain a brief description of the design, the regression test and validation methodology to be used at both the unit and global levels, the testing architecture and a listing of the actual tests that will be performed. It should detail:
a) Design/Product description and features
b) Test Code Architecture
c) Test Methodology description
. (i) Unit Level
. (ii) System/Global Level
d) Type of testing (random, focused/directed, focused random, global, local) to be done.
e) Description of the function of each piece of the design and a listing of test cases that cover that functionality
f) All exceptions and special corner case conditions for functionality listed in the test plan.
g) Reuse/Modification Information: If validation/test code is being re-used from a different project, this should be specified and code changes to be made should be listed.
h) Functionality not to be tested(due to re-use of that portion of the design or other reasons) should be specifically noted and reviewed closely.
i) Test case constraints and coverage details for corner conditions
j) Test case error conditions for test cases in test plan.
k) Strategy for coverage of any testing/validation methodology holes.
3. Hold a Test Plan Review
Schedule a test plan review that includes the team that will be working on the tests, any design architects or product experts and and technical leads that could provide valuable test plan input. Tabulate all comments and input so that you can add to the test plan as necessary.
4. Finalize Your Test Plan
Add all the comments and input obtained during your test plan review and email out your final version to your review team to ensure that you haven’t missed anything. Place your finalized test plan in a global repository so your entire team can have access to it. Any future edits should be visible to the entire team along with test plan completion status. Product release should only take place when all the test cases on your test plan have been run successfully so continual documentation of test case completion and pass/fail statistics is necessary.
Theo eHow.com
