Writing a test plan can seem like a monumental task…or a simple one. It depends on your concept of how large the test plan needs to be. Certainly, the test plan for building an airplane will be drastically bigger than for making some interface changes to a modest web site! Writing an effective test plan depends a great deal on the type of project…in terms of where the project falls on the scale from waterfall to agile. The airplane project will fall far on the waterfall end of the scale where the modest web site will fall far on the agile side of the scale. This article examines how to target the right size, degree of detail, and scope of contents in your test plan to fit the product and project at hand.
This is the fourth of a series of four articles on “Writing a Test Plan”, where we explore the challenges and favored approaches for developing and implementing a plan to test an integrated product consisting of hardware and software components. This article, Part 4 in the series, “Test Strategy, Schedule, and Deliverables”, explores the “nitty gritty” project management aspects of the test plan. Part 1, “Product Analysis and Test Objectives”, looks at how to get your head around a concise and useful set of objectives for the test effort. Part 2, “Plan Test Resources,” looks at the variety of resources required for effective testing and how to plan for them. Part 3, “Define Test Criteria,” provides ideas for how to measure the various aspects of testing to determine what passes and what fails.
On a waterfall project, requirements are well-known up front, so it is important to identify what you will test and the passing criteria for each requirement. It will also be important to document up front the procedures for making your way through the testing process over the course of project execution. In the instance of a waterfall project, the test plan will tend to be lengthy.
In the case of an agile project, the test plan ideally will be short – you can even strive for a one-page test plan!
In either case, you will need to identify who tests what, and when, and the answers will likely include the following four levels of testing:
- Developer/builder – This is first level testing and usually known as unit testing of a narrow set of functionality.
- Test lead/integrator – This second level of testing involves integrating multiple use cases from unit tests into a continuous thread that represents a complete business function.
- User – Once past integrated testing, user acceptance testing is the next level of scrutiny.
- Customer – The final customer will usually want evidence that the above three levels of testing have been executed thoroughly.
Other considerations in the test plan are for communicating how the product will be tested when it is updated – to make sure the product was not ‘broken’ by the update. This is known as ‘regression testing’.
The test plan will thus include test cases that correspond in some way to the requirements, and it will specify a test design, or an approach to executing the tests. It will outline the various tools that will be used, such as the data to be generated, how it will be presented for analysis, how issues will be recorded throughout the testing process, and how resolutions to issues will be recorded. In some cases, using the tools may be adequate, or a test report may be required by the customer.
Have you identified how to determine product fitness, and how to communicate it to the customer?