Shift-left testing is correct. Testing earlier in the development lifecycle, closer to where decisions are made and code is written, produces better outcomes at lower cost. This is not controversial. The defect cost curve — the observation that fixing a bug in production is orders of magnitude more expensive than fixing it in requirements — has been validated empirically across decades of software projects.
What's happening in some organisations, however, is something different: using "shift-left" as justification for removing independent QA from the process entirely. The argument goes: if developers write tests and QA happens as part of development, we don't need a separate QA function. This is not shift-left. It's a cost-cutting rationalisation wearing shift-left clothing.
What shift-left actually means
The original shift-left concept, attributed to Larry Smith's 2001 paper, was about moving testing activities earlier in the project timeline — introducing testing effort in requirements analysis, architecture review, and design phases rather than waiting until a testable build exists. The "left" refers to earlier in a left-to-right timeline of development phases.
In practice, shift-left testing means:
- QA involvement in requirements review — identifying ambiguities, testability gaps, and missing acceptance criteria before development begins
- Three amigos sessions (or equivalent) where QA, development, and product discuss stories before they're built
- Unit and integration test writing during development — not after
- Static analysis and code review as quality gates
- Test automation built alongside features, not after release
Notice what this list doesn't include: removing the independent testing function. Every item on the list is about adding quality activities earlier. None of them remove the need for verification by someone other than the person who wrote the code.
How it gets misappropriated
The misappropriation follows a consistent pattern. A team adopts shift-left practices legitimately — developers write more unit tests, QA gets involved earlier, CI/CD improves. This genuinely reduces defect rates. Leadership observes that defect rates are lower and concludes that QA headcount can be reduced. The headcount reduction is implemented. Defect rates climb. The cycle repeats.
The reason this pattern recurs is a category error: confusing the reduction in a type of defect (those found after development) with the reduction in need for a function (independent verification). Shift-left practices reduce the number of defects that reach the testing phase. They do not eliminate the testing phase, and they do not eliminate the need for someone independent of development to verify the software's behaviour.
Shift-left means testing happens earlier and more continuously. It does not mean testing becomes optional.
The independence problem
There is a fundamental epistemic problem with developers testing their own code. It's not about competence or diligence — good developers are perfectly capable of writing thorough tests. It's about the cognitive limitations inherent in verifying your own work.
When you write code, you have a mental model of how it works. When you write tests for that code, you tend to test the behaviour your mental model predicts. The bugs you're most likely to miss are the ones that result from incorrect assumptions in your mental model — the cases where the code does what you intended but what you intended was wrong. An independent tester approaches the software without your mental model. They test behaviours you didn't predict, explore paths you didn't design, and ask questions you didn't think to ask.
This isn't a hypothesis — it's a well-documented phenomenon in cognitive psychology and software engineering research. It's why code review exists. It's why pair programming works. It's why peer review is a universal practice in every technical and scientific field that cares about correctness.
What ISTQB says about independence
ISTQB FL The ISTQB Foundation Level syllabus dedicates specific attention to the concept of testing independence. It defines a spectrum of independence from no independence (developer tests their own code) through moderate independence (team member tests colleague's code) to full independence (external tester with no project history tests the product).
The syllabus is explicit: higher independence generally produces better defect detection, because independent testers are not influenced by the same assumptions, familiarity effects, or confirmation bias that affect the original developer. It also notes that full independence has costs — communication overhead, context ramp-up time — and that the optimal independence level depends on risk and context.
What the ISTQB guidance does not suggest, at any level, is that zero independence is acceptable. Developer self-testing is positioned as the lowest-independence option, not as an alternative to testing by others. This is a meaningful distinction that gets lost when "shift-left" is used to justify removing independent QA.
What developers should test
This isn't an argument against developer testing. Developer testing is valuable and necessary. ISTQB FL The activities that belong to developers in a healthy shift-left team:
- Unit tests for every piece of logic they write
- Integration tests for service boundaries they own
- Code review with testing completeness as an explicit criterion
- Definition of Done that includes passing tests
- Running the existing test suite before submitting a PR
These activities catch a significant category of bugs — primarily logic errors, unit-level regressions, and straightforward integration failures. They are fast, specific, and well-suited to developer execution because developers have the implementation context to write meaningful assertions.
What independent QA adds that dev self-testing can't
Independent QA adds specific value that developer self-testing structurally cannot provide:
- Exploratory testing: an independent tester asking "what happens if I do this?" without prior knowledge of the implementation finds a category of defects that never appear in specification-based tests
- Cross-feature interaction testing: developers work in bounded contexts; independent QA sees the product as a whole and tests interactions between features that no individual developer owns
- User perspective: a tester without implementation context approaches software more like a user and less like an engineer — and users consistently find issues that engineers with deep product knowledge overlook
- Compliance and non-functional verification: in regulated industries, someone independent of development must verify and attest to compliance behaviour; developer self-certification doesn't satisfy this requirement
- Challenge to assumptions: a QA engineer who asks "why does it work this way?" and "what should happen if..." challenges requirements and design assumptions that developers, embedded in the implementation, no longer question
Practical implementation
The right model is a partnership, not a handoff. QA and development working in the same sprint, with QA involved from story refinement to acceptance. Developers own unit and integration testing. QA owns exploratory testing, system testing, E2E regression, and whatever compliance verification the context requires.
The shift-left discipline reduces the number of defects that reach QA. The independent QA function finds the defects that developer testing couldn't — because they're the defects that require a different perspective to see. Both are necessary. Neither substitutes for the other.
If your organisation has removed independent QA in the name of shift-left, the defects haven't gone away. They've just moved to production.
References: ISTQB Foundation Level Syllabus v4.0; ISTQB Advanced Level Test Manager Syllabus; Larry Smith, "Shift-Left Testing" (2001), DDJ; Myers, Badgett & Sandler, "The Art of Software Testing" (3rd ed.).