Shift-Left Testing
Shift-left testing means moving testing activities earlier in the development process — writing tests alongside code, running static analysis on every commit, and involving QA in requirements and design — instead of testing only after development is "done." The goal is catching defects when they're cheap to fix, not after they've compounded downstream.
The name refers to the position of testing on a left-to-right timeline: requirements, design, development, testing, release. Traditionally testing sat near the right — after development finished. Shift-left moves testing activities toward the left: unit tests written alongside the code they test, static analysis and linting on every commit, contract tests run in CI before deployment, and testers involved in requirements review before a single line of code is written.
The economic case is the real driver: a defect found in requirements review costs a conversation to fix. The same defect found in production can cost an incident, a hotfix, a postmortem, and reputational damage. Shift-left is a bet that the earlier version is always cheaper.
It pairs with (and is sometimes confused with) shift-right testing, which pushes some testing activities into production itself — canary releases, feature flags, synthetic monitoring — treating production as another environment worth testing in, not just where testing stops.
