Overview
Testing Throughout the Software Development Lifecycle explains that the software development lifecycle (SDLC) changes when testing happens, how much is documented, which techniques fit and how much is automated. It lists good practices that hold in every lifecycle, introduces the test-first approaches (TDD, ATDD and BDD), and connects DevOps, continuous integration and shift left to earlier, faster feedback, with retrospectives as the improvement loop.
The middle section is the most testable: the five test levels (component, component integration, system, system integration and acceptance), each with its own objectives, test basis and responsibilities, and the four test types (functional, non-functional, black-box and white-box) that can be applied at any level. It then separates confirmation testing from regression testing and ends with maintenance testing and its triggers: modification, migration and retirement. Chapter 3 continues the shift-left theme through static testing.
How it's tested
Chapter 2 questions are mostly K2 scenarios: a team, a lifecycle and an activity, and you identify the test level, the test type, the test-first approach or the maintenance trigger. A few K1 questions ask you to recall good practices or examples of test-first development. The decisive words are usually the actor, the test basis and the objective named in the stem.
-
Name the level or type
A scenario describes who tests what against which test basis, and you identify the test level (for example system integration) or the test type (for example non-functional).
-
Confirmation or regression
A defect has been fixed and the stem asks what kind of testing re-runs the failed test versus what checks unchanged areas for adverse effects.
-
Lifecycle impact
The stem contrasts sequential and iterative or Agile and DevOps contexts and asks how testing changes, or which practice is an example of shift left.
A stem says an online shop's checkout calls an external payment provider and the team now tests the exchange of messages between the shop and that provider. Component integration is tempting because "integration" appears, but the interfaces are between the system under test and an external service, not between components of one system. That makes it system integration testing, and the clue is the external provider.
Syllabus sections 3
Official syllabus sections from the ISTQB outline, in outline order.
2.1 Testing in the Context of a Software Development Lifecycle (SDLC)How the lifecycle shapes testing, test-first approaches, DevOps, shift left and retrospectives.
- What it means
- The chosen SDLC affects the scope and timing of test activities, the level of detail of test documentation, the choice of techniques and approach, the extent of automation, and the tester's role. In sequential models, testers join early with reviews and test analysis but dynamic testing comes late; in iterative and incremental models, static and dynamic testing happen in every increment; Agile favors lightweight work products, extensive automation and experience-based techniques.
- What to understand
- Good practices for every SDLC: each development activity has a corresponding test activity, each test level has specific objectives, test analysis and design for a level start during the matching development phase, and testers review drafts early. Test-first approaches include TDD (tests drive coding and refactoring), ATDD (tests derived from acceptance criteria before development) and BDD (behavior expressed in Given/When/Then natural language that can be turned into executable tests). DevOps brings fast feedback, continuous integration (CI) and continuous delivery (CD) and automated regression, but needs a defined delivery pipeline, maintained tools and automation investment. Shift left means testing earlier, and retrospectives turn lessons into process improvement.
- How it shows up
- A K1 question asks which approach writes tests in Given/When/Then form, or a K2 question lists practices and asks which one is an example of shift left, such as running static analysis before dynamic testing or writing tests before code.
- Common confusion
- Treating DevOps as removing the need for manual testing; the syllabus states that manual testing, especially from the user's perspective, is still needed.
2.2 Test Levels and Test TypesThe five test levels, the four test types, and confirmation versus regression testing.
- What it means
- Test levels are groups of test activities organized together: component testing (components in isolation, usually by developers with harnesses or unit test frameworks), component integration testing (interfaces and interactions between components, shaped by the integration strategy), system testing (behavior and capabilities of the whole system, functional and non-functional), system integration testing (interfaces with other systems and external services) and acceptance testing (validation and readiness for deployment, in forms such as user acceptance, operational acceptance, contractual and regulatory acceptance, and alpha and beta testing).
- What to understand
- Levels differ by test object, objectives, test basis, typical defects and failures, and approach and responsibilities. Test types cut across all levels: functional testing evaluates what the system should do (completeness, correctness, appropriateness), non-functional testing evaluates how well it does it using ISO/IEC 25010 quality characteristics such as performance efficiency, security, reliability and interaction capability (also known as usability), black-box testing derives tests from specifications, and white-box testing from internal structure. Confirmation testing checks that a defect was fixed; regression testing checks that a change, including a fix, has not caused adverse consequences elsewhere, ideally guided by impact analysis.
- How it shows up
- Scenarios describe an actor, a test basis and an objective and ask for the level, or describe what is being evaluated (response time, a calculation, code paths) and ask for the type; others describe a fix and ask what testing comes next.
- Common confusion
- Thinking non-functional testing belongs only to system testing; the syllabus says it can and often should start at component level, and every test type can be applied at every test level.
2.3 Maintenance TestingTesting changes to a system in operation, and the triggers that start it.
- What it means
- Maintenance testing tests changes to a system already in operation, whether corrective, adaptive to a changed environment, or to improve performance or maintainability. It involves testing the change itself and regression testing the parts that should not have changed. Its scope depends on the risk of the change, the size of the existing system and the size of the change.
- What to understand
- The triggers fall into three groups: modifications (planned enhancements, corrective changes and hot fixes), upgrades or migrations of the operational environment (for example moving platform, which can need tests of the new environment and of data conversion when data is migrated from another application), and retirement (which may require testing data archiving and the restore and retrieval procedures when long retention periods apply). Impact analysis helps decide how much regression testing a change needs.
- How it shows up
- A K2 question describes an event, such as decommissioning a legacy application whose records must be kept for seven years, and asks what maintenance testing should focus on.
- Common confusion
- Thinking retirement needs no testing because the system is going away; archiving, restore and retrieval may still need to be tested.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Five test levels
Component, component integration, system, system integration and acceptance testing, each with its own test object, objectives, test basis, typical defects and responsibilities.
- Remember
- Component integration covers interfaces between components inside one system; system integration covers interfaces with other systems and external services.
- Tested as
- Several K2 questions describe a scenario and ask which level it is.
- Trap
- Choosing component integration whenever the word "integration" appears, even when an external system is involved.
-
Four test types
Functional (what the system does), non-functional (how well it does it), black-box (specification-based) and white-box (structure-based).
- Remember
- Every test type can be performed at every test level; type and level are independent dimensions.
- Tested as
- Questions ask which type a described test belongs to.
- Trap
- Assuming white-box testing only happens at component level; it can apply to integration flows, architecture and workflows too.
-
Non-functional quality characteristics
Characteristics from ISO/IEC 25010 such as performance efficiency, compatibility, interaction capability (usability), reliability, security, maintainability, flexibility (portability) and safety.
- Remember
- Non-functional testing can start at component level, and some characteristics such as usability are best tested on the complete system in a representative environment.
- Tested as
- Stems mention response time, load or security and expect "non-functional".
- Trap
- Classifying a test of a calculation's correctness as non-functional because it is detailed or technical.
-
Confirmation testing
Testing after a defect fix to confirm the original defect has been successfully fixed, by re-running the tests that failed or adding new tests for the change.
- Remember
- When time is short it may be limited to re-executing the steps that reproduced the failure.
- Tested as
- Fix-then-test scenarios.
- Trap
- Calling it regression testing because tests are being re-run.
-
Regression testing
Testing to confirm that a change, including a fix that has already been confirmation tested, has not caused adverse consequences elsewhere in the system or its environment.
- Remember
- Impact analysis helps size it; regression suites grow each iteration and are strong candidates for automation, ideally in the CI pipeline.
- Tested as
- Questions ask what checks unchanged functionality after a change.
- Trap
- Thinking regression testing is only needed at system level; it may be needed at every level.
-
TDD, ATDD and BDD
Test-first approaches: test-driven development drives code through test cases, acceptance test-driven development derives tests from acceptance criteria before development, and behavior-driven development expresses behavior in Given/When/Then natural language.
- Remember
- In all three, tests can persist as automated tests that protect future changes, and all are examples of shift left.
- Tested as
- K1 recall of examples of test-first approaches.
- Trap
- Mixing TDD (developer-level, code-focused) with ATDD (team-level, acceptance-criteria-focused).
-
Shift left
Performing testing earlier in the SDLC: reviewing specifications from a testing perspective, writing tests before code, using CI and CD for fast feedback, running static analysis before dynamic testing, and starting non-functional testing at component level.
- Remember
- It may cost extra training, effort and money early, with savings expected later, and it needs stakeholder buy-in.
- Tested as
- K2 questions ask which practice illustrates shift left.
- Trap
- Picking a practice that merely adds more testing at the end of the lifecycle.
-
DevOps and testing
DevOps uses CI and CD pipelines to give fast feedback on code quality, stable automated test environments and broad automated regression testing.
- Remember
- Risks include having to define and establish the delivery pipeline, introduce and maintain CI/CD tools, and fund automation, and manual testing from the user's perspective is still needed.
- Tested as
- K2 summarize questions on DevOps benefits and risks.
- Trap
- Choosing "no manual testing is required" as a benefit.
-
Retrospectives
Meetings at the end of an iteration, release or project, or when needed, to discuss what went well, what could improve and how to embed improvements.
- Remember
- Results are recorded, often in the test completion report, and benefits include more effective testing, better testware, a better test basis and better developer-tester cooperation.
- Tested as
- K2 questions on retrospectives as a process-improvement mechanism.
- Trap
- Treating retrospectives as a blame or performance-appraisal session.
-
Acceptance testing forms
User acceptance testing, operational acceptance testing, contractual and regulatory acceptance testing, and alpha and beta testing.
- Remember
- Acceptance testing focuses on validation and readiness for deployment and is ideally performed by intended users; alpha testing is at the developer's site, beta testing at users' own locations.
- Tested as
- Scenarios ask which form fits a backup-and-restore check (operational) or a legal requirement (regulatory).
- Trap
- Labeling operational checks such as backup, restore and disaster recovery as user acceptance testing.
-
Maintenance testing triggers
Modifications such as enhancements and hot fixes, upgrades or migrations of the operational environment, and retirement of an application.
- Remember
- Scope depends on the risk of the change, the size of the existing system and the size of the change; migration may need data conversion tests, and retirement may need archiving and retrieval tests.
- Tested as
- K2 summarize questions on what maintenance testing covers.
- Trap
- Forgetting that regression testing is part of maintenance testing, not only testing the change.
-
Good practices in every SDLC
Each development activity has a corresponding test activity; each test level has specific objectives; test analysis and design start during the matching development phase; testers review drafts as early as possible.
- Remember
- These hold whether the lifecycle is sequential, iterative or Agile.
- Tested as
- K1 recall of good testing practices.
- Trap
- Choosing a practice tied to one lifecycle, such as "write a detailed test plan before each sprint", as universal.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Component integration vs. system integration vs. system testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Component integration testing | Tests interfaces and interactions between components of one system | Depends on the integration strategy such as bottom-up, top-down or big-bang | Using it for interfaces to external services |
| System testing | Tests the overall behavior and capabilities of the whole system, functional and non-functional | Focuses on the system itself, often end-to-end tasks against system specifications | Assuming only an independent test team can perform it |
| System integration testing | Tests interfaces between the system under test and other systems and external services | Needs environments as close as possible to operational ones | Calling it component integration because both mention interfaces |
Confirmation testing vs. regression testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Confirmation testing | Checks that the original defect has been fixed | Targets the fix itself, re-running failed tests or new tests for the change | Expecting it to reveal side effects elsewhere |
| Regression testing | Checks that a change has not caused adverse consequences | Targets unchanged areas and the environment, guided by impact analysis | Thinking it replaces confirmation testing |
Functional vs. non-functional vs. black-box vs. white-box
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Functional testing | Evaluates the functions the system should perform | Answers "what" the system does | Thinking it must be black-box |
| Non-functional testing | Evaluates attributes other than functional characteristics, such as performance or security | Answers "how well" the system behaves | Assuming it can only be done on the full system |
| Black-box testing | Derives tests from documentation external to the test object | Checks behavior against specifications | Treating it as a test level |
| White-box testing | Derives tests from the internal structure or implementation | Aims to cover code, architecture, workflows or data flows | Assuming it applies only to source code at component level |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Integration means component integration
- What candidates pick
- Component integration testing for tests of messages exchanged with a third-party payment service.
- Why it looks right
- The stem talks about interfaces and integration.
- Why it's wrong
- Interfaces between the system under test and other systems or external services are the subject of system integration testing.
Clue to watch for An external system, partner or service is named.
-
Re-running means regression
- What candidates pick
- Regression testing for re-running the exact test that failed before the fix.
- Why it looks right
- Tests are being repeated, and many teams call any rerun a regression run.
- Why it's wrong
- Re-running the failed test to show the defect is fixed is confirmation testing; regression testing checks other areas for unintended effects.
Clue to watch for The purpose is stated as checking the fix itself.
-
Non-functional is late
- What candidates pick
- "Non-functional testing should only be performed during system testing."
- Why it looks right
- Performance and usability tests are often run on a complete system.
- Why it's wrong
- The syllabus says non-functional testing can and often should be performed at component level, and that all test types apply at all test levels.
Clue to watch for Statements with "only" tied to a level and a type.
-
DevOps removes manual testing
- What candidates pick
- A benefit stating that a DevOps pipeline makes manual testing unnecessary.
- Why it looks right
- DevOps emphasizes automation and fast pipelines.
- Why it's wrong
- The syllabus lists reduced repetitive manual testing as a benefit but says manual testing, especially from the user's perspective, is still needed.
Clue to watch for Absolute wording such as "no longer" or "eliminates".
-
UAT covers operations
- What candidates pick
- User acceptance testing for verifying backup, restore and disaster recovery before go-live.
- Why it looks right
- It happens at the acceptance stage, and UAT is the best-known form.
- Why it's wrong
- Backup and restore, disaster recovery and similar checks by administrators belong to operational acceptance testing.
Clue to watch for The actors are operations or system administrators, not business users.
-
Retirement needs no testing
- What candidates pick
- "No testing is required because the application is being decommissioned."
- Why it looks right
- Nothing new is being built.
- Why it's wrong
- Retirement is a maintenance testing trigger; data archiving and restore and retrieval procedures may need testing when data must be retained.
Clue to watch for A data retention period or archive is mentioned.
Answer framework
For a Chapter 2 scenario, identify these elements in order before choosing a level, type or approach.
- Identify the test object: a single component, components working together, the whole system, or the system with external systems.
- Identify the test basis and the actor, such as detailed design and developers, system specifications and testers, or business processes and users.
- Decide what is evaluated: functions (functional), characteristics like speed or security (non-functional), specifications (black-box) or structure (white-box).
- If a change or fix is involved, separate checking the fix (confirmation) from checking unchanged areas (regression), and note any maintenance trigger.
- Choose the option whose level and type both fit the scenario, and reject options with absolute claims about lifecycles or automation.
Practice question
Want more like this? The ISTQB CTFL practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with 2.2, because test levels and test types generate most of the chapter's questions. Draw a grid with the five levels as rows and the four types as columns, and write one example in each cell, such as a component-level performance test or a white-box test of a business workflow at system level. Filling every cell is the fastest way to stop treating levels and types as the same thing.
Next, learn confirmation versus regression testing with a single fix scenario, then learn the three maintenance triggers with one consequence each: modification needs regression, migration may need data conversion tests, retirement may need archiving and retrieval tests. Only then move to 2.1, which is broad but mostly K1 and K2 recall: the four good practices, TDD versus ATDD versus BDD, DevOps benefits and risks, and examples of shift left.
Candidates commonly underestimate the acceptance testing forms and the DevOps risk list, so make a flash card for each. Afterward, practice mixed scenario questions that name an actor, a test basis and an objective, then read Chapter 3, which develops shift left through static testing.
FAQ
How many questions does Chapter 2 have on the CTFL exam?
The official exam structure gives Chapter 2 six of the 40 questions, two at K1 and four at K2, which is 15% of the exam.
What is the difference between a test level and a test type?
A test level is a stage of testing defined by its test object and objectives, such as component or system testing. A test type is a group of tests defined by what they evaluate, such as functional or non-functional, and any type can be used at any level.
Is system integration testing the same as integration testing?
No. The syllabus has two integration levels: component integration testing covers interfaces between components of one system, and system integration testing covers interfaces with other systems and external services.
When is regression testing needed?
Whenever a change is made, including a defect fix that has already been confirmation tested, and in maintenance testing. Impact analysis helps decide how much regression testing a change needs.
What is the difference between TDD, ATDD and BDD?
TDD drives code through developer-written test cases, ATDD derives tests from acceptance criteria before the feature is built, and BDD expresses expected behavior in Given/When/Then natural language that can be converted into executable tests.
Does Chapter 2 include calculations?
No. All Chapter 2 questions are K1 or K2, so they test recall and understanding through short scenarios rather than calculations or technique application.
How does this chapter connect to the rest of the syllabus?
Chapter 3 extends shift left through reviews and static analysis, Chapter 4 provides the black-box and white-box techniques behind the test types, and Chapter 5 maps levels and types onto the test pyramid and testing quadrants.
Other Quality Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have just separated the five test levels from the four test types and confirmation testing from regression testing. Check that you can name the right level and type from a short scenario under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ISTQB CTFL AI tutor Get any concept explained your way