Shift-left testing
Moving checks earlier, from release week into design, coding, and pull requests, so defects are cheaper and faster to fix.
What it is
Shift-left testing moves feedback earlier on the delivery timeline: requirements get testable acceptance criteria, developers run checks locally, and pull requests get lint, type, unit, integration, and security feedback before merge. Larry Smith named the practice in a 2001 Dr. Dobb's Journal article; the 'left' comes from diagrams that draw development on the left and production on the right.
Reach for it when defects wait until a shared QA environment or release week to surface. The practical moves are small: review examples before coding, make fast checks easy to run, test risky seams in CI, and give developers production-like fixtures without making them share state.
Gotcha: shift-left does not mean dumping all quality work on developers or deleting testing on the right. Staging, canaries, observability, and production verification catch environment and usage failures that no pre-merge suite can reproduce. Earlier feedback adds a layer; it does not erase later evidence.
Ask AI for it
Shift this repository's quality checks left with GitHub Actions. Add independent pull-request jobs for `bun x ultracite check`, `tsc --noEmit`, Vitest unit tests, and the fastest integration tests; make their exact job names required status checks before merge. Add local package scripts that run the same commands, keep the pre-commit path under ten seconds, and document which slower Playwright and security checks still run after merge. Report the feedback time for each layer.