What is shift-left testing?

What is shift-left testing?

Shift-left testing, often shortened to shift left, is an approach that moves testing and other quality checks earlier in development. The name comes from drawing development as a timeline, with requirements on the left and release on the right. A check that fails minutes after a change usually costs less to fix than a bug that a customer reports.

The International Software Testing Qualifications Board (ISTQB) defines shift left as doing testing and quality assurance work as early as possible in the development lifecycle. In practice, checks move out of a separate test phase before release and into daily work on each change. A continuous integration and delivery (CI/CD) pipeline runs many of them, because it tests each change soon after it is pushed.

Shift left adds earlier checks and does not remove later ones. Its counterpart, shift right, adds testing after release.

How does shift-left testing work?

Shift left puts each check at the earliest point where it runs fast and gives a trustworthy result. A change meets the checks in this order:

1. The team reviews the requirements before any code exists, e.g. by checking that each one can be tested.
2. The editor runs a linter and a type checker as each file is saved.
3. The developer writes unit tests with the code, or before it in test-driven development (TDD), which starts from a failing test.
4. A pre-commit hook runs fast checks before Git records the commit. A pre-push hook can run the unit tests before the commits leave the machine.
5. The CI pipeline builds the change on a shared server. A smoke test checks that the app starts, and then the full suite runs.
6. After the merge, the pipeline deploys to a staging environment and then to production, where monitoring records errors from real traffic.

Each point can act as a quality gate, a checkpoint that a change must pass before it moves on.

An early failure usually costs less to fix, for four reasons:

• The change is small. An early failure points at a few lines, not a week of merged work.
• The context is fresh. The author can fix it at once, without reproducing a report.
• Nothing depends on the bug. No later change builds on it, and no stored data has the wrong shape.
• No customer is affected. A bug found after release can also need a hotfix, and sometimes a data repair.

What is an example of shift-left testing?

Here is an illustrative example. Acme Co. sells furniture online. Acme used to test checkout by hand in staging before each weekly release. The team moved that check left, into a browser test of checkout that runs on each pull request.

A developer at Acme asks a coding agent to "Let customers edit their delivery address during checkout." The change then meets these checks:

1. The agent runs npm run lint, which flags an unused import in checkout/address.js. The agent deletes it.
2. The agent adds a unit test that checks the saved address, not the cart, and npm test passes in 3 seconds.
3. The pre-commit hook runs the formatter and the linter, and Git records the commit.
4. The agent pushes the branch and opens a pull request, and CI runs the checkout test.
5. The checkout test fails 6 minutes after the push. The address saved, but the cart emptied.
6. The developer sends the failure log to the agent, which fixes the cart code and pushes again. CI passes.

Under the old process, a tester would have found the empty cart in staging days later, after other changes had merged. This example is simplified. A real project would also watch checkout in production.

What changes when a coding agent writes the code?

When a coding agent writes the change, the earliest point on the timeline is its session. The agent edits files through its tools, so an editor's checks on save may not run. A check runs there when the agent calls it or an agent hook runs it. The agent can then fix the code before its output says "done."

Shift left also changes who writes the early tests. When the agent writes the code and its unit tests from the same prompt, the tests can repeat the code's mistake and pass. Agents also push more changes, so CI can become the bottleneck. Running cheap checks first stops some broken changes before they reach it.

These checks belong right after an agent's change, because most are fast and none relies only on the agent's tests:

• Static checks. A formatter, a linter, and a type checker often finish in seconds.
• Existing tests. The tests that passed before the change run again, not only the agent's own tests.
• A startup check. A build and a short smoke run show whether the app still starts.
• The changed workflow. A test or a person tries the workflow that the change touched, e.g. checkout.

What are the limits of shifting left?

Shift left makes feedback faster, but it has limits:

• Early checks cover part of the system. A linter reads code, and a unit test runs one piece of it. Both miss failures that need the whole app, with real settings and data.
• A slow early check gets skipped. A hook that takes minutes delays each commit, so people often bypass it. A check moves left only as far as its speed allows.
• Testing work moves to developers. Developers take on more early checks, e.g. unit tests, while testers still explore the software and check the risks that automated tests miss. Without time for this work, early tests stay shallow.
• Early passes are limited evidence. No findings is not the same as complete coverage. A green pipeline shows only that the chosen checks passed.

What is testing in production?

Testing in production is a practice that checks software after release, under real traffic, alongside the tests that run before release. It is the main practice behind shift right. It can find failures that a test environment does not reproduce. Teams use these techniques:

• Monitoring and alerts. Error rates and logs show failures as real traffic triggers them.
• Canary releases. A release goes to a small share of users first, and the team rolls it back if errors rise.
• Feature flags. A change ships turned off, and the team turns it on for a few users before the rest.
• Synthetic checks. A script runs one workflow, e.g. checkout, against production on a schedule.

Testing in production does not replace testing before release. A failure there can reach some users before the team finds it, so teams keep releases small and reversible.

How is shift-left testing different from shift-right testing?

Shift left moves checks earlier to stop defects before users receive them. ISTQB defines shift right as an approach that tests a system continuously in production. Teams often use both on one workflow, e.g. checkout, with a test on each pull request and a synthetic check in production. The two differ on these attributes:

ISTQB defines continuous testing as automated testing early and often throughout the lifecycle, which gives fast feedback on each release candidate. Shift left supplies its early checks.

How does RunStory help with shift-left testing?

Early checks often read the code or run one piece of it, so they miss failures that need the whole app. RunStory runs your software against the change. It sends reproducible failures back to your coding agent. It is in private alpha for CLIs and web apps, and the alpha tests your software in isolated sandboxes. Your team keeps the final release decision.

Join the RunStory alpha →

FAQs

Does shift-left mean developers do all the testing?

Shift left does not mean that developers do all the testing. It moves fast, automated checks to whoever wrote the change, e.g. unit tests. Testers still explore the software and check the risks that automated tests miss.

What is continuous testing?

Continuous testing is a test approach that tests early and often across the lifecycle, with automated tests that give each release candidate fast feedback. Shift left places its earliest checks close to each change.

Is shift-left the same as test-driven development?

Shift-left testing is not the same as test-driven development. Test-driven development is one shift-left practice, in which a developer writes a failing test before the code. Shift left is the broader approach of moving any check earlier.

Where does shift-left testing start?

Shift-left testing starts with the requirements, before any code exists, when a team checks that each requirement can be tested. The checks then follow the code through the editor, the Git hooks, and the CI pipeline.