The test strategy model
I actually use, free

Every fixed-price test strategy engagement I've ever scoped starts with the client asking, more or less, "what will you actually give us?" Fair question. The honest answer is: a model for thinking, applied to your specific product. The model itself isn't proprietary. It shouldn't be. So here it is, in full, for nothing.

This is my working adaptation of the Heuristic Test Strategy Model, developed by James Bach and refined with Michael Bolton as part of Rapid Software Testing. I didn't invent the underlying thinking. Context, Structure, Approach, the oracle/heuristic vocabulary, the idea that testing is an investigation rather than a checklist, that's RST canon, and it predates most of the "modern" quality frameworks currently being resold to you in a different font. What I've done is shape it into the version I actually run engagements against, and draw it the way I explain it on a whiteboard.

Context comes first because it decides everything downstream

The six boxes at the top, Project Environment, People & Skills, Product Elements, Quality Criteria & Expectations, Risks, and Tools, aren't background information you fill in once and forget. They're the constraints and resources that make every later decision either sensible or theatre. A team with no dedicated QA and a two-week release cycle needs a completely different test strategy from a regulated fintech shipping quarterly, even if the two products look similar from the outside.

Two of these boxes do more work than people expect. Product Elements is structure, not "the features" (everything about the product), function (everything it does), data (everything it processes), interfaces (every conduit in or out), platforms (everything it depends on outside the project), operations (how it's actually used), and time (how the product's relationship with time changes its behaviour). Software is complex and mostly invisible. Missing one of these seven angles is usually where the untested gap turns out to live.

Quality Criteria & Expectations is the other one worth slowing down on, because "quality" is not one dimension. On every engagement I test against some mix of: capability, reliability, usability, charisma, security, scalability, compatibility, performance, installability, and development (how easily the thing can itself be built, tested, and changed). These are subjective, they compete with each other, and they are very often not written down anywhere, which means the real quality bar for the product is sitting in five people's heads, only some of which agree with each other. Making that list explicit, even roughly, is one of the highest-leverage half-days you can spend before writing a single test case.

Approach: pick the mix, don't pick a side

The framing I still hear most often is automation versus manual, as if you're choosing a religion. The model treats Scripted, Automation, and Exploratory as three approaches you blend deliberately, not three tribes you join. Scripted testing is done in advance from a specification that states the desired outcome, good for regression, compliance evidence, and anything where "prove it still does X" is the actual question. Automation/coded testing relies on existing, explicit information to assert what you already expect, fast, repeatable, and only as good as the expectations you encoded into it. Exploratory testing has no fixed expectations going in; it emphasises the tester's autonomy and expertise to generate ideas while capturing information for reporting afterward. It's how you find the things nobody thought to specify.

Every credible test strategy I've written blends the three in a ratio that matches the context above it. A regulated release needs more scripted evidence. A fast-moving product with a small team needs more exploratory coverage, because there isn't time to script everything and most of the risk is unknown-unknown anyway.

Structure is what you keep, matched to the approach that produced it

Scripted work produces test cases, quantitative results. Automation produces scripts, results, and change detection, the artefacts of continuous testing. Exploratory work produces charters, session-based test management notes, and qualitative findings. The mistake I see constantly is teams trying to force exploratory findings into a test-case template, which either destroys the nuance of what was found or makes testers stop doing exploratory work at all because the paperwork isn't built for it. Match the record-keeping to the approach, not the other way round.

Test Ideas: where technique meets risk

Test techniques, test types, types of risk, heuristics, and oracles all feed one thing: test ideas. This is the part most "test strategy documents" skip entirely, jumping straight from requirements to test cases. A heuristic is a useful, fallible tool that helps a tester make a fast judgement, in planning, design, or execution, often used to generate test ideas quickly rather than derive them from first principles every time. An oracle is how you'd recognise a problem if you saw one, which sounds obvious until you try to write down what yours actually are for a given feature. Test techniques worth keeping in the kit: function testing, domain testing, user testing, stress testing, risk testing, flow testing (integration, end-to-end), and automatic checks alongside deliberate scenario testing. None of these need a tool purchase. They need a tester who knows which one applies to what's in front of them.

Investigation is the actual job

This is the part of the model that separates testing from checking, to borrow Michael Bolton's distinction. Testing is an investigation conducted to provide information about quality. That investigation moves information through four verbs: it assists, it's informed by, it uncovers, and it confirms, cycling constantly between what you're told and what you find.

The information itself sits in four states: explicit (written down, agreed, easy to test against), tacit and implicit (known by someone, rarely documented), unknowns you're aware of (open questions you can go and answer), and unknowns you're not aware of, the ones that only surface because someone was actually investigating rather than executing a script. A test strategy that only ever tests against explicit information will look thorough and catch almost nothing that matters, because the explicit information was never where the risk was hiding.

Continuous testing sits alongside this as a standing practice, not a single phase: testing the ideas, the artefacts, the designs (BRDs, FRDs), the code (via review), the product, and the processes that produced all of the above. It doesn't have an end state. That's the point of the infinity symbol, not a design flourish.

Perceive Quality & Value, the only reason any of this exists

Everything above the cloud at the bottom of the diagram is machinery. The cloud is the output that actually matters: someone, a user, a stakeholder, a regulator, forms a perception of quality and value, and that perception is what determines whether the product succeeds. Every box above it should trace, eventually, to improving the accuracy and confidence of that perception. If a piece of your test strategy doesn't trace back to that cloud, it's activity, not testing. That's the same trap coverage percentages fall into, and it's worth reading alongside why coverage measures the wrong thing if you haven't already.

Want a strategy your team will actually use? See Test Strategy Development.

Use it, don't just admire it

Print the diagram. Walk your team through it against your actual product, not in the abstract, with your real context boxes filled in and your real quality criteria named. That one working session will surface more genuine risk than most 40-page strategy documents manage in their entire lifecycle, for the simple reason that a document sitting in a wiki doesn't force anyone to say the quiet part about what they're actually worried will break.

If you want help running that session, or turning it into a strategy document your team will actually use, that's a paid conversation and I'm glad to have it, see Test Strategy Development. The model above isn't the paid part. It never was. What you pay for is someone who's run this against a hundred different contexts telling you where yours breaks the pattern.