I think what you’re talking about is finding suitable levels of coverage. A strategy is how to achieve coverage, so gaps in strategy mean gaps in coverage. Given that coverage is a “good enough” concept, and only makes sense with respect to a specific model, I need to know by what models I need to achieve coverage and how thorough that investigation needs to be.
So I need to have good contextual knowledge for informed risk analysis, and I need to have good product knowledge to understand what details need to be covered. If I’m missing a big picture strategy it’s usually because I don’t understand high-level concepts about the project. One way to tackle this is to write out a paragraph describing what the product is for and who the product is for, that way I know I understand why it exists and who the audience is. Product websites and sales materials usually help here, because that’s what the users are expecting when they hand over money. Talking to product support (phone support, IT support, Operations, whoever) can help me understand who my internal clients are. When I understand what it’s for and who it’s for I can better establish coverage with respect to models that fit purpose and usage.
If I’m looking for new ideas in the product, here’s a few techniques I use:
- Use inside-out and outside-in risk analysis, coding and categorising my findings
- Using project-specific risk catalogues
- Using generic catalogues (HTSM, lists of verbs, and others)
- Inventing user scenarios
- Pair testing (sometimes with a tester)
- Static review of the code
- Creating and questioning explicit models of processes, architecture, and interfaces
- Evaluating risk by framing via the 5-fold test system
- Freeform exploratory sessions, breaking patterns of recent testing focus
- Other defocus techniques during exploration that may generate ideas (multiple factors at a time, broader observations, varying models)
Hope that’s helpful!