Testing throughout the SDLC
Chapter summary
Chapter 2 of the ISTQB Foundation Level syllabus covers how testing fits into different software development lifecycle models, introduces the five test levels and four test types, explains confirmation testing and regression testing, and closes with maintenance testing. The chapter carries 130 minutes of training time and accounts for 6 of the 40 exam questions (15% of the exam).
This page covers the main concepts in the chapter at a level that complements the full Chapter 2 guide.
How the development lifecycle shapes testing
Testing does not exist independently from how a team builds software. In a sequential model like the V-model, test activities are planned against corresponding development phases: component testing aligns with coding, system testing aligns with the integrated system. In iterative and incremental models, including Agile approaches, the full test process repeats within each iteration rather than running once at the end.
Certain good practices apply regardless of the lifecycle model in use: involving testers in requirements and design reviews, defining clear entry and exit criteria for each test level, writing testable requirements and user stories from the start, and using retrospectives to improve the test process over time.
Test-first approaches and DevOps
Test-driven development (TDD), acceptance test-driven development (ATDD), and behavior-driven development (BDD) all define tests before the code that will satisfy them is written. This is a practical application of the testing principle that early testing saves time and money, and it is an example of shift left in action.
Shift left means moving testing activities earlier in the lifecycle. Reviews of requirements before any code exists, static analysis of code as it is written, and test-first approaches are all examples. The earlier a defect is found, the cheaper it is to fix.
DevOps brings development, operations, and testing together with shared goals and an emphasis on automation and fast feedback. Continuous integration (CI) and continuous delivery or deployment (CD) depend on automated tests running frequently against each build. DevOps changes how teams think about test environments and test automation but does not change what testing is or why it matters.
The five test levels
Test levels are groups of test activities organized and managed together. Each level represents an instance of the full test process applied to software at a particular scope. The five levels are: component testing (individual software components, often automated), integration testing (interfaces between components), system testing (end-to-end behavior of a complete system), system integration testing (interfaces between the system and external systems), and acceptance testing (whether the system meets business and user needs before handover).
Each level has its own test basis, test objects, typical defects, approaches, and entry and exit criteria. The levels do not always run in strict sequence. In iterative development, multiple levels can overlap within a single iteration.
The four test types
Test types describe what quality characteristic a group of tests evaluates. They cut across test levels: any test type can be applied at any level. The four types are: functional testing (what the system does), non-functional testing (how the system performs, including performance, security, reliability, and usability), white-box testing (the internal structure of the system), and change-related testing (confirmation testing and regression testing).
The key distinction between test levels and test types is that a level describes when and at what scope testing happens, while a type describes what aspect of quality is being evaluated.
Confirmation testing and regression testing
After a defect is fixed, confirmation testing checks that the specific defect has been resolved. This means re-running the test case that originally found the problem, under the same conditions, ideally with the same person performing the test.
Regression testing checks that the fix, or any other recent change, has not broken something that was previously working. Regression test suites grow as a system evolves and are strong candidates for automation, since the same tests need to be run repeatedly against different builds.
Maintenance testing
Maintenance testing covers what happens to testing once a system is in production. It is triggered by three types of events: modifications (planned enhancements, defect corrections, or adaptations for a new environment), migrations (moving the system or its data to a new environment), and retirement (decommissioning the system and archiving its data).
The amount of maintenance testing required depends on the risk of the change, the size of the system, and how long the system has been in operation. Impact analysis is used to determine which parts of the system a change might affect, informing how much regression testing is needed.
Exam weight and K-levels
Chapter 2 contributes 6 questions to the exam (15%). Most learning objectives are K1 or K2. See the full Chapter 2 guide for a complete breakdown and the learning objectives page for the full objective-by-objective breakdown.
Last reviewed: June 2026.