How to Test Plan document
A test plan is a document that describes the approach that will be taken in order to test a product or system. This product/system can consist of hardware, software, or any combination of the two. The main purpose of the test plan is to document the strategy that will be used to verify that a product or system satisfies all design requirements and specifications so before a test plan can be prepared, it is necessary to obtain all requirements and specification documents used in the design of the product or system.
The test plan describes the testing objectives, the testing scope, the testing approach, and the methodology used to conduct testing. It is also important to identify all of the resources required to perform testing. So any hardware, software, and other tools required for testing should be included in the document. It will also indicate the functions and features that are going to be investigated and any known risk factors. In addition to all of this key information, a good test plan will go a step further and establish a testing schedule for the audience. Depending on the size and complexity of the product or system being tested, it is common practice for some business groups to create a high level test plan to provide an overview of all requirements and supplement it with supporting test plans that detail the elements of the subsystem. For example, if a system consists of both hardware and software, an organization may choose to have one plan for the hardware and another for the software.
The formatting for test plan documents usually varies depending on the products and the organizations product them. That is, the format for a plan detailing testing for a hardware product may be very different from a plan detailing a software system. And Organization A may require a different format than one required by Organization B. Despite these differences, most test plans share three basic elements: coverage, methods, and responsibilities.
Coverage refers to the identification of which requirements will be verified during testing. This also includes identification of the phases of the product life in which it will be tested. Product life phases are used because coverage for some phases may overlap, but may not be the same for all stages being tested. In order to determine the test coverage, the design requirements and specifications must be closely examined. Other items such as safety standards or regulatory codes should be reviewed as well. It is a good idea for the design team to keep test coverage in mind during the design process because the product may need to be designed in a manner that allows certain accesses for testing.
Test methods simply states how the test coverage will be implemented. These methods can range from something as simple as a visual inspection to an elaborate series of steps to be performed. Test methods always specify the resources required to perform testing and detail the pass/fail criteria that the tester must adhere to. Sometimes the organization has complete freedom in designating test methods but they are often driven by contractual agreements, industry standards, and/or regulatory agencies.
Test plans also indicate which group or groups within the organization will be responsible for performing the test. Responsibilities may be assigned to different people or groups for different methods and at different phases of the product life. This allows test organizations to schedule resources (people, equipment, space, etc.) and plan necessary equipment acquisitions in order to implement the test methods for which they are responsible. The deliverables are also detailed in the test plan responsibilities. Deliverables consist of the data that is to be collected, method of data reporting, and method of data storage.
Going through the process of preparing test plans help organizations to think through the efforts needed to validate the acceptability of the product that the produce and may provide some insight for future product design. The document itself will help people outside the organization understand what was done to validate the product.