What does shift-left mean in testing, and what can a tester do before any code exists?
answer
- Where on the delivery line checks happen
- Requirements and designs are testable artefacts
- Ambiguity and testability, before code
- Examples agreed by business, development, test
- Adds early checks, deletes no later ones
basics
~20 sShift-left means moving verification earlier in delivery, toward requirements and design, instead of leaving it as a phase after the build. Before code exists a tester reviews requirements for ambiguity and testability and agrees concrete examples of expected behaviour.
solid answer
~50 sPicture delivery as a line running idea, requirement, design, code, build, integrated system, release. Anything that finds a problem sits somewhere on that line, and shift-left is the deliberate choice to move checks toward the left-hand end. Before a line of code exists a tester can read the requirement as a source of defects (ambiguity, contradictions, undefined terms, missing negative cases), review it for testability (can the precondition be set up, can the outcome be observed), agree concrete worked examples of the expected behaviour with the business and the developer, and agree the shape of an interface before either side is built. The motive usually quoted is that a defect costs more the later it is found; the direction is widely accepted, the exact multipliers are contested. Shift-left adds early checks — it does not delete the later ones.
go deeper
Be ready to define shift-left in one sentence and name two concrete things a tester does before code exists — reviewing a requirement for ambiguity and agreeing worked examples of expected behaviour.
Explain the mechanics: what you look for in a requirement, why testability means controllability plus observability, and how agreed examples become the acceptance criteria everyone builds against.
Show you have run this on real work — how you got developers and business owners into the review, what a review produced that a later phase would have missed, and how you kept it from becoming a standing meeting.
Own the investment argument. Be able to say how much early review a programme should buy, defend the direction of the late-defect argument without leaning on a contested multiplier, and say what you would stop doing to pay for it.
## What "left" actually refers to Draw delivery as a line: idea, requirement, design, code, build, integrated system, release, live use. Every activity that can reveal a problem sits somewhere on that line. Historically most of them clustered near the right: a build was handed over, a test phase ran against it, and defects came back. **Shift-left is the deliberate movement of those checks toward the left-hand end of the same line** — not a new kind of testing, but the same intent applied earlier, to artefacts that are cheaper to change than code. The idea depends on one observation: a specification, a design sketch and an agreed example are all testable artefacts. You cannot execute them, but you can inspect them, and inspection finds a real and distinct class of defect — the ones that would otherwise be *built correctly* from a wrong instruction. ## What a tester can do before code exists 1. **Review the requirement as a defect source.** Read it hunting for vague quantifiers ("quickly", "most", "appropriate"), undefined terms, silent negative cases, contradictions between two rules, and pronouns with no clear referent. Each one is logged as a defect against the requirement, not merely mentioned in conversation. 2. **Review it for testability.** Two properties: *controllability* — can I put the system into the precondition the rule describes? — and *observability* — when it behaves, can I see the outcome the rule promises? 3. **Agree concrete examples.** Replace adjectives with worked cases: for this input, this outcome; for this boundary, this other outcome. Examples agreed jointly by business, development and test become the acceptance criteria, and they are the same artefact everyone builds against. 4. **Agree an interface before either side is built.** Two teams that must integrate can write down request and response shapes, field meanings and error cases first, then each build against that agreement rather than discovering the mismatch at integration. 5. **Support developer-owned checks.** The fastest verification is the one running inside the build, written and owned by whoever wrote the code. The tester's contribution is the cases the developer would not think of — boundaries, hostile inputs, the negative paths. ## A worked example A clinical-trial data capture form records a participant visit: 27 fields, an eligibility banner at the top, and an adverse-event section that unlocks only for enrolled participants. The requirement reads: *the eligibility banner must show the participant's current status.* A pre-code review asks one question — **current as of when?** The conversation reveals that status is served from a cached projection refreshed on a schedule, so the banner could show *enrolled* for a participant withdrawn 40 seconds ago, and the adverse-event section would unlock for someone who should no longer have it. That is a stale-cache read, and at review time it costs one paragraph added to the requirement: the banner must reflect a status no older than the current visit's start, and the cache must be invalidated on withdrawal. Found instead after the build, the same problem costs re-analysis, a design change to the caching layer, rework, a re-run of the regression pack, and a decision about visits already recorded against a wrong banner. ## The motive, stated honestly Shift-left is usually justified by the claim that a defect costs more the later it is found. The *direction* is widely accepted and matches ordinary experience: a requirement fixed in a conversation touches one artefact, while the same fault fixed after release touches analysis, code, tests, data and users. The *specific multipliers* often quoted are contested — they come from a small number of old studies over unlike projects and do not transfer cleanly. Quote the direction with confidence and treat any exact number as disputed; interviewers notice which of the two you assert. ## What shift-left is not - It is **not** deleting later verification. Integration, end-to-end and exploratory work still happen; shift-left changes what they find, not whether they run. - It is **not** "developers test now, so testers are unnecessary." Developer-owned checks and a tester's analysis answer different questions. - It is **not** a phase rename. Attending a refinement meeting silently is not a review. - It is **not** free. Reviews consume the time of several people, and early artefacts decay when scope churns. ## Signs it is working Useful leading indicators: ambiguities raised per requirement before build; the share of work items that reach development with agreed examples; defects recorded against requirements and designs rather than against code; and the rework rate on delivered items. A team that shifted left successfully sees the defect count *move earlier*, not simply drop.
- A developer says reviews are just more meetings. How do you make a requirement review worth their hour?Come prepared and time-boxed. Read the item beforehand and arrive with a written list of specific questions — undefined terms, missing negative cases, boundaries — rather than opening a discussion. Aim the session at decisions, record each one as a change to the requirement, and stop when the list is exhausted. A review that ends with three rules rewritten is visibly cheaper than the rework it displaced; a review that ends with general agreement is the meeting they were complaining about.
- Does shifting left mean the tester writes the developers' unit checks?No. Developer-owned checks stay owned by the people who wrote the code — that ownership is what keeps them fast and maintained. The tester's contribution is the cases: boundaries, hostile inputs, negative paths and the risky combinations a developer focused on the happy path will not think of. Some teams pair on this. The failure mode is a tester who inherits maintenance of a suite they cannot change safely, which shifts work left in name only.
- How would you measure whether a shift-left effort actually changed anything?Look for defects moving earlier rather than disappearing: count issues raised against requirements and designs, the share of items arriving with agreed examples, and the rework rate on delivered items. Compare where defects are found now versus before. A drop in total defect count alone is ambiguous — it can equally mean less was inspected.
It is the difference between proofreading a recipe before you cook and tasting the finished dish: both catch mistakes, but only one of them lets you fix the mistake without throwing food away.
saying these in an interview costs you the question
- Says shift-left removes the need for later testing
- Quotes an exact cost multiplier as established fact
- Treats shift-left as testers writing all automation
- Calls silently attending refinement a requirement review
- Claims requirements cannot be reviewed until code exists
- Thinks shift-left means starting the test phase sooner