Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    Shift Left Testing

    Find defects where they're cheapest to fix, in refinement, the editor and the pull request. But shift-left means early feedback, not running every expensive test at the earliest stage.

    Growingtended planted 2 min read
    On this page

    “Shift left” means pushing quality work earlier in the development lifecycle: to the left of the timeline. The reasoning is simple. A problem caught while you’re writing the code takes minutes to fix. The same problem found weeks later, by QA or in production, takes hours of rediscovering context, plus the cost of whatever it broke.

    What it looks like, left to right

    1. Refinement. QA helps write acceptance criteria and the definition of done before the ticket enters the sprint.
    2. Editor. Types and lint catch whole classes of bugs as you type.
    3. Pre-commit. Formatting, lint on staged files, secret scanning.
    4. Unit and integration tests, written by the developer alongside the code.
    5. Pull request. Fast checks: lint, unit, a small smoke suite.
    6. Merge. The slower suites: full end-to-end, visual regression.
    7. Production. Canaries, feature flags, synthetic monitoring. This is shift right, and you need both.

    Static analysis belongs here too: tools that check code without running it, flagging programming errors, standards violations and security issues. Treat its findings as prompts to investigate, since false positives happen.

    People, not just pipelines

    Shift-left is as much a culture change as a tooling one:

    • Developers learn to write good tests; nobody is “throwing it over the wall”.
    • QA engineers learn enough code to read what they’re testing and pair with developers. Pairing with QA makes developers think of paths they’d never have tried.
    • QA defines the quality bar up front, rather than discovering it at the end.

    Shift-left is not “shift everything left”

    The trap is to run your entire expensive suite on every pull request in the name of quality, until feedback takes the best part of an hour and people stop waiting for it. The point is catching issues early and cheaply. Put each test where its cost matches the feedback it gives: fast checks on every change, heavy suites on merge and nightly. Splitting checks this way can cut feedback time several-fold without losing coverage.

    “Isn’t this just waterfall?”

    No. Waterfall front-loads all the planning. Shift-left front-loads feedback, continuously and in small batches.

    In practice

    The changes that gave my teams the most quality per minute were unglamorous: faster lint jobs, coverage shown on every merge request, secret scanning before commit, and test-first habits for new features. Security shifts left too: see Removing Secrets from Git History and Preventing XSS in React. The testing layers themselves are in React Testing Strategy, and the feedback-loop view of testing in TDD as a Feedback Loop.

    • #testing
    • #quality
    • #ci
    • #devsecops
    • #ways-of-working

    ↪ Links to (4)