When writting test plans (or strategies), it can be difficult to recognize what you may have forgotten. A couple tools that can help are bug taxonomies and bug databases. When you finish drafting your test plan, you simply start walking the taxonomy (or the most critical bugs in your defect database) and ask yourself, for each bug, would your plan have found that?
Talking about risk in the context of testing can sometimes be an abstract exercise. A few years ago, James Bach shared a model with me on how to make it more concrete.
It can be helpful to work the model from either direction. Sometimes, you can start with a specific victim or problem and work backwords to identify more general patterms of threats and vulnerabilities. Or think of a generic threat and work to come up with as many victims as you can.
It can be helpful to work the model from either direction. Sometimes, you can start with a specific victim or problem and work backwords to identify more general patterms of threats and vulnerabilities. Or think of a generic threat and work to come up with as many victims as you can.
When trying to determine test coverage, try the following steps:
- identify the dimensions (tools like SFDPO can help)
- factor out which dimensions matter (one way to do this is to take your list and prioritize it)
- represent the dimensions in a model (some visual representation of what you're testing)