A software testing strategy answers one question: which test levels run, who owns them, and what gate stops a change before it ships. The moment part of a team is nearshore, augmented through a staffing partner, or shipping code an AI assistant drafted, four extra decisions belong in that document: which shape the test pyramid takes, who signs off on each layer, when a CI gate kicks in, and how often the whole thing gets reviewed.
What is a software testing strategy?
The ISTQB glossary wording, as reproduced by a plain-language mirror, defines it as "a high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects)." A test plan is a narrower document: "a document describing the scope, approach, resources and schedule of intended test activities."
The distinction matters more once a team spans more than one employer. A strategy is written once and covers every project underneath it. A plan gets written per project, sometimes per release, and if the strategy hasn't already settled who owns integration tests when a nearshore engineer, an augmented senior, and an in-house junior all touch the same service, every new plan reopens that argument from scratch.
Test pyramid vs. testing trophy: which shape fits a blended team?
Martin Fowler's description of the classic shape is blunt: "Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end." Google's testing team makes the same case from the other direction, warning that a realistic-looking end-to-end suite carries a cost that catches up with a team: "Although end-to-end tests do a better job of simulating real user scenarios, this advantage quickly becomes outweighed by all the disadvantages of the end-to-end feedback loop." The same post allows for variation team to team, but holds the line on shape: the mix will differ, but it should keep that pyramid form.
Kent C. Dodds' testing trophy inverts the ratio. Dodds' trophy builds on Guillermo Rauch's line "Write tests. Not too many. Mostly integration." and stacks static analysis, unit, integration and end-to-end layers with integration tests as the emphasis.
Neither shape is right by default. A backend service with three APIs and one thin admin panel is a pyramid candidate: the surface that changes most is server logic, and a unit test catches a regression there for a fraction of what a browser test costs to write and maintain. A product where most of the logic lives in how components compose on screen fits Dodds' trophy better: a thin unit layer, a thick integration layer, and only the handful of end-to-end checks that cover a path that loses money if it breaks. Pick the shape based on where the codebase's risk actually sits, not on which one a previous team used somewhere else.
How to build a software testing strategy
1. Define your test levels and pick a shape
Name each level in writing: unit, integration or component, contract tests for anything crossing a service boundary owned by a different team, and end-to-end. Attach the pyramid or the trophy to that list based on the architecture question above, and say so explicitly in the document instead of leaving the ratio to whoever wrote the most recent test file.
2. Decide who owns each layer when engineers are nearshore, augmented, or AI-assisted
Unit tests stay with whoever writes the code, regardless of who employs them. A nearshore engineer, an augmented senior, or a junior pairing with an AI assistant owns the unit tests for what they ship, the same as an in-house engineer would.
Integration and end-to-end tests are different, because they cross more than one person's code and nobody's individual ownership covers the whole thing. That gap needs a named owner independent of who touched the code last, and the same question of who holds review authority once part of a team is external has already been worked out for code review: an augmented senior should carry the same sign-off weight as an in-house senior on tests too, not a lesser version of it because of how they're contracted. An engineer working nearshore to a Western European team, out of Poland, Hungary, Slovakia, Serbia, Slovenia, Romania, or Spain, shares enough of the working day to actually own that triage rather than hand it off across a nine-hour gap. Trust for that kind of ownership isn't assumed. HighCircl's own vetting for augmented engineers runs four stages ending in a live session on architectural reasoning, and roughly 1 in 10 applicants clear it, which is the bar a lead should be checking for before handing someone integration-test sign-off, whatever vendor supplies the engineer.
3. Set CI gates before flaky tests or AI-generated PR volume force the decision
DORA's 2024 report found that AI adoption raised individual productivity, flow, and job satisfaction, while it lowered software delivery stability and throughput. A testing strategy is where a team decides what stops that drop before it happens rather than reading about it after a bad quarter.
What happened to one company's CI once AI wrote most of its diffs is the concrete version of that DORA finding. Anthropic's own account puts its CI job volume up 25x over six months, once engineers began shipping roughly 8x as much code per quarter with Claude authoring about 80% of it. That is one company's self-reported number about its own product, not an industry benchmark, but the mechanism generalizes: more diffs, produced faster, running the full suite every time, until something forces a change. Set the gate before the volume forces it. That means a threshold for flagging AI-assisted PRs for a different review pass, a rule for which changes require test-impact analysis instead of a full run, and a quarantine policy for a flaky test instead of leaving it to block or silently pass at random.
4. Track quality metrics separately from delivery metrics
A testing strategy shows up in two different scorecards, and conflating them hides which one is actually broken. The delivery-speed metrics DORA already tracks, change failure rate and recovery time especially, move directly in response to how much of the pyramid or trophy actually runs before a merge. How to track test coverage and defect density once the strategy is running is a separate question about the code itself, not about how fast or safely it shipped. A strategy that only watches deployment frequency will miss a coverage regression for months; one that only watches coverage will miss a test suite that's technically thorough and still too slow to gate a merge.
5. Put ownership and escalation rules in one shared document, so no vendor runs its own version
Untested code that ships anyway because nobody was clearly on the hook for its tests becomes exactly the kind of debt that piles up quietly. The fix looks like a debt register with a named owner per item: one document naming who owns each test layer, who can override a failing gate and under what condition, and who gets escalated to when a vendor's engineer and an in-house engineer disagree about whether a test is even worth keeping. Without that document, each vendor or contractor ends up running its own informal version of the same rules, and nobody notices they've drifted apart until a bug slips through a gap between two of them.
6. Review the strategy on a fixed cadence
Set a review date and stick to it rather than waiting for a bad release to force the conversation. A new vendor joining the team, a new AI tool changing how much code shows up in a single PR, or a shift from a backend-heavy to a frontend-heavy roadmap are all reasons the pyramid-versus-trophy call and the ownership map from steps 1 and 2 might need to change. A quarterly check is a reasonable default; anything shorter turns into churn, anything longer lets drift go unnoticed for two quarters instead of one.
Frequently asked questions
What's the difference between a test strategy and a test plan?
A strategy is the high-level document naming which test levels exist and how they're structured, written once and covering every project underneath it. A plan is scoped to a specific project or release: its scope, approach, resources, and schedule. ISTQB defines both separately, and a team that only writes plans ends up deciding ownership and gate policy fresh every sprint instead of settling it once.
Should we use the test pyramid or the testing trophy?
It depends on where the system's risk sits, not on which shape is more popular. A backend or API-heavy codebase fits the classic pyramid Fowler and Google's testing team describe: a large unit base, fewer integration tests, very few end-to-end checks. A frontend-heavy JavaScript product fits Kent C. Dodds' trophy better, with a thick integration layer doing most of the work. Pick the shape deliberately and write down why, so the next engineer who joins doesn't have to guess.
Who should own end-to-end tests on a blended team?
A named individual, independent of who last touched the code, regardless of whether that person is in-house, nearshore, or an augmented senior supplied by a vendor. The same authority already given to a senior augmented engineer in code review, full sign-off weight rather than comment-only status, extends to test ownership once that engineer has cleared a real vetting process for it.
Does AI-assisted code change what a testing strategy needs to cover?
Yes, mainly on the CI-gate side. AI-assisted code doesn't need a different set of test levels, but it changes the volume and speed at which PRs arrive, which is what pushed one company's CI job count up 25x in six months once its engineers started shipping most of their code with an AI assistant. A strategy written for a lower, steadier PR volume needs an explicit flag threshold and a test-impact-analysis rule before that volume shows up, not after.