[Introduction to the Template

Description: The Test Plan describes the strategy and approach used to plan, organize, and manage the project’s testing activities. It identifies testing objectives, methodologies and tools, expected results, responsibilities, and resource requirements. This document is the primary plan for the testing team.

Justification:  A Test Plan ensures that the testing process will be conducted in a thorough and organized manner and enable the team to determine the stability of the solution. A continuous understanding of the solution’s status builds confidence in team members and stakeholders as the solution is developed and stabilized.

{Team Role Primary: Test is responsible for the creating the Test Plan. This plan outlines the strategy the team will take for the solution’s testing. The Test Role is responsible for setting the quality expectations and incorporating those into the testing plan.

Team Role Secondary: Program Management participates in developing the test plan by ensuring that the solution requirements are met, the correct components are tested, and appropriate strategies are adopted for bug reporting and resolution. Development needs to understand how their work will be tested and how the bugs will be reported, assigned, resolved, and verified. User Experience verifies that the Test Plan contains the strategies and methods to test accessibility, usability, and interface features.}]

Summary

[Description: Provide an overall summary of the contents of this document.

Justification: Some readers may need to know only the highlights of the plan, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.]

<<Begin text here>>

Objectives

[Description: The Objectives section identifies the Test Plan’s objectives. The following list of objectives may apply to the project. Include any additional objectives specific to the project.

• To identify the activities required to prepare for and conduct testing
• To define the test scope, strategy and methodology to be used for the test
• To identify configuration controls and metrics
• To define metrics and status reporting
• To identify responsibilities for the tasks included in the plan
• To define the test tools and the environment needed to conduct the test
• To identify test interactions with other organizations
• To identify test customers and deliverables
• To identify the major testing milestones
• To define the sources of information used to prepare the plan

Justification: Identifying objectives ensures that the plan’s authors have carefully considered the situation and solution and created an appropriate testing approach.]

<<Begin text here>>

Test Approach & Assumptions

[Description: The Test Approach & Assumptions section describes at a high level the approach, activities, and techniques (including techniques for designing tests) to be followed in testing the solution. If different approaches are required for the solution’s various components, this section should define which components would be tested by each approach.

This section also describes the processes (criteria and techniques) that will be used to verify that the testing approach chosen will effectively guarantee the required degree of test completeness. A process could be as simple as requiring all appropriate groups to review, comment, and sign off on the document. A process could be more complex, requiring the use of tools to verify statement and path coverage.]

<<Begin text here>>

Major Test Responsibilities

[Description: The Major Test Responsibilities section identifies the teams and individuals who will be both managing and executing the testing process. This information could be placed in a matrix that identifies each key element of the testing process and the people who will participate in that process.]

<<Begin text here>>

Features and Functionality to Test

[Description: The Features and Functionality to Test section identifies at a high level all features and functionality or all user and usage functionality that will be tested. Sufficient detail is required to allow plan reviewers to determine if any major area, feature, or test modes are being left out or insufficiently covered. For documentation testing (e.g. procedures or guidelines – such as installation and configuration methods), list the documents by name and indicate their intended audience and expected content. Briefly describe the standards that will be employed in verifying their usability, correctness, and completeness. Some examples of the information to be included in this section are

• Specific features to be tested
• Whether testing will include unsupported functionality
• The types of facility (feature) testing to be performed
• The types of error testing to be performed
• The types of stress/load testing to be performed
• The type of usability testing to be performed
• The type of reliability testing to be performed
• The type of recovery testing to be performed
• The type of manageability testing to be performed
• The type of compatibility/migration testing to be performed
• The type of security testing to be performed
• The types of software and hardware to be employed if testing is to be performed over multiple software and hardware configurations (configuration testing)

This section may be developed using a table that indicates for each feature, function, user, or usage function (horizontal headings), the types of testing applicable to each (vertical left headings).]

<<Begin text here>>

Expected Results of Tests

[Description: The Expected Results of Tests section describes what results should be demonstrated from the tests. This information should include expectations by both by the solution team and the tester(s). This section should also define if the results must be exactly as anticipated or if a range of results is acceptable.]

<<Begin text here>>

Deliverables

[Description: The Deliverables section describes the materials that must be made available or created in order to conduct the tests and that will be developed from the tests to describe test results.]

<<Begin text here>>

Test Documentation

[Description: The Test Documentation section itemizes all documentation that records the activities of the testing process (procedures, configurations, plans, action items, etc.). For each document, describe the specific information each will contain. The set of documents may include:

• Test bed configurations
• Test logs
• Periodic test status reports
• Input to release retrospective
• Test results summary report at the completion of testing
• Final release note documentation]

<<Begin text here>>

Test Data

[Description: The Test Data section identifies any existing test data that will be used during the testing, either as is or with modifications. It also identifies any test data that will need to be created for testing.]

<<Begin text here>>

Interactions with Other Organizations

[Description: The Interactions with Other Organizations section identifies all interfacing organizations that will participate in the testing. It describes the normal interactions that will take place during the test process between the primary test team and all other participating organizations. This should include a description of the type of support expected to/from each interfacing organization.

{Team Role Primary: Program Management will manage these organizational interfaces as they have a broad view of the project.

Team Role Secondary: Test}]

<<Begin text here>>

Testing Procedures and Walkthrough

[Description: The Testing Procedures and Walkthrough section provides a general description of the steps the tests will go through to ensure quality tests.]

Testing Setup

[Description: The Testing Setup section identifies the approach and procedures that will be used for the initial phase of the test. This approach should define the steps of the set up process. The set up process should include the staging requirements for the testing and procedures to initialize the testing matrix.]

<<Begin text here>>

Testing Procedures

[Description: The Testing Procedures section describes the detailed steps to be followed by testers during the testing cycle. It should include a description of points where testing is suspended for documentation of results, expectations on re-initialization of the environment, and tests that are to be performed in sequence.]

<<Begin text here>>

Testing Walkthrough

[Description: The Testing Walkthrough section describes how the planned testing procedures will be reviewed to ensure quality. The walkthrough identifies who will participate, what specifically will be reviewed, and how the walkthrough will be conducted.]

<<Begin text here>>

Tracking and Reporting Status

[Description: The Tracking and Reporting Status section defines what information test team members will communicate during the testing process. It defines the specific test status information that will be created and distributed. This normally includes status information on each test case (percent planned, developed, automated, executed, passed, failed, and blocked) and the probability of completing the test cycle on schedule.]

<<Begin text here>>

Test Resource Requirements

[Description: The Test Resource Requirements section identifies the environmental conditions, staffing and training, and tools needed to conduct the tests successfully.]

Environmental Needs

[Description: The Environmental Needs section itemizes all supplies required for testing and any auxiliary support tasks. This section should be broken into separate subsections devoted respectively to the hardware, software, data resources and documentation required for testing.

Any resource-sharing requirements between releases and among testers should be described here. If a separate integration test environment is not planned, then the sharing of resources between integration and system/documentation testing should be described as well. If a separate solution test environment is not planned, then the sharing of resources between system/documentation and solution testing should also be described.]

<<Begin text here>>

Staffing & Training Needs

[Description: The Staffing & Training Needs section identifies the staff necessary to accomplish the test effort. It should also identify if these requirements are expected to vary over the life of the test cycle. Staff requirements should be articulated by type (skill area) and number (if more than one). If staff will require additional training, this section should describe those needs and indicate how they will be met.]

<<Begin text here>>

Test Tool Requirements

[Description: The Test Tool Requirements section describes any additional hardware, tools, and/or simulators that are needed to support testing the solution. This should include information on where the tools are located, whether existing tools need modification, or if new tools must be developed.]

<<Begin text here>>

Bug Reporting Tools and Methods

[Description: The Bug Reporting Tools and Methods section describes the overall bug reporting strategy and methodology. It also defines what will qualify as a bug in the code, product features, documentation, etc.]

Bug Reporting Tool Strategy

[Description: The Bug Reporting Tool Strategy section identifies the bug reporting tool standards and strategy for implementation.]

<<Begin text here>>

Bug Classification Strategy

[Description: The Bug Classification Strategy section defines the process that will be used to classify bugs. This should include the categories of bugs and how they will be quantified. If a tool or spreadsheet is planned, include a visual image of the tool metrics that demonstrates how bugs will be quantified and classified.]

<<Begin text here>>

Triage Strategy

[Description: The Triage Strategy section describes how bugs will be triaged for resolution after quantification and classification. It describes the criteria for assigning a bug to immediate resolution versus placing it in a priority queue.]

<<Begin text here>>

Bug Closure Criteria

[Description: The Bug Closure Criteria section identifies the criteria that will be used to determine that a bug is resolved. It also describes the resolution path to ensuring that a bug is closed and has sign-off.]

<<Begin text here>>

Schedules

[Description: The Schedules section identifies the major test cycles, tasks, milestones, and deliverables. It also describes who is responsible for each test cycle and its tasks. In addition, it identifies the expected start and completion date for each test cycle and the tasks within that cycle. This section should identify all tasks that will require coordination with other groups or involve deliverables to or from outside organizations.

Justification: The test schedule will be incorporated into the Master Project Plan.]

<<Begin text here>>

Risks & Dependencies

[Description: The Risks & Dependencies section identifies three items: assumptions, risks, and dependencies. The assumptions are those that have been made while developing the test plan. The risks are those that arise from either the assumptions or that are anticipated during the testing process. For each risk, indicate the probable impact if the assumption turns out to be incorrect, and the measures employed to correct the situation. Dependencies include things such as the development plan and functional specifications that will help create details for the test plan procedures.

Justification: Identifying risks early enables the team to begin managing those risks.]

<<Begin text here>>

Open Issues

[Description: The Open Issues section identifies any key concerns and tasks that need to be followed up on in order to ensure the plan’s completeness.]

<<Begin text here>>

Appendix

Appendix A – Test Case Specification Example

[Description: Provide an example of a Test Case Specification.]

<<Begin text here>>