The Ten-Minute Test Plan
Here's how to get started on an effective and meaningful test plan.
by Jeff Gainer
Posted September 29, 2003
The discipline of writing a test plan requires you to stop, think, and evaluate how you're going to test and why. It also requires you to think about essential issues that are easily overlooked—such as when you're ready to test, and how to determine how much testing is enough. What follows is an overview of the essentials for an effective, meaningful test plan. Sure, it's easy enough to Google "test plan" and copy something from the Net, replacing the project name and a paragraph or two. But that's not a test plan—it's just a bureaucratic exercise. Your test plan must address the specifics of your project and provide realistic, detailed plans for action.
Testing Scope
This is where you'll detail what you're going to test—and just as importantly—what you're not going to test. Use this initial section to present a high-level overview of the application and detail testing approaches. Will you be performing only black-box functionality tests? Will performance testing be a concern? If so, what are the criteria you are testing against? Be sure to identify requirements, where they are, and how you will insure that you have the correct version.
Entry and Exit Criteria
When are you ready to test? For starters, you'll need the hardware, necessary software, and probably several versions of test data. You'll need some form of configuration management system to "roll back" test data to a pre-test condition between test cycles.
An essential prerequisite to testing is having a fully functioning version of the application to be tested. This seemingly obvious criterion is often overlooked—perhaps because it seems so self-evident. Yet I've seen test labs and teams all dressed up with no place to go, simply because the development team thought they sent a full build, yet some crucial component was missing. So be sure to include specifics about how the application will be packaged and delivered to the test team. Be sure to have a single point of contact from the development team who you can turn to if there are build issues.
Staffing, Roles, and Responsibilities
This is where you make your case for staffing. How many people will you require? What roles will they fill? What qualifications or training will your staff need? Contrary to popular myth, there is no rule-of-thumb ratio that prescribes y number of testers vs. x number of developers. The number of testers required is a function of how much testing work the team needs to complete, not the number of developers creating the application. In addition to the number of people to develop and execute tests, someone must be responsible for the defect database, and someone must be responsible for compiling and disseminating the result reports. Also consider appointing full- or part-time liaisons to other essential groups, such as requirements, infrastructure, and development.
Tools and Automation
If you'll be using any test-automation tools, this is the place to list what they are and how you plan on using them. Will you be testing performance, functionality, or both? Will your developers use any test tools for unit testing? Will your team require training? If so, schedule time not only for training, but allow for skill ramp-up time as well.
Certainly, there are also non-automation tools that you'll need to use. What will you use for defect tracking? Who will be responsible for the day-to-day management of your defect tracking system? Whether you'll use a sophisticated issue-tracking tool or a simple home-grown database or spreadsheet, someone needs to be designated as the caretaker and owner of the issue database.
Schedule
The testing effort will, like a development project, neatly fit into a number of overlapping phases. First, of course, is the planning phase. Next will be the development phase—creating test cases corresponding to the various test approaches. Finally, the execution phase, that is, executing test cases against the application and recording the results. Don't fall into the all-too-common trap of specifying only one execution phase. If you don't find any bugs, that's great, but that's simply not going to happen. Your team will require several cycles of testing, waiting for development fixes, then retesting.
Defect Tracking Workflow
When you or a member of your team finds a defect, what happens next? How will the developers be notified of the outstanding bugs? How long will the expected turnaround time be before the test team gets an opportunity to re-test the new code?
Metrics & Reporting
This, finally, is the goal of testing. Test results are not a matter of subjective judgment or opinion. In the end, the purpose of testing is to produce an objective report on product quality.
The Awful Truth
Okay, the truth is that you can't write a test plan in 10 minutes. More likely, a first draft will take you something approaching ten days of intense concentration. The length of a test plan directly correlates between the size and complexity of the project and the application. No matter how small or large, you'll need a plan. Your test plan will be a living document through the project. Expect some changes, but some of the basic decisions, like the topics above, are best decided early on, long before you have an application to test. Start planning early, and continually evaluate your progress against your plan, revising the plan when necessary. However else you may approach testing, don't neglect or short-change this step. The planning phase is your time to think strategically before the pressure is on, to refine and clarify your ideas. The payoff will be real.
About the Author
Jeff Gainer is a principal partner at Darwin Partners, where he specializes in software process improvement consulting. He has written a profusion of management and technical articles for numerous publications including Enterprise Development and Visual Basic Programmer's Journal. You can reach him by e-mail at gainerj@jeffgainer.com or read his previously published work on the Web at www.jeffgainer.com.
|
