A test strategy isn't a document
about testing. It's a set of decisions.
What to test, how deeply, and why — matched to your actual risk profile, your release cadence, and the team you have. Fixed-price. 1–2 weeks. Written to be used, not filed.
Automation without strategy
is expensive and slow.
Most QA problems are strategy problems in disguise. Too many tests covering low-risk features. Not enough coverage of the things that actually break. A regression suite that takes 45 minutes to run because nobody decided which tests mattered. Developers writing tests for the happy path because nobody defined what else needs to be covered.
The test strategy answers those questions before any automation is written: What are the highest-risk areas of this product? What does "good enough to ship" mean? What gets automated vs. left as manual verification? What coverage is the right target, and why?
Getting those decisions wrong before writing tests means the tests are wrong — and rewriting them later costs more than getting it right at the start.
Four deliverables. Everything needed to execute.
Risk map
The highest-risk areas of the product identified and scored — by likelihood of failure, business impact, and existing coverage. The foundation for every other decision in the strategy.
Test strategy document
What gets tested, how deeply, and why. Coverage targets. Automation vs. manual decisions. Release gates — what constitutes "ready to ship." Tooling rationale. Written to be understood by engineers, not QA specialists.
Coverage gap analysis
Mapped against current practice: what should be covered but isn't, what's covered but doesn't need to be, and what's over-engineered. Prioritised remediation list.
Review session
A structured walkthrough of the strategy with the engineering team. Questions answered. Decisions validated against their knowledge of the product. Document updated to reflect the discussion.
Three inputs. One or two weeks. One useful document.
Discovery
Review of the product, existing tests (if any), release process, and tech stack. Interviews with key engineering stakeholders — typically 60–90 minutes total. Identify the riskiest areas and the current coverage gaps.
Analysis & drafting
Risk map produced. Strategy document drafted. Coverage gap analysis completed. Strategy is calibrated to the actual team — not an idealised QA practice that requires three full-time testers to execute.
Review & finalise
Strategy shared for team review. Review session run. Comments incorporated. Final document delivered. For larger products, this phase extends to week 2.
Not a document for compliance.
Not a list of test cases.
A test strategy is not a QA policy document, a test plan, or a set of test cases. It's the decisions that inform all of those things. If the strategy is doing its job, it makes every subsequent testing decision faster, because the decisions have already been made.
✓ The team doesn't agree on what "done" means for testing
✓ You're growing the engineering team and need shared standards
✓ You've had production incidents that testing should have caught
✓ You want an external view on whether your current approach is sensible
Fixed-price. Confirmed after discovery.
Range is driven by product complexity and scope: single product vs. multiple services or mobile. Audit fee is offset against follow-on work (QA Foundations, Automation Build) if contracted within 60 days.