This is the cheat sheet you wish you had built yourself when you started studying. Every concept on the ISTQB Certified Tester Foundation Level v4.0 exam, condensed into scannable tables and quick-reference summaries you can review in the days and hours before your exam.
It is not a substitute for actually learning the material. If you do not understand the concepts, no cheat sheet will save you. But if you have done the work and need a structured way to revise, this article gives you the entire syllabus in one place, organized by exam relevance.
We have also prepared a downloadable PDF version at the bottom of this page so you can print it, save it to your phone, or send it to yourself for last-minute review.
If you have not yet started preparing, our CTFL v4.0 syllabus deep dive covers the syllabus chapter by chapter. If you need an honest assessment of difficulty before booking, read How Hard Is the ISTQB CTFL v4.0 Exam?.
Quick Exam Snapshot
| Item | Value |
|---|---|
| Number of questions | 40 |
| Time allowed | 60 minutes (75 with non-native English extension) |
| Pass mark | 65% (26 of 40 correct) |
| Question type | Multiple choice, single correct answer |
| Negative marking | None |
| Open book | No |
| Calculator | Not provided, not required |
| Languages | English (most boards); some boards offer others |
| Validity | Lifetime, no recertification |
Time budget: 90 seconds per question average. Mark uncertain questions and return at the end.
Strategy reminder: Always answer every question. Even an educated guess gives you a 25% chance; leaving blank gives you 0%.
The Seven Testing Principles
These are the most exam-tested concepts in Chapter 1. Expect at least one direct question and several indirect references.
| # | Principle | What it means | Common exam scenario |
|---|---|---|---|
| 1 | Testing shows the presence, not the absence, of defects | Tests can find bugs but cannot prove the software is bug-free | Question describes a tester claiming “no defects found means no defects” |
| 2 | Exhaustive testing is impossible | Cannot test all input combinations; must prioritise | Question asks why we use risk-based testing |
| 3 | Early testing saves time and money | Find defects early; later fixes cost more | Shift-left questions, requirements review value |
| 4 | Defects cluster together | A small number of modules contain most defects | Question about prioritising regression testing |
| 5 | Tests wear out (pesticide paradox) | Repeating same tests stops finding new defects | Question about reviewing/refreshing regression suites |
| 6 | Testing is context dependent | Different domains need different test approaches | Safety-critical vs e-commerce comparison |
| 7 | Absence-of-errors is a fallacy | Software with no defects can still fail to meet user needs | Question about validation vs verification |
Defect vs Failure vs Error vs Mistake
The single most exam-tested term distinction in Chapter 1.
| Term | What it is | Where it lives | Synonyms |
|---|---|---|---|
| Mistake / Error | A human action (or confusion) that produces an incorrect result | In a person’s head or hands | Same: mistake = error in v4.0 |
| Defect | A flaw in the work product | In code, requirements, design, test cases | Bug, fault, flaw |
| Failure | An observable deviation from expected behaviour during execution | What the user/tester sees | None standard |
The chain: A person makes a mistake → which produces a defect in the work product → which causes a failure when the product runs.
Critical edge cases:
- A defect can exist without producing a failure (the faulty code path is never executed)
- A failure can occur without a defect (environmental causes: power outage, network drop)
- Not every mistake produces a defect (the human catches it before it reaches the work product)
For a full breakdown with practice questions, see our defect vs failure deep dive.
Verification vs Validation
Another high-frequency exam term pair.
| Term | Question it answers | Activity examples |
|---|---|---|
| Verification | Are we building the product right? | Reviews, static analysis, unit tests against specs |
| Validation | Are we building the right product? | User acceptance testing, beta testing, demos to stakeholders |
Memory aid: Verification = match to specification. Validation = match to user need.
Test Levels
Test levels say when in the SDLC you are testing.
| Level | What it tests | Test basis | Typical performer |
|---|---|---|---|
| Component (unit, module) | Individual hardware/software components in isolation | Detailed design, code | Developer |
| Component integration | Interactions between components | Architecture, interface specs | Developer / integration tester |
| System | The entire integrated system | System requirements, use cases | Independent test team |
| System integration | Interactions between this system and other systems | System interface specs | Integration tester |
| Acceptance | Whether to accept the system | Business requirements, user stories | Business / users / customers |
Acceptance testing types:
- User acceptance testing (UAT): Do users accept the system?
- Operational acceptance testing: Can operations team support it?
- Contractual acceptance testing: Does it meet contractual requirements?
- Regulatory acceptance testing: Does it meet legal/regulatory requirements?
- Alpha testing: Acceptance testing in the developer’s environment by people outside the development team
- Beta testing: Acceptance testing at the user’s site by potential users
Test Types
Test types say what you are looking for. Test types are orthogonal to test levels: any type can be applied at any level.
| Type | What it evaluates | Example questions answered |
|---|---|---|
| Functional | What the system does | Does the login button log the user in? |
| Non-functional | How well the system performs | Does the login complete in under 2 seconds? |
| White-box (structural) | The internal structure of the code | Are all branches exercised? |
| Change-related | Behaviour after a change | Has the fix worked? Are old features still working? |
Change-related testing has two flavours:
- Confirmation testing (retesting): Does the specific defect that was fixed actually stay fixed?
- Regression testing: Have other previously-working features been broken by the change?
These two are commonly confused. Confirmation = narrow and targeted. Regression = broader and protective.
Non-Functional Quality Characteristics (ISO 25010)
Non-functional testing evaluates these. Chapter 2 expects you to recognise them.
| Characteristic | What it means |
|---|---|
| Functional suitability | Does it do what it should? |
| Performance efficiency | Time, resource, capacity behaviour |
| Compatibility | Coexistence and interoperability |
| Interaction capability | Usability, accessibility, user error protection |
| Reliability | Maturity, availability, fault tolerance, recoverability |
| Security | Confidentiality, integrity, non-repudiation, accountability, authenticity |
| Maintainability | Modularity, reusability, analysability, modifiability, testability |
| Portability | Adaptability, installability, replaceability |
| Safety | Avoidance of harm to people, property, environment |
Black-Box Test Design Techniques
These are the most exam-tested techniques. Expect 4 to 6 questions across these four.
Equivalence Partitioning (EP)
| Aspect | Detail |
|---|---|
| Purpose | Group inputs that should be treated the same; test one per group |
| Coverage | Every partition is exercised by at least one test |
| Key principle | Valid AND invalid partitions both need testing |
| Common trap | Forgetting invalid partitions (below range, above range, wrong type) |
Example: Age 18 to 65 valid → 4 partitions (below 18, 18 to 65, above 65, non-integer).
Boundary Value Analysis (BVA)
| Aspect | Detail |
|---|---|
| Purpose | Test values at the edges of partitions where defects cluster |
| 2-value approach | Test the boundary + the value just outside (2 values per boundary) |
| 3-value approach | Test just inside + boundary + just outside (3 values per boundary) |
| When to use 3-value | Safety-critical or financial systems |
Example for range 18 to 65 (integers):
- 2-value at lower boundary: 17, 18 (4 values total for both boundaries)
- 3-value at lower boundary: 17, 18, 19 (6 values total for both boundaries)
Decision Table Testing (DTT)
| Aspect | Detail |
|---|---|
| Purpose | Test combinations of conditions that produce specific actions |
| Number of rules | 2^N for N binary conditions (2 conditions = 4 rules; 3 conditions = 8 rules) |
| Collapsing | Combine rules with same actions where the differing condition does not affect outcome |
| Best for | Complex business rules with multiple conditions |
State Transition Testing
| Aspect | Detail |
|---|---|
| Purpose | Test transitions between states triggered by events |
| Components | States, transitions, events, actions |
| Coverage levels | Valid transitions, invalid transitions, all states, all transition pairs |
| Best for | Login systems, ATMs, order lifecycles, anything with sequential states |
For deep coverage of these three with worked examples, see Decision Tables, EP, and BVA.
Other Black-Box Techniques to Know
| Technique | One-line description |
|---|---|
| Use case testing | Test cases derived from use case scenarios (actor + interaction with system) |
| User story testing | Test conditions are the acceptance criteria of user stories |
| Pairwise testing | Test all pairs of parameter-value combinations |
| CRUD testing | Test create, read, update, delete operations on entities |
| Domain testing | Tests on, near, inside, and outside boundaries of equivalence partitions |
| Random testing | Inputs randomly generated |
White-Box Test Design Techniques
Less weight than black-box but still 1 to 2 questions expected.
Statement Coverage
Formula: (Statements executed / Total executable statements) × 100%
100% statement coverage means every executable statement has been run at least once. Does not guarantee branch coverage.
Branch Coverage (a.k.a. Decision Coverage)
Formula: (Branches executed / Total branches) × 100%
100% branch coverage means every direction of every decision has been exercised (each if runs both true and false). Implies 100% statement coverage; the reverse is not true.
Quick Worked Example
read(x);
if (x > 0)
print("positive");
print("done");- One test with x = 5: statement coverage = 100% (all three statements run), branch coverage = 50% (only the
truebranch of the if was tested). - Two tests, x = 5 and x = -1: statement coverage = 100%, branch coverage = 100%.
This is the kind of calculation the exam tests at K3 level. Practise these by hand.
Coverage Hierarchy
| Coverage type | Strength |
|---|---|
| Statement coverage | Weakest |
| Branch (decision) coverage | Stronger; implies statement coverage |
| Condition coverage | Tests outcomes of atomic conditions |
| Modified condition/decision coverage (MC/DC) | Strongest commonly used; required for safety-critical (DO-178C, ISO 26262) |
Static Testing: Review Types
Chapter 3 carries about 4 questions. Most are about identifying review type from a scenario. Memorise the defining characteristics.
| Review Type | Led by | Documented? | Defined process? | Metrics? | Main purpose |
|---|---|---|---|---|---|
| Informal review | No specific role | No | No | No | Cheap, ad-hoc defect detection |
| Walkthrough | Author | Sometimes | Loose | Sometimes | Knowledge sharing, learning |
| Technical review | Trained moderator (not author) | Yes | Yes | Sometimes | Technical quality assessment |
| Inspection | Trained moderator | Yes (formal) | Yes (with entry/exit criteria) | Yes | Highest defect detection, process improvement |
Decoder for exam questions:
- “Author led the meeting and explained the work” → Walkthrough
- “Independent moderator with formal report” → Technical review
- “Defined process, checklists, metrics, formal documentation” → Inspection
- “Quick, undocumented review” → Informal
Roles in a Formal Review
| Role | Responsibility |
|---|---|
| Manager | Allocates resources, schedules reviews |
| Author | Created the work product being reviewed |
| Moderator (facilitator) | Runs the meeting |
| Scribe (recorder) | Documents issues found |
| Reviewer (checker, inspector) | Identifies defects |
| Review leader | Overall responsibility for the review |
Test Activities (Fundamental Test Process)
| Activity | What happens |
|---|---|
| Test planning | Define objectives, scope, schedule, resources |
| Test monitoring | Gather data on testing progress |
| Test control | Take corrective actions based on monitoring |
| Test analysis | Identify test conditions from the test basis |
| Test design | Derive test cases from test conditions |
| Test implementation | Prepare testware (test data, environment, scripts) |
| Test execution | Run the tests, compare actual vs expected |
| Test completion | Archive testware, report results, lessons learned |
Monitoring vs control: Monitoring is passive (gathering data). Control is active (taking action based on data). The exam will trick you here.
K-Levels (Cognitive Levels)
| Level | Verb | What you must do | Approx. % of CTFL exam |
|---|---|---|---|
| K1 | Remember | Recall a fact, term, or list | ~40% |
| K2 | Understand | Explain, compare, classify | ~45% |
| K3 | Apply | Use a technique to solve a problem | ~15% |
Higher levels in Advanced and Expert exams:
| Level | Verb | What you must do |
|---|---|---|
| K4 | Analyse | Break down, identify causes |
| K5 | Evaluate | Make judgements based on criteria |
| K6 | Create | Produce new work |
CTFL stops at K3. Most candidates fail because they prepare only for K1 (memorisation) and underestimate K2 and K3 application.
Severity vs Priority
| Term | What it measures | Determined by | Independent? |
|---|---|---|---|
| Severity | Impact on the system | Technical assessment | Yes |
| Priority | Urgency of fixing it | Business need | Yes |
A typo on the homepage can be low severity (system still works) but high priority (visible to users, embarrassing).
A crash in a rarely-used admin feature can be high severity (system fails) but low priority (few users affected).
Risk-Based Testing
| Concept | Formula or definition |
|---|---|
| Risk | Likelihood × Impact |
| Risk level | Quantified risk (often High, Medium, Low) |
| Product risk | Risk to the quality of the product (functional, non-functional, security) |
| Project risk | Risk to the project’s ability to deliver (schedule, resources, scope) |
| Risk analysis | Risk identification + risk assessment |
| Risk control | Risk mitigation + risk monitoring |
Risk-based testing prioritisation rule: Higher risk = more thorough testing. Lower risk = less effort.
Defect Management
What Goes in a Defect Report
The CTFL exam expects you to recognise the elements of a good defect report (based on ISO/IEC/IEEE 29119-3):
- Unique identifier
- Title and summary
- Date of discovery, author
- Severity, priority, status
- Steps to reproduce
- Expected vs actual result
- Environment (OS, browser, version)
- Test case reference (if applicable)
- Affected component
- Stakeholders to notify
- Lifecycle history (status changes)
Typical Defect Lifecycle States
New → Open → In Progress → Fixed → Verified → Closed
↓
Reopened → (back to In Progress)
↓
RejectedTest Estimation Techniques
| Technique | How it works |
|---|---|
| Metrics-based estimation | Use historical data from similar projects |
| Expert-based estimation | Ask experienced people |
| Three-point (PERT) | (Optimistic + 4×Most likely + Pessimistic) / 6 |
| Wideband Delphi (planning poker) | Iterative consensus among experts |
| Test point analysis | Function-point-based formula approach |
SDLC Models and Testing
| Model | How testing fits |
|---|---|
| Sequential (Waterfall, V-model) | Testing in distinct phases after development |
| V-model | Each development phase has a corresponding test level (acceptance ← requirements; system ← system design; integration ← architecture; component ← detailed design) |
| Incremental | Test each increment as it is built |
| Iterative | Test repeatedly through cycles |
| Agile | Testing throughout, test-first approaches (TDD, BDD, ATDD) |
| DevOps | Continuous testing in CI/CD pipelines, shift-left and shift-right |
Test-First Approaches
| Approach | Focus |
|---|---|
| TDD (Test-Driven Development) | Write failing test → write code → refactor |
| BDD (Behavior-Driven Development) | Tests in Given/When/Then form, business-readable |
| ATDD (Acceptance Test-Driven Development) | Acceptance tests defined collaboratively before development |
Tools (Chapter 6)
Smallest chapter, ~3 questions. Stay at the conceptual level; you do not need to know specific tool names.
Tool Categories
| Category | Examples (conceptual) |
|---|---|
| Test management | Test case management, defect tracking, requirement management |
| Static testing | Static analysers, review support tools |
| Test design and implementation | Test data generators, test design tools |
| Test execution and coverage | Test execution tools, coverage tools |
| Non-functional testing | Performance, security, accessibility tools |
| Collaboration | Wikis, communication tools |
Benefits of Test Automation
- Repetition without fatigue
- Faster execution
- Consistency
- Frees humans for exploratory work
Risks of Test Automation
- Underestimated maintenance burden
- Unrealistic expectations
- Over-reliance (automation cannot replace exploratory testing)
- Initial investment cost
- Tool-vendor lock-in
Common Confusion Pairs at a Glance
These are the term pairs that cost candidates the most marks. Memorise them.
| Pair A | Pair B | Distinction |
|---|---|---|
| Defect | Failure | Defect is in the code; failure is observable |
| Verification | Validation | “Building right” vs “right thing” |
| Confirmation testing | Regression testing | Re-test specific fix vs check for unintended breaks |
| Test monitoring | Test control | Gather data vs take action |
| Severity | Priority | Impact vs urgency |
| Product risk | Project risk | Quality of product vs success of project |
| Walkthrough | Inspection | Author-led vs moderator-led with metrics |
| K1 | K2 | Recall vs understand |
| Black-box | White-box | Spec-based vs structure-based |
| Equivalence partitioning | Boundary value analysis | Group same-treated values vs test edge values |
| Test level | Test type | When you test vs what you look for |
| Static testing | Dynamic testing | No execution vs executes the code |
Exam Day Strategy in 60 Seconds
Before:
- Sleep well, do not cram
- Eat normally
- Arrive 15 to 30 minutes early (test centre) or log in 30 minutes early (online)
- Have your government photo ID ready
During:
- Read the question stem carefully; underline BEST, MOST, EXCEPT, NOT
- Eliminate obviously wrong options first
- Mark uncertain questions and return to them at the end
- Aim to finish question 40 with at least 5 minutes left for review
- Always answer every question (no negative marking)
- Do not change answers without a clear reason
After:
- Result is shown immediately for most boards
- Digital certificate arrives within 2 to 8 weeks depending on board
What Carries the Most Marks (Priority Order)
If you have to skip something due to time, skip in this order. Drop the bottom of the list first.
| Rank | Topic | Approx. exam weight | Skip last? |
|---|---|---|---|
| 1 | Chapter 4 black-box techniques | ~20% | Never skip |
| 2 | Chapter 5 risk and management | ~15% | Never skip |
| 3 | Chapter 1 fundamentals (defect/failure, principles) | ~15% | Skip last |
| 4 | Chapter 5 monitoring, control, completion | ~10% | Skip last |
| 5 | Chapter 4 white-box techniques | ~7% | Skip later |
| 6 | Chapter 2 SDLC and test levels/types | ~10% | Skip later |
| 7 | Chapter 3 review types | ~8% | Skip later |
| 8 | Chapter 4 experience-based techniques | ~5% | Skip earlier |
| 9 | Chapter 6 tools | ~7% | Skip earlier |
| 10 | Chapter 2 maintenance testing | ~3% | Skip first |
Translation: Chapters 4 and 5 together carry close to 50% of the exam. Spending half your study time on them is rational. Chapter 6 is small enough to learn in 2 hours.
The Last 24 Hours: Final Review Checklist
Tick these off the day before your exam.
Conceptual readiness:
- I can recite the seven testing principles and give an example of each
- I can distinguish defect, failure, error, and mistake using a real scenario
- I can build a decision table from a 3-condition requirement
- I can apply 2-value and 3-value boundary value analysis
- I can identify all four review types from a scenario description
- I can explain the difference between monitoring and control, severity and priority, product risk and project risk
- I can calculate statement and branch coverage on a small code fragment
Logistics readiness (online exam):
- I have run the system test in the last 24 hours
- I have a government photo ID ready, name matching registration exactly
- My private exam room is ready and has been room-scanned
- My laptop is charged and connected to power
- I have closed all unnecessary applications
- My phone is in another room
Logistics readiness (test centre):
- I know the centre address and how to get there
- I have arranged transport with a buffer
- My ID is in my wallet
- I know what items I can and cannot take in
For the full pre-exam recovery plan and failure patterns to avoid, read 7 Reasons Candidates Fail the ISTQB CTFL Exam.
Download the One-Page PDF Cheat Sheet
We have condensed the most exam-critical content from this article into a single printable PDF you can keep next to your study notes or save to your phone for last-minute review.
The PDF includes:
- The seven testing principles
- Defect vs failure vs error vs mistake hierarchy
- Black-box techniques summary
- White-box coverage formulas
- Review types comparison
- K-level distribution
- Common confusion pairs
- Exam day checklist
Download the ISTQB CTFL v4.0 Cheat Sheet PDF (free, no registration required)
Beyond the Cheat Sheet
A cheat sheet is a memory aid, not a learning shortcut. If you find yourself referring to this article and not recognising the concepts, you need more depth, not more revision time.
Our CTFL v4.0 Study Guide covers the full syllabus with worked examples for every technique, 320+ practice questions across 8 sets, the official ISTQB sample papers, and detailed explanations for the most commonly missed questions. It is the resource we recommend for candidates who want a structured, complete preparation rather than just a cheat sheet.
For specific topic deep-dives, these free articles cover the highest-weight exam content:
- CTFL v4.0 Syllabus Explained: Chapter by Chapter
- Decision Tables, Equivalence Partitioning, and Boundary Value Analysis
- Defect vs Failure vs Error vs Mistake
- 7 Reasons Candidates Fail the ISTQB CTFL Exam
- How Hard Is the ISTQB CTFL v4.0 Exam?
Need help with the ISTQB Glossary terminology? We have an interactive flashcard tool for the full 597 terms from the official glossary v4.6.2.
This cheat sheet reflects the ISTQB CTFL v4.0 syllabus, mandatory since 9 May 2024. Quick-reference content is provided as a study aid; always cross-check with the official ISTQB syllabus before relying on it for high-stakes decisions.
Discover more from ISTQB Guru
Subscribe to get the latest posts sent to your email.
Have a question? Ask here.