# Software Testing Strategies (And Why Most Teams Don't Have One)

> A software testing strategy decides what must never break, what gets tested on every change, and what you stop testing. Here are the five strategies teams actually run.

Source: https://qa.tech/blog/software-testing-strategies · Published: 2026-09-03

---
A software testing strategy is the set of decisions about what you test, when, and what you deliberately don't. Three decisions carry most of the weight: which flows must never break, what gets checked on every code change, and what you stop testing because the cost outgrew the risk.

That is the definition. What teams actually do is more interesting.

We went back through twenty-seven recorded conversations with engineering leaders, QA managers and test leads over the past two months. Not one of them described maintaining a written testing strategy. Several had documents. Nobody had a document that governed decisions.

This isn't a criticism, and it isn't unusual. It just means most articles on this topic describe an artefact that doesn't exist in practice. So this one starts from what does.

## What a software testing strategy actually is

A strategy answers questions that come up on a Tuesday afternoon, under time pressure, usually without anyone convening a meeting:

- A payment flow changed. Do we run everything, or just payments?
- The suite takes four hours and the release is in two. What do we cut?
- Nobody has touched the admin panel in eight months. Do we still test it every cycle?
- We have 1,300 tests. Should we have 1,300 tests?

If those get answered the same way every time by whoever is nearest, you have a strategy. It's just implicit, held in one or two people's heads, and it disappears when they go on holiday.

### Test strategy vs test plan

These get used interchangeably and they aren't the same thing.

A **test strategy** is a standing set of decisions: what levels of testing you run, what your quality bar is, what you gate releases on. It changes when the product or the team changes, so maybe twice a year.

A **test plan** is what you do for one release or one feature: which cases, which environments, who runs them, what "done" looks like. It changes constantly.

Most teams that think they lack a strategy actually have plenty of plans. What they're missing is the layer above, which is why every plan gets argued from scratch.

## The five strategies teams actually run

These came out of the conversations, not from a framework. Most teams run a blend of two.

### 1. Tacit experience

The team knows the risky parts of the app and tests those. No document, no rules, just judgement.

An engineering lead at an IoT company described the whole approach in one sentence: "with each PR, at least two people review the changes, and the scope is more or less about the PR itself. We don't test everything." He was clear about why it works for them. "The team is relatively experienced and knows much about where to look."

It's fast, it's cheap, and on a small team with low churn it beats a bad document nobody reads. The failure mode is that it lives in specific people. At a public transport agency, the test lead had lived the other side of it: "we spent quite a lot of time maintaining the test cases, and I wasn't even across the tests myself."

**Where it breaks:** headcount changes, or the app gets bigger than anyone's mental model.

### 2. Test the diff

Look at what changed, test that. Skip the rest.

A QA lead at a telemedicine company had this automated: "on every merge request, we don't run the regression, we only run what we think would be affected. We have a script that checks the affected files and we generate tests based on those affected files."

Note the hedge in the middle of that sentence. *What we think would be affected.* Diff-scoping is genuinely good practice and it's the direction most modern tooling is going, but it depends entirely on how well you can trace a change to the behaviour it touches. A CSS variable and a pricing rule both look like one changed file.

**Where it breaks:** changes with non-obvious blast radius. Shared components, config, anything a code diff doesn't reveal.

### 3. Risk-based impact assessment

The enterprise version of the same idea, done by people instead of scripts. This is the one with a formal name in the literature: risk-based testing, where scope follows the assessed risk of each change rather than a fixed checklist.

At a global betting group, an HR-systems test lead walked through it: product owners and the testing team work out together which modules a change touches, then select cases from the regression suite accordingly. Reasonable. Then the cost: "the product owners tend to spend almost 10, 15 days in analyzing the entire impact assessment sheet." "It's a manual work," she said.

Ten to fifteen days of senior product time, per release, to decide what to test.

**Where it breaks:** the analysis costs more than the testing.

### 4. Accumulation

Nobody decided this one. It's what happens when no other strategy is in place.

The VP of Engineering at a BNPL fintech put the origin story this way: "it was the way to get the best coverage and certainty with the least effort on our test pyramid. However, maintaining that as we grew, it just became bigger and bigger and bigger and more unwieldy." His QA manager supplied the number: 1,300 tests, run every two weeks.

A QA leader at a thirty-product HR software company had the same pattern, three orders of magnitude worse. Roughly 60,000 regression test cases, of which about 60% work. "Remaining 40 are requiring maintenance every day." One person, full time, half their capacity, keeping the suite alive rather than testing anything.

Accumulation is a maintenance obligation the team inherited from its own past decisions. The tests were expensive to write, so nobody deletes them.

There's a second cost that doesn't show up in the test count. A suite this size is never fully green, so the team learns to read failures as weather rather than signal. At the point where someone re-runs a failed job to see if it passes the second time, the suite has stopped being a check and become a ritual.

**Where it breaks:** slowly, and mostly in whether anyone believes it.

### 5. Nothing

Worth naming, because plenty of teams are here and it isn't always the wrong place to be.

A fintech startup founder, asked to describe his testing process: "yeah, that's kind of it. It's pretty ad hoc." What fills the gap, per a test lead at a Nordic accounting software company: "we've already tested it enormously manually. It's mostly just on gut feel for how it works."

Gut feel from someone who knows the product is a real signal. It's also completely unauditable, doesn't survive that person leaving, and gets worse as the app grows.

**Where it breaks:** the first release nobody senior has time to look at.

## What all five have in common

None of them can tell you what's covered.

Ask any of these teams what percentage of their application is tested and you get a shrug with a number attached. One product leader at a martech SaaS guessed "probably at 10% coverage" and then undercut himself in the same breath: "I'm picking a number out of the air, but it's not a big number." The BNPL fintech's VP: "we rely a lot on these end-to-end tests. I don't think we have an accurate number on coverage, because it's not something we can just pull out." His QA manager called coverage "every company's headache".

The CTO of a telemedicine company went a step further and questioned whether the measurement is even defined: "I have felt for a while that we need to improve the way we measure quality. Do we actually need to define it properly first? I think we've done a really poor job." He connected it to volume, which is the part that matters now. "As we start to increase in lines of code and the amount of AI-generated features into the product, are we ready to actually be able to test it, to measure it, to even define what quality even means?"

His own answer was no. He isn't alone: [SmartBear's March 2026 survey](https://www.businesswire.com/news/home/20260318326658/en/) of 273 director-level and above respondents found 70% already concerned that application quality is suffering, and 68% expecting AI-speed development to create testing bottlenecks.

Which makes the starting point for a strategy uncomfortable but simple: you probably can't say what's covered, and the volume of change is going up.

## The types of software testing a strategy has to place

You can't decide what to test without a rough map of the levels. Briefly, since this ground is well covered elsewhere:

| Level | What it checks | Who usually owns it |
|---|---|---|
| Unit | One function or component in isolation | Developers, in the same PR |
| Integration | Two or more components together, including services and databases | Developers |
| [End-to-end](https://qa.tech/blog/what-is-end-to-end-testing-and-how-can-qa-tech-help) | A complete user journey through the real interface | QA, or nobody |
| [Regression](https://qa.tech/blog/what-is-regression-testing) | Features that already worked, re-checked after a change | QA, or a scheduled job |
| [Smoke](https://qa.tech/blog/smoke-vs-sanity-testing-when-and-why-to-use-each) | The handful of flows that prove the build is alive | CI, on every deploy |
| Exploratory | Unscripted investigation of new or changed behaviour | Whoever has time, which is the problem |
| Performance, accessibility, security | Non-functional characteristics | Specialists, or a tool, or nobody |

A strategy is mostly a set of decisions about which of these rows you actually staff, and at what depth. Teams that skip this step tend to over-invest in end-to-end tests, because those are the ones a manager can see.

Where these sit in the software testing life cycle matters less than who owns each row. A level with no owner is not being tested, whatever the process diagram says.

## Four decisions that make a strategy

This is the part you can write down in an afternoon.

**One: what must never break.**

Name the flows where a failure is a business event, not a bug ticket. Signup, login, checkout, payment, whatever your equivalent is. The BNPL fintech's engineering lead priced a single escaped defect in this category at over £100,000. That's the list that earns a scheduled suite.

Keep it short. Forty entries is not a list of critical flows, it's a wish. If you are choosing tooling to cover them, the questions worth asking are in our guide to [AI QA testing](https://qa.tech/ai-qa-testing).

**Two: what gets checked on every change.**

Not the same list. This one is scoped to the diff, and it pays for itself, because a bug caught before merge costs a conversation and a bug caught in production costs a release.

The two lists overlap but they're not identical, and conflating them is how you end up running a four-hour suite on every pull request and then turning it off.

**Three: what you explore rather than script.**

New features have no regression history, so there's nothing to re-check. What they need is someone trying to break them. On a financial-data company's CMS team, an engineer admitted they often "don't even necessarily know what all the test cases are supposed to be" when a feature ships. They validate what they can. "But then further down the line, a few weeks later, there are some edge cases we didn't think of."

That's an exploratory testing gap, and no amount of scripted regression fills it.

**Four: what you stop testing.**

The decision nobody makes. Every suite carries tests for features that no longer matter, flows nobody uses, and edge cases that were interesting once. They cost maintenance forever and they buy nothing.

If you have never deleted a test, your strategy is accumulation, whatever the document says. We've written separately about [when to kill a test](https://qa.tech/blog/when-kill-test-how-prune-test-suite-that-s-slowing) and it's the least popular and highest-return part of this.

### The constraint nobody puts in the document

Environments and test data decide whether any of this survives contact with a Tuesday. A strategy that assumes a clean, seeded, reachable environment on demand will quietly fail on the days that matter, because the environment is shared, or the data has drifted, or the one account that can reproduce the bug belongs to someone on holiday. If your strategy document has a critical-flows list and nothing about test data, the list is aspirational.

## The shape we recommend

Two layers, and our co-founder Daniel Mauno Pettersson tends to state it before anyone asks. Here he is on an onboarding call with a Nordic healthcare software team, translated from Swedish:

> "We don't believe very much in really huge regression sweeps. There's always a risk of flakiness in almost any web application, because of how the web works. If you have a giant sweep, you almost always have something misbehaving, some race condition or whatever. So we believe more in having the core flows in there for the things that must never break. And then complement that with exploratory testing on all the new things that actually change, and put your gunpowder there."

The numbers he gives that team matter, because "small" on its own is useless advice. Around 60 tests in the scheduled suite, covering sign-up, payment, the core functionality. Then when a feature ships: "have we made it so a user can upload a profile picture? Then it runs something like 20 dynamic tests." Those 20 don't join the permanent suite. They tested the change, and the change is now tested.

On a webinar in July he gave the range more generally. "You usually do a smaller set of regressions, maybe there are 50, 100 or 200 test cases, depending on the complexity of your product, and then you heavily rely on dynamic testing." For the subset you gate every commit on he goes lower still, to five or ten, on the grounds that if one of those breaks "you really take that seriously and you consider that a problem."

So: a **[small scheduled regression suite](https://qa.tech/blog/what-is-regression-testing)** in the low hundreds at most, with a much shorter list inside it that blocks a merge. Plus **[dynamic testing on every pull request](https://qa.tech/blog/what-is-dynamic-testing)**, meaning tests written or generated against what actually changed, run before merge rather than in a nightly job someone triages the next morning. That half has to live where code already gets reviewed, which for most teams means [testing on the pull request itself](https://qa.tech/product/pr-testing), whether or not you also [automate regression testing](https://qa.tech/use-cases/automated-regression-testing).

Vilhelm von Ehrenheim, our other co-founder, described the sequencing on a call in July: "the agent looks at the diffs and the context it has about the application. And then it can run small, isolated tests just for those features. And then you get a little bit more testing upstream before you actually run larger regression suites."

Why not just build the big suite instead? Because a large suite made of scripts has a maintenance curve that beats you. Daniel again: "if you don't trust the change in the first place, you really have to trust the change in the test. And this is actually easy to start with, but it becomes unmaintainable really fast over time."

And because size and confidence come apart. Vilhelm, on what he sees across accounts: "there's way too many companies that have a lot of tests, but they have no idea what they're actually doing. They can have a really high percentage in coverage, but do they actually test what the user is experiencing?"

One hospitality-tech CTO had already stopped using the word coverage. "For me, I call it a confidence rating." His process is still manual and he was clear about that trade: it "comes with high confidence, because somebody has literally gone, I've done it."

Some teams reach this shape without being sold it. The telemedicine QA lead from pattern two was already diff-scoping his merge requests. A seed-stage security startup wrote its own trial criteria and landed on the same structure: "identified and implemented on at least six critical flows", and deliberately varied ones, because "not only should it be flows that are critical, but also different kinds of flows, so we cover different edge cases."

### Where this advice doesn't apply

Three situations weaken the small-suite argument, and naming them is better than pretending.

**Someone above you mandated the big suite.** The thirty-product HR company runs 60,000 UI regression cases daily because, per their QA leader, "our management is inclined towards more UI oriented or end-to-end regression tests compared to unit tests or integration tests." No strategy survives that until the mandate changes.

**Scale can invert the ratio.** At the BNPL fintech's volume, their QA manager was direct about where per-change testing fits: "at these numbers, it could only be complimentary, not a main thing. That's because of the sheer numbers." For his situation he's right.

**Regulated environments need traceability, not just verdicts.** A medical-device compliance manager: "when you work in a regulated market, the use of AI is very conservative. I need traceability, so any time I need to, I can look at any test run. Everything needs to be stored."

That last one carries a twist worth sitting with. An engineer at a health-software company described what the audited status quo actually looks like: "in nine cases out of ten today it says do A, do B, do C. And then a human opens a browser, clicks through it and says done. So strictly speaking we have no traceability that anything was done at all. Because it's just someone saying it was done."

Traceability is a real requirement. A signed-off checklist is not obviously stronger evidence than a stored run with screenshots and a step-by-step trace.

### The honest limit

Vilhelm, on where the dynamic half is hardest to trust: "it's almost harder when it's just a new, very complicated feature and we run 15 tests. Is that actually really covering the full thing? That's a harder confidence to really compute."

That's the open problem in this approach, from the person building it. Dynamic testing on a small change is easy to have confidence in. On a large new feature it stays a judgement call, the way it always was.

## How to tell if your strategy is working

Four questions, and none of them is "how many tests do we have".

**Can you say what's covered?** Not a percentage someone estimated in a meeting. An actual answer about which flows have tests and which don't.

**Where are bugs being found?** If most arrive from customers, the strategy is failing regardless of suite size. If most arrive pre-merge, it's working.

**What share of QA time goes to maintenance?** The thirty-product company was at fifty percent of one person's capacity. Above roughly a third, the suite is the product.

**How long does a full run take, and does anyone wait for it?** A suite people skip under pressure is not a control on anything. Parallelising it buys wall-clock time and is worth doing, but it does not make an untrusted suite trusted.

## Write it down: a one-page test strategy template

Longer templates exist. Almost none get maintained, and an unmaintained document is worse than none because people cite it. One page, revisited quarterly:

```plaintext
CRITICAL FLOWS (must never break)
  - [flow] – owner – where it's tested
  ... keep under 10

ON EVERY CHANGE
  What triggers testing: [PR opened / merge to main / deploy]
  Scope: [full suite / diff-scoped / critical flows only]
  Blocks merge: [yes / no]

ON A SCHEDULE
  What runs: [suite name, size]
  How often: [cadence]
  Who reads the result: [name – if blank, delete the suite]

NOT TESTED, DELIBERATELY
  - [area] – why – when we'd revisit
  ... this section being empty is the finding

EXPLORATORY
  Who explores new features before release, and when

QUALITY BAR
  What blocks a release
  What we ship with

REVIEW DATE
```

The section that changes behaviour is "not tested, deliberately." Most teams have never written that down, and filling it in is usually the first time anyone says out loud what the strategy actually is.