---
name: shift-left-testing
description: Use when asked to move testing earlier in the development lifecycle — code review, static analysis, and testing-as-you-write rather than testing-after-the-fact — the strategic principle underlying test-driven development (see test-driven-development) and CI-integrated quality gates broadly.
---

# Shift-Left Testing

Shift-left testing moves testing activities earlier in the software
development lifecycle — identifying and fixing defects as code is being
written, rather than waiting until development is "complete" to test it.
The name refers to shifting testing leftward on a development timeline
where testing has traditionally been placed at the end ("shifted right").

## Why earlier is better

A defect caught while the code is being written is far cheaper and
faster to fix than the same defect caught later — a developer with full
context on a change just made can fix it in minutes; the same defect
found in system testing or production requires re-establishing context,
often across a team, at much higher cost.

## Techniques that embody shift-left

Unit testing, integration testing, acceptance testing, UI/UX testing, and
localization testing can all be shifted left when run continuously
during development rather than only at the end — shift-left isn't a
separate technique itself, it's an organizing principle applied to when
these existing techniques run. Supporting tools: code review and static
analysis catch issues before any test even runs; continuous integration
and continuous testing catch issues the moment a change is committed,
rather than in a later, separate testing phase.

## Common pitfalls

- **Treating "shift-left" as one specific tool** rather than a scheduling
  principle applied to techniques a team already has — the same unit test
  suite run only nightly instead of on every commit isn't shifted left,
  regardless of what the tests themselves check.
- **Shifting testing left without also shifting quality ownership left**
  — moving test *execution* earlier without also making developers
  responsible for writing/maintaining those earlier tests just relocates
  the bottleneck rather than removing it.
- **No static analysis or code review in the loop** — these catch a real
  class of issue before a single test even runs, and skipping them misses
  cheap, early signal shift-left is specifically meant to capture.

## Learn more

- [[test-driven-development]] for the individual-developer-level discipline that embodies shift-left most directly.
- [[unit-testing]], [[integration-testing]] for the specific techniques shift-left applies scheduling pressure to.