Quotation of the Day

Custom Search

Friday, July 3, 2009

Testing Plan Template

Project Overview

(Optional) In this section, briefly discuss the project background and objectives. The appropriate information can be copied from the Project Definition document.

Testing Risks

Testing risks are circumstances and events that may occur before or during testing that would have an adverse impact on the testing process. For each high- and medium-level risk, determine what activities you will do to ensure that the risk does not occur. These risk plan activities should also be moved to the project workplan.

Testing Risk

Level (H/M/L)

Risk Plan

Example

The team is not familiar with the Web testing tools we will be using on this project.

H

· Try to find at least one person who has used the tools before.

· Send at least two team members to formal training.

· Set up follow-up training sessions to cross-train the rest of the developers.

Testing Schedule

This section contains a summary of the overall testing schedule. It is not at the activity level, but it should contain more detail than the major milestones included as a part of the Testing Strategy.

Testing Milestone/Events

Date Started

Date Completed

Example

Testing Strategy

05/15/YYYY

05/31/YYYY

Testing Plan

06/01/YYYY

06/30/YYYY

Unit Testing

08/15/YYYY

10/10/YYYY

—Test scripts turned in to project manager

10/10/XXXX

Integration Testing

—Integration coordinators assigned

09/15/YYYY

09/23/YYYY

—Integration testing

10/01/YYYY

11/01/YYYY

—Integration tests approved and scripts turned in

10/20/YYYY

11/01/YYYY


Unit Testing Design

Unit testing is the first and most basic level of testing. The testing focuses on individual components and is usually performed by the person who developed the component.

Person Responsible

Define the person responsible for the unit testing.

Person(s) Approving

Define the person(s) or organization responsible for approving individual unit tests and for validating that the component is ready to be moved to the next level of testing.

Test Environment

Describe any noteworthy features of the unit test environment, including location, equipment needed, software or tools used, etc.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc. (A formal validation may not be needed for unit testing.)

Forms Used

Check the TechRepublic download library for unit test templates available in the future.


Integration Testing Design

Integration testing involves combining the individual components into the complete solution. The purpose is to test the interfaces between the various components and to ensure that the entire solution works as a whole according to the business requirements.

Person Responsible

Define the person responsible for the integration testing.

Person(s) Approving

Define the person(s) or organization responsible for approving the integration test and for validating that the group of components is ready to be moved to the next level of testing.

Test Environment

Describe any noteworthy features of the integration test environment, including location, equipment needed, software or tools used, etc.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc.

Forms Used

Check the TechRepublic download library for integration test templates available in the future.


System Testing Design

System testing is the most important and complex of the testing stages and can consist of multiple subtests. System testing validates the overall requirements of the solution in terms of quality, performance, and functionality. The system test may include subtests such as the following:

· Requirements validation ensures that the solution satisfies the documented business requirements.

· Stress testing proves that the solution can handle heavy volumes of data, transactions, concurrent users, etc.

· Security testing ensures that the proper level of security and internal controls are in place.

· Disaster-recovery testing shows the solution’s ability to be recovered in case of disaster or massive failure.

· Usability testing determines how well the user will be able to use and understand the application. It identifies areas of poor human factors design that may make the system difficult to use.

· Procedures validation determines whether the user procedures and overall documentation is accurate and understandable.

Person Responsible

Define the person or group responsible for the system testing.

Person(s) Approving

Define the person(s) or organization responsible for approving the system testing and for validating that the solution is ready to be moved to the next level of testing.

Test Environment

Describe any noteworthy features of the system test environment, including location, equipment needed, software or tools used, etc. Many tools, processes, and locations may be needed for system testing that will not be used elsewhere on the project.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc.

Forms Used

Check the TechRepublic download library for system test templates available in the future.


Acceptance Testing Design

Acceptance testing is designed for the customer to prove that the solution meets the original business requirement. In many cases, the customer is responsible for this testing since when the solution is completed successfully, it is expected that the customer will approve and accept it. Customers need to test the solution as they would expect to use it in production and then work with the project team to validate that the results come out as expected.

Person Responsible

Define the person or group responsible for the acceptance testing.

Person(s) Approving

Define the person(s) or organization responsible for approving the acceptance testing and for validating that the solution is ready to be moved into production. This level of approval should signify customer acceptance of the completed solution.

Test Environment

Describe any noteworthy features of the acceptance test environment, including location, equipment needed, software or tools used, etc.

Testing Process and Validation

Describe the testing logistics in some detail. This includes the types of tests to be performed, what you are trying to validate, how you will know if you are successful, how you will report errors, how the errors will be retested, etc.

Forms Used

Check the TechRepublic download library for acceptance test templates available in the future.

Optional Sections

You can add the following sections to the Testing Strategy if they provide more perspective and value to the reader or if the information is needed within your company.

Testing Methodology

Describe any specific methodology or standards that will help the reader understand the rationale behind each part of the Testing Plan.

Testing Assumptions

Document any assumptions surrounding the testing plan.

· Assumption #1

· Assumption #2

· Assumption #3

· Etc.

Testing Metrics

Describe any metrics you will capture as part of the testing process, such as total components tested, total defects per testing event, average time for defect correction, total number of hours spent on testing, total cost of testing, etc.

No comments: