The decisions to settle
A useful strategy comes down to a handful of choices, but they have to be actually made:
- Scope. Which parts of the product deserve systematic verification, and which can be checked case by case. Treating everything equally is the same as prioritising nothing.
- Levels and types. What is tested in isolation, what is tested through integration, what genuinely requires an end-to-end journey. The test pyramid is a principle, not a template: its shape follows your architecture.
- Environments and data. Where tests run, against what data, and how that data is regenerated. This is the single point that sinks the most automation efforts.
- Entry and exit criteria. What allows a release to ship, and what blocks it. Written in advance, not negotiated the evening before delivery.
- Indicators. Three at most, and none that can be improved without improving actual quality.
Why most strategies are never applied
They fail for the same reason almost every time: one person wrote them, then circulated them to a team that took part in none of the trade-offs. A decision you did not make is not a decision you will defend three weeks before a release.
So we build the strategy with the people who test, in working sessions, and the written version comes afterwards — it records trade-offs already accepted instead of trying to impose them.
The second cause of failure is volume. A forty-page strategy is not more rigorous than a six-page one; it is simply less read.
What you get
A short, dated document with an owner named against each decision. It states explicitly what is not covered and why — the part technical leadership uses most, because it makes the risk discussable instead of leaving it implicit.
Alongside it, the release criteria in a form your continuous integration pipeline can enforce, so they are checked automatically rather than recalled in a meeting.
Before and after
If you do not yet know where you stand, the audit usefully comes first. If the strategy already exists and the problem is execution, the question is one of organisation and industrialisation — see the consulting offering.
And if the obstacle is that nobody on the team has the level to apply these decisions, that is not a consulting problem: it is a case for training or for hiring.