Test Plan is the scheduler for entire Testing process. The Test Plan describes the approach to all development, unit, integration, system, qualification and acceptance testing needed to complete a project properly.
You should be aware that many people use the term 'test plan' to describe a document detailing individual tests for a component of a system. We are introducing the concept of high level test plans to show that there are a lot more activities involved in effective testing than just writing test cases.
Why is this important?
Establishing a test plan based on business requirements and design specification is essential for the successful acceptance of a project's deliverables. It is important to note that the higher risk a project has, the greater the need for a commensurate amount of testing. The project Schedule & Task Plan and the project Staffing Plan need to account for testing requirements during the planning and execution phases of the project.
Testing validates the requirements defined for the projects objectives and deliverables. Though IT project practices require testing throughout the execution phase of a project, undoubtedly the most important testing occurs at the end of development and prior to deployment. Orderly test plans that specify the criteria for test passage or failure are critical to a project's success.
Prepare a Test Plan describing the scope, processes and criteria for testing particular deliverables of the project. The plan should describe the following elements:
1. Provide an overview:
Describe project objectives and background (providing some context for the testers). - Give a short system description. - Define the Test Plan objectives. - Provide testing references as required. - Note any outstanding issues, assumptions, known risks and contingencies.
2. Define test scope, (features to be tested; Features not to be tested).
3. Describe test methodologies.
4. Describe testing approach. - Describe test data (test cases, system and user interface test cases, user acceptance test plans, status reports of testing, and test outcome report at the end of testing detailing the overall results of testing progress). - Provide all test documents. - Validate test requirements. - Define test control procedures, (for example, classification code and prioritization scheme for error tracking and resolution; tracking mechanisms for test results such as a test case validation log or test error log).
5. Define and describe test phases. For each test phase such as unit, integration, system, etc., identify definition, participants, data sources, entrance and exit criteria, requirements and work products.
6. Define the test environment, (description of hardware, software, location, staffing and training).
7. Schedule testing tasks and make resource assignments.
8. Define test approvals process and result distributions.
How to Scale
The size and nature of the project requirements should determine the scale of the test plan. The actual test methods and techniques must be adapted to the type of project being developed and the testing environment and tools that are available. Project managers need to think about the purpose of the testing, keeping in mind the process and stages for testing. Best practices dictate that testing be done early and often.
IEEE Standard for Software Test Documentation
(ANSI/IEEE Standard 829-1983)
This is a summary of the ANSI/IEEE Standard 829-1983. It describes a test plan as:
"A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning."
This standard specifies the following test plan outline:
Test Plan Identifier:
1. A unique identifier
1. Summary of the items and features to be tested
2. Need for and history of each item (optional)
3. References to related documents such as project authorization, project plan, QA plan, configuration management plan, relevant policies, relevant standards
4. References to lower level test plans
1. Test items and their version
2. Characteristics of their transmittal media
3. References to related documents such as requirements specification, design specification, users guide, operations guide, installation guide
4. References to bug reports related to test items
5. Items which are specifically not going to be tested (optional)
Features to be Tested
1. All software features and combinations of features to be tested
2. References to test-design specifications associated with each feature and combination of features
Features Not to Be Tested
1. All features and significant combinations of features which will not be tested
2. The reasons these features wont be tested
1. Overall approach to testing
2. For each major group of features of combinations of features, specify the approach
3. Specify major activities, techniques, and tools which are to be used to test the groups
4. Specify a minimum degree of comprehensiveness required
5. Identify which techniques will be used to judge comprehensiveness
6. Specify any additional completion criteria
7. Specify techniques which are to be used to trace requirements
8. Identify significant constraints on testing, such as test-item availability, testing-resource availability, and deadline
Item Pass/Fail Criteria
1. Specify the criteria to be used to determine whether each test item has passed or failed testing
Suspension Criteria and Resumption Requirements
1. Specify criteria to be used to suspend the testing activity
2. Specify testing activities which must be redone when testing is resumed
1. Identify the deliverable documents: test plan, test design specifications, test case specifications, test procedure specifications, test item transmittal reports, test logs, test incident reports, test summary reports
2. Identify test input and output data
3. Identify test tools (optional)
1. Identify tasks necessary to prepare for and perform testing
2. Identify all task interdependencies
3. Identify any special skills required
1. Specify necessary and desired properties of the test environment: physical characteristics of the facilities including hardware, communications and system software, the mode of usage (i.e., stand-alone), and any other software or supplies needed
2. Specify the level of security required
3. Identify special test tools needed
4. Identify any other testing needs
5. Identify the source for all needs which are not currently available
Testing is performed using hardware with the following minimum system requirements:
133 MHz Pentium
Microsoft Window, 98
32 MB RAM
10 MB available hard disk space
A display device capable of displaying 640x480 (VGA) or better resolution
Internet connection via a modem or network
1. Identify groups responsible for managing, designing, preparing, executing, witnessing, checking and resolving
2. Identify groups responsible for providing the test items identified in the Test Items section
3. Identify groups responsible for providing the environmental needs identified in the Environmental Needs section
Staffing and Training Needs
1. Specify staffing needs by skill level
2. Identify training options for providing necessary skills
1. Specify test milestones
2. Specify all item transmittal events
3. Estimate time required to do each testing task
4. Schedule all testing tasks and test milestones
5. For each testing resource, specify its periods of use
Testing scheduling and status reporting are performed by the Project Lead and project Administrator to monitor progress towards meeting product testing schedules and release date, as well as to identify any project scheduling risks. Each build will be tested before next subsequent build date. Software testing schedules will coincide with module development and release schedules
Risks and Contingencies
1. Identify the high-risk assumptions of the test plan
2. Specify contingency plans for each
1. Specify the names and titles of all persons who must approve the plan
2. Provide space for signatures and dates