Shift-left testing

Shift-left testing means doing quality work earlier: on the left of a timeline that runs from requirements to release. Instead of a test phase after development finishes, testers and developers review requirements, agree acceptance criteria, write automated tests alongside the code, and run them on every commit. A defect found in a requirements review costs a conversation; the same defect found in production costs an incident.

What it looks like in practice

• Refinement. A tester asks “what happens if the coupon has expired?” before any code exists, and the answer becomes an acceptance criterion.
• Design. Testability is discussed up front: stable test IDs, API endpoints to seed data, feature flags.
• Development. Unit and API tests are written with the feature, not weeks later. Static analysis and linting run in the editor and on pull requests.
• CI. Every pull request runs the fast suites, and a failure blocks the merge.

Shift left vs shift right

Shift-right testing is the complementary idea: learning from production through monitoring, canary releases, feature flags, synthetic checks and A/B experiments. Some failures, such as real traffic patterns or third-party outages, only appear in production. Mature teams do both. Shifting left is not a reason to stop observing what happens after release.

Common mistakes

• Renaming without changing anything. If testers still receive a finished build and a deadline, nothing shifted. The test is whether quality conversations happen before code is written.
• Making developers do all the testing alone. Shift-left spreads testing across the team; it does not remove the need for testing skills. Testers often shift into coaching, test design and building tooling.
• Only shifting automation. Running UI tests earlier helps, but the biggest gains usually come from clarifying requirements and pushing checks down to unit and API level.