|
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.
Back to top
|
