Shift-left testing means moving test activities earlier in the delivery cycle: testers review requirements before code exists, tests are written ahead of implementation, and static analysis and automated component tests run on each change to the repository. It does not drop testing at later levels; it catches defects sooner.
Quick Overview
What you will learn:
- How the ISTQB Foundation Level syllabus defines shift left and which practices it lists
- Where TDD, ATDD and BDD fit in
- What shifting left means for security under NIST SSDF, OWASP SAMM and OWASP ASVS
- How responsibilities change when testing starts before the code
Who this article is for:
- Quality engineers and testers in agile teams
- Developers and tech leads building a CI/CD pipeline
- Product owners who write acceptance criteria
Reading time: 7 minutes
Shift Left in the ISTQB Syllabus
The ISTQB treats shift left as another name for the principle of early testing. Section 2.1.5 of the Certified Tester Foundation Level syllabus v4.0.1, available from the certification page on istqb.org, describes it as performing testing earlier in the software development lifecycle, without waiting for code to be implemented or components to be integrated. The same section adds a caveat that is easy to miss: shifting left does not mean neglecting testing later in the lifecycle.
The syllabus illustrates the idea with good practices rather than a single technique. Testers review specifications and tend to find ambiguities, gaps and inconsistencies there. Test cases are written before the code, which then runs in a test harness during implementation. Continuous integration, and better still continuous delivery, adds fast feedback and automated component tests. Static analysis of source code happens before dynamic testing or as part of the automated process. Non-functional testing starts at component level where that is possible.
Section 2.1.3 places test-first development in the same family. In TDD, tests come first, code is written to pass them, and both are refactored. ATDD derives tests from acceptance criteria during system design, and BDD expresses expected behaviour in a Given/When/Then format that stakeholders can read.
Making the Case Without Myths
The syllabus on istqb.org justifies early testing qualitatively: a defect removed early does not propagate into work products derived from the flawed one, and fewer failures surface late. It is equally candid about the price. Shifting left may mean extra training, effort or cost at the start, with savings only expected later, and it needs stakeholders who are convinced by the idea.
That suggests a better business case than the multipliers that circulate about the rising cost of a late bug. Track your own numbers instead: the phase in which each defect was found, the time it took to fix, and whether that distribution moves earlier after you change the process.
The Security Side: SSDF, SAMM and ASVS
Security follows the same logic. NIST SP 800-218, the Secure Software Development Framework version 1.1 published in February 2022 on csrc.nist.gov, includes practices that naturally sit early in delivery. PW.1 covers designing software to meet security requirements using risk modelling such as threat modelling. PW.7 covers reviewing or analysing human-readable code, by people or by tools. PW.8 covers testing executable code to find vulnerabilities that earlier reviews missed. According to the NIST publication page on csrc.nist.gov, a draft revision, SP 800-218 Rev. 1 (SSDF version 1.2), was released on 17 December 2025 and its comment period closed on 30 January 2026; until a final version appears, 1.1 remains the reference.
OWASP offers two complementary tools on owasp.org. SAMM, currently at version 2.2.0, is an open maturity model covering the whole software lifecycle that helps an organisation evaluate its existing security practices and improve them in well-defined iterations. The Application Security Verification Standard, whose version 5.0.0 was published on 30 May 2025, supplies security requirements that a team can reference when writing specifications and test cases, which is exactly where shift left wants them.
Who Owns Quality When Testing Moves Left
The syllabus describes a whole team approach in which any team member with the right skills can take on any task and everyone is responsible for quality. In a shift-left team this usually looks like:
- Quality engineer: reviews requirements, agrees the test strategy and automation approach with developers, helps write acceptance tests.
- Developer: writes component tests, often test-first, and acts on static analysis findings in the pipeline.
- Product owner: phrases acceptance criteria so that tests can be derived from them.
- Security champion: named in SSDF task PW.1.1 as a particular focus when training the team in risk modelling.
Read Also
- A testing strategy for agile projects — where testing fits in a sprint
- From manual tester to QA engineer — the skills behind the role
- DevSecOps in practice — security inside the pipeline
Build Your Skills
Take a look at the ISTQB Certified Tester Foundation Level and Test Driven Development: from theory to practice courses. The first builds a shared vocabulary of testing concepts and techniques, the second teaches writing tests before code. Contact us to match the scope to your team.
Frequently Asked Questions (FAQ)
What is contract testing and how does it support shift left?
Contract testing checks that an API provider and its consumer both honour the agreed interface. It exposes mismatches while each service is being built, long before a full integration environment exists. Our article on contract testing in a microservices architecture covers the trade-offs.
Which testing techniques are used in a shift-left approach?
The usual set includes specification and requirements reviews, component tests written test-first, acceptance tests derived from criteria through ATDD or BDD, static analysis in the CI pipeline and early non-functional checks. System and acceptance testing remain, but they receive fewer defects.
What does a QA engineer do in a shift-left team?
Less time goes into executing tests after implementation and more into reviewing requirements, shaping the test strategy, building automation and supporting developers and the product owner. The aim is quality designed into the process from the start rather than inspected at the end.
Does the ISTQB Foundation Level syllabus cover shift left?
Yes. The CTFL v4.0.1 syllabus available on istqb.org devotes section 2.1.5 to shift left and lists the practices that implement it, linking the concept to early testing and to TDD, ATDD and BDD. It is therefore part of preparing for the certification.