Topic: Components of A Good Software Test Plan

What is Software Test Plan and what are the components of A Good Software Test Plan?

Software Test Plan represents objectives of the testing, scope of testing, testing approach, assumptions in testing, dependencies in testing, risks in testing, and schedule for the appropriate test phase or phases. Many test organizations will use the test plan to describe the testing phases, testing techniques, testing methods, and other general aspects of any testing effort. General information around the practice of testing should be kept in Testing Standards. This avoids redundant and conflicting information being presented to the reader and keeps the Test Plan focused on the task at hand - planning the testing effort.

Objectives of Software Testing Efforts

Objectives of the current software testing effort need to be clearly mentioned and understood by the software testing / QA team. The primary objectives for software testing should relate to the purpose of the current release.
The test objective describes why the testing efforts are required. The scope of software testing describes what is required for the testing efforts. Once again any general testing objectives should be documented in the "Best Practices" repository. General or common objectives for any testing effort could include; expanding the test case regression suite, documenting new requirements, automating test cases, updating existing test cases, and so on.

In the Scope

The components of the application or system to be tested (hardware, software, middleware, etc.) need to be clearly defined as being "In the Scope" components. This can take the form of an itemized list of the in scope: requirements, functional areas, systems, business functions, or any aspect of the system that clearly delineates the scope to the testing team. The "What is to be tested" question should be answered by in the scope portion of the test plan.

Out of the Scope

The components of the system that will not be tested also need to be clearly defined as "Out of Scope" components. This does not mean that these system components will not be executed; just that test cases will not be included that specifically tests these system components. The "What is NOT to be tested" question should be answered by the out of scope portion of the test plan. Often neglected this part of the test plan begins to deal with the risk based scheduling that all test organizations must address - What parts of the system can I afford not to test? The testing approach section of the test plan should address this question.

Approach in Software Test Plan

This Approach in Software Test Plan defines the testing activities for the application or the system in the current testing phase. This addresses how testing will be accomplished against the in scope aspects of the system and any mitigating factors that may reduce the risk of leaving aspects of the system out of scope. The approach should be viewed as a "to do" list that will be fully detailed in the test schedule. The approach should clearly state which aspects of the system are to be tested and how - Backup / Recovery Testing, Compatibility/Conversion Testing, Destructive Testing, Environment Testing, Interface Testing, Parallel Testing, Procedural Testing, Regression Test, Security Testing, Storage Testing, Stress & Performance Testing, and any other testing approach that is applicable to the current testing effort. The reasoning for using any given set of approaches should be described, usually from the perspective of risk.

Assumptions by the Test Team

Assumptions are statements or facts which the Test Team believes to be true - assumptions specific to each testing phase should be documented. These are the assumptions upon which the test approach was based - listed assumptions also can cause risks and there may be a negative impact on the testing activities if they are proved to be incorrect. In any environment there is a common set of assumptions that apply to any given release. These common assumptions should be documented in the "Best Practices" repository, only assumptions unique to the current testing effort should be documented and perhaps those common assumptions critical to the current situation.

Dependencies in Testing Efforts

Events or milestones that must be completed in order to proceed within any given testing activity are called Dependencies. These are the dependencies that will be presented in the test schedule. In this section the events or milestones which are deemed critical to the testing effort should be listed and any potential risks to the testing schedule itemized.

Risks in Testing Efforts

Risks are the factors that could negatively impact the testing effort. An itemized list of risks should be drawn up and their potential impact on the testing effort described. Risks that have been itemized in the Project Plan need not be repeated here unless the impact to the testing effort has not already been clearly stated.

Testing Schedule

Testing Schedule defines when and by whom testing activities will be performed. The information gathered for the body of the Test Plan is used here in combination with the available resource pool to determine the test schedule. Experience from previous testing efforts along with a detailed understanding of the current testing goals will help make the test schedule as accurate as possible. There are several planning / scheduling tools available that make the plan easier to construct and maintain.