Custom Search

Wednesday, July 1, 2009

Testing Strategy Template

Introduction

One of the basic principles of the testing process is to plan for testing early in the development life cycle. For large projects, this starts in the analysis phase with the formulation of the Testing Strategy, which you later translate into the lower-level Testing Plan.

The Testing Strategy provides overall guidance and direction for the rest of the testing process. Preparing a Testing Strategy helps the project team think through the work at a high level, concentrating on the requirements of the testing events, the approach that will be used, and the resources necessary to complete the testing.

Testing stages in the Testing Strategy include:

· Unit Testing—The first testing is to ensure that the component meets expectations in terms of features and functionality. In almost all cases, the person that develops the component also does unit testing.

· Integration Testing—After the components have been unit tested, they are executed together. This testing verifies that the interfaces work correctly and that data is processed in its entirety as expected.

· System Testing—This is where the most rigorous testing takes place, to ensure that the solution meets the technical and environmental needs of the customer and that the solution behaves as it should. Many individual tests can be performed under the system test umbrella. These include stress testing, usability testing, security testing, performance testing, recovery testing, and multisite testing.

· Acceptance Testing—This is the final set of tests to ensure that the solution meets the business objectives and requirements. The business customers may be responsible for this testing. It requires their active participation to work with the solution, as they will when it moves to production status.

This template is designed to help you draft your own Testing Strategy. Note that the shaded text in this template is explanatory only; you should delete these comments and the example text from your version of the document.


Project Overview

Briefly discuss the project background and objectives. The appropriate information can be copied from the Project Definition document.


Business Risks

These are high-level risks of the project that will affect the overall testing strategy. For instance, the risk of doing business on the Internet may drive the need for rigorous system tests of firewalls, technical architecture, and security. The risks can be classified in terms of high, medium, and low, depending on the nature and impact of the problem. For each high and medium risk, identify which elements in the overall testing approach will help ensure that the potential problem does not occur.

Risk Area

Level (H/M/L)

Risk Plan

Example

Since this is our first system doing e-commerce on the Internet, there is a concern that security will not be tight enough.

H

· Rigorously test security with our initial partners.

· Bring in subject matter experts to validate our security design.

· Set up tests for people to try to break in to the system or get around security features.






Testing Milestones

This section contains the overall schedule at a major milestone level. The associated details will be broken down further in the Testing Plan. Since this document is created in the analysis phase, these dates are subject to later revision.

Testing Milestone

Date Completed

Example

Testing Strategy

06/01/YYYY

Testing Plan

07/01/YYYY

Unit Testing

10/01/YYYY

Integration Testing

11/01/YYYY



Testing Environment

Think through the technologies and facilities needed for the testing process. If the overall testing environment needs are understood up front, it will be easier to put the environment in place after the Test Plan is created. In addition, some parts of the environment may not be available and may need to be planned for and acquired well in advance.


Example

The developers will conduct unit testing from their offices, with no additional software required. Integration testing will also be conducted in the developer’s workspace, based on who is assigned to coordinate the major system components. System testing and user testing will be coordinated in the project war room. The war room will have six desktop machines installed, with Internet access and our standard testing tools. For system testing, we will also need access to the servers in the operations center….



Testing Approach

Describe the testing process at a high level, including how you will conduct unit testing, integration testing, system testing, and acceptance testing. This is where fundamental decisions are made about the type of testing that makes sense for your project. For instance, if you are implementing a packaged solution, the approach may start in system testing, with the vendor providing close support. If you are doing iterative development cycles, the testing approach will reflect this overall development life cycle. For system testing, define the major testing events such as stress testing, security testing, disaster-recovery testing, usability testing, and response-time testing.



Unit Testing Approach

Describe the approach for conducting unit testing to ensure that each component works according to specifications.


Example

Each developer is responsible for unit testing his or her programs as they are completed. The project manager will consider each assigned component to be completed when it has been developed and successfully unit tested. The developers will keep all test data, along with a document stating the expected results, so that these same cases can be used in the integration tests….



Integration Testing Approach

Integration testing validates that the individually tested components work correctly together.


Example

Specific developers will be assigned to coordinate the integration tests. The project manager will assign the specific parts of the system to be tested. The prior test cases created during unit testing will be used as the basis for integration testing, with new test cases added to fully test all the interfaces and dependencies. All databases should be loaded with a set of test data so that all logic can be initially tested. Reports will be created from the files that would normally be sent to our customers so that the data can be validated….



System Testing Approach

System testing is the time for fully testing all features and functions and for ensuring that production conditions are fully tested. This can include stress testing, requirements validation, security testing, customer testing, testing of the training material, etc.


Example

System testing will include many separate tests to ensure that the application will work as expected in production. The test cases from integration testing will be brought forward as the basis for system testing. During system testing, we will conduct a stress test to generate the number of transactions we feel are normal for one day and feed them through the online system within an hour. This will be in an environment that mirrors the ultimate production environment. As many tests as possible will be conducted with a subset of our trading partners, so that we can simulate the actual Web transactions going from our application to our partner’s environment….


Acceptance Testing Approach

Describe the approach for conducting business unit customer acceptance testing to ensure that the system satisfies requirements for operational functionality, procedures, and usability.


Example

The customers will have access to all of the test data that has been generated previously, but they will ultimately be responsible for generating whatever sets of transactions are required to test the system to their satisfaction. For all intents and purposes, the system will be placed in a production status, including hardware and software. They will coordinate testing with the partners as well and ensure that the resulting transactions are as they expect….


Optional Sections

The following sections can be added to the Testing Strategy if it provides more perspective and value to the reader or if the information is needed within your company.



Business Assumptions

Document any assumptions surrounding the testing strategy.

· Assumption #1

· Assumption #2

· Assumption #3

· Etc.



Testing Objectives

The project should have a set of overall objectives to be achieved. Usually these overall objectives can be broken down into a specific set of testing objectives that will be accomplished through the testing process. You can state these in terms of the overall testing results, or you can break them down into objectives for the unit, integration, system, and acceptance testing. (Remove this comment section from final document.)



Testing Organization

In this section, define the high-level organization structure for testing. This might be especially helpful for large projects where many people will be involved in various aspects of the testing process. It also would be good if an independent testing organization has responsibility for portions of the testing process. An organization chart works well here, or you can just list the various groups involved. At this point, you may not have specific names, but you should know what groups will be needed.

Testing Event

Organizations/People Involved

Example

Unit Testing

Developers

Integration Testing

Developers, DBAs, project manager

System Testing

Testing organization, developers, partners, server administration,…

Acceptance Testing

Developers, customers,…