If you are preparing for any ISTQB exam, you will quickly learn a hard truth. The exam is not really testing whether you can test software. It is testing whether you speak ISTQB.
That may sound cynical, but it is the reality of any terminology-based certification. The ISTQB syllabus is built on a precise vocabulary defined in the ISTQB Glossary. Questions on the exam often come down to a single word. Is the candidate confusing error with defect? Is verification being used where validation belongs? Is the question really about retesting or about regression?
This page is built to solve that problem in one place.
What you get on this page:
- Over 200 ISTQB terms, alphabetised, with anchor links
- A plain-English definition for every term (the way a senior tester would actually explain it)
- A paraphrased ISTQB-style definition where it differs meaningfully
- A short example so the term is not abstract
- An exam tip on the terms that testers most often get wrong
- The most confused term pairs on the CTFL exam, side by side
- A “high-frequency” marker (★) on terms that appear repeatedly in CTFL and Advanced exams
- A suggested study order, because cramming an alphabet list is inefficient
- A downloadable PDF version for offline study
This is not a rewording of the official ISTQB Glossary. It is a study aid. The goal is for you to actually remember these terms on exam day, not just recognise them.
Looking for full exam preparation, not just vocabulary? Start with the ISTQB CTFL v4.0 Study Guide or jump to Study Materials for All Exams to find the exact syllabus you are preparing for.
How to Use This Glossary
There are three ways to use this page, and your approach should match where you are in your preparation.
If you are early in your preparation (two or more weeks before the exam): Read the glossary in the suggested study order at the bottom of this page. Do not try to memorise everything on day one. Focus on the ★ starred terms first. These are the ones that show up on almost every CTFL exam.
If you are one week from the exam: Skim the full A-Z, but spend real time on the Commonly Confused Term Pairs section. Every year, a large chunk of candidates fail the CTFL not because they did not study, but because they confused two similar-sounding terms under exam pressure.
If you are revising the night before: Go directly to the High-Frequency Exam Terms and Commonly Confused Pairs sections. Trust your prior reading for the rest.
Legend:
- ★ High-frequency CTFL exam term. Learn this one cold.
- (!) This term is routinely confused with another. See the Commonly Confused Pairs section.
- (Adv) This term is more relevant to an ISTQB Advanced Level exam than to CTFL.
Alphabetical Index
Jump directly to a letter.
A · B · C · D · E · F · G · H · I · K · L · M · N · O · P · Q · R · S · T · U · V · W
A
Acceptance Criteria ★ The specific conditions a product, feature, or user story must meet before a customer, user, or authorised body accepts it. In Agile, acceptance criteria are attached to user stories and drive test case design. Example: “The login form must lock the user out after 3 failed attempts within 5 minutes.” Exam tip: Acceptance criteria are a test basis, not a test type. Do not confuse them with acceptance testing. Related: User Story, Definition of Done, Acceptance Testing.
Acceptance Testing ★ A test level, typically the last, where the system is checked against business requirements by users, customers, or their proxies. The goal is to establish confidence that the system is fit for use. Example: Business users run end-to-end scenarios on a staging environment before go-live. Exam tip: Acceptance testing is a test level, not a technique. It includes UAT, operational acceptance, contract acceptance, regulatory acceptance, and alpha/beta testing. Related: UAT, Alpha Testing, Beta Testing, Operational Acceptance Testing. Want to specialise? Explore the CT-AcT Acceptance Testing certification.
Accessibility Testing Testing that verifies a product is usable by people with the widest possible range of abilities, including users with visual, auditory, motor, or cognitive impairments. Commonly aligned with WCAG standards. Example: Confirming a website can be navigated using only a keyboard and a screen reader. Related: Usability Testing, Non-Functional Testing.
Accuracy (Quality Characteristic) Under functional suitability, the degree to which a system provides correct results with the required level of precision. Think of a tax calculator that must be correct to two decimal places. Related: Functional Suitability, ISO 25010.
Ad Hoc Testing Informal testing done without a documented plan, test cases, or formal expected results. The tester explores the system guided by experience and intuition. Exam tip: ISTQB considers ad hoc testing a form of experience-based testing, not an excuse to skip planning. Related: Exploratory Testing, Experience-Based Testing.
Agile A family of iterative software development approaches based on the Agile Manifesto. Favours working software, customer collaboration, responsiveness to change, and short feedback cycles. Example: Scrum, XP, and Kanban are all Agile approaches. Related: Scrum, Iteration, Sprint, Agile Manifesto. Preparing for an Agile testing exam? See the ISTQB Agile Tester Study Guide or the CTAL-ATT Agile Technical Tester page.
Agile Manifesto The 2001 statement of values and principles that defines Agile. Four values (individuals and interactions over processes, working software over documentation, customer collaboration over contract negotiation, responding to change over following a plan) and twelve principles. Exam tip: The CTFL-AT exam can ask which value or principle supports a given behaviour. Read the actual manifesto at agilemanifesto.org.
Alpha Testing Simulated or actual operational testing performed at the developer’s site by potential customers or an independent test team. Done before beta testing. Related: Beta Testing, Acceptance Testing.
Analysability A maintainability sub-characteristic. How easy it is to diagnose deficiencies, locate the root cause of failures, or identify parts that need to change. Related: Maintainability, Quality Characteristic.
Anomaly Any condition that differs from what is expected based on requirements, specifications, design, or a tester’s experience. An anomaly is the umbrella term that covers defects, failures, and unusual observations. Exam tip: If a question says a tester “noticed something strange,” that is an anomaly. Whether it becomes a defect report depends on analysis. Related: Incident, Defect, Failure.
API Testing Verifying the functional behaviour, reliability, performance, and security of application programming interfaces, typically without a UI. Example: Sending a POST request to /api/login with an invalid password and validating the 401 response. Related: Interface Testing, Integration Testing.
Application Programming Interface (API) A defined way for software components to communicate. An API specifies what requests are valid, what responses to expect, and the contract between consumer and provider.
Attack (Security) A malicious attempt to exploit a vulnerability in a system. In security testing, “attack patterns” are the structured techniques a tester uses to probe for weaknesses. Related: Penetration Testing, Security Testing, Vulnerability. See the CT-SEC Security Tester certification.
Audit An independent examination of a software product, process, or set of procedures to assess compliance with specifications, standards, contracts, or other criteria. Related: Review, Static Testing.
Availability The percentage of time a system is operational and accessible when required for use. Often expressed as “four nines” (99.99%). Related: Reliability, Non-Functional Testing.
B
Backlog An ordered list of work items a development team can pull from. In Scrum, the product backlog is maintained by the product owner. Related: Product Owner, Scrum, Sprint.
Behavior-Driven Development (BDD) A collaboration practice where business, developers, and testers describe expected behaviour in a shared language (usually Gherkin’s Given/When/Then). Executable specifications drive both development and testing. Example: Given a logged-in user, When they click "Logout," Then they are redirected to the home page. Related: Gherkin, TDD, Acceptance Criteria.
Beta Testing Testing performed at customer sites by potential or existing users under real conditions, without developer involvement. Done after alpha testing. Exam tip: Remember the order: Alpha (at the developer’s site) then Beta (at the customer’s site). Related: Alpha Testing, Acceptance Testing.
Big Bang Integration An integration strategy where all, or many, components are combined at once instead of incrementally. Rarely recommended because fault localisation becomes painful. Related: Integration Testing, Incremental Integration.
Black-Box Testing ★ A family of testing techniques based on analysis of specifications or behaviour without knowledge of the internal structure. The tester treats the system as a closed box with inputs and outputs. Example: Equivalence partitioning, boundary value analysis, decision table testing. Exam tip: ISTQB v4.0 calls these specification-based techniques. “Black-box” is the older name; both are accepted. Related: Specification-Based Testing, White-Box Testing, Experience-Based Testing.
Boundary Value Analysis (BVA) ★ (!) A black-box technique that tests values at the edges of equivalence partitions. Defects cluster at boundaries, which is why this technique is so effective. Example: If valid age is 18-65, test 17, 18, 65, 66. Two-value BVA uses boundary and just-outside. Three-value BVA also adds just-inside. Exam tip: This is one of the most tested techniques on CTFL. Be sure you know both two-value and three-value BVA. Related: Equivalence Partitioning, Black-Box Testing.
Branch A point in a program where control flow can take one of two or more paths, such as an if, switch, or loop condition.
Branch Coverage The percentage of branches (decision outcomes) exercised by a test suite. 100% branch coverage means every possible outcome of every decision has been executed at least once. Branch coverage subsumes statement coverage. Example: An if/else has 2 branches; hitting both gives 100% branch coverage. Related: Decision Coverage, Statement Coverage, White-Box Testing.
Bug A colloquial term for a defect. ISTQB prefers “defect” in formal contexts. Related: Defect, Error, Failure.
Build Verification Test (BVT) A minimal set of tests run against each build to confirm it is stable enough for further testing. Close cousin of smoke testing. Related: Smoke Testing, Continuous Integration.
C
Capture/Playback Tool A type of test execution tool that records a tester’s actions and plays them back as scripts. Useful for simple flows, fragile for complex UIs. Related: Test Automation, Test Execution Tool.
Cause-Effect Graph A technique that models logical relationships between causes (inputs, conditions) and effects (outputs, actions) as a graph, from which decision tables can be derived. Related: Decision Table Testing, Combinatorial Testing.
Change Request A formal proposal to alter the product, process, or documentation. Feeds into change control. Related: Configuration Management, Impact Analysis.
Checklist-Based Testing An experience-based technique where the tester uses a high-level list of items to check. Faster than formal cases, useful for recurring test areas. Related: Experience-Based Testing, Exploratory Testing.
Classification Tree Method A combinatorial technique that organises inputs into a tree of classes and combines them systematically to design test cases. Common in tools like Classification Tree Editor (CTE). Related: Combinatorial Testing, Test Design Technique.
Code Coverage A family of measures describing how much code has been exercised by tests. Expressed as a percentage. Common flavours: statement, branch, decision, condition, path. Exam tip: Code coverage is a white-box metric. It does not measure whether the tests are any good, only whether code was executed. Related: White-Box Testing, Statement Coverage, Branch Coverage.
Combinatorial Testing Techniques that select test cases from large combinations of input parameters, typically using pairwise or n-wise coverage, to find faults caused by interactions. Related: Pairwise Testing, Classification Tree Method.
Commercial Off-the-Shelf (COTS) A software product that is ready to use and sold to a general market. Different from custom-developed software. Testing COTS usually focuses on configuration and integration.
Compatibility Testing A non-functional test type that checks co-existence with other software and interoperability with external systems. Example: two apps sharing memory or a file system. Related: Interoperability Testing, Non-Functional Testing.
Complete Testing See Exhaustive Testing. It is the theoretical idea of testing every input combination. It is impossible in practice and one of the Seven Principles of Testing.
Component The smallest independently testable unit of software. Also called a unit or module. Related: Unit, Module, Component Testing.
Component Integration Testing Testing focused on the interactions and interfaces between components. A test level in ISTQB, distinct from component testing itself. Related: Integration Testing, System Integration Testing.
Component Testing ★ A test level that verifies individual software components in isolation, usually by developers. Also called unit testing or module testing. Example: A JUnit test for a calculateTax() function. Exam tip: In CTFL v4.0, the test levels are: component, component integration, system, system integration, and acceptance. Memorise this list. Related: Unit Testing, TDD, Test Level.
Concurrency Testing Testing that two or more activities executed at the same time do not cause defects such as deadlocks, race conditions, or starvation. Related: Performance Testing, Non-Functional Testing.
Condition A boolean expression that cannot be broken down further, such as x > 10. Part of a decision. Related: Decision, Branch, Condition Coverage.
Condition Coverage (Adv) The percentage of condition outcomes (true and false) that have been exercised by tests. Every boolean atom must evaluate both ways. Weaker than decision coverage alone. Related: Multiple Condition Coverage, MC/DC.
Configuration Management The discipline of identifying, controlling, and tracking changes to configuration items (code, documents, environments, test assets). Related: Version Control, Change Request.
Confirmation Testing ★ (!) Also known as re-testing. After a defect has been fixed, confirmation testing re-runs the exact test that revealed it to verify the fix. Exam tip: Candidates frequently confuse confirmation testing (just the failing test) with regression testing (checking nothing else broke). Both are usually done for the same fix. Related: Re-Testing, Regression Testing, Change-Related Testing.
Continuous Delivery (CD) A software engineering approach in which every change that passes automated quality checks can be released to production at any time. Related: Continuous Integration, DevOps.
Continuous Integration (CI) The practice of merging and validating code changes frequently, often many times a day, triggered automatically by version-control events. Related: CD, DevOps, Build Verification Test.
Control Flow The order in which statements and decisions in a program are executed. White-box coverage measures are based on control flow. Related: Control Flow Graph, White-Box Testing.
Coverage The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite. Related: Code Coverage, Coverage Item.
Coverage Item An element or property used as a basis for test coverage. Examples: a statement, a branch, an equivalence partition, a requirement.
Critical Testing Process (CTP) (Adv) A content-based process improvement model that focuses on twelve critical activities in testing, associated with Rex Black. Related: TMMi, TPI Next.
Cyclomatic Complexity A metric developed by Thomas McCabe that measures the number of linearly independent paths through a program. Higher complexity means more testing effort. Exam tip: The formula: M = E − N + 2P for a connected graph, where E is edges, N is nodes, P is connected components. For single programs, simplify to M = Decisions + 1. Related: White-Box Testing, Structural Testing.
D
Data Flow Testing (Adv) A white-box technique based on how data is defined, used, and killed as it flows through code. Helps find uninitialised reads and redundant writes. Related: White-Box Testing.
Data-Driven Testing An automation pattern where the test script is separated from the test data. The same script is run with many sets of inputs. Example: A single login test driven by a CSV of 50 valid and invalid credential pairs. Related: Keyword-Driven Testing, Test Automation.
Debugging The developer activity of locating, analysing, and removing the cause of a failure. Debugging is not testing; ISTQB is strict about this distinction. Exam tip: Testing finds failures. Debugging removes their causes. They are different activities done by different roles. Related: Defect, Root Cause Analysis.
Decision A point in a program where one of two or more control flows can be chosen. Typically an if, switch, while, or for construct.
Decision Coverage ★ The percentage of decision outcomes exercised by tests. Every decision must evaluate both true and false. Decision coverage subsumes statement coverage. Exam tip: In CTFL v4.0, statement coverage and decision (branch) coverage are the two white-box metrics you must know cold. Related: Branch Coverage, Statement Coverage.
Decision Table Testing ★ A black-box technique that captures combinations of conditions and resulting actions in a table, then derives one test case per column. Example: A discount rule table with rows for “premium customer,” “promo code,” “cart > $100” and columns for each valid combination. Exam tip: Decision table questions are a CTFL favourite. Practice simplifying tables by removing impossible combinations. Related: Cause-Effect Graph, Black-Box Testing.
Defect ★ (!) An imperfection or deficiency in a work product that causes it to not meet its requirements or specifications. Also called a fault or bug. Exam tip: The chain is: a person makes a mistake (error) → that mistake creates a defect in the code → the defect, when executed, causes a failure. Memorise this chain. Related: Failure, Error, Mistake, Bug.
Defect Density The number of defects found in a unit of size (for example, defects per KLOC or per function point). Related: Metric, Defect Management.
Defect Management The end-to-end process of detecting, reporting, classifying, analysing, resolving, and preventing defects. Covers workflow, reporting, and trend analysis.
Defect Masking A situation where one defect prevents another from being observed. Fix the first, and a second one emerges. Example: A login page crash hides a downstream payment bug that is never reached. Related: Defect, Anomaly.
Defect Report A structured record of a defect, typically including ID, summary, steps to reproduce, expected vs actual, severity, priority, environment, and attachments. Related: Incident Report, Severity, Priority.
Defect Taxonomy A classification scheme for defects, often used to analyse patterns (root cause, type, phase injected, phase detected). Related: Root Cause Analysis.
Definition of Done (DoD) ★ In Agile, the shared, explicit criteria that a work item (story, feature, sprint) must meet to be considered complete. Quality standards live here. Example: “Unit tests pass, code reviewed, deployed to staging, acceptance criteria met.” Exam tip: CTFL-AT candidates must know the difference between Definition of Done and Definition of Ready. Related: Definition of Ready, Acceptance Criteria, Agile.
Definition of Ready (DoR) Criteria a work item must meet before a team commits to it in a sprint. Typically covers clarity of acceptance criteria, sizing, and dependencies. Related: Definition of Done, Backlog Refinement.
Deviation See Incident. Any event during testing that requires investigation.
DevOps A cultural and technical approach that unifies development and operations to shorten the delivery cycle, increase deployment frequency, and improve reliability. Related: Continuous Integration, Continuous Delivery, Shift-Right.
Driver A test support component that replaces a higher-level component and drives a lower-level component under test. Opposite of a stub. Example: A test driver calls a newly developed payment module with crafted inputs. Exam tip: Driver = replaces the caller. Stub = replaces the callee. This is a classic CTFL distinction. Related: Stub, Test Harness, Component Testing.
Dynamic Testing ★ Testing that involves executing the software under test. Contrast with static testing, which examines artefacts without running code. Related: Static Testing, Execution.
E
Efficiency (Performance Efficiency) A quality characteristic in ISO 25010 describing the performance of a system relative to the resources used under stated conditions. Includes time behaviour, resource utilisation, and capacity. Related: Performance Testing, Resource Utilisation.
Emulator A device, system, or software that duplicates the functionality of another system. Test emulators mimic real environments when the real thing is unavailable. Related: Simulator, Virtualisation.
Entry Criteria ★ The conditions that must be satisfied before a test activity can begin. Example: build is available, test environment ready, test cases reviewed. Related: Exit Criteria, Test Planning.
Environment See Test Environment.
Equivalence Partition A subset of input, output, or state where the system is expected to behave the same way. One test per partition is, in theory, enough. Related: Equivalence Partitioning.
Equivalence Partitioning (EP) ★ A black-box technique that divides inputs or outputs into equivalence classes and tests one representative value per class. Example: For a field accepting ages 18-65, partitions are <18 (invalid), 18-65 (valid), >65 (invalid). Test one value from each. Exam tip: EP and BVA are usually applied together. EP picks the partitions; BVA then tests their boundaries. Related: Boundary Value Analysis, Black-Box Testing.
Error (!) A human action that produces an incorrect result. In ISTQB’s chain, an error is what a person does (the mistake of thought). Often used interchangeably with “mistake.” Exam tip: Error ≠ Defect. Error is the human origin. Defect is the artefact that results. Failure is the observable symptom. Related: Mistake, Defect, Failure.
Error Guessing An experience-based technique where the tester uses intuition and past knowledge to anticipate where defects are likely. Example: Testing empty strings, nulls, very long inputs, leading zeros, boundary characters. Related: Exploratory Testing, Experience-Based Testing.
Exhaustive Testing Testing every possible combination of inputs, preconditions, and paths. Practically impossible. One of the Seven Testing Principles. Related: Seven Testing Principles.
Exit Criteria ★ The conditions that must be met to declare a test activity or test level complete. Example: all severity-1 defects fixed, 95% of test cases passed, coverage target reached. Exam tip: Exit criteria drive the completion decision; they do not guarantee quality on their own. Related: Entry Criteria, Test Planning.
Experience-Based Testing Techniques that rely on the tester’s knowledge, experience, and intuition rather than a formal specification or structural model. Example: Error guessing, exploratory testing, checklist-based testing. Related: Black-Box Testing, Structure-Based Testing.
Exploratory Testing ★ Simultaneous learning, test design, and test execution, typically structured using session-based test management (SBTM) and test charters. Exam tip: Exploratory testing is not random. It is disciplined, charter-driven, and time-boxed. Related: Session-Based Test Management, Test Charter.
F
Failure ★ (!) An event where a component or system does not perform a required function within specified limits. A failure is what the user or tester observes. Exam tip: A defect in dormant code can never cause a failure until that code is executed. No execution = no failure = no evidence. This is why dynamic testing exists. Related: Defect, Error, Anomaly.
Fake A test double that has a working implementation but is not suitable for production. Example: an in-memory database used in place of a real one. Related: Mock, Stub, Spy.
False-Fail Result A test reports a failure that is not due to a real defect. The system is fine; the test or environment is broken. Exam tip: Often called a “false positive.” Whatever you call it, it erodes trust in the test suite if not fixed quickly. Related: False-Pass Result, Flaky Test.
False-Pass Result A test passes even though there is a real defect. A dangerous outcome because the defect escapes to production. Related: False-Fail Result.
Fault Synonym for defect. A permanent deviation from correctness in a work product. Related: Defect, Failure.
Fault Tolerance A reliability sub-characteristic. The ability of a system to operate despite the presence of defects or stressful conditions. Related: Reliability, Robustness.
Feature A distinct, externally visible characteristic or capability of a system. Features are typically decomposed into user stories. Related: User Story, Requirement.
Field Testing Testing performed at customers’ sites under real operational conditions. Beta testing is a form of field testing.
Finite State Machine A model with a finite number of states and well-defined transitions between them triggered by events. The basis for state transition testing. Related: State Transition Testing.
Formal Review ★ A review that follows a defined process, roles, checklists, and documented outcomes. Examples: inspection, technical review. Exam tip: CTFL expects you to know the five stages: planning, initiate review, individual review, issue communication and analysis, fixing and reporting. Related: Inspection, Walkthrough, Static Testing.
Functional Suitability ISO 25010 characteristic. How well the system’s functions meet stated and implied needs. Includes functional completeness, functional correctness, functional appropriateness. Related: Quality Characteristic.
Functional Testing ★ Testing based on what the system should do. Derived from specifications, use cases, or requirements. Contrast with non-functional testing (which tests how it does it). Related: Non-Functional Testing, Black-Box Testing.
G
Gherkin The structured Given/When/Then syntax used by BDD tools like Cucumber to express executable specifications. Example: Given a user with an active subscription When they cancel Then their plan status is 'cancelled'. Related: BDD, Acceptance Criteria.
Gray-Box Testing A combination of black-box and white-box techniques where the tester uses partial knowledge of internals to design external tests. Not a formal ISTQB test level.
H
Hardware-Software Integration Testing (Adv) Testing the interactions between hardware and software components, common in embedded systems, automotive, and IoT. Related: Integration Testing. Testing in regulated industries? See the CT-AuT Automotive Software Tester page.
Hazard Analysis (Adv) A technique used in safety-critical systems to identify potential hazards, their sources, and mitigations. Related: Risk Analysis, Safety-Critical Testing.
Heuristic Evaluation A usability inspection method where experts assess a UI against recognised heuristics, such as Nielsen’s ten. Related: Usability Testing. See the CT-UT Usability Tester certification.
High-Level Test Case A test case without concrete input values or expected results, describing the scenario only. Paired with low-level test cases that add the data. Related: Low-Level Test Case.
I
Impact Analysis The analysis of what parts of a system could be affected by a proposed change. Drives regression test selection. Related: Change-Related Testing, Regression Testing.
Incident Any event that requires investigation during testing. An incident may or may not turn out to be a defect. Exam tip: Not every incident becomes a defect. Some are environment issues, test errors, or misunderstood specifications. Related: Defect, Anomaly.
Incident Report The document recording an incident, its context, and investigation outcomes. Related: Defect Report.
Incremental Development Model A lifecycle model in which the system is built, tested, and delivered in increments. Each increment adds functionality. Related: Iterative Development, V-Model.
Independence of Testing The degree to which the testing role is separated from the development role. Ranges from developers testing their own code to independent external teams. Exam tip: ISTQB lists several levels of independence. Higher independence generally finds more defects, but context matters. Related: Tester, Test Level.
Informal Review A review without a defined process, roles, or documented outcomes. Cheap, fast, variable in rigor. Related: Formal Review, Walkthrough.
Inspection ★ The most formal type of review. Uses defined roles (moderator, author, reader, reviewer), entry and exit criteria, and is led by a trained moderator. Produces metrics. Exam tip: Inspection is the gold standard of static testing. It is also the most expensive. Related: Formal Review, Walkthrough, Static Testing.
Installability Testing Testing whether software can be successfully installed and uninstalled in the target environment. A portability sub-characteristic. Related: Portability.
Integration The process of combining components or systems into larger assemblies.
Integration Testing ★ Testing the interfaces and interactions between integrated components or systems. Two levels: component integration and system integration. Related: Component Integration Testing, System Integration Testing.
Interface A shared boundary across which two or more components or systems communicate.
Interface Testing Testing that focuses on communication across interfaces: data exchange, protocols, timing, error handling. Related: API Testing, Integration Testing.
Interoperability The degree to which two or more systems, products, or components can exchange information and use it. A compatibility sub-characteristic. Related: Compatibility Testing.
Iteration A single development cycle in an iterative or Agile lifecycle, producing a working increment. In Scrum, an iteration is called a sprint. Related: Sprint, Agile.
K
Key Performance Indicator (KPI) A measurable value demonstrating how effectively an objective is being achieved. In testing, KPIs might include defect removal efficiency, automation coverage, or mean time to detect. Related: Metric, Test Monitoring.
Keyword-Driven Testing An automation pattern where test scripts are composed from high-level keywords (like LoginAs, ClickButton), separating test logic from implementation. Related: Data-Driven Testing, Test Automation. Building an automation practice? See the CTAL-TAE v2.0 Study Guide or the CT-TAS Test Automation Strategy page.
L
Level Test Plan A test plan that applies to a single test level, such as a system test plan. Cascades from the master test plan. Related: Master Test Plan, Test Planning.
Load Testing (!) A performance test type that evaluates system behaviour under expected load, typically the anticipated number of concurrent users or transactions. Exam tip: Load = expected load. Stress = beyond capacity. Do not confuse them. Related: Stress Testing, Performance Testing. See the CT-PT Performance Tester certification.
Low-Level Test Case A test case with concrete input values and expected results. The executable counterpart to a high-level test case. Related: High-Level Test Case.
M
Maintainability ISO 25010 characteristic. The degree of ease with which a product can be modified: corrected, adapted, improved, or ported. Sub-characteristics include analysability, modifiability, testability, modularity, reusability. Related: Testability, Technical Debt.
Maintenance Testing Testing changes to a system in production due to corrections, enhancements, or adaptations, plus regression testing to confirm nothing else broke. Related: Regression Testing, Impact Analysis.
Master Test Plan A test plan covering multiple test levels and used by test management. Parent of level test plans. Related: Level Test Plan, Test Planning.
Metric A measurement scale and the method used for measurement. Example: defects per KLOC, test execution duration. Related: KPI, Test Monitoring.
Mistake (!) A human error; the act that leads to a defect. In ISTQB, “mistake” and “error” are used interchangeably. Exam tip: The critical distinction is not mistake vs error. It is mistake/error (human) vs defect (artefact) vs failure (symptom). Related: Error, Defect, Failure.
Mock A test double that verifies how it was called. Used to isolate the unit under test from its dependencies and check interactions. Related: Stub, Fake, Spy.
Model-Based Testing (MBT) (Adv) An approach where test cases are generated automatically from a formal model of the system’s behaviour, state, or data. Related: Finite State Machine. See the CT-MBT Model-Based Tester page.
Module Synonym for component or unit.
Monkey Testing Random input testing, historically done by automated “monkeys” that fire random events at an interface. Useful for stability and crash testing on mobile and desktop apps.
Multiple Condition Coverage (Adv) The percentage of unique combinations of all conditions within a decision exercised by tests. Stronger than decision and condition coverage, but combinatorially expensive. Related: MC/DC, Condition Coverage.
Mutation Testing (Adv) A technique where small changes (mutants) are introduced into code to evaluate whether the test suite detects them. Measures test effectiveness, not code quality. Related: Fault Injection.
N
Negative Testing Testing aimed at showing a system does not work when it should not. Example: invalid inputs, malformed data, unauthorised access attempts. Exam tip: Negative testing is part of responsible test design, not the opposite of positive testing. Both are needed. Related: Positive Testing, Robustness.
Non-Functional Requirement A requirement that does not describe behaviour itself but how the system must behave: performance, security, usability, portability, compatibility, reliability, maintainability. Related: Functional Requirement.
Non-Functional Testing ★ Testing of non-functional characteristics such as performance, usability, security, compatibility, reliability, portability, maintainability. Example: Load testing, accessibility testing, penetration testing. Related: Functional Testing, Quality Characteristic.
O
Operational Acceptance Testing (OAT) Acceptance testing focused on operational readiness: backup, recovery, deployment, monitoring, security policies, documentation. Related: Acceptance Testing, User Acceptance Testing.
Operational Profile A statistical distribution of expected use of a system. Drives performance and reliability test design. Related: Performance Testing, Reliability.
Oracle (Test Oracle) ★ A source used to determine whether a test has passed or failed. Could be a specification, a previous version, a model, a heuristic, or an experienced person. Exam tip: The oracle problem is the difficulty of knowing the correct result for every test. ISTQB expects candidates to recognise this term. Related: Expected Result.
P
Pair Programming Two developers working together at one workstation, one writing code (driver) and the other reviewing (navigator). Reduces defects at source. Related: Pair Testing, Review.
Pair Testing Two testers (or a tester and developer) collaborating at one machine to design and execute tests. Common in Agile.
Pairwise Testing A combinatorial technique that covers all pairs of parameter values, dramatically reducing the test count compared to exhaustive combinations. Also called 2-wise or all-pairs. Related: Combinatorial Testing, Classification Tree Method.
Path Coverage (Adv) The percentage of distinct paths through a program exercised by tests. Generally impractical for real software due to combinatorial explosion. Related: Cyclomatic Complexity, White-Box Testing.
Penetration Testing A security test type where testers actively try to exploit vulnerabilities, simulating an attacker. Usually done late and often by external specialists. Related: Security Testing, Attack.
Performance Efficiency See Efficiency. ISO 25010 quality characteristic including time behaviour, resource utilisation, and capacity.
Performance Testing A non-functional test type that evaluates how a system behaves under a particular workload. Includes load, stress, soak (endurance), spike, and scalability testing. Related: Load Testing, Stress Testing.
Portability ISO 25010 characteristic. The degree to which a system can be transferred from one environment to another. Includes adaptability, installability, replaceability.
Positive Testing Testing with valid inputs to confirm the system does what it should. Paired with negative testing for balanced coverage. Related: Negative Testing.
Precondition A state or condition required before a test can be executed.
Priority The urgency with which a defect must be fixed, typically set by a business stakeholder. Exam tip: Priority is about business urgency. Severity is about technical impact. They are set by different people for different reasons. Related: Severity, Defect.
Product Owner In Scrum, the person responsible for maximising the value of the product, ordering the backlog, and representing the customer. Related: Scrum, Backlog.
Product Risk ★ A risk directly related to the product and its quality characteristics. Example: “the payment module may incorrectly calculate tax.” Exam tip: Product risks are what testing mitigates. Project risks (schedule, resources) are managed differently. Related: Risk-Based Testing, Project Risk.
Project Risk A risk related to the management of the project: schedule, budget, resources, environment, supplier delivery. Related: Product Risk, Risk Management.
Prototype An early, simplified version of a system used to explore ideas, validate requirements, or test feasibility.
Q
Quality ★ The degree to which a product meets stated and implied needs of its stakeholders. ISO 25010 provides the reference model. Related: Quality Characteristic, Quality Assurance.
Quality Assurance (QA) (!) Process-oriented activities that aim to prevent defects and improve processes. QA is preventive. Exam tip: QA ≠ Testing. Testing is a detection activity; QA is a prevention discipline. Do not use them interchangeably in an exam. Related: Quality Control, Testing.
Quality Characteristic A category of quality attributes defined by ISO 25010. Functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability.
Quality Control (QC) Product-oriented activities that identify defects in work products. Testing is a core QC activity. Related: Quality Assurance, Testing.
Quality Gate A checkpoint at which quality criteria must be met before proceeding. Often implemented in CI/CD pipelines.
R
Recovery Testing A non-functional test type that checks how well a system recovers from failures, crashes, or loss of resources. Related: Reliability, Failover Testing.
Refactoring Restructuring code without changing its external behaviour, usually to improve readability, reduce complexity, or remove duplication. Exam tip: Refactoring requires a solid regression safety net. Without tests, refactoring is just “rewriting and hoping.” Related: Maintainability, Regression Testing.
Regression Testing ★ (!) Testing of a previously tested component or system after modification, to ensure that defects have not been introduced or uncovered. Exam tip: Regression is about side effects from change. Re-testing is about confirming the fix itself. Exam questions weaponise this difference. Related: Re-Testing, Confirmation Testing, Change-Related Testing.
Release A version of a product or component delivered to internal or external users. Related: Version Control.
Reliability ISO 25010 characteristic. Ability of a system to perform required functions under stated conditions for a stated period. Sub-characteristics: maturity, availability, fault tolerance, recoverability. Related: Availability, Fault Tolerance.
Requirement A condition or capability a user needs to solve a problem, or that a system must meet to satisfy a contract, standard, or specification.
Requirements-Based Testing Testing derived directly from requirements. A specific form of specification-based testing. Related: Specification-Based Testing, Traceability.
Residual Risk The risk remaining after mitigation actions (including testing) have been applied. Related: Risk, Risk-Based Testing.
Resource Utilisation A performance efficiency sub-characteristic. The amounts and types of resources a product uses when performing its functions. Related: Performance Efficiency.
Result The effect of running a test, such as screen output, data changes, error messages, or logs. Compared to the expected result to determine pass or fail.
Re-Testing ★ (!) Also called confirmation testing. Re-executing a failing test after the defect has been fixed to confirm the fix. Exam tip: Re-testing confirms the fix. Regression testing checks for damage caused by the fix elsewhere. Do both. Related: Confirmation Testing, Regression Testing.
Review ★ A static testing technique where a work product is examined by people to find defects, improve quality, or achieve consensus. Types: informal review, walkthrough, technical review, inspection. Related: Static Testing, Inspection, Walkthrough.
Risk ★ A factor that could result in a future negative consequence. Characterised by likelihood and impact. Related: Product Risk, Project Risk, Risk Level.
Risk Assessment The process of identifying, analysing, and prioritising risks. Inputs to risk-based test planning. Related: Risk-Based Testing.
Risk-Based Testing ★ An approach that prioritises test design, execution, and resources according to the risk level of features and components. Exam tip: CTFL asks “what risk-based testing looks like in practice.” Answer: higher-risk items get earlier, deeper, and more thorough testing. Related: Product Risk, Risk Level.
Risk Level The qualitative or quantitative rating of a risk, usually computed from likelihood × impact. Related: Risk Assessment.
Robustness The degree to which a system functions correctly in the presence of invalid inputs or stressful environmental conditions. Related: Fault Tolerance, Negative Testing.
Root Cause The source of a defect. Finding the root cause is essential for preventing the same class of defect in future. Related: Root Cause Analysis.
Root Cause Analysis (RCA) A structured process of identifying the underlying cause of a defect, beyond the surface symptom. Techniques include 5 Whys and fishbone diagrams. Related: Defect Management.
S
Sanity Testing A narrow, quick verification that a specific change or fix works as expected. Sometimes confused with smoke testing; sanity is usually narrower and done after a fix. Related: Smoke Testing, Confirmation Testing.
Scalability Testing A non-functional test type that checks how well a system scales with increasing load, data, users, or geographic distribution. Related: Performance Testing, Load Testing.
Scenario A description of a user’s interaction with a system to achieve a goal. Scenarios often drive scenario-based and use-case testing.
Scrum An Agile framework with defined roles (product owner, scrum master, development team), events (sprint, sprint planning, daily scrum, review, retrospective), and artefacts (product backlog, sprint backlog, increment). Related: Agile, Sprint, Product Owner.
Security Testing Testing to identify vulnerabilities and determine whether the system protects data and functionality against unauthorised access. Related: Penetration Testing, Attack. See the CT-SEC Security Tester page.
Session-Based Test Management (SBTM) A structured approach to exploratory testing that uses time-boxed sessions, charters, and debriefs. Related: Exploratory Testing, Test Charter.
Severity (!) The degree of impact a defect has on the functioning of the system. Usually rated on a scale such as critical, high, medium, low. Exam tip: Severity is set by the tester, technically. Priority is set by the business, urgency-wise. A low-severity defect can have high priority (like a typo on a homepage banner). Related: Priority.
Shift-Left An approach that moves testing activities earlier in the lifecycle, including static testing, test-first development, and early test design. Related: TDD, BDD, Static Testing.
Shift-Right An approach that extends testing into production, using monitoring, canary releases, feature toggles, chaos engineering, and A/B tests. Related: DevOps, Continuous Delivery.
Smoke Testing (!) A small, shallow set of tests run on a new build to confirm it is stable enough for further testing. Exam tip: Smoke testing (broad, shallow, on every build) is different from sanity testing (narrow, deeper, after a specific change). Related: Sanity Testing, Build Verification Test.
Specification A document that specifies requirements, design, behaviour, or other characteristics of a component or system.
Specification-Based Testing ★ ISTQB v4.0 term for black-box testing. Test design based on the specification of a component or system, without knowledge of internal structure. Related: Black-Box Testing, Structure-Based Testing.
Sprint A time-boxed iteration in Scrum, typically 1-4 weeks, at the end of which a potentially shippable increment is produced. Related: Iteration, Scrum.
Stability (Reliability Sub-Characteristic) The ability of a system to avoid unexpected effects from modifications. A maintainability-related quality. Related: Reliability, Maintainability.
Stakeholder Any person, group, or organisation with an interest in, or affected by, the system.
State Transition Testing ★ A black-box technique that models the system as states and transitions, then designs tests to cover states, transitions, or sequences of transitions. Example: An ATM card lifecycle: Active → Blocked → Unblocked → Expired. Related: Finite State Machine, Black-Box Testing.
Statement Coverage ★ The percentage of executable statements exercised by tests. Weakest common white-box coverage measure. Exam tip: 100% statement coverage does not imply 100% branch coverage. A single straight-line test may hit every statement but miss many branches. Related: Branch Coverage, Decision Coverage, White-Box Testing.
Static Analysis ★ The analysis of software artefacts (typically source code) without executing them, using tools to detect code-quality issues, vulnerabilities, or standards violations. Example: SonarQube, Checkstyle, ESLint, Coverity. Related: Static Testing, Dynamic Testing.
Static Testing ★ Testing of work products without executing them. Includes reviews (human) and static analysis (tool). Exam tip: Static testing finds defects before they become runtime failures. It is one of the highest-leverage testing activities. Related: Dynamic Testing, Review, Static Analysis.
Stress Testing (!) A performance test type that evaluates system behaviour beyond its anticipated or specified limits. Exam tip: Load = expected. Stress = breaking point. Soak = extended duration. Spike = sudden surge. Related: Load Testing, Performance Testing.
Structure-Based Testing ★ ISTQB v4.0 term for white-box testing. Test design based on the internal structure of the component or system. Related: White-Box Testing, Specification-Based Testing.
Stub A test support component that simulates a lower-level component the unit under test calls. Opposite of a driver. Example: A payment-gateway stub that always returns “success” to test the order flow. Exam tip: Stub = replaces the callee. Driver = replaces the caller. Related: Driver, Mock, Test Harness.
System Integration Testing (SIT) A test level that verifies the interactions between the system and external systems (other applications, services, hardware, third-party APIs). Related: Integration Testing, Component Integration Testing.
System of Systems A collection of independent systems that are integrated into a larger system to deliver capabilities no single system provides alone.
System Testing ★ A test level that verifies the behaviour of a complete, integrated system against its specified requirements. Related: Test Level, Integration Testing, Acceptance Testing.
T
Technical Debt The accumulated cost of shortcuts and compromises in design, code, or tests. Debt incurs “interest” as future changes become harder. Related: Refactoring, Maintainability.
Test Analysis ★ The activity of identifying test conditions by analysing the test basis. First step in the fundamental test process. Related: Test Basis, Test Condition.
Test Approach The implementation of the test strategy for a specific project, considering context, risk, and resources. Related: Test Strategy, Test Plan.
Test Automation ★ The use of software to perform or support test activities such as test management, test design, test execution, and results comparison. Related: Capture/Playback Tool, CI/CD. Plan your automation practice: see the CTAL-TAE v2.0 Study Guide.
Test Basis The body of knowledge used as the basis for test analysis and design. Could be requirements, specifications, designs, user stories, or code. Related: Test Analysis, Traceability.
Test Case ★ A set of preconditions, inputs, expected results, and postconditions that verify a specific behaviour. The atomic unit of formal testing. Example: Test Case: Login with valid credentials. Preconditions: active user. Inputs: valid email, valid password. Expected: redirect to dashboard, session created. Related: Test Condition, Test Procedure.
Test Charter A short statement of the goals of a test session, used in exploratory testing and session-based test management. Example: “Explore the checkout flow with invalid promo codes and observe validation and error handling.” Related: Exploratory Testing, SBTM.
Test Condition ★ An aspect of a test basis that is relevant to achieve specific test objectives. A condition is what to test; a test case is how. Related: Test Case, Coverage Item.
Test Control A test management activity that takes corrective action when test monitoring reveals variance from the plan. Related: Test Monitoring, Test Planning.
Test Data The inputs used to execute tests. Can be crafted, copied from production (with appropriate anonymisation), or generated. Related: Data-Driven Testing, Test Environment.
Test Data Preparation The activity of creating, collecting, selecting, and transforming test data.
Test Design ★ The activity of transforming test conditions into concrete test cases and test procedures. Related: Test Analysis, Test Implementation.
Test Design Technique A method used to derive or select test cases. ISTQB groups them as specification-based (black-box), structure-based (white-box), and experience-based. Related: Black-Box Testing, White-Box Testing.
Test-Driven Development (TDD) A development practice where the test is written before the code, then the code is written to make the test pass, then refactored. Red-Green-Refactor cycle. Related: Unit Testing, Shift-Left.
Test Environment The set of hardware, software, data, configurations, and tools required to execute a test. Separate from production. Related: Test Data, Entry Criteria.
Test Estimation Predicting the effort, duration, and cost of testing activities. Common methods: expert judgement, analogy-based, three-point. Related: Three-Point Estimation.
Test Execution ★ The activity of running tests and recording results. Can be manual or automated. Related: Test Case, Test Procedure.
Test Harness A framework that supports the execution of tests, typically providing drivers, stubs, and result comparison. Related: Driver, Stub, Test Automation.
Test Implementation The activity that prepares test cases for execution: creating test data, configuring environments, sequencing cases, setting up schedules. Related: Test Design, Test Execution.
Test Item The work product under test. Typically a component, subsystem, or system.
Test Level ★ A group of test activities organised and managed together: component, component integration, system, system integration, acceptance. Exam tip: Memorise the five test levels from CTFL v4.0 precisely. Questions frequently ask you to place an activity at the correct level. Related: Component Testing, System Testing, Acceptance Testing.
Test Log A chronological record of test execution activities and results. Related: Test Execution, Test Report.
Test Management ★ The planning, estimating, monitoring, controlling, and reporting of test activities. Related: Test Strategy, Test Plan. Preparing for CTAL-TM v3.0? See the Test Manager Study Guide.
Test Manager The person responsible for test management for a test level or project. May be called a QA lead, test lead, or similar title. Related: Test Management.
Test Monitoring ★ The collection of information about test progress against the plan, producing reports and dashboards. Related: Test Control, Test Metrics.
Test Objective A reason or purpose for designing and executing a test. Example: “verify that the password strength meter correctly flags weak passwords.” Related: Test Basis, Test Case.
Test Oracle See Oracle. The source used to decide whether the outcome of a test is correct.
Test Planning ★ The activity of producing a test plan: defining scope, approach, resources, schedule, entry and exit criteria, risks, and deliverables. Related: Test Strategy, Test Plan.
Test Procedure A document specifying the sequence of actions for executing a test, including any required data and environment setup. Related: Test Case, Test Script.
Test Progress Report A report produced during a test activity summarising status, metrics, and deviations from plan. Related: Test Monitoring, Test Summary Report.
Test Pyramid An automation design heuristic associated with Mike Cohn: many unit tests at the base, fewer integration tests in the middle, few end-to-end tests at the top. Related: Test Automation, Unit Testing.
Test Report A document summarising testing activities and results, produced for a specific audience. Related: Test Progress Report, Test Summary Report.
Test Session A time-boxed period of testing, especially in exploratory testing. Typically 60-120 minutes with a charter and debrief. Related: SBTM, Test Charter.
Test Strategy ★ A high-level description of the test levels to be performed, their objectives, and the overall approach. Usually defined at the organisation or programme level. Related: Test Approach, Test Plan.
Test Suite A set of test cases grouped for execution. Can be organised by feature, risk, priority, or test level. Related: Test Case.
Test Summary Report A report produced at the end of testing summarising activities, outcomes, and recommendations. Related: Test Report, Test Progress Report.
Test Technique See Test Design Technique.
Tester A person who performs testing. Can range from a developer running unit tests to a dedicated independent tester. Related: Independence of Testing.
Testability A maintainability sub-characteristic. The degree to which a system provides test hooks, observable state, and controllable inputs. Untestable code is rarely high-quality code. Related: Maintainability.
Testing ★ The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation, and evaluation of software products to determine they satisfy specified requirements, to demonstrate they are fit for purpose, and to detect defects. Exam tip: ISTQB’s formal definition is longer than you expect. Read it in the syllabus at least once. Related: Static Testing, Dynamic Testing.
Three-Point Estimation An estimation technique using optimistic (O), most likely (M), and pessimistic (P) values. PERT formula: Estimate = (O + 4M + P) / 6. Related: Test Estimation.
Traceability ★ The ability to link test artefacts back to their origins (requirements, risks, designs) and forward to their outcomes. Essential for impact analysis and regulatory compliance. Related: Impact Analysis, Test Basis.
Type 1 / Type 2 Error (Adv) Statistical terminology occasionally used in testing. Type 1 = false positive (reject when we should have accepted). Type 2 = false negative (accept when we should have rejected). Related: False-Fail Result, False-Pass Result.
U
Unit Testing See Component Testing. The two terms are synonymous in ISTQB.
Usability Testing Testing to determine the extent to which a product can be used by specified users to achieve specified goals effectively, efficiently, and satisfactorily. Related: Accessibility Testing, Heuristic Evaluation. See the CT-UT Usability Tester page.
Use Case A description of a sequence of interactions between an actor and a system to achieve a goal, including alternate and exception flows. Related: Use Case Testing, Scenario.
Use Case Testing ★ A black-box technique that derives test cases from use cases, covering the main flow and every alternate and exception flow. Related: Scenario-Based Testing, Black-Box Testing.
User Acceptance Testing (UAT) ★ Acceptance testing performed by end users to confirm that the system meets their business needs. Usually the last test level before release. Related: Acceptance Testing, OAT.
User Story ★ In Agile, a short description of a feature from the user’s perspective. Usually written as: “As a [role], I want [feature], so that [benefit].” Often paired with acceptance criteria. Example: “As a returning customer, I want to save my shipping address, so that I don’t re-enter it every time.” Related: Acceptance Criteria, Backlog, Scrum.
V
V-Model A sequential development lifecycle model pairing each development phase with a corresponding test level. Requirements with acceptance testing, architecture with system testing, and so on. Related: Waterfall, Test Level.
Validation ★ (!) Confirmation that the product meets the needs of the user and intended use. “Are we building the right product?” Exam tip: Validation = fit for purpose. Verification = built to spec. Memorise the contrast; it is the classic CTFL trap. Related: Verification, Acceptance Testing.
Verification ★ (!) Confirmation that a product meets its specified requirements. “Are we building the product right?” Related: Validation, Reviews, Static Testing.
Version Control A system for recording changes to files over time so that specific versions can be recalled. Example tools: Git, Subversion, Mercurial. Related: Configuration Management.
Volume Testing A non-functional test type that checks system behaviour with large volumes of data (records, files, storage). Related: Performance Testing, Scalability Testing.
Vulnerability (Security) A weakness in a system that could be exploited by a threat. The raw material of security testing. Related: Security Testing, Attack.
W
Walkthrough A review type led by the author, often informal, where the author guides participants through a work product to gather feedback. Less rigorous than inspection. Related: Formal Review, Inspection.
Waterfall Model A sequential development lifecycle with distinct phases (requirements, design, implementation, verification, maintenance). Testing is concentrated late in the cycle, which is both its defining feature and its weakness. Related: V-Model, Incremental Development.
White-Box Testing ★ Testing based on an analysis of the internal structure of the component or system. Also called structure-based testing. Example: Statement coverage, branch coverage, path coverage. Related: Structure-Based Testing, Code Coverage.
Commonly Confused Term Pairs (The Exam Traps)
Most CTFL candidates who fail do so because of these confusions, not because they did not study. Learn these six pairs cold.
1. Error vs Defect vs Failure vs Mistake
This is the single most tested concept on CTFL.
| Term | What It Is | Who Causes / Sees It |
|---|---|---|
| Mistake / Error | A human action that produces an incorrect result | A developer, analyst, designer |
| Defect / Fault / Bug | An imperfection in the work product | Exists in the code, dormant until executed |
| Failure | Observable deviation of actual from expected result | A user, tester, or monitoring system |
Chain: Mistake (human) → Defect (in artefact) → Failure (at runtime).
You can have a defect with no failure (dormant code). You cannot have a failure without a defect.
For the full discussion, see: Defect vs Failure vs Error vs Mistake: The ISTQB Distinctions Candidates Get Wrong.
2. Verification vs Validation
- Verification: Are we building the product right? (Against the spec.)
- Validation: Are we building the right product? (Fit for user need.)
Verification is usually static (reviews, walkthroughs, inspections). Validation is usually dynamic (testing against user needs, acceptance testing).
3. Re-Testing vs Regression Testing
- Re-Testing (Confirmation Testing): Run the specific test that failed, after the defect is fixed, to confirm the fix works.
- Regression Testing: Run a broader set of tests to ensure the fix did not break anything else.
Both are done for the same defect. Skipping either one is a mistake.
4. Severity vs Priority
- Severity: Technical impact of a defect. Set by the tester.
- Priority: Business urgency to fix it. Set by the product owner or business.
A spelling mistake on the homepage can be low severity and high priority. A crash in a feature nobody uses can be high severity and low priority.
5. Smoke Testing vs Sanity Testing
- Smoke Testing: Broad, shallow. Run on every new build to confirm stability.
- Sanity Testing: Narrow, deeper. Run after a specific bug fix or targeted change.
Some candidates are told these are the same thing. On the exam, treat them as distinct.
6. Load Testing vs Stress Testing
- Load Testing: Expected load. Does the system meet performance targets under realistic use?
- Stress Testing: Beyond capacity. Where does it break, and how does it fail?
Add soak (extended load) and spike (sudden surge) for the full performance family.
7. QA vs QC vs Testing
- Quality Assurance (QA): Preventive. Improves processes so fewer defects are introduced.
- Quality Control (QC): Detective. Finds defects in products.
- Testing: A QC activity. One important tool, not the whole discipline.
Confusing QA with testing is a career-long misconception, not just an exam trap.
8. Driver vs Stub
- Driver: Replaces a higher-level component that would call the unit under test.
- Stub: Replaces a lower-level component that the unit under test would call.
Mnemonic: Driver drives downward. Stub stands in shallow (or “stub sits below”).
High-Frequency Exam Terms (The Top 40)
If you are short on time, master these 40 terms before anything else. These are the terms that appear most often in CTFL v4.0 and Agile Tester (CTFL-AT) exams, based on pattern analysis of recent papers and syllabus emphasis.
- Acceptance Criteria
- Acceptance Testing
- Black-Box Testing (Specification-Based Testing)
- Boundary Value Analysis
- Branch Coverage (Decision Coverage)
- Component Testing
- Confirmation Testing (Re-Testing)
- Decision Table Testing
- Defect
- Definition of Done
- Dynamic Testing
- Entry Criteria
- Equivalence Partitioning
- Exit Criteria
- Experience-Based Testing
- Exploratory Testing
- Failure
- Formal Review
- Functional Testing
- Inspection
- Integration Testing
- Non-Functional Testing
- Oracle (Test Oracle)
- Product Risk
- Regression Testing
- Review
- Risk
- Risk-Based Testing
- State Transition Testing
- Statement Coverage
- Static Analysis
- Static Testing
- System Testing
- Test Case
- Test Condition
- Test Level
- Test Management
- Test Strategy
- Validation
- Verification
If all forty are second nature, you will handle a very large chunk of the CTFL paper on terminology alone.
Need targeted practice? The CTFL v4.0 Study Guide includes practice questions specifically on terminology and technique identification.
Suggested Study Order (The Smart Way to Memorise)
Memorising an alphabetical list end-to-end is inefficient. Your brain remembers concepts in chunks, not sorted by the letter they start with. Study in these seven waves:
Wave 1: The Foundational Chain (Day 1) Mistake / Error, Defect, Failure, Anomaly, Incident, Bug, Fault. If any of these are still fuzzy, nothing else will stick properly.
Wave 2: The Testing Verbs (Day 2) Testing, Static Testing, Dynamic Testing, Verification, Validation, Quality Assurance, Quality Control, Debugging.
Wave 3: The Test Levels and Types (Day 3) Component Testing, Integration Testing (both kinds), System Testing, Acceptance Testing, Functional Testing, Non-Functional Testing, Regression Testing, Re-Testing, Smoke Testing.
Wave 4: Specification-Based Techniques (Day 4) Equivalence Partitioning, Boundary Value Analysis, Decision Table Testing, State Transition Testing, Use Case Testing.
Wave 5: Structure-Based Techniques (Day 5) White-Box Testing, Statement Coverage, Branch / Decision Coverage, Cyclomatic Complexity, Path Coverage.
Wave 6: Test Management and Process (Day 6) Test Planning, Test Strategy, Test Approach, Entry Criteria, Exit Criteria, Test Basis, Test Condition, Test Case, Test Procedure, Test Monitoring, Test Control, Risk, Product Risk, Project Risk, Risk-Based Testing.
Wave 7: Reviews, Agile, and Tooling (Day 7) Review, Walkthrough, Inspection, Technical Review, Informal Review, Static Analysis, Agile, Scrum, Sprint, User Story, Definition of Done, Definition of Ready, Test Automation, CI / CD.
By the end of seven days, you will have revised every high-frequency term twice (once in its chunk, once in this list). That is when memorisation actually sticks.
Download the Printable ISTQB Glossary (PDF)
This page is a reference, but printed glossaries are better for offline review and for marking up during commutes.
Download the full ISTQB Glossary PDF (200+ terms, plain-English definitions, exam tips, confused pairs, study order).
The PDF is included in every ISTQB study-material package at ISTQB.Guru. Your download link will be sent to your email.
Keep Going: Next Steps by Exam
Vocabulary is necessary but not sufficient. To actually pass your ISTQB exam, you need full-syllabus study materials, practice questions with explanations, and realistic mock tests.
- ISTQB CTFL v4.0 (Foundation Level): CTFL v4.0 Study Guide · CTFL Certification Overview · Online CTFL Training
- CTFL-AT (Agile Tester): Agile Tester Study Guide · CTFL-AT Certification Overview
- CT-AI (AI Testing 2021): CT-AI Study Guide · AI Testing Certification Overview
- CT-GenAI (Generative AI, 2025): CT-GenAI Certification Overview · CT-AI vs CT-GenAI: Which to Take First
- CTAL-TA v3.1 (Advanced Test Analyst): CTAL-TA Study Guide · CTAL-TA v3.1 Overview · CTAL-TA v4.0 (NEW)
- CTAL-TM v3.0 (Advanced Test Manager): TM v3.0 Study Guide · CTAL-TM Overview
- CTAL-TAE v2.0 (Test Automation Engineer): TAE v2.0 Study Guide · CTAL-TAE Overview
- CTAL-TTA (Technical Test Analyst): CTAL-TTA Overview
- CTAL-ATT (Agile Technical Tester): CTAL-ATT Overview
- CT-ATLaS (Agile Test Leadership at Scale): CT-ATLaS Overview
- Specialist Exams: Performance Tester (CT-PT) · Security Tester (CT-SEC) · Usability Tester (CT-UT) · Mobile Tester (CT-MAT) · Model-Based Tester (CT-MBT) · Game Testing (CT-GaMe) · Automotive Software Tester (CT-AuT) · Acceptance Testing (CT-AcT) · Gambling Tester (CT-GT) · Test Automation Strategy (CT-TAS)
- All Exams in One Place: Study Materials for All ISTQB Exams
Related Reading
- Is the ISTQB Certification Worth It in 2026? An Honest Assessment for Different Career Stages
- 7 Reasons Candidates Fail the ISTQB CTFL Exam (and How to Avoid Them)
- How Hard Is the ISTQB CTFL v4.0 Exam? An Honest 2026 Difficulty Breakdown
- ISTQB CTFL v4.0 Syllabus Explained: A Chapter-by-Chapter Deep Dive
- Decision Tables, Equivalence Partitioning, and Boundary Value Analysis: The Three Test Techniques That Decide Your CTFL Exam
Final Word
Most candidates treat vocabulary as a chore that happens between “the real studying.” That is backwards. On the ISTQB exam, vocabulary is the real studying. The questions are designed to catch candidates who know the concept informally but cannot separate confusingly similar terms under time pressure.
Bookmark this page. Come back to it when a specific term trips you up during practice questions. Work through the commonly confused pairs until you cannot mix them up if you tried.
When the exam day comes and question 16 asks whether a defect caused a failure or an error caused a defect, you will not hesitate. That is when the time you invested here pays off.
Good luck with your ISTQB certification.