Shift Left Testing and Shift Right Testing: Where Each Check Belongs
Shift left and shift right aren't rival philosophies. Place each risk where it can first be seen, connect the two with an incident-to-test loop, and keep a scheduled smoke pack as the bridge.
This is lesson 8.3 of AI and Shift-Left Testing Strategy. Lesson 8.2 moved checks as early as they can go; this one decides which checks belong after release.
Shift left testing and shift right testing are a placement decision
Shift left testing and shift right testing answer different questions. Shift left asks "is this change correct?" before release, where a defect costs an edit. Shift right asks "is the running system healthy for real users?" after release, where only production has the traffic, data and configuration that reveal some failures. The useful question is never "left or right?" but "where can this particular risk first be seen?" Place each risk there, then connect the two sides so that what production teaches you moves left.
For the side-by-side comparison table and a latency budget enforced on both sides, read shift left vs shift right testing. This lesson works through placement for a real API.
What is shift left testing and shift right testing?
| Shift left | Shift right | |
|---|---|---|
| When | Before release: refinement, pull request, staging | After release: production or a canary |
| Question it answers | Does the change do what was agreed? | Does the system work for real users, right now? |
| Typical checks | Requirement examples, contract checks, generated API tests, mocks | Post-deploy smoke tests, synthetic checks, canaries, observability |
| Data used | Test data, seeded or generated | Real data, read-only |
| Cost of a failure found there | An edit and a re-run | An incident, a rollback, a customer report |
Place each risk where it can first be seen
Take six risks for the sandbox store's orders API and ask where each one can first be observed.
| Risk | Earliest place it shows | Side |
|---|---|---|
An order with quantity: 0 is accepted | A negative test on the pull request | Left |
| A field is removed from the order response | A breaking-change check on the spec | Left |
| Production is deployed with a missing secret, so every call fails | A smoke test right after the deploy | Right |
| Responses slow down under the real mix of traffic | Production metrics; a load budget on the left catches part of it | Both |
| A bug only appears with a real catalogue of 50,000 products | Production first, then a test with that data shape on the left | Right, then left |
| A third-party dependency starts timing out | A scheduled synthetic check with an alert | Right |
Two patterns stand out. Anything about the change itself belongs on the left. Anything about the environment, the data at scale or other people's systems can only be seen on the right, and the left side can only learn from it after the fact.
Shift left and shift right testing approaches
On the left: requirement review with examples, contract and breaking-change checks, generated functional, negative and boundary API tests, integration journeys on staging, mock servers for dependencies that aren't ready, and performance and security checks before release.
On the right: a smoke test after every deploy, synthetic checks on a schedule, canary releases that expose a change to a small share of traffic first, feature flags that switch a change off without a deploy, observability (logs, metrics and traces), and controlled chaos experiments with a known blast radius.
A smoke test after deploy is the simplest bridge between the two. It is the same kind of test you write on the left, run against the real environment on the right.
/api/v1/products?error=503curl -X GET 'https://demo.totalshiftleft.ai/api/v1/products?error=503'That 503 is what a customer would see if the service came up broken. A smoke test that calls three or four read-only endpoints every few minutes sees it too, usually before the first support ticket.
Shift left and shift right testing practices that connect the sides
- Use the same numbers on both sides. If the orders API must answer in under 500 ms, that is the threshold for the pre-release check and for the production alert.
- Keep data-changing and heavy tests on the left. In production, run read-only checks only: no creates, no deletes, no load.
- Close the loop after every incident. End the review with "which earlier check should have caught this?" and add it. For the missing-secret incident, the answer might be a configuration check in the deploy job, plus the smoke test as the backstop.
- Alert a person, not a dashboard. A smoke test that fails silently is a log entry. Send failures to the channel the on-call engineer watches.
- Don't mistake synthetic checks for observability. A scheduled test proves a few known paths work. It can't tell you about the requests you didn't think to script, which is what logs, metrics and traces are for.
Common mistakes
- Treating shift right as testing in production instead of testing before. The right side catches what the left can't see; it is not a place to defer work the left could do.
- Smoke tests that change data. They pollute production and create noise for the next incident.
- No owner for the loop. If nobody turns incidents into earlier checks, the two sides drift apart.
In Shift-Left API: a scheduled post-deploy smoke pack
Shift-Left API is a test platform, not an APM or observability tool: it has no real-user monitoring, tracing or log analysis. What it gives the right side is the bridge, a scheduled smoke pack built from the same tests you wrote on the left. Test Run Packs and the test scheduler need Professional, Enterprise or the 15-day trial.
- Pick the smoke tests. In a project built from
https://demo.totalshiftleft.ai/openapi/rest.json, keep three or four read-only tests: the product list, one product, and one order read with?expand=user,product. - Build the pack. In Execution, click New Test Run Pack, choose Functional, and name it Store API smoke. Select the tests.
- Choose the environment. A pack runs against one environment. Use the project default, or tick Override in step three to point it at the deployed environment.
- Set a notification. In step four, send failures to one channel: email, Slack, Microsoft Teams or a webhook.
- Schedule it. In step five, set Repeat to every 15 minutes and click Schedule Test Run. Upcoming Schedule shows the next run.
- Run it after each deploy too. Add the same pack to the end of your deploy pipeline with the GitHub Action, Azure DevOps task, Jenkins plugin or REST API, so a broken release is caught in minutes, not at the next scheduled run.
Scheduled runs execute on the Shift-Left Engine, so the engine must be able to reach the environment you test. Every run lands in Reporting with its pass rate; lesson 9.12 turns that history into dashboards.
Try it yourself
On a trial, build a pack from three read-only sandbox tests, set Repeat to every 15 minutes on step five, and schedule it. Check Upcoming Schedule, wait for the first run, and find it in Reporting: which execution type does it show?
Recap
- Shift left testing and shift right testing are a placement decision: put each risk where it can first be seen.
- Shift left and shift right testing approaches meet at the post-deploy smoke test: a left-side test, run on the right.
- Shift left and shift right testing practices connect the sides: same thresholds, read-only checks in production, and every incident turned into an earlier check.
Next, in lesson 8.4, you look at where AI fits into API test automation, and what it should never be allowed to change.
Try it: On a trial, build a Test Run Pack from three read-only tests on the sandbox (the product list, one product and one order), set Repeat to every 15 minutes on step five, and schedule it.
Frequently asked questions
What is shift left testing and shift right testing, in one line each?+
Shift left testing moves checks earlier, before release, so defects are found while they are cheap to fix. Shift right testing checks the running system after release, with real traffic, data and infrastructure, to find what no pre-production environment can show. Most teams need both.
Which shift left and shift right testing approaches should a team start with?+
On the left, start with generated API tests and a breaking-change check on every pull request. On the right, start with a read-only smoke test after every deploy and on a short schedule, with an alert on failure. Canary releases, feature flags and chaos experiments come later, once those two are reliable.
What shift left and shift right testing practices connect the two sides?+
Use the same thresholds on both sides, keep anything that changes data or loads the system on the left, and end every production incident by asking which earlier check should have caught it. Then add that check. Over time the left side of the suite becomes a record of what production has taught you.
Related lessons
Shift-left testing is a set of decisions, not a tool. Map every check to the earliest stage it can run, change three agile rituals, put gates in the pipeline, and measure where defects are now found.
Turn a handful of tests into something that runs on its own. Build a Test Run Pack in Shift-Left API, schedule it for every night, run it now, and find every run in Reporting.
Turn a pile of test runs into one screen your team can watch and share: a dashboard for each role, an export you can print to PDF, share links and a TV Mode wall display.