To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
Writing the test plan is definitely the most important test-related activity that doesn't involve looking at the software. For the first couple of times, writing the plan can be challenging, but the learning curve isn't all that steep -- with frequent practice, you should be able to write a test plan for the standard project in a matter of hours. (Caveat: there is NO such thing as a standard project, but the idea looks good in print!)
Software Testing Help has a decent outline for a test plan template. Designing a test plan template is a relatively straightforward process, but it is helpful to have an experienced test manager build that template for you or, better yet, along with you. If you post to some of the testing-related user groups, you should be able to find someone willing to help you craft a template that fits your needs.
The goal of the test plan is to capture the strategy needed to sufficiently test the project at hand. It scopes your thoughts, leading you from one testing topic to another. It is NOT a place to store test cases, but rather a place to organize your thinking. For instance, a test template might call out a series of operating system and language combinations -- test cases would capture each of these combinations as a check list.
It's also a place to document dependencies -- especially dependencies on downstream groups such as database administrators or legacy applications. Raising dependencies here helps you, as the test manager, collaborate with other groups early in the project and prevent that last-minute fire drill.
Another purpose of the test plan is to document risk. When you call out a risk (for instance, testers only available part-time), it gives you a chance to think up a risk mitigation plan (how to prevent the risk from actually occurring) and a resolution plan (how to cope with the risk if it arises). It raises awareness to management, and helps them decide whether the risk is great enough that they should take steps now to prevent it.
Your test plan will organize and categorize the testing. You might be asked to calculate estimated testing costs, and some plans even include test schedules. This is where you begin to think about your testing staff and how to split the work up. I generally do not start any of the scheduling until my plan is complete and I've been able to estimate costs. Only then do I consider how to break this out and share it across my team.
Finally, a couple of critical elements of the test plan are 1) defect management and 2) the project's exit criteria. Defect management describes how defects will be documented as well as the process for moving defects through their lifecycle. This is where you gain consensus from business and customer partners for managing bugs. The exit criteria is a key part of your overall plan, because exit criteria describe how the team will know when the project has been completed. Defect status is a core element of exit criteria, as well as test pass status. Other elements depend on what the team wants and how the organization works.
To be quite honest, your best bet for building a test plan is to bring in outside help the first time or two that you do this. Find a testing consultant who is not interested in forcing their testing process on your organization, but is interested in helping you find the right plan for your style. You might find help online, or you might look locally or even internationally. If you live in an exotic location, you might find an experience test manager willing to come on-site to help, in exchange for travel and expenses. By bringing in experienced help the first time, your first project will be more successful. In addition, you'll be able to write future test plans to the same consistent level.
|
