Shift left

Shift left describes moving quality activities earlier in the delivery timeline, towards the left of a diagram on which time runs from left to right. In practice it means testers reading requirements and asking what finished means before anything is built, developers writing automated checks alongside the code rather than after it, security review happening at design time instead of the fortnight before launch, and accessibility settled in the interface design rather than audited once it has shipped.

The underlying argument is economic and largely uncontested. A misunderstanding caught in a conversation costs a conversation. The same misunderstanding caught after release costs a fix, a retest, a deployment, and whatever it did to the people who met it in the meantime. What is genuinely contested is how far the idea travels. Shifting left is not a mandate to abolish later testing, and a team that stops examining the assembled system because its units are covered has simply exchanged one blind spot for a different one. Some checks can only be performed against an assembled, deployed system, and no amount of earlier work makes that requirement disappear.

What it looks like in an ordinary week

• A three-way conversation before a story is built, so a developer, a tester and whoever asked for it agree on the acceptance conditions while changing them is still free.
• Threat modelling during design, where moving an authorisation boundary is an edit to a diagram rather than a migration against live data.
• Automated checks written with the feature and running on every commit, instead of a testing phase scheduled once development is declared finished.
• Accessibility decided in the design. Colour contrast, focus order and error messaging are cheap to settle on a mockup and expensive to retrofit into a shipped component library.

Shifting left redistributes testing rather than reducing it, and teams that treat the move as a saving usually meet the same work again during their next release.