Test

Test Plan Template (IEEE 829-1998 Format)
Test Plan Identifier Some type of unique company generated number to identify this test plan, its level and the level of software that it is related to. Preferably the test plan level will be the same as the related software level. The number may also identify whether the test plan is a Master plan, a Level plan, an integration plan or whichever planlevel it represents. This is to assist in coordinating software and testware versions within configuration management. • • • • Unique "short" name for the test plan Version date and version number of procedure Version Author and contact information Revision history

Keep in mind that test plans are like other software documentation, they are dynamic in nature and must be kept up to date. Thereforethey will have revision numbers. You may want to include author and contact information including the revision history information as part of either the identifier section of as part of the introduction. Introduction State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive summary part of the plan. You may want to include anyreferences to other plans, documents or items that contain information relevant to this project/process. If preferable, you can create a references section to contain all reference documents. • • • • • • Project Authorization Project Plan Quality Assurance Plan Configuration Management Plan Relevant Policies and Standards For lower level plans, reference higher level plan(s)

Identify the Scope of theplan in relation to the Software Project plan that it relates to. Other items may include, resource and budget constraints, scope of the testing effort, how testing relates to other evaluation activities (Analysis & Reviews), and possible the process to
©2001 - Software Quality Engineering - Version 7.0 A-6

be used for change control and communication and coordination of key activities. Asthis is the “Executive Summary” keep information brief and to the point. Test Items These are things you intend to test within the scope of this test plan. Essentially a list of what is to be tested. This can be developed from the software application test objectives inventories as well as other sources of documentation and information such as: • • • • • Requirements Specifications DesignSpecifications Users Guides Operations Manuals or Guides Installation Manuals or Procedures

This can be controlled and defined by your local Configuration Management (CM) process if you have one. This information includes version numbers, configuration requirements where needed, (especially if multiple versions of the product are supported). It may also include key delivery schedule issues for criticalelements. Identify any critical steps required before testing can begin as well, such as how to obtain the required item. This section can be oriented to the level of the test plan. For higher levels it may be by application or functional area, for lower levels it may be by program, unit, module or build. References to existing incident reports or enhancement requests should also be included. Thissection can also indicate items that will be excluded from testing Features To Be Tested This is a listing of what is to be tested from the USERS viewpoint of what the system does. This is not a technical description of the software but a USERS view of the functions. It is recommended to identify the test design specification associated with each feature or set of features. Set the level of riskfor each feature. Use a simple rating scale such as (H, M, L); High, Medium and Low. These types of levels are understandable to a User. You should be prepared to discuss why a particular level was chosen.

©2001 - Software Quality Engineering - Version 7.0 A-7

This is another place where the test objectives inventories can to used to help identify the sets of objectives to be tested...