ISTQB Foundation Level Glossary
Summary
This glossary collects the key terms from the ISTQB Foundation Level syllabus in one place, with plain-language explanations rather than formal definitions. If you're working through the chapter guides on this site and come across a term you want a quick refresher on, this is the page to bookmark. Terms are organized alphabetically, with a note on which syllabus chapter introduces each one. This page currently covers terms from chapters 1 through 4. Terms from chapters 5 and 6 will be added as those chapter guides are published.
How to use this page
Every term that appears as a keyword at the start of a syllabus chapter is something you should be able to recall (K1 level) even if it is not called out specifically in that chapter's learning objectives. That makes this page useful both as a study aid while you're working through the chapters, and as a quick reference in the days before your exam, when you want to make sure you have not forgotten any of the core vocabulary.
This glossary does not try to replace the chapter guides. The definitions here are intentionally short. If a term feels unclear even after reading its definition here, the related chapter guide will have a fuller explanation with context and examples.
Chapter 5 and Chapter 6 terms, such as risk, entry criteria, exit criteria, defect report, test pyramid, testing quadrants, and test automation, are candidates for a future glossary update now that those chapter guides are available.
Glossary
Acceptance criteria (Chapter 4): The conditions a piece of software must meet for a user, customer, or other stakeholder to accept it. Used to scope user stories and to derive acceptance tests.
Acceptance testing (Chapter 2): The test level often performed last, focused on whether a system meets business and user needs before it is handed over.
All-states coverage (Chapter 4): A coverage criterion for state transition testing where every state in a state diagram is visited by at least one test.
All-transitions coverage (Chapter 4): A coverage criterion for state transition testing that includes both valid and invalid transitions, more thorough than valid-transitions coverage.
ATDD (Acceptance test-driven development) (Chapter 4): An approach where tests are derived from acceptance criteria before development begins, created collaboratively by testers, developers, and business representatives.
Black-box test technique (Chapter 4): A test design technique based on the test basis (requirements, specifications) without looking at the internal structure of the system.
Boundary value analysis (BVA) (Chapter 4): A test technique that focuses on the values at and around the boundaries between equivalence partitions, since defects are more common at boundaries.
Branch coverage (Chapter 4): A white-box coverage measure based on the percentage of decision outcomes (branches) in the code that have been exercised by tests.
Checklist-based testing (Chapter 4): An experience-based technique where testers design and execute tests to cover items on a checklist.
Confirmation testing (Chapter 2): Testing performed after a defect fix to confirm the original defect has been resolved, usually by re-running the test that originally found it.
Coverage (Chapter 1): The extent to which a specified set of items (such as requirements or code statements) has been exercised by a test suite, usually expressed as a percentage.
Debugging (Chapter 1): The activity of finding the cause of a failure (a defect), analyzing it, and fixing it. Distinct from testing, which finds failures but does not fix their causes.
Decision table testing (Chapter 4): A test technique that derives test cases from combinations of conditions and the actions that result from each combination.
Defect (Chapter 1): A flaw in a work product that can cause it to fail to perform as required. Also called a fault or a bug.
DevOps (Chapter 2): An organizational approach where development, operations, and often testing work together toward shared goals, with an emphasis on automation and fast feedback.
Equivalence partitioning (Chapter 4): A test technique that divides data into partitions where every value in a partition is expected to be processed the same way, so testing one value per partition is enough.
Error (Chapter 1): A human action that produces an incorrect result, which can lead to a defect. Also called a mistake.
Error guessing (Chapter 4): An experience-based technique where testers anticipate likely defects based on knowledge of common mistakes and past failures.
Exploratory testing (Chapter 4): An approach where test design, execution, and evaluation happen more or less simultaneously, with the tester learning about the system as they go.
Failure (Chapter 1): An event where a component or system does not perform as expected, often caused by a defect being triggered during execution.
Functional testing (Chapter 2): A test type focused on what a system does, checking functions against requirements or expected behavior.
Inspection (Chapter 3): The most formal type of review, with defined roles, entry and exit criteria, and a follow-up step to confirm defects were fixed.
Integration testing (Chapter 2): The test level focused on the interfaces and interactions between integrated components or systems.
Maintenance testing (Chapter 2): Testing triggered by modification, migration, or retirement of a system that is already in production.
Migration testing (Chapter 2): A type of maintenance testing that checks data and systems work correctly after being moved to a new environment.
Non-functional testing (Chapter 2): A test type focused on quality characteristics like performance, usability, reliability, and security, rather than specific functions.
Quality assurance (QA) (Chapter 1): A process-oriented, preventive approach focused on improving development and testing processes, on the basis that good processes lead to good products.
Regression testing (Chapter 2): Testing performed on unchanged parts of a system to check that a recent change has not broken previously working functionality.
Retrospective (Chapter 2): A workshop held at the end of a project, release, or iteration where the team reflects on what went well, what did not, and what to improve.
Review (Chapter 3): A static testing activity where a work product is examined by one or more people, with the aim of finding defects and improving quality.
Root cause (Chapter 1): The fundamental reason a problem occurred, identified through root cause analysis, often performed after a failure or defect is found.
Shift left (Chapter 2): The practice of moving testing activities earlier in the software development lifecycle, such as through reviews and test-first approaches.
State transition testing (Chapter 4): A test technique that derives test cases from a model of a system's states, the events that trigger transitions between states, and the resulting actions.
Statement coverage (Chapter 4): A white-box coverage measure based on the percentage of executable statements in the code that have been exercised by tests.
Static testing (Chapter 3): Testing that examines a work product (such as a document or code) without executing it, including reviews and static analysis.
System testing (Chapter 2): The test level focused on the overall behavior of a complete system, often covering both functional and non-functional characteristics.
Test analysis (Chapter 1): The test activity that identifies testable features and defines test conditions, answering the question "what to test?"
Test basis (Chapter 1): The body of knowledge (requirements, designs, user stories, and so on) used as the source for deriving test conditions and test cases.
Test case (Chapter 1): A set of preconditions, inputs, actions, expected results, and postconditions developed to cover a particular test objective or condition.
Test condition (Chapter 1): A testable aspect of a component, system, or its requirements, identified during test analysis.
Test design (Chapter 1): The test activity that elaborates test conditions into test cases and other testware, answering the question "how to test?"
Test execution (Chapter 1): The test activity where tests are run, results are compared to expected outcomes, and anomalies are logged.
Test level (Chapter 2): A group of test activities organized and managed together, representing an instance of the full test process applied to software at a particular stage (such as component, integration, system, or acceptance testing).
Test object (Chapter 1): The work product being tested.
Test objective (Chapter 1): A reason or purpose for designing and executing tests, such as finding defects or building confidence in quality.
Test type (Chapter 2): A group of test activities related to a specific quality characteristic, such as functional, non-functional, white-box, or change-related testing, which can apply across multiple test levels.
Testware (Chapter 1): Work products produced during the test process, such as test plans, test cases, test scripts, and test reports.
Traceability (Chapter 1): The ability to link test basis elements, testware, test results, and defects to each other, supporting coverage evaluation and impact analysis.
Validation (Chapter 1): Checking whether a system meets the needs of users and other stakeholders in its operational environment.
Verification (Chapter 1): Checking whether a system meets specified requirements.
White-box test technique (Chapter 4): A test design technique based on the internal structure of the test object, such as its code.
Last reviewed: June 2026.