A test plan describes how testing would be accomplished. It is a document that specifies the purpose, scope, and method of software testing. It determines the testing tasks and the persons involved in executing those tasks, test items, and the features to be tested. It also describes the environment for testing and the test design and measurement techniques to be used. Note that a properly defined test plan is an agreement between testers and users describing the role of testing in software.
A complete test plan helps the people who are not involved in test group to understand why product validation is needed and how it is to be performed. However, if the test plan is not complete, it might not be possible to check how the software operates when installed on different operating systems or when used with other software. To avoid this problem, IEEE states some components that should be covered in a test plan. These components are listed in Table.
Assigns responsibilities to different people and keeps them focused.
Avoids any misinterpretation of schedules.
Provides an abstract of the entire process and outlines specific tests. The testing scope, schedule, and duration are also outlined.
Communication plan (who, what, when, how about the people) is developed.
Identifies areas that are critical for success.
Specifies the way in which a defect should be documented so that it may reoccur and be retested and fixed.
Describes the data, interfaces, work area, and the technical environment used in testing. All this is specified to reduce or eliminate the misunderstandings and sources of potential delay.
A carefully developed test plan facilitates effective test execution, proper analysis of errors, and preparation of error report. To develop a test plan, a number of steps are followed, as listed below.
Set objectives of test plan: Before developing a test plan, it is necessary to understand its purpose. But, before determining the objectives of a test plan, it is necessary to determine the objectives of the software. This is because the objectives of a test plan are highly dependent on that of software. For example, if the objective of the software is to accomplish all user requirements, then a test plan is generated to meet this objective.
Develop a test matrix: A test matrix indicates the components of the software that are to be tested. It also specifies the tests required to check these components. Test matrix is also used as a test proof to show that a test exists for all components of the software that require testing. In addition, test matrix is used to indicate the testing method, which is used to test the entire software.
Develop test administrative component: A test plan must be prepared within a fixed time so that software testing can begin as soon as possible. The purpose of administrative component of a test plan is to specify the time schedule and resources (administrative people involved while developing the test plan) required to execute the test plan. However, if the implementation plan (plan that describes how the processes in the software are carried out) of software changes, the test plan also changes. In this case, the schedule to execute the test plan also gets affected.
Write the test plan: The components of a test plan such as its objectives, test matrix, and administrative component are documented. All these documents are then collected together to form a complete test plan. These documents are organized either in an informal or formal manner.
In the informal manner, all the documents are collected and kept together. The testers read all the documents to extract information required for testing the software. On the other hand, in a formal manner, the important points are extracted from the documents and kept together. This makes it easy for testers to extract important information, which they require during software testing.
A test plan has many sections, which are listed below.
Overview: Describes the objectives and functions of the software to be performed. It also describes the objectives of test plan such as defining responsibilities, identifying test environment and giving a complete detail of the sources from where the information is gathered to develop the test plan.
Test scope: Specifies features and combination of features, which are to be tested. These features may include user manuals or system documents. It also specifies the features and their combinations that are not to be tested.
Test methodologies: Specifies the types of tests required for testing features and combination of these features such as regression tests and stress tests. It also provides description of sources of test data along with how test data is useful to ensure that testing is adequate such as selection of boundary or null values. In addition, it describes the procedure for identifying and recording test results.
Test phases: Identifies different types of tests such as unit testing, integration testing and provides a brief description of the process used to perform these tests. Moreover, it identifies the testers that are responsible for performing testing and provides a detailed description of the source and type of data to be used. It also describes the procedure of evaluating test results and describes the work products, which are initiated or completed in this phase.
Test environment: Identifies the hardware, software, automated testing tools; operating system, compliers and sites required to perform testing, as well as the staffing and training needs.
Schedule: Provides detailed schedule of testing activities and defines the responsibilities to respective people. In addition, it indicates dependencies of testing activities and the time frames for them.
Approvals and distribution: Identifies the individuals who approve a test plan and its results. It also identifies the people to whom the test plan document(s) is distributed.