The first thing in writing a test plan may seem obvious – to study the product and identify the objectives of the test. However, this seemingly obvious step can be elusive if you are steeped in process, especially from past approaches. You must first seek to understand the unique attributes of the product at hand before considering just how to test if it meets requirements and works as intended. So, lean back a bit from your past experience…and lean in toward the product at hand and understand its nature – the nuances, unique requirements, and critical characteristics. The article examines the process of gaining that intimate understanding of the product and defining a quality set of objectives for testing what is being built.
This is the first 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 1 in the series, “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. Finally, Part 4, “Test Strategy, Schedule, and Deliverables”, explores the “nitty gritty” project management aspects of the test plan.
The bottom line is that the test plan needs to be purpose-driven, and so you need to gain a clear understanding of the purpose…
…and so, in order to begin thinking about testing it, you need to understand nature of product, such as:
- Who will use it and why – In what way does it contribute to organizational and personal success?
- How it works – What is the function that product performs? What are the nuts and bolts about how it performs that function?
- Hardware, software, and middleware that it consists of – What assets are required that make up the product? How do they work together?
- Interfaces, or integration points – What are the key touchpoints where there is a transfer from one component to another?
- What’s in or out of scope – What are the limits or boundaries of the product? What is it designed to do, and what does it specifically not do? It will also be helpful to understand the scope of the project itself.
- Assumptions – Keep track of assumptions you are making along the way. Be ready to communicate these, and to verify when you have the opportunity.
With an understanding of the nature of the product, you can begin to define test objectives:
- Customer inputs – Create a draft and incorporate inputs you are able to obtain directly from the customers.
- Product understanding – Map your product understanding to your draft test objectives.
- Budget – Familiarize yourself with testing and project budget constraints.
- Schedule – Familiarize yourself with the phased timeline for delivery of the product. What capabilities will be delivered and when?
- Resources – What human resource constraints do you have? Is your staff a given, or can you go outside for supplemental resources if needed?
- Target/goal of test based on features and constraints – What is the desired end state of the testing effort? What intermediate end states along the timeline will be needed to succeed?
Are you now familiar with the desired end product and developed an initial set of test objectives?
This is a series of four articles on “Writing a Test Plan” — exploring the challenges and approaches for testing an integrated product consisting of hardware and software components.
- Product Analysis and Test Objectives
- Plan Test Resources
- Define Test Criteria
- Test Strategy, Schedule, and Deliverables