How to Do Shift Left Testing: Rituals in Agile, Gates in DevOps

This is lesson 8.2 of AI and Shift-Left Testing Strategy. Lesson 8.1 moved one requirement's tests ahead of the code; this lesson turns that into how a whole team works.

How do you do shift left testing as a team?

How to do shift left testing comes down to one decision repeated for every check you run: what is the earliest point at which this check has the information it needs, and who owns it there? Requirement checks move into refinement, contract checks into the spec's pull request, API tests into the code's pull request, and a smoke test stays after deploy. Then you add gates so the early checks actually stop bad changes, and you measure where defects are found. Tools come last.

For a week-by-week rollout plan with a pilot team, read the eight-step shift-left testing framework. This lesson is about the decisions behind each step.

Start with a map, not a tool

List the checks your team already runs, then place each one at its earliest possible stage. For an API like the sandbox store, the map looks like this:

Two columns matter more than the stage. Owner tells you whose habits change. What it needs tells you what blocks the move: if there is no spec, contract checks can't shift left until someone writes one.

Shift left testing in agile: change three rituals

Most of shift-left testing in an agile team happens in meetings you already hold.

1. Refinement produces examples. For each acceptance criterion, the team writes inputs and expected outcomes, like the eight rows in lesson 8.1. QA leads this; the product owner answers the gaps.
2. The definition of ready gets stricter. A story is ready only when its criteria have examples and any API change is drafted in the spec. A story that says "add a coupon code to orders" isn't ready until the spec shows the field, its format and the error for an invalid code.
3. The definition of done includes the tests. The tests are merged in the same pull request as the code, and the pipeline gate is green. "Tested next sprint" stops being an option.

What you should see within a few sprints: fewer stories reopened after review, and fewer defects whose root cause is "the requirement didn't say".

Shift left testing in DevOps: gates in the pipeline

In the pipeline, shifting left means each stage has a gate with a written rule, and the cheapest checks run first.

Three rules keep the gates credible:

• Start in warn mode. A strict gate on day one becomes a gate people learn to bypass. Report for two weeks, then fail builds, then raise the threshold.
• Gate on contract breaks, not only test failures. A removed field can pass every existing test and still break a client.
• Quarantine flaky tests with an owner and a date. A test that fails at random teaches the team to ignore red builds.

Shift left testing best practices

1. Pick one service with real pain, not the easiest one. A service with frequent regressions shows results quickly.
2. Make the spec the source of truth. Review it like code, and generate tests from it rather than keeping a second, hand-written description of the API.
3. Merge tests with the change, in the same pull request.
4. Keep the pull request fast. If the PR stage takes longer than a coffee, move slow checks to after merge rather than letting developers stop waiting for it.
5. Measure the stage where defects are found. Track the share found before merge, the escape rate to production, and time from push to feedback. Test counts are not a measure of shift-left.
6. Keep checks on the right. Shift-left reduces post-release testing; lesson 8.3 explains what it can't replace.

Common mistakes

• Moving every test into the pull request. The PR gets slow, people stop waiting for it, and the gate loses its point.
• Leaving QA out of refinement. Developers write tests that confirm their own understanding, and the gaps in the requirement survive.
• Buying a tool before drawing the map. Without owners and gates, a test generator produces tests that nobody runs.

In Shift-Left API: a spec-first pipeline gate

Shift-Left API covers the API rows of the map: tests generated from the spec, change detection when the spec moves, and a pack that a pipeline runs with a pass-rate gate. Test Run Packs, change review and CI need Professional, Enterprise or the 15-day trial; generation is in every edition, Free included.

1. Generate from the spec. Import https://demo.totalshiftleft.ai/openapi/rest.json and click Generate tests on an endpoint. A deterministic coverage engine plans the tests with no AI key; an AI provider, if you set one, polishes them and adds a few per endpoint.
2. Review spec changes. Re-import a new version, and change detection shows which changes are breaking and which are safe, for your approval. Lesson 9.3 shows it end to end.
3. Build a pack. In Execution, click New Test Run Pack, select the tests, and keep the project's default environment or override it. A pack runs against one environment, so keep one pack per environment.
4. Add the gate. Add the GitHub Action (it installs by @v1), the Azure DevOps task or the Jenkins plugin, or call the REST API from any other CI. Set the pack ID and a pass threshold. The step runs the pack, writes JUnit results, and fails the build when the pass rate falls below the threshold. Lesson 9.15 shows a build passing, then failing after a price change.

Try it yourself

On a trial, import the sandbox spec, generate tests for the Products endpoints, and build a Test Run Pack from them in Execution. Click Run Now, then open the run in Reporting. The pass rate you see is the number a CI step compares with its threshold.

Recap

• How to do shift left testing: place every check at the earliest stage that has what it needs, name its owner, and give it a gate.
• Shift left testing in agile changes refinement, the definition of ready and the definition of done.
• Shift left testing in DevOps puts the cheapest checks first in the pipeline, starts gates in warn mode, and keeps a smoke test after deploy.

Next, in lesson 8.3, you decide which checks belong on the right, after release.