- What Is a Test Strategy?
- Gathering the Information to Build a Test Strategy
- Questions Resolved by a Test Strategy
- Optional Components of the Test Strategy Document
- Evolving the Test Strategy
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Questions Resolved by a Test Strategy
At the beginning of a software project, there are usually more questions and unknowns than answers. Sometimes the only definitive knowledge you have at the start of a project is the glimmer of an ideal product and a rigid completion date. Everything between the ideal product and the deadline can be viewed as a detail, right?
A long list of questions comes to mind at this stage, and working through the strategy helps to answer such questions. The test strategy should address at least the following major areas:
- Scope. What do you need to test? It can be just as important to communicate what won’t be tested as what will be tested. Sometimes scope can help to answer the question, "To what extent do we test?"
- Resources. Who is on the test team? Who is available to test? This information defines the testing resources. Sometimes the resources are unknown at the planning stage; perhaps resources are yet to be hired or will be outsourced. In these cases, it’s important to identify where resources are needed.
- Skill set. What testing skills are needed for each component (or functional area) to be tested? Instead of planning testing based on who you have on staff, consider what skills the project needs, and determine from that information whether you need to add different skill sets and resources to your team.
- Test environment. What environment will you use to test? Sometimes a test environment already exists, so the question seems extraneous. But sometimes this is one of the most difficult questions to resolve because the environment doesn’t exist, or the current environment isn’t adequate for the project.
- Test data. What data will you use to test? Do you need a sampling of production data? (Can you even get your hands on a sampling of production data?) Sometimes a snapshot of production data is the normal fare for the test environment. Sometimes getting test data into the environment is one of the largest challenges for the project.
- Volume. Do you need a volume of data? Planning for volume data often gets pushed aside until later in the project. But if this volume data is overlooked, resources and testing might be planned without appropriately considering volume and variety of test data.
- Timeframes. When do you expect to get the first build to the test team? Timeline questions can be complicated to resolve early in the planning. High-level first-pass estimates are sometimes the best you can do. The advantage of early estimations isn’t focusing on specific dates, but rather planning ideas about how and what prerequisites might be needed to accomplish testing.
- Defect process. What’s the process for reporting defects? Do you have a defect-reporting tool? Who can report a defect? You may have a well-established process but need to change it for this specific project. You may not have a process at all. If you need to build a new process or tool, I recommend referencing the process or tool in your test strategy document, but writing a separate document to address the defect process details.
- Risk. What areas hold the most risk? When you peel back a product and investigate its core components, each component evolves into its own intriguing story, in which the number and types of tests begin to unfold in your mind. And with those test ideas, associated risks and impact come to light, which feeds back into the strategic planning.
Addressing these issues resolves some of the more strategic decisions that need to be made from a testing perspective. Your test strategy may need to address more questions or include other sections. Each time I write a test strategy, it seems there are always specific considerations to address for that product, and I have yet to have develop a boilerplate that can be reused without adaptation (which goes to show that each project has its own nuances).