Shift-Left Testing
The cheapest bug to fix is the one you find in the requirements — before a developer has written a single line of code. Shift-left means moving QA activity to the left of the timeline, into planning, requirements, and design.
1 The Hook
An Auckland fintech writes a user story: “As a user, I can transfer funds between accounts.” No maximum amount specified. No handling for insufficient funds specified. No international transfer restrictions noted.
Development writes code for the happy path. QA writes tests for the happy path. All tests pass. Week 3 in production: a customer transfers $500,000 to an overseas account. There is no daily limit check. The story never required one.
Post-incident analysis: a 10-minute Three Amigos session would have surfaced three gaps — daily limits, insufficient funds handling, and international transfer restrictions — before a developer opened their IDE.
The story was not wrong. It was incomplete. That is what shift-left catches: the things nobody wrote down because nobody thought to ask.
2 The Rule
Every user story has edge cases the product owner didn’t think of, technical constraints the developer hasn’t flagged, and compliance requirements QA is uniquely positioned to spot. Surface them before development starts.
Senior engineer insight
The shift-left principle clicked for me during a government programme where the QA team was brought in at sprint planning, not at code-complete. Within two sprints, the defect escape rate into SIT dropped by 60% — not because testing improved, but because the stories going into development were unambiguous for the first time. The real leverage is not in catching bugs earlier; it is in eliminating the conditions that produce them.
Most common mistake: teams hold Three Amigos sessions after stories are already groomed and estimated, treating it as a checkbox rather than the actual refinement activity. By that point, the product owner has anchored on a scope, the developer has mentally committed to an approach, and QA questions that challenge either assumption create friction instead of value. Run the session while the story is still fluid.
3 The Analogy
A structural survey before you buy a house.
You could buy it, move in, then discover the foundations are cracked. Or you survey it first. The crack costs the same to fix — but finding it before purchase gives you choices: negotiate, walk away, or budget for the repair. Finding it after you move in leaves you only one option.
A defect found in requirements gives you choices. A defect found in UAT gives you a crisis.
4 Watch Me Do It
A Three Amigos session for a KiwiSaver contribution rate change feature. Three people, ten minutes, one story.
The user story: “As a KiwiSaver member, I can update my contribution rate from my profile page.”
What each person surfaces:
- Developer: “The Revenue NZ API only accepts specific rate values (3%, 4%, 6%, 8%, 10%). We need validation for anything outside that set.”
- QA: “What happens if the member changes rate mid-pay-period? What if the employer hasn’t processed the previous rate yet?”
- Product owner: “The change must not take effect until the next pay period. We cannot change it retrospectively.”
Resulting acceptance criteria:
Ten minutes of conversation. Four testable acceptance criteria. Zero ambiguous user stories left for a developer to interpret alone.
From the field
A Wellington-based insurance team adopted shift-left practices mid-programme after repeated UAT blow-outs. The squad assumed that having a tester attend sprint planning was enough — QA was present, so stories were "shift-left reviewed." What they discovered in the retrospective was that the tester had been silent in planning because they felt outnumbered and under-prepared; no one had made the QA contribution an explicit agenda item. They restructured Three Amigos into a dedicated 20-minute slot the day before planning, with a fixed template: QA asked about failure modes, regulatory constraints (FMA and Privacy Act 2020), and integration failure scenarios before any estimation occurred. UAT defects from ambiguous requirements dropped from 14 per sprint to 3 within six weeks. The lesson that generalises: shift-left is a structural commitment, not a role change. Attendance without a defined contribution is theatre.
5 When to Use It
Shift-left activity is most valuable at three moments in the delivery cycle:
- Sprint planning and refinement: Review every story before it enters a sprint. Stories with no acceptance criteria or ambiguous scope should not be accepted into development.
- Before development of complex features: Any story with business logic, regulatory constraints (Revenue NZ, FMA, Privacy Act), or external dependencies (payment APIs, identity providers) warrants a Three Amigos session.
- Before API or integration design is finalised: Once an API contract is agreed, changing it is expensive. QA review of API designs, not just implementations, catches interface gaps before they are built.
6 Common Mistakes
🚫 “I used to think: QA’s job starts when code is ready to test.”
Actually: By the time code exists, the cost of a requirements defect has already multiplied. A developer has interpreted an ambiguous story, built the wrong thing, and now needs the code changed, retested, and re-reviewed. QA adds more value in a 10-minute story review than in a 3-day SIT cycle chasing avoidable defects.
🚫 “I used to think: Three Amigos sessions are only for BDD teams.”
Actually: Three Amigos is a conversation technique, not a BDD requirement. You do not need Cucumber or Gherkin to run one. You need a product owner, a developer, and a tester in a room for ten minutes. The output is agreed acceptance criteria — written in whatever format your team uses.
🚫 “I used to think: acceptance criteria slow down delivery.”
Actually: Absent acceptance criteria slow down delivery — they just push the slowdown into SIT and UAT where it is more expensive. A story with clear, testable acceptance criteria is faster to develop, faster to test, and less likely to need rework. The 10-minute investment in planning saves days downstream.
7 Now You Try
You are the QA tester in a Three Amigos session for this user story: “As a user, I can reset my password using my email address.” The product owner has said nothing beyond this. Write: (a) the 3 questions you would ask as QA, (b) the technical constraints you would expect the developer to raise, and (c) at least 4 testable acceptance criteria in Gherkin or plain English.
Why teams fail here
- QA attends planning sessions but has no defined contribution — they listen, nod, and the stories move into development with the same gaps as before.
- Acceptance criteria are written by the product owner alone after planning, without developer or QA input, so they describe the happy path and nothing else.
- TDD adoption stalls because developers are writing tests against ambiguous requirements — the tests pass, but they are testing the wrong thing.
- Teams treat shift-left as a one-time process change rather than a sprint-by-sprint discipline, so it erodes under delivery pressure within two or three sprints.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about shift-left testing.
Q1. What is shift-left testing and why does it reduce defect cost?
Strong answer: Shift-left testing means involving testers earlier in the delivery process — in requirements, design, and development, not just at the end. The cost of fixing a defect multiplies at each later stage: a defect found in requirements costs a document correction; found in UAT costs a week of fixes and reruns; found in production costs the fix plus the business impact of the failure. Shift-left reduces defect cost by catching defects when they are cheapest to fix. In agile teams, shift-left means testers review acceptance criteria before development begins, pair with developers during implementation, and test within each sprint rather than after.
Q2. How does shift-left testing change the tester's role in a sprint?
Strong answer: In a traditional model, testers receive a build at sprint end and test against requirements. In a shift-left model, testers are involved from the start: they review and contribute acceptance criteria in backlog refinement, ask "what could go wrong?" in three amigos sessions, test stories as they are developed (not after), and raise defects in time for developers to fix them within the sprint. This requires testers to be technically engaged earlier — understanding what is being built and how, not just what it is supposed to do.
Q3. What is the difference between shift-left and DevSecOps in testing?
Strong answer: Shift-left is the broad principle of moving quality activities earlier. DevSecOps extends shift-left specifically to security — moving security testing into the CI/CD pipeline rather than a pre-release gate. DevSecOps includes: SAST (static application security testing) running on every commit, dependency scanning in the build pipeline, DAST (dynamic application security testing) in the integration environment, and container image scanning before deployment. The NZ government's NZISM recommends a security-by-design approach that aligns with DevSecOps shift-left principles.
Q1: Why is a defect found in requirements cheaper to fix than one found in SIT?
Because in requirements, the fix is a conversation — you add or clarify a sentence. In SIT, the fix requires a developer to change code, a tester to re-test, a build to be redeployed, and the cycle to be repeated. The IBM Systems Sciences Institute estimated requirements defects cost 10× more to fix in development and 100× more to fix in production than in requirements.
Q2: What is the specific contribution QA makes in a Three Amigos session?
QA surfaces failure modes, edge cases, and compliance requirements that the product owner and developer typically do not consider. The product owner thinks about the happy path. The developer thinks about the implementation. QA asks “what happens when it goes wrong?” — and that asymmetry is why you need all three perspectives.
Q3: What makes an acceptance criterion testable?
A testable acceptance criterion has a specific condition (Given), a specific action (When), and a specific, measurable outcome (Then). “The system should be fast” is not testable. “When I submit a payment, the confirmation screen appears within 3 seconds on a 4G connection” is testable.
Q4: When in the sprint cycle should shift-left activity happen?
At sprint planning and refinement, before any story enters development. Stories without testable acceptance criteria should not be accepted into a sprint. QA review of stories should happen at the same time as developer review, not after.
Q5: Do you need a BDD framework to run a Three Amigos session?
No. Three Amigos is a conversation technique. You need a product owner, a developer, and a tester. The output can be written in Gherkin, in plain English, in a table, or in whatever acceptance criteria format your team uses. The format is less important than having the conversation.
9 ISTQB Mapping
The ISTQB Foundation syllabus covers static testing techniques (reviews, walkthroughs, inspections) and the shift-left principle as a key quality strategy. The syllabus explicitly positions requirements review as a testing activity. This lesson applies those principles with a Three Amigos and ATDD focus, grounded in NZ fintech and government programme examples.
Key takeaway
The cheapest place to fix a defect is in the conversation before the story is written — because at that point, the fix costs nothing except ten minutes and a willingness to ask uncomfortable questions.
10 Next Steps
You have covered the left end of the spectrum. Now the right end: validating behaviour in production safely, with feature flags and canary deployments.