Test Strategy
What to test, to what depth, and what evidence proves it. Risk-based, written down, and sized to your system flow by flow.
Not everything deserves the same attention
Testing everything to the same depth is unaffordable, and testing by instinct leaves the gaps in the worst places. A strategy is the judgement in between: made on purpose, before the pressure arrives, and written down so somebody can disagree with it.
We start from consequence. Anything that moves money, data or compliance evidence gets deep automated coverage. Cosmetic corners get what they are worth. What you end up with says plainly what is covered, what is not, and why - which is the part that matters when a regulator, an auditor or a new supplier asks.
This is where our testing work starts. What follows it is automated testing and performance and load testing.
Four ways we get brought in
Most work starts with one of these. You don't need to know which before you talk to us.
Strategy definition
Functional and non-functional testing, what gets automated, and who does what, written down.
Strategy audit
We benchmark what you have against your team's actual practice and where the risk really sits.
Maturity assessment
Where you stand across people, process and tooling, and what is worth fixing first.
Training and upskilling
Your engineers and testers write it with us. A strategy nobody helped write is one nobody follows.
What a strategy actually decides
- What it costs when this breaks
- Coverage follows consequence. We work through the flows with you and ask what happens if each one fails quietly for a week, which sorts them faster than any discussion about percentages.
- What proves it works
- Not just that something is tested, but what the evidence is and who it needs to satisfy. If an auditor or a customer is going to ask, the answer should exist before the question does.
- What we are not testing
- The uncomfortable half, and the one that makes the rest honest. A strategy that claims to cover everything is either untrue or unaffordable, so we name the gaps and say why we are content with them.
- Who runs it, and with what
- Where testing sits in your sprints, release cycles and pipelines, and the roles that make it stick. Tooling recommendations are grounded in what you already run: test and defect management, automation frameworks, CI/CD integration.
What lands on your desk
- A written strategy
- Setting out what is covered, what is not, and the reasoning for both.
- A prioritised roadmap
- Of what to fix first, riskiest gap at the top.
- Recommendations for the process
- So testing fits the way your team already works instead of asking them to work around it.
What it looks like when it works
On our most recent build the strategy put deep coverage on the flows carrying operational data, and left the edges alone.
| Item | Result | Notes |
|---|---|---|
| Automated tests | 300+ | running continuously through the build, concentrated on the flows that carry operational data |
| Requests under load | 3,480 | at 5 a second, about 17x the expected busy-hour peak - run by the detection provider connecting to the service, not by us |
| Application errors | Zero | across the whole load run |
| Kick-off to live | Under 4 weeks | at a fixed scope and fixed price - a relatively simple installation |
Common questions
Will you write a strategy for a system you didn't build?
Yes, and it is often the first useful thing we do. Assessing what an existing system covers, what it doesn't, and which gaps actually matter gives you a decision to make: close the gap, or accept it and say why.
What do we actually receive?
A written strategy saying what is covered, what is not and why; a prioritised roadmap of what to fix first, ordered by what a failure would cost; and recommendations for how testing should sit inside the way your team already works.
Isn't this just a document?
It is a document, but the point of it is the argument it settles. It says which flows get deep automated coverage and which get almost none, so nobody has to make that call under pressure the week before go-live.
How much testing is enough?
It is risk-based, not exhaustive. Every flow that moves money, data or compliance evidence gets automated coverage; cosmetic corners don't. That judgement is exactly what a strategy writes down.
Does this slow delivery down?
The opposite, and that is the whole reason for it. Teams that ship quickly are the ones with tests doing the checking, and a strategy is what stops the suite growing into something slow that nobody trusts.