ISTQB Glossary Explained: 50 Essential Software Testing Terms You Must Know

A strong understanding of ISTQB terminology is essential for anyone working in software testing, from new testers preparing for certification to experienced professionals collaborating in complex delivery environments. The ISTQB glossary standardizes the language of testing so that teams across organizations, industries, and geographies can communicate clearly and avoid ambiguity. When everyone uses the same terminology, conversations become more precise, documentation becomes more reliable, and testing processes become more consistent.

This first part of the two-post series covers the first 50 ISTQB glossary terms, focusing on foundational testing concepts, test levels, test types, design techniques, documentation, traceability, and the principles that guide structured QA work. Each term is explained in depth with practical relevance, ensuring you not only understand the definition but also how the concept is used in real projects and why ISTQB emphasizes it. By the end of Part 1, you will have a strong foundational vocabulary that supports better communication, better test design, and greater confidence in both professional and certification contexts.

1. Testing

Testing is the systematic activity of evaluating software to determine whether it meets specified requirements and behaves as expected. In ISTQB terminology, testing is not limited to execution, it also includes planning, analysis, design, environment setup, and reporting. Proper testing helps reveal defects early, reduce risks, and verify that software supports business needs. Testers do not prove the absence of defects, but they increase confidence in the product’s quality by uncovering hidden issues. In real-world projects, testing guides decisions on release readiness and overall product stability. For ISTQB exams, remember that testing is both a process and a lifecycle activity, not just running test cases.

2. Debugging

Debugging is the activity performed by developers to identify the root cause of a defect and implement a fix. ISTQB stresses that debugging and testing are distinct: testers discover failures, developers debug the underlying cause. Debugging requires technical analysis, log inspection, code tracing, and replication of failure conditions. In agile environments, debugging is tightly integrated into continuous development cycles, often supported by monitoring or automated alerts. Common exam confusion arises when candidates mix up “finding a defect” with “fixing a defect,” which ISTQB sees as entirely different responsibilities. Testers verify the fix later, but testers do not debug.

3. Quality

Quality refers to the degree to which a software product fulfills requirements and satisfies stakeholder expectations. ISTQB treats quality as both objective (measurable through tests) and subjective (user satisfaction). A system can meet documented requirements yet still fail user expectations due to poor usability or performance. Modern QA approaches define quality as a shared responsibility of the entire team, not just testers. Testing activities help measure quality, but quality is built through good design, engineering practices, and continuous feedback. In the exam, remember that quality is defined relative to requirements and needs, not perfection.

4. Defect (Bug)

A defect is a flaw in a component or system that may cause the software to behave incorrectly or fail under specific conditions. In ISTQB terms, a defect originates from human error during development or requirement creation. Defects may remain hidden until triggered by tests or real user actions. Teams categorize defects by severity, priority, and root cause to manage them efficiently. In practice, defects guide improvements in processes, coding standards, and requirement clarity. On the exam, remember that a defect is the cause, and a failure is the observable effect.

5. Error (Human Mistake)

An error is a human action that produces an incorrect result, such as writing wrong logic, misunderstanding requirements, or misconfiguring environments. Errors are the root causes of defects, which later lead to failures when executed. ISTQB highlights that errors occur across all roles: analysts, developers, testers, designers, DevOps engineers. Understanding error patterns helps teams implement preventive measures such as pair programming, reviews, and static analysis. In exam questions, remember: Error → Defect → Failure is the lifecycle chain ISTQB wants you to understand.

6. Failure

A failure is the actual incorrect behavior of a system during execution. Failures occur when defects are triggered by certain inputs, environments, or operations. Not all defects result in failures immediately; some remain dormant until specific scenarios activate them. Operational failures in production often cost far more than failures caught during testing, which is why risk-based testing is essential. Failures also inform release decisions and severity assessment. On ISTQB exams, failure is always the observable deviation, not the hidden cause.

7. Test Case

A test case is a detailed specification of inputs, conditions, and expected results designed to verify a particular aspect of system behavior. ISTQB emphasizes that a high-quality test case is traceable to requirements, reproducible, clear, and measurable. A test case helps testers determine whether a component functions correctly under defined circumstances. In real-world teams, test cases support repeatability, automation, and regulatory requirements. Writing good test cases also uncovers requirement gaps or ambiguous acceptance criteria. On the exam, remember that test cases represent “what to test,” not “how to test” (that is defined by the test procedure).

8. Test Procedure

A test procedure describes the sequence of actions required to execute one or more test cases. It specifies step-by-step instructions, preconditions, data requirements, and post-execution steps. In automation frameworks, test procedures translate into scripts or workflows executed by tools. ISTQB expects candidates to distinguish between test case design and test procedure execution, which is a common exam trick. Test procedures ensure consistency across testers and executions, especially in regulated or high-stakes industries. In real practice, procedures are crucial when training new testers or maintaining audit trails.

9. Test Data

Test data refers to all input values and environmental conditions required to execute test cases. ISTQB highlights that test data must be realistic, complete, and aligned with business scenarios to ensure meaningful test results. Poor test data selection often leads to missed defects or invalid results. Testers may generate data manually, pull it from production clones, or use data-generation tools. Data privacy regulations such as GDPR or HIPAA require teams to mask or anonymize production data. On the ISTQB exam, remember that test data is separate from the environment itself but is necessary for execution.

10. Test Environment

A test environment includes the hardware, software, configurations, data, networks, and tools needed to execute tests. ISTQB defines it as the controlled setup where tests are conducted, often mirroring production for accurate results. Many defects arise due to incorrect or incomplete test environments, making environment management a critical part of QA processes. Modern teams rely on containerization and cloud environments for scalable, repeatable setups. Environment stability affects test reliability, automation success, and defect reproduction. In exam scenarios, remember that environment issues can block or invalidate test executions.

11. Unit Testing

Unit testing focuses on verifying individual components, functions, or methods in isolation. ISTQB defines a “unit” as the smallest testable part of the system, usually written and executed by developers. These tests ensure that the logic inside each component works correctly before integration with other parts. Automating unit tests is a common practice in modern development because it provides immediate feedback whenever code changes occur. Strong unit testing reduces downstream defects, accelerates debugging, and supports continuous integration pipelines. For exam purposes, remember that unit testing is structural, often white-box based, and performed at the earliest stage of testing.

12. Integration Testing

Integration testing evaluates how components or systems interact with each other once unit testing is complete. ISTQB highlights that integration can occur incrementally, such as top-down, bottom-up, or using a hybrid approach. The focus shifts from internal logic to interface correctness, data exchange, and communication patterns between modules. Common issues discovered at this level include mismatched data formats, incorrect API interactions, or flawed sequence flows. Teams often use stubs and drivers to simulate missing components during early integration. In the exam, remember that integration testing verifies interactions, not individual module behavior.

13. System Testing

System testing examines the complete, integrated system to verify that it meets functional and non-functional requirements. ISTQB classifies this as a high-level, black-box testing activity because the entire system behaves as a user would see it. This level checks end-to-end workflows, performance characteristics, security behaviors, and usability. System testing requires a stable environment that closely mirrors production to generate reliable results. It is often executed by a dedicated QA team rather than developers. For ISTQB candidates, system testing validates the system as a whole, not its individual components.

14. Acceptance Testing

Acceptance testing determines whether the software is ready for release by validating it against user needs and business requirements. ISTQB states that acceptance criteria guide the scope of these tests, ensuring the system behaves exactly as stakeholders expect. This level represents the final checkpoint before deployment, making it crucial for business validation. Acceptance testing includes functional checks, usability evaluation, workflow validation, and domain-specific scenarios. End users or product owners often participate in this process, ensuring that real-world expectations are met. In ISTQB terminology, acceptance testing is a form of validation, answering the question, “Are we building the right product?”

15. Alpha Testing

Alpha testing is conducted by internal teams or selected users in a controlled environment before the product is released to a wider audience. ISTQB treats alpha testing as a type of acceptance testing focused on uncovering usability issues, incomplete features, or stability risks early. It is especially common in commercial software products, games, or consumer applications where early feedback is valuable. Alpha testers simulate real user interactions but with close monitoring and developer support. Defects found during alpha testing help refine the product before beta testing. In exam contexts, alpha testing occurs internally, not in a live environment.

16. Beta Testing

Beta testing involves releasing the product to external users in a real-world environment to gather insights about usability, performance, and unexpected behaviors. ISTQB describes beta testing as an operational acceptance activity where real customers interact with the system in their natural environments. This helps reveal defects that controlled environments fail to detect, such as device-specific issues or edge-case workflows. Feedback from beta users shapes the final product improvements before the official launch. Beta testing also validates support readiness, documentation quality, and overall user satisfaction. For ISTQB exams, remember: beta testing is conducted externally and under real operating conditions.

17. Component Testing

Component testing (also known as module testing) focuses on verifying the functionality of individual modules, similar to unit testing but often performed at a slightly higher level. ISTQB differentiates it by emphasizing functional behavior rather than code-level logic. Component testing aims to ensure each module meets specified requirements before integration with other modules. Testers may use black-box, white-box, or gray-box techniques depending on visibility into the component. Common issues found include incorrect calculations, missing validations, or interface handling errors. For exam clarity, component testing validates modules as standalone units before combining them.

18. Component Integration Testing

Component integration testing evaluates interactions between integrated modules to ensure they work correctly as a combined unit. ISTQB places strong emphasis on the interfaces—data flow, APIs, message passing, and dependency relationships. This level typically detects errors such as mismatched data formats, incorrect API calls, and sequence issues that unit or component testing would not reveal. Component integration testing is performed after component testing and before system testing. Stubs or drivers may still be required if some components are not yet available. In exam questions, remember that this testing verifies module-to-module interactions, not the full system.

19. System Integration Testing

System integration testing focuses on combining independent systems or subsystems and verifying end-to-end communication across them. ISTQB describes this level as validating interactions between larger components such as third-party services, databases, payment gateways, or enterprise modules. This testing often uncovers issues like incompatible protocols, authentication failures, or data consistency problems across distributed systems. System integration testing requires controlled test environments that simulate real production infrastructure. Teams often rely on tools that mimic external systems to avoid dependency issues. For the exam, note that this level tests interactions between systems, not within them.

20. Operational Acceptance Testing (OAT)

Operational acceptance testing ensures the system is ready for deployment from an operational perspective. ISTQB highlights that this testing verifies backup processes, installation and upgrade procedures, disaster recovery, monitoring readiness, and maintainability. OAT focuses less on functionality and more on system stability, operability, and support readiness. DevOps teams, system administrators, or operations engineers typically execute these tests. Weaknesses uncovered during OAT can delay deployment because they directly affect business continuity. In the ISTQB exam, operational acceptance validates “production readiness,” not user functionality.

21. Functional Testing

Functional testing verifies that the system performs its intended functions according to documented requirements or business expectations. ISTQB classifies it as a black-box approach because the focus lies on observable behavior rather than internal code. Testers check features, workflows, calculations, validations, and system responses to various inputs. This type of testing ensures that each functional requirement is testable and correctly implemented. Functional testing often reveals requirement gaps or ambiguity, prompting clarification with business stakeholders. For exam purposes, functional testing answers the question, “Does the system do what it is supposed to do?”

22. Non-Functional Testing

Non-functional testing evaluates how well the system performs rather than what it does. ISTQB includes aspects such as performance, scalability, usability, security, reliability, and portability in this category. These qualities determine user satisfaction and operational stability even when functional requirements are met. Non-functional defects can severely impact user experience—for example, a perfectly functional app that loads slowly may still fail in the market. Teams often use specialized tools and environments for non-functional testing because results depend on accurate simulation of user load and conditions. On the exam, remember that non-functional testing focuses on quality attributes, not feature behavior.

23. Performance Testing

Performance testing measures how fast and stable a system behaves under various conditions. ISTQB describes it as evaluating responsiveness, throughput, resource use, and reliability. This helps identify bottlenecks such as slow APIs, inefficient queries, or memory leaks long before customers encounter them. Performance tests simulate real or expected workloads to validate that the system can meet performance-related service-level agreements (SLAs). Specialized tools like JMeter, LoadRunner, or Gatling are commonly used for this purpose. For ISTQB understanding, performance testing checks speed and stability but does not necessarily push the system to extremes (which would be stress testing).

24. Load Testing

Load testing assesses how the system performs under expected user or transaction loads. ISTQB distinguishes it from performance testing by emphasizing “expected” rather than extreme loads. This ensures that the system can handle typical usage patterns without degradation in response time or stability. Load testing also helps teams plan infrastructure capacity, optimize code paths, and validate scalability. Monitoring during load tests often reveals issues such as slow database queries or resource exhaustion. In the exam context, load testing evaluates performance under normal operating conditions.

25. Stress Testing

Stress testing pushes the system beyond its normal operating limits to identify breaking points and assess resilience. ISTQB highlights that stress testing helps determine how the system behaves under extreme or unexpected load conditions. This is important for uncovering vulnerabilities such as crashes, memory leaks, or performance degradation under pressure. Stress testing is especially critical in domains with unpredictable spikes, such as ecommerce during sales events or ticketing systems during launches. Teams use stress test results to strengthen system robustness and improve graceful failure handling. For ISTQB exams, stress testing examines system behavior under excessive load, not expected conditions.

26. Security Testing

Security testing evaluates the system’s ability to protect data, resist attacks, and prevent unauthorized access. ISTQB classifies it as a key non-functional area critical for risk mitigation. Security testing includes identifying vulnerabilities, evaluating authentication and authorization mechanisms, and validating data protection controls. Common issues uncovered include SQL injection, insecure APIs, weak password policies, or session management flaws. Modern development cycles integrate security testing into CI/CD pipelines through automated scanning and penetration testing. In ISTQB terminology, security testing ensures confidentiality, integrity, and availability of the system.

27. Usability Testing

Usability testing assesses how easy and intuitive it is for users to interact with the system. ISTQB emphasizes factors such as learnability, satisfaction, efficiency, and error prevention. Real users or UX evaluators observe how individuals navigate through tasks, interpret screens, and respond to interface designs. Poor usability often leads to customer dissatisfaction even if functional behavior is correct. Usability findings frequently influence design improvements, accessibility fixes, and workflow redesigns. For exam clarity, usability testing evaluates user experience, not functional correctness.

28. Compatibility Testing

Compatibility testing determines whether the system works correctly across different environments, such as browsers, operating systems, devices, or networks. ISTQB notes that compatibility issues often occur because users have diverse configurations that the system must support. This testing includes verifying rendering, performance, feature accessibility, and integration across environments. For web or mobile applications, compatibility testing prevents issues like misaligned layouts or broken functionality on certain browsers. Automation and cloud device farms are commonly used to expand coverage efficiently. On the exam, compatibility testing checks coexistence and interoperability across platforms.

29. Regression Testing

Regression testing ensures that recent changes—such as bug fixes, enhancements, or refactoring—have not introduced new defects. ISTQB considers regression testing a critical activity for maintaining system stability throughout the software lifecycle. Regression tests focus on previously working functionality, confirming that updates did not break existing behavior. Automation plays a key role here because regression suites are executed frequently, sometimes multiple times per day in CI pipelines. In practice, regression testing reduces risk and increases confidence in continuous delivery. For exam purposes, regression testing verifies unchanged functionality after modifications.

30. Smoke Testing

Smoke testing provides a quick, high-level check to determine whether the system’s basic functions work well enough to proceed with deeper testing. ISTQB explains smoke testing as a build verification activity performed after new builds or deployments. These tests are intentionally shallow, covering critical functionality such as login, dashboard access, or major workflows. If smoke tests fail, there is no point in running detailed or expensive test suites because the build is unstable. Development and QA teams rely on smoke testing to detect major errors early and prevent wasted testing effort. For ISTQB candidates, smoke testing ensures build stability before full testing begins.

31. Black-Box Testing

Black-box testing evaluates a system’s behavior based solely on inputs and expected outputs without considering the internal code structure. ISTQB emphasizes that this technique is used to validate functional and non-functional requirements from the user’s perspective. Testers focus on how the system responds under different conditions rather than how it processes data internally. Black-box testing helps uncover issues like incorrect calculations, missing validations, or unexpected behavior triggered by specific inputs. Because it mirrors real user scenarios, it is often used at higher test levels such as system or acceptance testing. In the ISTQB exam, remember that black-box techniques are requirement-based, not code-based.

32. White-Box Testing

White-box testing examines the internal structure, logic, and code pathways of a component. ISTQB explains that testers or developers use knowledge of the code to design tests that ensure specific paths, branches, and conditions are executed. This technique uncovers issues such as unreachable code, incorrect logic paths, untested branches, and missing error handling. White-box testing is frequently performed at the unit level, although it can apply at higher levels when code visibility is available. Coverage metrics such as statement coverage or decision coverage help measure completeness. On the exam, white-box testing is always structural, code-based testing, not behavioral testing.

33. Gray-Box Testing

Gray-box testing blends elements of both black-box and white-box approaches. Testers have partial knowledge of the internal structure but still evaluate the system based on functional behavior. ISTQB points out that gray-box testing improves test efficiency because testers can design more targeted scenarios based on architecture, interfaces, or data flows. This technique is especially useful in integration testing, API testing, and security validation. Gray-box testers can uncover issues that purely black-box testing might miss, such as hidden dependencies or data flow problems. For the exam, gray-box testing combines structural awareness with behavioral evaluation.

34. Boundary Value Analysis (BVA)

Boundary value analysis focuses on testing values at or near the edges of input ranges where defects are most likely to occur. ISTQB teaches that software often behaves unpredictably at boundaries due to logic errors, off-by-one mistakes, or incorrect comparisons. Testers identify minimum, maximum, just-below, and just-above values to fully examine system behavior. For example, if an input range is 1–100, BVA tests 0, 1, 2, 99, 100, and 101. This technique reduces the number of test cases while maximizing defect discovery. BVA is heavily tested in ISTQB exams, often paired with equivalence partitioning.

35. Equivalence Partitioning (EP)

Equivalence partitioning divides input data into groups (partitions) expected to behave similarly so testers can select representative values. ISTQB highlights that each partition should yield the same outcome, meaning if one value works, all others in that partition should behave the same. Partitions may be valid (accepted by the system) or invalid (rejected by the system). This technique helps reduce redundant testing while maintaining comprehensive coverage. For example, an age field accepting 18–60 forms valid partitions within range and invalid partitions below or above it. In the exam, EP is often used to design minimal but effective test sets.

36. Decision Table Testing

Decision table testing models combinations of conditions and outcomes in a structured table format. ISTQB explains that this technique is ideal for complex business rules where multiple inputs influence the output. Testers create tables that map conditions to actions, allowing systematic evaluation of every combination. Decision tables help uncover logic errors such as missing rules, conflicting rules, or inconsistent behavior. This method is widely used in financial systems, insurance platforms, or compliance-driven applications where rules are critical. In ISTQB exams, decision table questions test your ability to interpret combinations and derive correct test cases.

37. State Transition Testing

State transition testing evaluates how a system behaves as it moves between different states based on events or conditions. ISTQB highlights that many systems—such as login modules, workflows, or devices—behave differently depending on their current state. Testers design scenarios that cover valid transitions, invalid transitions, and edge cases such as repeated events. For example, an ATM behaves differently in “Card Inserted,” “Pin Entered,” or “Transaction Complete” states. State transition diagrams and tables help testers visualize behavior patterns and identify missing or incorrect transitions. This technique frequently appears in exam questions involving state machines.

38. Use Case Testing

Use case testing focuses on validating user interactions and end-to-end scenarios defined in use case documents. ISTQB considers use cases a powerful way to connect requirements to testing since they describe how users achieve specific goals within the system. Testers use use case flows—basic, alternative, and exception—to derive realistic, workflow-driven test cases. This method ensures the system supports real-world processes, not just isolated functions. Use case testing is heavily used in system and acceptance testing because it emphasizes business value and user experience. In the exam, use case testing is classified as a black-box, scenario-based technique.

39. Exploratory Testing

Exploratory testing involves simultaneous learning, test design, and execution. ISTQB describes it as a flexible, adaptive approach where testers rely on domain knowledge, creativity, and intuition to discover defects. Exploratory testing is especially useful when requirements are incomplete, rapidly changing, or ambiguous. Testers document insights, unexpected behaviors, and new test ideas as they explore the system. Session-based test management is often used to maintain structure while allowing freedom of exploration. For ISTQB exams, remember that exploratory testing is not random—it is intentional, guided, and based on experience.

40. Error Guessing

Error guessing is a test design technique where testers use past experiences, intuition, and domain knowledge to anticipate where defects are likely to occur. ISTQB highlights that experienced testers often identify weak points—such as complex logic, boundary conditions, or recent code changes—based on patterns they have seen before. Error guessing complements formal techniques by targeting areas that might otherwise be overlooked. Common examples include testing empty fields, invalid formats, sequence issues, or unexpected user actions. It requires skill and judgment, making it more subjective than structured methods. In the exam, error guessing is always based on experience, not documentation.

41. Test Basis

The test basis refers to all sources of information that testers use to design test cases, such as requirements, user stories, specifications, wireframes, contracts, or risk analyses. ISTQB emphasizes that high-quality testing depends on having clear, accessible, and accurate test basis documents. When the test basis is weak or incomplete, testers often discover requirement gaps or interpret requirements incorrectly, which leads to missing tests or invalid assumptions. Identifying ambiguities in the test basis is itself a valuable contribution because it prevents misunderstandings downstream. During planning, teams verify that the test basis is stable enough to begin formal test design. For exam purposes, the test basis is the foundation from which tests are derived.

42. Test Condition

A test condition is anything that can be tested within the system, including functions, features, constraints, interfaces, or specific data states. ISTQB highlights that identifying test conditions early helps testers organize coverage and determine what needs verification. Conditions serve as mid-level test design elements—more detailed than requirements but higher-level than test cases. For example, a login requirement may yield conditions such as “valid username,” “invalid password,” “session timeout,” or “account locked.” Test conditions help create traceability between requirements and test cases. In ISTQB exams, test conditions represent “what to test,” not the exact steps of how to test it.

43. Test Charter

A test charter defines the mission and scope for exploratory testing sessions. ISTQB states that a charter outlines what areas to explore, objectives to achieve, risks to investigate, and resources required. Charters ensure exploratory testing remains structured, measurable, and aligned with project goals, rather than purely ad hoc. Teams often create multiple charters representing different modules, risks, or functionalities to avoid gaps in coverage. After execution, testers document insights, unexpected behavior, and follow-up test ideas tied to the charter. On the exam, remember that charters guide exploratory testing but do not prescribe detailed steps like scripted test cases.

44. Test Plan

A test plan is a document describing the scope, approach, schedule, resources, risks, metrics, and deliverables for testing activities. ISTQB defines it as the central document that ensures everyone understands what will be tested, how it will be tested, and who is responsible. Test planning aligns testing goals with business priorities and ensures that test activities integrate smoothly with development and release timelines. A strong test plan anticipates challenges such as environment constraints, staffing limitations, or risk-prone areas. Modern agile teams may create lightweight living test plans, but traditional projects often require detailed, formal versions. On the exam, remember that test plans control testing activities, whereas test strategy defines the organizational approach.

45. Test Strategy

A test strategy outlines the overall testing approach at an organizational or project level. ISTQB considers it a high-level document that sets principles for how testing will be performed, including test levels, test types, environments, tools, metrics, risk management, and quality standards. Unlike the test plan—which is project-specific—the strategy provides a consistent framework across teams, ensuring uniformity in testing practices. Well-defined strategies help teams choose appropriate techniques, automation approaches, and coverage expectations. In real-world settings, the test strategy directly influences planning, estimations, and resource allocation. For ISTQB, remember that test strategy is organizational and long-term, whereas test plan is project-specific.

46. Test Summary Report

A test summary report provides a formal evaluation of the testing performed, summarizing results, coverage, defects found, quality assessment, and overall readiness for release. ISTQB states that this report communicates key findings to stakeholders, helping them make informed decisions about deployment. The summary highlights what was tested, what remains untested, and any residual risks that could impact production. This document is especially important in regulated industries, contractual projects, or large enterprise releases where traceability is required. It also records lessons learned and recommendations for future testing cycles. On the exam, the summary report represents final test closure activities.

47. Traceability

Traceability ensures that every requirement is linked to corresponding test conditions, test cases, and defects. ISTQB explains that traceability provides confidence that testing coverage is complete and aligned with requirements. There are two forms: forward traceability (from requirements to tests) and backward traceability (from tests back to requirements). Traceability helps teams analyze the impact of requirement changes and identify untested or redundant areas. Tools like Jira, Azure DevOps, and TestRail often support automated traceability mapping. In exam questions, traceability always refers to coverage and alignment between requirements and tests.

48. Coverage

Coverage measures the extent to which testing has exercised requirements, code, or other test bases. ISTQB highlights different coverage types, including requirements coverage, code coverage, condition coverage, and decision coverage. Higher coverage increases confidence in software quality, though 100 percent coverage does not guarantee defect-free software. Coverage metrics help identify gaps by showing which areas of a system have not been tested. They also guide prioritization and risk analysis when time or resources are limited. For ISTQB exams, coverage is always a measurable metric, not a qualitative observation.

49. Acceptance Criteria

Acceptance criteria define the conditions that must be met for a requirement or user story to be considered complete. ISTQB notes that acceptance criteria reduce ambiguity by specifying expected behavior before development begins. They guide test case design, support user acceptance testing, and act as shared alignment between testers, developers, and product owners. Well-written acceptance criteria help identify edge cases early, preventing misunderstandings during development. Agile teams commonly express acceptance criteria in formats like Given-When-Then. In ISTQB exams, acceptance criteria belong to the test basis and guide acceptance testing.

50. Test Oracle

A test oracle is the source of truth against which the tester compares actual results. ISTQB describes oracles as anything that provides expected outcomes—requirements, user manuals, algorithms, domain knowledge, or even existing system behavior. A reliable oracle ensures that testers can determine whether observed behavior is correct or defective. When oracles are incomplete or ambiguous, testers must validate assumptions with domain experts, which increases testing complexity. Automated testing also requires oracles, either coded or data-driven, to verify outcomes. On the exam, remember that the test oracle defines expected results, not how tests are executed.

The first 50 ISTQB terminology concepts form the backbone of professional test analysis, planning, design, and execution. These terms frame how testers think, how they communicate with development teams, and how they structure their work throughout the software lifecycle. Whether you are preparing for ISTQB exams or strengthening your day-to-day QA responsibilities, mastering these terms ensures that testing activities are aligned with industry standards and executed with clarity and consistency.

In the second and final part of this series, we will explore the remaining 50 terms, covering risk-based testing, execution workflows, incident and defect management, automation concepts, Agile and DevOps testing practices, and the tools that support modern QA teams. Together, both posts create a complete, authoritative reference that you can rely on throughout your testing career.