Q13 of 38 · Manual & exploratory
What is shift-left testing and why does it matter?
Short answer
Short answer: Shift-left testing means moving testing activities earlier in the development cycle — into design and even requirements — instead of treating them as a phase at the end. It catches defects when they're cheapest to fix.
Detail
The phrase comes from a left-to-right diagram of SDLC phases: requirements → design → develop → test → deploy. Shift-left pushes testing activities leftwards: testers attend requirement reviews and challenge assumptions, write acceptance tests during design, pair on unit tests during development, and run static analysis on every commit. Testing becomes continuous rather than a phase.
The economic argument is well-established: a defect caught in requirements typically costs 1x to fix; the same defect caught in production costs 50–100x because of rework, customer impact, hotfix logistics, and trust damage. Shift-left turns that curve in your favour.
Concrete shift-left practices:
- Acceptance criteria written before development — three-amigos sessions (PM + dev + QA) on each story.
- Static analysis and linting in pre-commit hooks — catch obvious bugs before code review.
- TDD or BDD — tests written before or alongside the code they verify.
- Contract tests against API specs — backend and frontend can develop in parallel without integration drift.
- Threat modelling and security review during design — not after a pentester finds an exploit in production.
Shift-left isn't "testers do everything earlier and developers ship faster" — it's a redistribution of responsibility. Developers take on more low-level testing; testers contribute to design and architecture.