The ISTQB Certified Tester Foundation Level v4.0 syllabus is the single document that defines what the exam tests. Everything you need to pass is in it, and everything that is not in it is not on the exam. Yet most candidates read it once, get overwhelmed, and switch to secondary material without ever really understanding how the syllabus is structured.
That is a mistake. The v4.0 syllabus is well-organised, and once you understand the internal logic of each chapter, your study time drops significantly.
This guide walks through all six chapters, explains what each is really about, flags the topics that carry the most exam weight, and gives you a sample question from each chapter with a full explanation.
If you want the short preparation overview first, see our companion article on how hard the CTFL v4.0 exam is.
How the Syllabus Is Structured
The v4.0 syllabus (officially released 21 April 2023, mandatory from 9 May 2024) contains six chapters and approximately 180 minutes of total learning objectives. Each learning objective is tagged with a K-level that tells you the depth at which it will be examined:
- K1 (remember): recall a fact, term, or list
- K2 (understand): explain a concept, compare options, or classify a scenario
- K3 (apply): use a technique to solve a concrete problem
The exam has 40 questions in 60 minutes, with roughly this distribution per chapter:
| Chapter | Topic | Approx. Questions | Exam Weight |
|---|---|---|---|
| 1 | Fundamentals of Testing | 8 | 20% |
| 2 | Testing Throughout the SDLC | 5 | 12.5% |
| 3 | Static Testing | 4 | 10% |
| 4 | Test Analysis and Design | 11 | 27.5% |
| 5 | Managing the Test Activities | 9 | 22.5% |
| 6 | Test Tools | 3 | 7.5% |
Verify against the current syllabus; ISTQB adjusts distributions occasionally.
Notice that Chapters 4 and 5 together account for 50% of the exam. If you are short on time, prioritise these two chapters. Skipping them is a fast route to failing.
Chapter 1: Fundamentals of Testing
What this chapter is really about
Chapter 1 establishes the vocabulary and mental model you will use throughout the rest of the syllabus. It answers four questions:
- Why do we test?
- What is testing (and what is it not)?
- What are the activities in a testing process?
- What human factors affect testing?
If you do not get Chapter 1 right, every other chapter becomes harder because you will lack the vocabulary to understand it.
Key topics
The purpose of testing Testing is not just about finding defects. ISTQB defines several testing objectives: evaluating work products, triggering failures, reducing risk, providing information for decisions, preventing defects, and verifying contractual or regulatory compliance. Exam questions often ask you to identify which objective applies to a given scenario.
Testing vs debugging These are separate activities done by different people. Testing identifies failures. Debugging finds the defect that caused the failure. Questions testing this distinction are common.
The seven testing principles
- Testing shows the presence, not the absence, of defects
- Exhaustive testing is impossible
- Early testing saves time and money
- Defects cluster together
- Tests wear out (the pesticide paradox)
- Testing is context dependent
- Absence-of-errors is a fallacy
Memorising the list is not enough. Questions ask you to apply these to situations, for example: “A testing team has been running the same regression tests for two years and is finding fewer and fewer defects. Which principle does this illustrate?” (Answer: pesticide paradox.)
Test activities The fundamental test process: test planning, monitoring and control, test analysis, test design, test implementation, test execution, and test completion. You need to know what happens in each and the typical order.
Roles in testing Test management role and testing role. Know the responsibilities of each.
Essential skills for testers Generic skills (analytical thinking, communication, curiosity, critical thinking), testing-specific skills (test technique application), and domain skills.
Team approach to testing The whole-team approach, independence of testing, and the trade-offs of different levels of tester independence.
Terms you must get crisp
- Error, defect, failure, root cause
- Verification vs validation
- Quality assurance vs quality control vs testing
- Test object, test basis, test condition, test case, test suite
The defect vs failure vs error vs mistake distinction is one of the most commonly examined concepts in the entire syllabus. Expect at least one question on it.
Sample question
A developer writes code that uses the wrong variable name in a calculation. This is submitted to the build. During testing, the application produces an incorrect total on the invoice screen.
Which of the following correctly describes what happened?
A) The wrong variable name was a failure, and the incorrect total was a defect B) The wrong variable name was a defect, and the incorrect total was a failure C) The wrong variable name was an error, and the incorrect total was a defect D) The wrong variable name was a mistake, and the incorrect total was an error
Correct answer: B
The wrong variable name is the defect (a flaw in the code). The incorrect total displayed on the screen is the failure (the observable deviation from expected behaviour). The developer’s thinking that led to writing the wrong name would be the error or mistake, but that is not what is being asked about here. Option A reverses defect and failure. Option C misuses “error” to describe the code itself. Option D mislabels the observable behaviour.
Suggested study time
4 to 6 hours for a thorough reading and note-taking. Another 2 hours revisiting after you have finished the other chapters.
Chapter 2: Testing Throughout the Software Development Lifecycle
What this chapter is really about
How testing fits into different ways of building software. The chapter is short on the exam (5 questions) but introduces concepts that Chapter 5 relies on heavily.
Key topics
SDLC models and testing Sequential models (Waterfall, V-model), iterative models, and incremental models. Agile and DevOps are modern examples. You do not need to know implementation details of any methodology, but you do need to know:
- How testing fits into each type
- The role of test-first approaches (TDD, BDD, ATDD)
- The shift-left concept: moving testing activities earlier in the lifecycle
- The shift-right concept: testing in production
Good testing practices across the SDLC Test objectives for every development activity, test types for every test level, test objectives modelled after the process, collaboration between testers and other roles.
Testing as a driver How testing can drive development (TDD, BDD, ATDD) rather than just follow it.
DevOps and testing Continuous testing, test automation in CI/CD pipelines, and the implications for tester roles.
Test levels Component testing, component integration testing, system testing, system integration testing, acceptance testing. For each level, know:
- Its specific objectives
- The test basis typically used
- The typical test objects
- Who typically performs it
Test types Functional testing, non-functional testing, white-box testing, change-related testing (confirmation and regression). Note: test types are orthogonal to test levels. Any type can be applied at any level.
Confirmation testing vs regression testing Confirmation testing (re-test) verifies a specific defect is fixed. Regression testing checks that changes have not broken previously working functionality. Questions often try to confuse these two.
Maintenance testing Testing performed on operational systems when modifications are made.
Common confusions
- Test levels vs test types: these are two different dimensions, not synonyms. A system test (level) can be a functional test, performance test, or security test (types).
- Shift-left vs test-first: shift-left is broader (moving any testing activity earlier). Test-first specifically means writing tests before code.
- Confirmation testing vs regression testing: confirmation is narrow and targeted; regression is broader.
Sample question
A team is developing a new banking application using the V-model. Which of the following describes the correct relationship between development activities and test levels in the V-model?
A) Requirements specification corresponds to component testing B) System design corresponds to acceptance testing C) Detailed design corresponds to component testing D) Coding corresponds to system testing
Correct answer: C
In the V-model, each development activity on the left arm has a corresponding verification or validation activity on the right arm. Requirements specification pairs with acceptance testing, system design pairs with system testing, detailed (component) design pairs with component testing, and coding pairs with component testing. Option C correctly pairs detailed design with component testing. The others all pair activities that are not directly related in the V-model.
Suggested study time
3 to 4 hours.
Chapter 3: Static Testing
What this chapter is really about
Testing without executing the code. This chapter is small (4 exam questions) but deceptively tricky because ISTQB defines the review types with precise characteristics you must memorise.
Key topics
Static testing basics What can be reviewed (work products such as requirements, user stories, design documents, code, test cases), the benefits of static testing, and the differences between static and dynamic testing.
Value of static testing Early defect detection, prevention of defects, improvement of productivity, reduction in development costs, improved communication.
Differences between static and dynamic testing Static finds defects directly in the work product. Dynamic finds failures, from which defects are then identified. Static can cover requirements and design documents. Dynamic requires executable code.
Feedback and review process The generic review process: planning, initiating the review, individual review, issue communication and analysis, fixing and reporting.
Roles and responsibilities in reviews Manager, author, moderator (facilitator), scribe (recorder), reviewer, review leader. You must know who does what.
Review types This is where the exam gets specific. You must know the defining characteristics of each:
- Informal review: no formal process, no documentation, inexpensive, main benefit is cheap detection
- Walkthrough: led by the author, mainly for knowledge sharing and learning
- Technical review: led by a trained moderator (not the author), focused on technical quality, may produce a formal report
- Inspection: most formal, led by a trained moderator, follows a defined process, uses checklists and rules, produces formal documentation and metrics
The distinguishing factors: who leads it, whether it is documented, whether it uses checklists, whether it collects metrics.
Success factors for reviews Management support, clear objectives, suitable review type, preparation, training, learning from reviews.
The #1 trap in this chapter
Questions describe a meeting scenario and ask which review type it is. You have to recognise the review type from the characteristics described. If the scenario mentions “the author explained the work to colleagues,” it is a walkthrough. If it mentions “metrics were collected and formal rules were applied,” it is an inspection.
Sample question
A team holds a meeting to review a design document. The meeting is led by an independent moderator who is not the author. The team follows a defined process with entry and exit criteria, uses a checklist of common defects, and collects metrics on defects found. A formal report is produced.
Which type of review is this?
A) Informal review B) Walkthrough C) Technical review D) Inspection
Correct answer: D
The defining clues are: defined process, entry/exit criteria, checklist, metrics, and formal report. These are all characteristics of an inspection. A walkthrough (B) is led by the author, not an independent moderator. A technical review (C) is led by a trained moderator and is formal, but typically does not include metrics collection or the full checklist-driven process. Informal review (A) has no formal process at all.
Suggested study time
3 hours. Spend the time memorising the review type characteristics in a table format.
Chapter 4: Test Analysis and Design
What this chapter is really about
How to derive test cases from requirements using defined techniques. This is the largest and most technical chapter, carrying about 27% of exam marks. Many questions here are K3 (apply), which means you must actually use the techniques, not just recognise them.
Key topics
Test techniques overview Three categories: black-box (specification-based), white-box (structure-based), and experience-based. Know the general properties of each category.
Black-box testing techniques
- Equivalence partitioning: divide input data into groups where all values in a group should be treated the same way. Test at least one value from each partition.
- Boundary value analysis: test the values at the edges of equivalence partitions. v4.0 covers both the 2-value approach (boundary and just beyond) and the 3-value approach (just inside, boundary, just beyond).
- Decision table testing: represent combinations of conditions as a table, derive test cases from columns.
- State transition testing: identify states, events, transitions, and actions. Derive tests for valid transitions and invalid transitions.
White-box testing techniques
- Statement testing and coverage: every executable statement is executed at least once. Calculate coverage as (statements executed / total statements) × 100.
- Branch testing and coverage: every branch (each direction of every decision) is executed at least once.
You must be able to calculate coverage for small code examples.
Experience-based techniques
- Error guessing: using tester experience to predict likely defects
- Exploratory testing: simultaneous learning, test design, and execution
- Checklist-based testing: using a pre-defined list
Collaboration-based test approaches
- Collaborative user story writing: the three Cs (Card, Conversation, Confirmation)
- Acceptance criteria: scenario-based (Given/When/Then) and rule-based
- Acceptance test-driven development (ATDD)
The techniques you must practise, not just read
You cannot pass Chapter 4 without doing the techniques by hand:
- Build a decision table from a plain-English requirement with 3 to 4 conditions. Collapse redundant columns.
- Apply 2-value and 3-value boundary analysis to a numeric range such as “valid age is 18 to 65.”
- Draw a state transition diagram from a described system and derive valid and invalid transition tests.
- Calculate statement and branch coverage for small code fragments (5 to 10 lines).
Candidates who only read about these techniques consistently fail the chapter.
Sample question
A function accepts an integer age value. Valid input is 18 to 65 inclusive. Using the 3-value boundary value analysis approach, how many test values should be tested at each boundary?
A) 2 values per boundary B) 3 values per boundary C) 4 values per boundary D) It depends on the implementation
Correct answer: B
The 3-value boundary value analysis approach tests the boundary value itself plus one value on each side. For the lower boundary of 18: test 17, 18, and 19. For the upper boundary of 65: test 64, 65, and 66. That is 3 values per boundary. The 2-value approach would test only the boundary and one value beyond (18 and 17 for the lower boundary). Option D is a distractor: the number of test values per boundary is defined by the technique, not by the implementation.
Suggested study time
10 to 15 hours with hands-on practice. This is the chapter where study time pays off most.
Chapter 5: Managing the Test Activities
What this chapter is really about
Planning, controlling, and completing testing work. Chapter 5 carries about 22% of the exam and is the chapter most underestimated by candidates who focus heavily on Chapter 4 techniques.
Key topics
Test planning Purpose and content of a test plan, typical sections, how test plans differ across test levels, entry and exit criteria, estimation techniques (metrics-based, expert-based).
Risk management This is a major topic. You must know:
- Risk = likelihood × impact
- Project risk (affects the ability to deliver: resource, schedule, scope) vs product risk (affects the quality of the product: functional, non-functional, security risks)
- Risk analysis, risk assessment, risk mitigation
- Risk-based testing: using risk to prioritise testing effort
Test monitoring, control, and completion
- Test monitoring: gathering data on the testing work
- Test control: taking corrective actions based on monitoring data
- Test completion: closing out testing, archiving, lessons learned
Do not confuse these three. A question about “what a test manager monitors” has a different answer than one about “what a test manager controls.”
Configuration management Version control, baselines, and why they matter for testing.
Defect management The defect lifecycle, contents of a defect report (ISO/IEC/IEEE 29119-3 style), and workflow from discovery to closure.
A defect report should contain (among others): unique identifier, title, summary, severity, priority, steps to reproduce, expected vs actual result, environment, date, and status.
Common confusions
- Monitoring vs control: monitoring is passive (gathering data); control is active (doing something about it)
- Severity vs priority: severity is the impact on the system; priority is the urgency of fixing it. A typo on a login screen might be high severity (can’t log in) but also high priority (blocks everything), while a cosmetic issue might be low severity and low priority. These are independent ratings.
- Product risk vs project risk: product risk is about the thing being built; project risk is about the effort of building it.
Sample question
A test manager notices that defect resolution time has increased from 2 days to 7 days over the past sprint. She schedules a meeting with the development lead to discuss bottlenecks and agrees to reassign two defects to a different developer.
Which testing activities is the test manager performing?
A) Test monitoring only B) Test control only C) Both test monitoring and test control D) Test planning and test completion
Correct answer: C
Noticing that defect resolution time has increased is test monitoring (gathering and reviewing data). Scheduling the meeting and reassigning defects is test control (taking corrective action based on the monitoring data). The scenario describes both activities. Monitoring without control would be only observing; control without monitoring would be acting blindly. In practice, these two activities are tightly linked but distinct.
Suggested study time
8 to 10 hours. Many candidates underspend here.
Chapter 6: Test Tools
What this chapter is really about
The smallest chapter (3 questions, about 7.5% of the exam). The content is at a conceptual level. You do not need to know specific tool names.
Key topics
Tool support for testing Categories of tools: test management tools, static testing tools, test design and implementation tools, test execution and coverage tools, non-functional testing tools, and collaboration tools.
Benefits and risks of test automation Benefits include repetition, speed, and reliability. Risks include unrealistic expectations, underestimating maintenance, and over-reliance.
Tool selection Considerations include organisational readiness, tool fit, cost of ownership, integration with existing tools, and training needs.
Sample question
Which of the following is a typical risk of introducing test automation into an organisation?
A) Tests will be executed faster than by manual testers B) Automated test scripts will require ongoing maintenance as the application changes C) Test results will be more consistent across runs D) Automation will make regression testing easier to repeat
Correct answer: B
Options A, C, and D are all benefits of test automation, not risks. Option B is a well-known risk: automated test scripts must be updated as the application under test evolves, and organisations frequently underestimate this maintenance burden.
Suggested study time
2 hours. Most of this is common sense for experienced testers.
Study Sequence Recommendation
For most candidates, this order works best:
- Chapter 1 first, to build vocabulary (5 hours)
- Chapter 2 next, to establish the SDLC framing (3 hours)
- Chapter 3 briefly, to get review types memorised (3 hours)
- Chapter 4 with heavy practice (12 hours)
- Chapter 5 with case study thinking (10 hours)
- Chapter 6 last and light (2 hours)
- Mock exams and revision (8 to 10 hours)
Total: around 45 hours for most candidates.
Download the Syllabus
The official v4.0 syllabus is freely available from ISTQB.org. Read it first, then use this deep-dive as your chapter-by-chapter companion.
Next Steps
Once you have a working understanding of each chapter, test yourself. Take a full-length timed mock exam and identify which chapters need more work. Our CTFL v4.0 Study Guide includes mock exams, worked examples for every Chapter 4 technique, and the complete ISTQB glossary.
Not sure if you are ready yet? Read our companion article: How Hard Is the ISTQB CTFL v4.0 Exam?
This article reflects the ISTQB CTFL v4.0 syllabus (version 4.0, April 2023, mandatory from May 2024).
Discover more from ISTQB Guru
Subscribe to get the latest posts sent to your email.
Have a question? Ask here.