I found a table of contents ..
TEST PLAN OUTLINE
(IEEE 829 Format)
1. Test Plan Identifier
4. Test Items
5. Software Risk Issues
6. Features to be Tested
7. Features not to be Tested
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
17. Planning Risks and Contingencies
Test plan (IEEE) Documentation specifying the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, responsibilities, required resources, and any risks requiring contingency planning. See: test design, validation protocol.
It doesnt matter whether a cat is black or white so long as it catches mice
Test cases are often confused with checkpoints. A check point is a single point within a set of test steps which a value can be checked. Even some professional bodies have made this mistake. A test case is synonimous with a business case, although there does not necessarily mean a 1:1 relationship. A test case must clearly define its own purpose and expected results. Also a test case must be traceable back to a functional spefication and/or a Business Requirement. Another area that causes confusion is Scenario's. My personal approach to this is that you have a basic test case which several scenarios can apply (i.e. variations on input which cause variation in functional behaviour). This may mean you will excute steps using several different inputs, achieving varying functional behaviour to complete the test case.