Developer

Hammer out your tactical testing decisions with a Testing Plan

A software Testing Plan spells out what tests you will be performing, as well as the people, equipment, methods, and timing involved. Follow these guidelines to develop your plan, and you'll sail through the actual testing process.


A key part of the software testing life cycle is the Testing Strategy, which provides the overall guidance and direction for how the software solution will be tested. However, just as you cannot start writing code directly from the business requirements, you cannot start the testing events until you translate the strategy to lower-level detail. That is the purpose of the Testing Plan.

You create the Testing Plan during the design phase of the project. As you will see in upcoming columns, there are dozens of tests you can perform during the testing process. The Testing Plan defines what types of tests will be performed, what the test scenarios look like, what the expected results are, how you will track errors, who will test, where the testing will take place, etc. All of these details must be worked out before you can perform the testing process.

The question is whether you wait until the construction phase begins to start planning or whether you plan them ahead of time. Creating the Testing Plan during the design phase allows you to be prepared for testing before it begins and gives you confidence that your solution is being tested appropriately. If you create a comprehensive Testing Plan, you will find that all the tactical testing decisions have been made. All that is left is to execute the plan you have just created.

What to include in the Testing Plan
A lot of information can go into the Testing Plan. The main information includes the:
  • Project Overview. This can be copied from the Project Definition.
  • Testing Risks. The Testing Strategy includes the overall business risks related to testing. The Testing Plan contains any risks associated with the actual testing process. For instance, not having enough testing time would be a risk, as would the use of a testing tool for the first time. For each high- and medium-level risk, describe what you are doing to mitigate the potential problem.
  • Testing Schedule. Describe the testing process in detail, including the specific dates of testing, who is responsible, how many effort hours are required, etc.
  • Testing Design. Describe in detail how the unit tests, integration tests, system tests, and acceptance tests will be performed. Each testing stage should have its own section in the Testing Plan:

—Identify who is responsible for each stage of the testing process.

—Determine who will approve the results of each testing stage and how the approval will take place. For instance, each developer may approve his or her own unit test results, but the project manager may approve the integration test results.

—Describe the testing environment in detail, including the techniques and tools to be used. Describe the physical environment where the testing will occur and what equipment and tools are needed.

—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. (In future columns, I will describe each of the testing stages in more detail, including the various types of tests that can be performed.)

—Note the templates and tools being used. This includes automated testing tools, error logs, test cases, use case definitions, etc. Include samples of the various forms and templates in the appendices.

Some project teams actually lay out test cases as a part of the Testing Plan, although my preference is to hold off on that level of detail until the construction phase. You can, however, include other information that will help you plan the details of the testing process, including any specific testing methodology you are using, testing assumptions, testing metrics, etc.

Customer involvement in the Testing Plan
If the customer approved the overall Testing Strategy, they do not need to approve the Testing Plan. The plan is really more of an IT document that describes the specifics of how the testing will be carried out. Of course, some sections of the Testing Plan must be communicated to the customer, especially portions of the system test and the user acceptance test.

Scaling the Testing Strategy and Testing Plan
With large projects, you need to think through the testing process rigorously, starting with the Testing Strategy and followed by the Testing Plan. For the purposes of this series, we’ll assume that we’re executing a large project. Medium-size projects can probably combine sections of the Testing Strategy into the Testing Plan and get by with one document. For small projects, the project manager can organize the testing process in his or her head and put the appropriate activities directly onto the workplan. You should also scale forms, templates, and processes to ensure that they make sense based on the size and complexities of the project.

What, when, why
Here are the key points to remember about the Testing Plan:
  • The Testing Plan breaks down the high-level Testing Strategy to a point where all the testing details are laid out.
  • You should create the Testing Plan in the design phase, before the testing process begins. If you wait until the testing process is under way before you think through your Testing Plan, you may find that you will have done extra work or that you have skipped a critical part of the process.
  • If you create a comprehensive Testing Plan, the actual execution of the unit, integration, system, and acceptance tests becomes nothing more than following the plan you have already set.

What’s next?
In the next column, we’ll explore the testing that many of you are most familiar with—our friend the unit test. Individual components are first tested independently during unit testing.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.

Editor's Picks

Free Newsletters, In your Inbox