Shift Left Testing

Shift left is the idea that quality work belongs earlier: in the conversation before the code, in the developer's editor, in the pull request — rather than in a test phase after development is "done".

The underlying claim is that defects cost more the later they are found. That is broadly true and the famous multipliers are not: the "100x more expensive in production" figure traces back to small studies from the 1980s on waterfall projects and does not transfer cleanly to a team that deploys daily. The direction is right; the arithmetic is folklore.

#Where the work moves to

Before code — clarify the requirement.

The cheapest defect to fix is the one caused by a misunderstanding that was resolved in a fifteen-minute conversation. That is the whole mechanism behind BDD's three amigos: a product person, a developer and a tester agreeing on concrete examples, including the edge cases, before anything is built.

The two awkward questions asked in that meeting are the return on it.

While coding — the inner loop.

{
  "scripts": {
    "dev": "concurrently \"next dev\" \"jest --watch\" \"tsc --noEmit --watch\""
  }
}

Type errors, lint errors and failing unit tests visible in seconds, in the editor. This is the highest-frequency feedback loop there is and the one most worth investing in — see TDD, whose real value is exactly this.

At the pull request — automated checks.

# Fast, blocking, in this order. The whole point is that a typo fails in
# ninety seconds rather than after a twenty-minute browser run.
- lint and format          # seconds
- typecheck                # seconds
- unit tests               # under a minute
- security scans           # under a minute
- integration tests        # a few minutes
- e2e (sharded)            # a few minutes

See GitHub Actions for a pipeline in this shape.

At design time — threat modelling and testability review.

Two questions in a design review that pay for themselves repeatedly:

How will we test this? How could this be abused?

If the answer to the first is "end-to-end only", the design has a testability problem that is far cheaper to fix now than after it is built — see writing testable code.

#The version that does not work

Shift left is frequently deployed as a budget decision: disband QA, tell developers they own quality, change nothing else.

What follows is predictable. Developers test what they built, the way they built it. Nobody is looking for what nobody thought of. The exploratory testing that used to catch the strange cases simply stops, and it stops invisibly — there is no ticket for the bug nobody found.

Shifting left works when the support shifts with it:

• Tooling. Fast tests, reliable environments, one-command data setup. This is an SDET's job and it has to be somebody's.
• Skills. Testing well is a learnable skill that most developers have not been taught. Pairing with a tester is the cheapest way to transfer it.
• Time. If the estimate does not include testing, testing does not happen. This is a planning decision, not a discipline problem.
• Exploratory testing. Still needed, still a distinct skill, now done by the team rather than by a gate at the end.

Move the activity, keep the expertise.

#Shift right, as the complement

Some things cannot be known before production:

• How real users behave with the feature
• What the performance is at real scale with real data
• Which third party degrades at 09:00 on a Monday
• Whether the error message helps anybody

Testing in production, done deliberately, covers these:

// Feature flags: deploy to everyone, release to nobody, then to 1%.
if (await flags.enabled('new-checkout', { userId })) {
  return newCheckout(request);
}
return legacyCheckout(request);

• Canary releases with automatic rollback on error-rate regression
• Synthetic monitoring — a handful of end-to-end journeys running against production every few minutes
• Observability good enough to answer questions nobody pre-registered

Shift left and shift right are complements. Left reduces the number of problems that reach production; right reduces how long they survive there.

#The honest summary

The direction is right and the slogan is overused. What actually helps, in rough order of value:

1. A fast, reliable test suite developers run constantly
2. A conversation about examples before the code is written
3. Blocking automated checks on every pull request
4. Testability considered at design time
5. Exploratory testing, still, by people who are good at it
6. Production monitoring as the last line

None of that is a reorganisation. Most of it is tooling and habit, which is why it is both cheaper and harder than it sounds.