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.
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 IRD 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.
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 (IRD, 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.
8 Self-Check
Click each question to reveal the answer.
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.
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.