Test Plan

In the Project Management Plan you included a section on your quality plan.  In most cases, that section made some reference to what types of testing you would accomplish to ensure quality development; however, it was too brief to actually plan the actions that would occur during testing.  Rather its purpose was to remind you that it is necessary to allocate time in the project plan for testing and quality control.  The purpose of the test plan is to make testing systematic.  By doing so, you are likely to save time and cover more functions during testing.

Testing Principles:
bullet Make the formal technical review part of your test plan.  If you can catch programming errors in the review, you'll save yourself a lot of time during implementation.
bullet The purpose of testing is to uncover errors, so work hard at thinking about what could go wrong.  Use data that you ordinarily wouldn't expect (e.g. values out of range).
bullet Once again, the purpose of testing is to uncover errors, so design each of your test cases to look for some different kind of problem.  If they all look for the same error, then perhaps some other error goes unnoticed.
bullet Begin testing at the unit (function, class, or component) level.  Afterwards, test cooperating components.
bullet Keep your unit test cases available, so you can use them again after refactoring your code, or after integration of several components.
bullet Plan some tests from your documentation (does the application do what you say it will do:  behavior, function, and performance.
bullet Plan to test your deployment.

Test Plan Content:  Consider developing the following document:
bullet Project Introduction:  Identifies team, project purpose, application overview:  these words can be the same taken from your SRD simply to provide minimal context for the reader.
bullet Test Strategy:  Give a short (one to two paragraph or brief list) description of what activities and it what areas you will institute for testing (hint:  most of these ideas can be found in the "principles" above).
bullet Test Plan: 
bullet Procedures:  This section provides details for the activities listed above.  For each activity, provide a small set of procedures which the team must follow.
bullet Records:  - This section describes the information that the team will keep on its testing activity.  I'm am *not* looking for an expansive set of documentation here.  A simple directory structure for test cases and minimal records, such as, for example, keeping track that a class passed FTR, unit testing, and integration testing is sufficient.
bullet Test Execution:  If you keep you procedures and records streamlined and maintain your development discipline, then you will be well prepared to keep record of the outcome of your testing activities.  This record becomes the "Test Execution" part of your test document.  Of course, this record is built as you proceed through development.  In longer term projects, however, these records are useful for measuring quality and providing feedback to the development process.