Home/ quality-management/ ISTQB Certified Tester Foundation Level/ Cheat Sheet
ISTQB Certified Tester Foundation Level· Exam reference card · 2026 · Edureify AI
ISTQB Certified Tester Foundation Level

ISTQB Certified Tester Foundation Level Cheat Sheet

ISTQB CTFL Tests Software Testing Fundamentals — Terminology Precision Is Critical

The Foundation Level uses very precise terminology. In ISTQB, defect, failure, error, and fault have specific meanings — confusing them loses points on definition questions.

Check Your Readiness →
Among the harder certs
Avg: Approximately 68–73%
Pass: 750 / 1000
Most candidates understand ISTQB Certified Tester Foundation Level concepts — and still fail. This exam tests how you apply knowledge under pressure.
Core Framework

ISTQB CTFL Seven Principles of Testing

ISTQB CTFL v4.0 tests software testing fundamentals: principles, lifecycle, test design techniques, test management, and tools. The exam requires precise use of ISTQB terminology and understanding of when each test technique applies.

  1. 01
    1. Testing shows the presence of defects, not their absence
  2. 02
    2. Exhaustive testing is impossible — prioritize by risk
  3. 03
    3. Early testing saves time and money
  4. 04
    4. Defects cluster — 80/20 rule applies to defects
  5. 05
    5. Beware of the pesticide paradox — vary test cases
  6. 06
    6. Testing is context-dependent — no one-size-fits-all approach
  7. 07
    7. Absence of errors fallacy — a bug-free app still may not meet user needs
Scenario Traps

Wrong instinct vs correct approach

A developer finds a defect while testing their own code
✕ Wrong instinct

The developer should fix it immediately since they know the code best

✓ Correct approach

ISTQB recommends independent testing for objectivity — developers testing their own code suffer from confirmation bias. The defect should be logged and an independent tester should verify the fix.

Test coverage shows 100% statement coverage has been achieved
✕ Wrong instinct

Testing is complete — all code has been exercised

✓ Correct approach

100% statement coverage doesn't mean all branches or conditions have been tested. Branch coverage provides stronger assurance. The pesticide paradox also means these same tests may not find new defects.

A late-stage defect is found that requires significant rework
✕ Wrong instinct

This is normal — defects are always found in later stages

✓ Correct approach

ISTQB Principle 3: early testing saves time and money. This finding should trigger a retrospective on how earlier testing could have caught this defect sooner.

Quick Rules

Know these cold

  • ▸ Error (human) → Defect (in artifact) → Failure (visible behavior) — these are sequential
  • ▸ Verification = building it right; Validation = building the right thing
  • ▸ BVA: test boundary values AND just inside/outside the boundary — not just the boundary itself
  • ▸ Pesticide paradox: repeating the same tests stops finding new defects — vary the test cases
  • ▸ Defect clustering: 80% of defects come from 20% of modules — focus testing effort there
  • ▸ Independent testing reduces confirmation bias — testers should not test their own code
  • ▸ Risk-based testing — rioritize testing by likelihood and impact of failure
Self Check

Can you answer these without checking your notes?

In this scenario: "A developer finds a defect while testing their own code" — what should you do first?
ISTQB recommends independent testing for objectivity — developers testing their own code suffer from confirmation bias. The defect should be logged and an independent tester should verify the fix.
In this scenario: "Test coverage shows 100% statement coverage has been achieved" — what should you do first?
100% statement coverage doesn't mean all branches or conditions have been tested. Branch coverage provides stronger assurance. The pesticide paradox also means these same tests may not find new defects.
In this scenario: "A late-stage defect is found that requires significant rework" — what should you do first?
ISTQB Principle 3: early testing saves time and money. This finding should trigger a retrospective on how earlier testing could have caught this defect sooner.
Failure Patterns

Common Exam Mistakes — What candidates get wrong

Confusing error, defect, and failure terminology

Error: a human mistake that introduces a defect. Defect (bug/fault): an imperfection in the code. Failure: the visible manifestation when the defect is executed. Not all defects cause failures — candidates who use these terms interchangeably lose precision points.

Misidentifying black-box vs. white-box test techniques

Black-box techniques (equivalence partitioning, boundary value analysis, decision tables) test based on requirements without code knowledge. White-box techniques (statement coverage, branch coverage) require code knowledge. Applying the wrong category for the scenario is a common error.

Confusing verification and validation

Verification: are we building the product right? (conformance to specification). Validation: are we building the right product? (meeting user needs). These are tested in almost every ISTQB exam and frequently confused.

Misapplying boundary value analysis

BVA tests at boundary values and just inside/outside boundaries. For a range of 1–10, test: 0, 1, 2, 9, 10, 11 (two-value BVA). Candidates who only test at exact boundaries miss the values that expose the most errors.

Treating test levels as sequential gates

Unit, integration, system, and acceptance testing are test levels — they address different objectives, not a rigid sequential gate. In agile, these levels occur continuously and concurrently.

ISTQB CTFL rewards testing terminology precision. Test whether your testing knowledge matches the ISTQB standard.

Start Diagnostic Test → View all exams