A Shift Left Testing Example: One Requirement, Tested Before the Code

This is lesson 8.1 of AI and Shift-Left Testing Strategy. It follows one requirement through a shift-left workflow; for the definition, benefits and maturity levels, start with what is shift-left testing.

A shift left testing example in one sentence

Here is a shift left testing example you can check yourself: take one rule from the sandbox store's requirements, "order quantity is an optional whole number of at least 1, and defaults to 1", and write its tests while the rule is still being discussed, before anyone writes the code. The tests then wait for the code, and the first build that breaks the rule fails on the spot. Nothing about the check changes; only the moment you first run it does.

The shift-left testing pillar page moves a contract check through four pipeline stages. This lesson starts one step earlier, with a requirement.

The requirement, as written

The sandbox store's requirements document states it twice. Functional requirement FR-004 says POST /api/v1/orders returns 201 with the order, and that quantity defaults to 1. Business rule O-01 adds the detail:

RULE O-01 quantity — optional whole number of at least 1. Default 1. Invalid → 400: 0, -1, 1.5, 2.5.

On a traditional timeline, this rule is coded first and tested later. On a shifted-left one, QA reads it in refinement and asks the questions that become tests.

Step 1: test the requirement before the code

A requirement is testable when every input has an expected outcome. Write the examples down and see which ones the document answers:

Two rows have no answer. Is there an upper limit? Is a numeric string accepted or rejected? That is the cheapest defect you will ever find: a gap in a sentence, fixed by editing the sentence. Found after release, the same gap is a production incident ("a customer ordered a million units") or a compatibility promise you can no longer take back.

Step 2: make the examples executable

The table becomes tests before the endpoint exists. They need only the contract: the path, the request body, the expected status and fields. The spec says quantity is an integer with minimum: 1 and default: 1, so the positive, negative and boundary cases can be written, or generated, from it plus the rule.

Against the real sandbox, which already implements the rule, you can see both sides:

curl -X POST 'https://demo.totalshiftleft.ai/api/v1/orders' \
  -H 'Content-Type: application/json' \
  -d '{"quantity":0}'

curl -X POST 'https://demo.totalshiftleft.ai/api/v1/orders' \
  -H 'Content-Type: application/json' \
  -d '{"quantity":2}'

The first returns 400 with details[0].field set to quantity; the second returns 201 with status: "pending". In a real project, at this point the endpoint would not exist yet: the tests run against a mock server built from the spec, or simply wait in the suite until the first build.

Step 3: let the tests gate the first commit

When the developer opens the pull request that adds the endpoint, the suite runs on it. If the implementation accepts quantity: 0, the build fails before review, with a test whose name points back to O-01. Nobody needs to remember the rule; the suite does.

Three things made this work, and none of them is a tool:

1. The rule was written down with examples.
2. QA took part before the code, not after it.
3. The tests existed before the change that they judge.

Shift left testing in QA: what changes for testers

Shifting left moves QA's centre of gravity, not QA's existence.

• Refinement becomes test design. Testers ask "what should happen when…" for each acceptance criterion and record the answers as examples.
• Testers own the oracle. The expected outcomes come from requirements and the spec, not from whatever the code happens to return.
• Developers run the tests first. The suite runs on their branch, so most failures are seen by the person who caused them, minutes later.
• Exploratory and release testing stay. They stop being the first chance to find a defect and become a check on what the earlier stages missed.

The hard part is usually the requirements, not the testing: unclear rules are one of the six adoption problems covered in shift-left testing challenges.

Shift left testing vs TDD

They are related, and often confused.

TDD is one way to shift left at the unit level. The closer relatives of this example are acceptance-test-driven development and behaviour-driven development, which also start from examples agreed before coding.

Shift left testing pros and cons

The last con is why shift-left is never the whole strategy. Lesson 8.3 covers what stays on the right.

Common mistakes

• Writing tests from the implementation. If the expected result is "whatever it returned", the test can't find a defect.
• Skipping the unanswered rows. The "2" and 1000000 cases are the valuable ones; leaving them out hides the gap.
• Shifting only the work, not the decision. If QA writes early tests but nothing fails a build, the tests are documentation.

In Shift-Left API: requirements to tests before a run

Shift-Left API reads the requirements document and the spec together, so the rule above becomes tests before anything has been executed. Lesson 9.2 walks through the screens in full; here is the short version.

1. Set up an AI provider first: reading prose documents uses AI, with your own key or, on Trial and Enterprise, a self-hosted model.
2. In a project built from https://demo.totalshiftleft.ai/openapi/rest.json, open Requirements, click Choose requirement files, and upload the store's requirements document.
3. Click Review all requirements. Rules the AI read from prose wait for your approval; rules read from structured sources such as the spec are approved automatically unless they conflict, so the quantity rule may already be approved. Approve what is waiting.
4. Open Orders → Create a new order and click Generate tests. The tests are planned from the spec and the approved requirements; generating runs nothing against the API.
5. Open Requirements → Traceability. The quantity requirement is listed with its source in the document and its linked tests, and the Tests column says they have not run.

That last screen is the shift-left moment in one row: a requirement with tests, and no code run yet.

Try it yourself

In the free edition, upload the store's requirements to a project built from the sandbox spec, approve the requirements, generate tests for Create a new order, and open Traceability. Find the quantity rule: how many tests are linked to it, and what does the Tests column say about them?

Recap

• A shift left testing example starts with a requirement, not a tool: write the examples, find the unanswered rows, and turn them into tests before the code.
• Shift left testing in QA moves testers into refinement and test design; exploratory and release testing remain as a later check.
• Shift left testing vs TDD: TDD is a unit-level coding practice and one way to shift left; the strategy covers requirements, contracts and APIs too.

Next, in lesson 8.2, you turn this one example into a team practice: rituals in agile, gates in the pipeline.