Create a Testing Plan for your Project
by Tom Mochal

Are you tired of your projects ending up severely “challenged” and missing their commitments for schedule, budget and scope? TenStep has the full solution of products and services to help your organization successfully execute projects. Contact us today at info@TenStep.com. We will work on the best package of projects and services to meet YOUR organization’s needs.

A Testing Plan is used to describe your specific approach and the details regarding the testing of your solution. There are literally dozens of tests that can be performed on a project. If you have a large, complex project, you may need to use quite a few of the tests. However, all of the tests will not be applicable to all projects. The Testing Plan is where you define the types of tests that will be performed, what the test scenarios look like, what the expected results are, how you will track errors, who will test, where will the testing will take place, etc.

Look closely at the detail below that is included in the Testing Plan. 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 will be 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.

There is a lot of information that can go into the Testing Plan. The main information includes:

• Project Overview. This can be copied from the Project Charter. This is of benefit to team members and others that may not have had a chance to review the Project Charter.

• Testing Risks. The Testing Strategy included 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 using 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 as much detail as you know, including the dates of testing, who is responsible, how many effort hours are required, etc.

• Testing Design. Describe 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.
     
  • 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.
    
    

• Defect Management. Describe what happens when an error is discovered. This may be different depending on the test. For instance, errors uncovered in Unit Testing should just be corrected and retested. Errors uncovered in the System Test may need to be documented and addressed as a team. Errors uncovered during Acceptance Testing may need to be formally prioritized and tracked, with client involvement and signoff after retesting.

• Tracking and Monitoring. It is important to set up some process to track and monitor the status of the testing. This tracking should ensure that all test cases are exercised successfully and that the testing has client signoff if necessary. This section also describes the metrics that you are collecting and how you will know when a testing cycle is complete.

Your project team can actually start to create the data for the test cases as the cases are defined in the Testing Plan. However, creating the actual test data can be done in the Construct Phase as well. You can 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.

Large projects need to think through the testing process rigorously, starting with the Testing Strategy and followed by the Testing Plan. Medium-sized 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 probably organize the testing process in his/her head and put the appropriate activities directly into the schedule. Forms, templates and processes should also be scaled to make sure that they make sense based on the size and complexities of the project.

Each month, Tom Mochal presents techniques and processes for IT development projects.  Tom is the recent winner of the 2005 PMI Distinguished Contribution Award. His company, TenStep, Inc. develops business methodologies, including a project management process called TenStep (www.TenStep.com) and a project lifecycle process called LifecycleStep (www.LifecycleStep.com).