Have you ever been on a development project where the testing process was not considered until the programming was already in progress? You end up trying to plan the testing process while you’re in the testing process, the test environments are probably not set up, and it’s unclear who is responsible for what. This situation can be avoided by thinking ahead and determining your testing strategy up front, well before the coding process begins.

This is the second article in a series that focuses on the testing process and its life cycle. One of the basic principles to consider is the need to plan the testing process early in the development life cycle. For large projects, the testing process starts in the analysis phase, with the formulation of the Testing Strategy, which is later translated into the lower-level Testing Plan.

It all starts with the strategy
Many of you are probably cringing at the thought of having to create these deliverables. It’s just more overhead, right? However, the content that goes into the strategy is information you’ll need to know at some point in the project anyway. The question is whether you plan early or wait so long that you have to rush through the testing decisions at the back end of the project.

You use the Testing Strategy to create the Testing Plan. The actual software testing is then just a matter of executing the plan. What could be simpler?

What to include in the Testing Strategy
During the analysis phase, you gather and validate the business requirements for the solution. It makes sense that the Testing Strategy is completed during this phase as well. In a sense, you are defining the overall testing requirements.

The purpose of the Testing Strategy is to define the overall context for the entire testing process. The process is different depending on the specific characteristics of your solution. In many respects, this is the most important part of the testing process, since all future testing decisions will be made within the context of the strategy. Here are the basic parts of the testing strategy:

  • Project Overview: You can copy this from the Project Definition.
  • 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 as high, medium, and low, depending on the nature and impact of the problem. For each high and medium risk, identify what elements in the overall testing approach will help ensure that the potential problem does not occur.
  • Testing Milestones: This section gives the reader a preliminary overview of the testing timelines. Obviously, since this document is created in the analysis phase, these dates are subject to later revision.
  • Testing Approach: This describes the testing process at a high level, including how you will conduct unit testing, integration testing, system testing, and acceptance testing. (If your project is large enough, each of these might be its own section.) This is where you make fundamental decisions regarding 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.
  • 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 break out the specific activities required to put the environment in place. In addition, you may need to plan for and acquire some parts of the environment well in advance.

Depending on your project, there may be other high-level sections to include, such as testing objectives, testing assumptions, testing organization, and testing tools, along with effort and cost estimates.

Don’t forget to get your customer involved
The Testing Strategy should be written at a high level so that it can be read and understood by the customer. Since all future testing decisions are based on the strategy, the project sponsor and other major stakeholders should approve this document.

Key points to remember
The developer’s role here is not trivial. As you contribute to this strategy document, keep these three points in mind:

  • If you are working on a large project, you need to formulate an overall Testing Strategy during the analysis phase. The Testing Strategy defines the overall approach to testing and describes how the testing process will ensure that the solution has the appropriate level of quality and reliability.
  • The Testing Strategy provides the overall guidelines from which all future testing decisions are made. A well-crafted Testing Strategy allows the rest of the testing process to be defined more effectively.
  • The Testing Strategy needs to be understood and approved by the sponsor. If the strategy is accepted, there is a much better likelihood that the final solution will meet the customer’s expectations.

Remember, you will ultimately have to live with the resulting testing process, so it may as well be a good one.

What’s next?
The Testing Strategy provides overall context, but it does not include details such as who is doing the testing, what types of tests are involved, how you will track and measure the testing process, and what you will do when errors occur. Before you can actually begin coding and testing, you need to break down the Testing Strategy into the more detailed Testing Plan. We’ll look at the Testing Plan next time. Future articles will discuss unit, integration, system, and acceptance testing.