Chapter 2 shows how testing changes with the way software is built. You will learn how the development lifecycle shapes testing, how test-first approaches and DevOps work, what shift left means, the five test levels, the four test types, confirmation versus regression testing, and when maintenance testing is needed. It carries 6 of the 40 exam questions.
ISTQB CTFL › 2. Testing Throughout the SDLC Syllabus v4.0.1 · updated 3 Nov 2026
| Exam weight | Questions | K-levels | Training time |
|---|---|---|---|
| 15% | 6 | 2 × K1, 4 × K2 | 130 minutes |
Keywords to remember (K1): acceptance testing, black-box testing, component integration testing, component testing, confirmation testing, functional testing, integration testing, maintenance testing, non-functional testing, regression testing, shift left, system integration testing, system testing, test level, test object, test type, white-box testing.
2.1 Testing in the context of an SDLC
An SDLC model is a high-level picture of how software development is organised: which phases and activities exist and how they relate in logic and time.
| Family | Examples | Key idea |
|---|---|---|
| Sequential | Waterfall, V-model | One phase follows another; code arrives late |
| Iterative | Spiral, prototyping | Repeat cycles that refine the product |
| Incremental | Unified Process | Deliver the product in pieces |
On top of these models, teams use more detailed methods and Agile practices such as ATDD, BDD, domain-driven design (DDD), Extreme Programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum and TDD.
2.1.1 Impact of the SDLC on testing (K2)
Testing must fit the chosen SDLC. The SDLC affects:
- the scope and timing of test activities (test levels and test types),
- the level of detail of test documentation,
- the choice of test techniques and test approach,
- the extent of test automation, and
- the role and responsibilities of the tester.
| SDLC | What testing looks like |
|---|---|
| Sequential (for example V-model) | Early on, testers review requirements and do test analysis and design. Executable code comes late, so dynamic testing usually cannot start early. |
| Iterative and incremental | Each iteration delivers a working increment, so static and dynamic testing can happen at all test levels in every iteration. Frequent delivery needs fast feedback and extensive regression testing. |
| Agile | Change is expected at any time, so teams prefer lightweight documentation and heavy test automation for regression. Manual testing is often done with experience-based techniques that need little up-front analysis and design. |
2.1.2 Good testing practices for every SDLC (K1)
Whatever the lifecycle:
- Every development activity has a matching test activity, so everything is subject to quality control.
- Each test level has its own specific objectives, so testing is thorough without being redundant.
- Test analysis and design for a level starts during the matching development phase (early testing).
- Testers review work products as soon as drafts exist, which supports shift left.
2.1.3 Testing as a driver for development: TDD, ATDD and BDD (K1)
In these test-first approaches, tests are written before the code and guide development. All three apply early testing, follow shift left and support iterative development. The tests often stay as automated tests to protect future changes and refactoring.
| Approach | How it works | Who mainly writes the tests |
|---|---|---|
| TDD (test-driven development) | Write a test, write code until it passes, then refactor tests and code. Tests drive the coding instead of extensive design | Developers |
| ATDD (acceptance test-driven development) | Derive tests from acceptance criteria during system design, then build the feature to pass them | The whole team: business, developers, testers |
| BDD (behaviour-driven development) | Describe the desired behaviour in simple natural language, usually Given/When/Then, which stakeholders understand; then turn it into executable tests | Business and team together |
Example BDD scenario:
Given a registered customer with ₹500 in their wallet When they buy an item costing ₹200 using the wallet Then the wallet balance shows ₹300
2.1.4 DevOps and testing (K2)
DevOps brings development (including testing) and operations together around common goals. It needs a cultural shift and promotes team autonomy, fast feedback, integrated toolchains and practices such as continuous integration (CI) and continuous delivery (CD), delivered through a DevOps pipeline.
| Benefits for testing | Risks and challenges |
|---|---|
| Fast feedback on code quality and on whether changes break existing code | The delivery pipeline must be defined and set up |
| CI promotes shift left: developers submit code with component tests and static analysis | CI/CD tools must be introduced and maintained |
| Automated CI/CD helps create stable test environments | Test automation needs extra resources and can be hard to build and maintain |
| Better visibility of non-functional characteristics such as performance and reliability | |
| Less repetitive manual testing thanks to pipeline automation | |
| Lower regression risk because of large automated regression suites |
Even with heavy automation in DevOps, manual testing from the user’s perspective is still needed. An option saying “DevOps removes the need for manual testing” is wrong.
2.1.5 Shift left (K2)
Shift left is another name for the principle of early testing: do testing earlier in the SDLC instead of waiting for code or integration. It does not mean that later testing can be skipped.
Good shift-left practices:
- Testers review specifications, finding ambiguities, gaps and inconsistencies.
- Write test cases before the code and run the code in a test harness while it is being written.
- Use CI, and better still CD, for fast feedback with automated component tests on every commit.
- Run static analysis on source code before dynamic testing, or automatically in the pipeline.
- Start non-functional testing at the component level where possible, instead of waiting for a complete system.
Shift left may cost extra training, effort and money early, but it is expected to save more later. Stakeholders must buy into it.
2.1.6 Retrospectives and process improvement (K2)
A retrospective is a meeting, often at the end of an iteration, release or project (or whenever needed), where the whole team (testers, developers, architects, product owner, business analysts) discusses:
- What went well and should be kept?
- What did not go well and could be improved?
- How do we apply the improvements and keep the successes?
Results are recorded, normally in the test completion report, and actions must be followed up.
Benefits for testing: more effective and efficient testing, better testware, team bonding and learning, a better test basis (requirements gaps get fixed), and better cooperation between development and testing.
2.2 Test levels and test types
A test level is a group of test activities organised and managed together, for software at a given stage, from single components to whole systems or systems of systems. Each test level is an instance of the test process. A test type is a group of test activities aimed at specific quality characteristics; most test types can be done at every test level.
In sequential models, the exit criteria of one level are often part of the entry criteria for the next. In iterative models this may not apply, and levels can overlap in time.
2.2.1 The five test levels (K2)
| Test level | Also called | Focus | Typically done by |
|---|---|---|---|
| Component testing | Unit testing | Components in isolation; often needs test harnesses or unit test frameworks | Developers, in their development environment |
| Component integration testing | Unit integration testing | Interfaces and interactions between components; depends heavily on the integration strategy (bottom-up, top-down, big-bang) | Developers |
| System testing | Overall behaviour and capabilities of the whole system: end-to-end functional tasks and non-functional characteristics (for example usability on a complete system in a representative environment) | Often an independent test team | |
| System integration testing | Interfaces between the system and other systems and external services; needs an environment close to production | Testers | |
| Acceptance testing | Validation and readiness for deployment: does the system meet the users’ business needs? | Ideally the intended users |
Forms of acceptance testing: user acceptance testing (UAT), operational acceptance testing, contractual and regulatory acceptance testing, alpha testing and beta testing.
Test levels are told apart by their test object, test objectives, test basis, defects and failures, and approach and responsibilities.
Example for an online food-delivery app:
- Component test: the function that calculates the delivery fee.
- Component integration test: the cart service correctly passes items to the pricing service.
- System test: a customer can search, order, pay and track an order end to end, and the app responds within 2 seconds.
- System integration test: the app talks correctly to the payment gateway and the maps API.
- Acceptance test: restaurant owners and customers confirm the app supports their real workflow.
2.2.2 The four test types (K2)
| Test type | Question it answers | Based on |
|---|---|---|
| Functional testing | What should the system do? Checks functional completeness, correctness and appropriateness | Requirements, user stories |
| Non-functional testing | How well does it behave? Checks quality characteristics | Quality requirements (ISO/IEC 25010) |
| Black-box testing | Does the behaviour match the specification? | Specifications, not internal structure |
| White-box testing | Is the internal structure covered well enough? | Code, architecture, workflows, data flows |
The ISO/IEC 25010 non-functional quality characteristics listed in the syllabus:
- Performance efficiency
- Compatibility
- Usability (also called interaction capability)
- Reliability
- Security
- Maintainability
- Portability (also called flexibility)
- Safety
Non-functional testing can start early (in reviews or component testing). Many non-functional tests reuse functional tests but add a constraint, for example “the search must return results in under 1 second”. Finding non-functional defects late can seriously threaten a project, and some tests need special environments such as a usability lab.
All four test types can be applied at all test levels, with a different focus at each level.
2.2.3 Confirmation testing and regression testing (K2)
| Confirmation testing | Regression testing | |
|---|---|---|
| Purpose | Confirm that the original defect is fixed | Confirm that the change caused no adverse side effects elsewhere |
| What is run | The tests that failed because of the defect, plus new tests for any changes made in the fix; at minimum, the steps that reproduced the failure | Tests of the changed area, other components, connected systems and even the environment |
| How much | Depends on risk | Decided by impact analysis |
| Automation | Optional | A strong candidate for automation, because regression suites run many times and grow every release |
Both are needed at every test level where defects are fixed or changes are made. In CI and DevOps, automated regression tests should be part of the pipeline.
A fix is first confirmation tested (is the defect gone?) and then regression tested (did the fix break anything else?). Regression testing also follows new features and environment changes, not only defect fixes.
2.3 Maintenance testing (K2)
Once software is in operation, changes keep coming. Maintenance can be corrective, adaptive (to changes in the environment) or aimed at improving performance or maintainability. Releases can be planned or unplanned (hot fixes).
Maintenance testing checks both that the change works and that the unchanged parts (usually most of the system) still work. Impact analysis can be done before a change to decide whether to make it at all.
The scope of maintenance testing depends on:
- the risk of the change,
- the size of the existing system, and
- the size of the change.
| Trigger | Example | What to test |
|---|---|---|
| Modification | Planned enhancement, corrective change, hot fix | The change plus regression |
| Upgrade or migration of the operational environment | Moving from on-premise servers to the cloud; migrating data from an old CRM | The new environment, the changed software, and data conversion |
| Retirement | Shutting down a legacy application | Data archiving, and restore and retrieval procedures if data must be kept for years |
Learning objectives checklist
| LO | Level | You should be able to… |
|---|---|---|
| FL-2.1.1 | K2 | Explain how the chosen SDLC affects testing |
| FL-2.1.2 | K1 | Recall good testing practices for all SDLCs |
| FL-2.1.3 | K1 | Recall examples of test-first approaches |
| FL-2.1.4 | K2 | Summarise how DevOps affects testing |
| FL-2.1.5 | K2 | Explain shift left |
| FL-2.1.6 | K2 | Explain how retrospectives drive process improvement |
| FL-2.2.1 | K2 | Distinguish the test levels |
| FL-2.2.2 | K2 | Distinguish the test types |
| FL-2.2.3 | K2 | Distinguish confirmation testing from regression testing |
| FL-2.3.1 | K2 | Summarise maintenance testing and its triggers |
Chapter 2 self-check (10 questions)
In a sequential SDLC such as the V-model, which statement about testing is most accurate?
- A. Dynamic testing usually starts in the first phase of the project
- B. Testers review requirements and design tests early, but dynamic testing usually starts later
- C. Test automation is always more extensive than in Agile projects
- D. Only experience-based techniques are used
Show answer
Answer: B. Testers review requirements and design tests early, but dynamic testing usually starts later
In sequential models, executable code arrives late, so early test work is reviews, test analysis and test design; dynamic testing comes later.
Which is a good testing practice that applies to all SDLCs?
- A. Every test level should have the same test objectives
- B. Test design should start only after all code is complete
- C. For every development activity there is a corresponding test activity
- D. Testers should review work products only once they are final
Show answer
Answer: C. For every development activity there is a corresponding test activity
Pairing each development activity with a test activity keeps everything under quality control. Each level has different objectives, test design starts early, and testers review drafts.
Which approach expresses tests in a Given/When/Then format that business stakeholders can understand?
- A. Test-driven development
- B. Behaviour-driven development
- C. Exploratory testing
- D. Component integration testing
Show answer
Answer: B. Behaviour-driven development
BDD describes desired behaviour in simple natural language, usually Given/When/Then, and then turns it into executable tests.
Which is a benefit of DevOps for testing?
- A. Manual testing is no longer needed
- B. Test automation needs no extra resources
- C. Fast feedback on whether changes adversely affect existing code
- D. CI/CD tools never need maintenance
Show answer
Answer: C. Fast feedback on whether changes adversely affect existing code
Fast feedback is a listed benefit. Manual testing from the user’s view is still needed, and automation and CI/CD tools are listed challenges.
Which practice is an example of shift left?
- A. Running all performance tests only after system integration testing
- B. Running static analysis on source code before dynamic testing
- C. Skipping system testing because component tests passed
- D. Writing test cases after the code has been released
Show answer
Answer: B. Running static analysis on source code before dynamic testing
Static analysis before dynamic testing (or in the pipeline) moves defect detection earlier. Shift left does not mean skipping later testing.
Where are the results of a retrospective normally recorded?
- A. In the defect reports
- B. In the test completion report
- C. In the test execution schedule
- D. In the risk register only
Show answer
Answer: B. In the test completion report
Retrospective results are recorded and are normally part of the test completion report, and improvement actions must be followed up.
Testing that the online shop correctly exchanges data with an external payment gateway belongs to which test level?
- A. Component testing
- B. Component integration testing
- C. System integration testing
- D. Acceptance testing
Show answer
Answer: C. System integration testing
System integration testing focuses on interfaces between the system under test and other systems and external services.
Checking that a report is generated within 3 seconds is an example of which test type?
- A. Functional testing
- B. Non-functional testing
- C. White-box testing
- D. Confirmation testing
Show answer
Answer: B. Non-functional testing
Response time is about how well the system behaves (performance efficiency), which is non-functional testing.
A defect in the discount calculation has been fixed. Which activity checks that the fix did not break the invoice module?
- A. Confirmation testing
- B. Regression testing
- C. Acceptance testing
- D. Component testing
Show answer
Answer: B. Regression testing
Confirmation testing checks the defect itself is fixed. Regression testing checks for adverse effects elsewhere, such as in the invoice module.
A company is shutting down an old HR system but must keep employee records for 10 years. What should maintenance testing focus on?
- A. Usability of new screens
- B. Data archiving and restore and retrieval procedures
- C. Component testing of new features
- D. Performance under peak load
Show answer
Answer: B. Data archiving and restore and retrieval procedures
Retirement is a maintenance trigger. When long data retention is needed, testing covers data archiving and the procedures to restore and retrieve the data.
Next: Chapter 3: Static Testing.