ISTQB Certified Tester Foundation Level (CTFL) v4.0.1 Vocabulary

Comprehensive vocabulary flashcards covering fundamental software testing concepts, SDLC integration, static testing, black-box, white-box, experience-based test techniques, test management, risk analysis, and test tools from the ISTQB Certified Tester Foundation Level Syllabus v4.0.1.

Software Testing

A set of activities to discover defects and evaluate the quality of software work products.

Test Object

The software work product that is being evaluated through testing.

Verification

The activity of checking whether a software system or work product meets specified requirements.

Validation

The activity of checking whether a software system meets users' and other stakeholders' needs in its operational environment.

Debugging

A non-testing development activity concerned with finding the causes of a failure (defects), analyzing these causes, and eliminating them, or removing defects discovered directly by static testing.

Quality Assurance (QA)

A process-oriented, preventive approach that focuses on the implementation and improvement of processes based on the principle that following a good process generates a good product.

Error

A human mistake or action that produces a defect in a work product.

Defect

An imperfection, fault, or bug in a work product (such as requirements, code, or build files) where it does not meet its specification, which may cause a failure if executed.

Failure

An event in which a component or system fails to do what it should do, or does something it shouldn't, caused by the execution of a defect or by environmental conditions.

Root Cause

A fundamental reason for the occurrence of a problem (e.g., a situation that leads to an error), which can be removed or addressed to prevent recurrence of similar defects and failures.

Absence-of-Defects Fallacy

The testing principle stating that thoroughly verifying requirements and fixing all defects does not guarantee system success if the software does not fulfill users' needs, expectations, or business goals.

Defect Clustering

The testing principle illustrating the Pareto principle, stating that a small number of system components usually contain most of the defects discovered or cause most operational failures.

Test Analysis

The test activity that analyzes the test basis to identify testable features, define and prioritize test conditions, and answer the question 'what to test?' in terms of measurable coverage criteria.

Test Design

The test activity that elaborates test conditions into test cases and other testware, defines test data requirements, designs test environments, and answers the question 'how to test?'.

Test Implementation

The test activity that creates or acquires the testware necessary for execution (such as test data, test procedures, test suites, and scripts) and prepares the test environment.

Test Execution

The test activity that involves running manual or automated tests according to the execution schedule, comparing actual outcomes with expected outcomes, and logging results and anomalies.

Test Completion

The test activity occurring at project milestones (e.g., release or iteration end) to collect data, archive testware, shut down test environments, document lessons learned, and issue a completion report.

Testware

Work products created as outputs of test activities, including test plans, test conditions, test cases, test charters, test scripts, test data, test logs, and test reports.

Traceability

The established relationship between elements of the test basis, testware, test results, and defects, used to assess coverage, evaluate residual risk, and determine the impact of changes.

Whole Team Approach

An Extreme Programming practice where any team member with the necessary knowledge and skills can perform any task, and everyone on the team shares responsibility for quality.

Independence of Testing

The degree of organizational separation between testing personnel and the author of the work product, ranging from no independence (author testing) to very high independence (external testers).

Shift Left

An approach that involves performing testing activities earlier in the software development lifecycle (e.g., specification reviews, writing tests before code) to detect defects sooner and save rework costs.

Test-Driven Development (TDD)

A test-first development approach where tests are written first to direct coding, the code is implemented to satisfy the tests, and both are subsequently refactored.

Behavior-Driven Development (BDD)

A development practice where application behavior is defined through test cases written in natural language understandable by all stakeholders, usually following the Given/When/Then format.

DevOps

An organizational approach aimed at creating synergy by getting development (including testing) and operations to collaborate through practices like Continuous Integration (CI) and Continuous Delivery (CD).

Retrospective

A meeting held at project or iteration milestones where participants reflect on what went well, what could be improved, and how to incorporate those improvements into future work.

Component Testing

A test level focusing on testing individual software components in isolation, typically executed by developers in their development environments (also called unit testing).

Component Integration Testing

A test level focusing on the interfaces and interactions between software components (also known as unit integration testing).

System Testing

A test level that evaluates the overall behavior and capabilities of an entire integrated system or product, covering functional end-to-end tasks and non-functional quality characteristics.

System Integration Testing

A test level focusing on interactions and interfaces between the system under test, other external systems, and third-party services.

Acceptance Testing

A test level focusing on validation to demonstrate readiness for deployment and confirm that the system meets user business requirements.

Functional Testing

A test type that evaluates 'what' the system should do by checking functional completeness, functional correctness, and functional appropriateness against requirements.

Non-Functional Testing

A test type that evaluates 'how well' a system behaves by assessing attributes such as performance efficiency, compatibility, usability, reliability, security, maintainability, portability, and safety.

Black-Box Testing

Specification-based testing derived from documentation not related to the internal structure of the test object, evaluating behavior against specifications.

White-Box Testing

Structure-based testing derived from the implementation or internal structure of the system (such as code, architecture, or data flows) to achieve coverage of internal paths.

Confirmation Testing

Testing performed specifically to verify that a reported defect has been successfully resolved (re-testing).

Regression Testing

Testing performed to verify that a code change or defect fix has not introduced adverse side effects or new defects into unchanged parts of the software or environment.

Maintenance Testing

Testing triggered by modifications (enhancements, bug fixes), upgrades/migrations of the operational environment, or system retirement to evaluate changes and prevent regressions.

Static Testing

The manual examination of software work products (e.g., reviews) or tool-driven evaluation (static analysis) without executing the code.

Static Analysis

The assessment of work products with a formal syntax (such as code or models) using automated tools without executing the software to identify defects, security vulnerabilities, or maintainability issues.

Informal Review

A review type that does not follow a defined process and does not require formal documented output, primarily used to detect anomalies.

Walkthrough

A review type led by the author to evaluate work product quality, educate reviewers, gain consensus, generate ideas, and detect anomalies.

Technical Review

A review conducted by technically qualified peers and led by a moderator to resolve technical problems, make decisions, evaluate quality, and detect anomalies.

Inspection

The most formal type of review, following a complete defined process with rules, checklists, metrics collection, and entry/exit criteria, led by a trained moderator, where the author cannot act as leader or scribe.

Equivalence Partitioning (EP)

A black-box test technique that divides input or output data into valid and invalid partitions based on the assumption that all members of a partition will be processed identically by the test object.

Boundary Value Analysis (BVA)

A black-box test technique based on exercising the minimum and maximum boundaries of ordered equivalence partitions, using either 2-value or 3-value approaches per boundary.

Decision Table Testing

A black-box test technique that uses a tabular format of conditions and resulting actions to systematically test complex business rules and combinations of inputs.

State Transition Testing

A black-box test technique based on a state diagram or state table that verifies valid transitions, states, and invalid transition handling triggered by events under specific guard conditions.

Statement Testing

A white-box test technique where coverage items are executable statements, aiming to design test cases that execute statements in the code until an acceptable coverage percentage is reached.

Branch Testing

A white-box test technique where coverage items are branches (transfers of control in the control flow graph), which inherently subsumes statement coverage.

Error Guessing

An experience-based test technique used to anticipate the occurrence of errors, defects, and failures based on the tester's past knowledge and typical developer mistakes.

Exploratory Testing

An experience-based test technique where test design, execution, and logging are performed concurrently as the tester explores the test object, often guided by a test charter within a time-boxed session.

Checklist-Based Testing

An experience-based test technique where tests are designed and executed to cover conditions or questions derived from a checklist based on experience or defect history.

3 C's

The three critical aspects of an Agile user story: Card (physical or digital description), Conversation (dialogue explaining software use), and Confirmation (acceptance criteria).

INVEST

A mnemonic describing the qualities of a good user story: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Acceptance Criteria

The conditions that an implementation of a user story must satisfy to be accepted by stakeholders, acting as test conditions for acceptance tests.

Acceptance Test-Driven Development (ATDD)

A collaborative test-first approach where team members (business, developer, tester) define acceptance tests based on user story acceptance criteria prior to code implementation.

Test Plan

A document describing the context, test objectives, test approach, resources, schedule, entry/exit criteria, and risk register for a testing project.

Entry Criteria

The set of precondition criteria (e.g., availability of testware, passing smoke tests) that must be satisfied before undertaking a specific testing activity (referred to as Definition of Ready in Agile).

Exit Criteria

The set of conditions (e.g., coverage targets, defect thresholds) that must be fulfilled to declare a test activity or level complete (referred to as Definition of Done in Agile).

Wideband Delphi

An expert-based, iterative estimation technique where experts provide isolated estimates, review deviations, discuss results, and re-estimate until reaching consensus (e.g., Planning Poker).

Three-Point Estimation

An estimation technique where experts provide the optimistic ($a$), most likely ($m$), and pessimistic ($b$) values, with the final estimate calculated as $E = \frac{a + 4m + b}{6}$.

Test Pyramid

A model illustrating that tests have different granularity and execution speeds; the bottom layer contains many fast, isolated unit tests, while the top contains fewer, slower, end-to-end tests.

Testing Quadrants

A model grouping test levels and types across two dimensions: business-facing versus technology-facing, and supporting the team versus critiquing the product (Q1 through Q4).

Risk

A potential event, hazard, threat, or situation whose occurrence causes an adverse effect, characterized by likelihood and impact.

Risk Level

A measure of risk determined by combining risk likelihood with risk impact ($\text{Risk Level} = \text{Risk Likelihood} \times \text{Risk Impact}$).

Project Risk

A risk related to project management and control (e.g., staffing issues, schedule delays, budget cuts, supplier failures) that impacts the ability to achieve project goals.

Product Risk

A risk related to the quality characteristics of a software work product (e.g., missing features, runtime errors, poor performance, security flaws).

Risk-Based Testing

An approach to testing where test activities are selected, prioritized, and managed based on the results of risk analysis and risk control.

Test Monitoring

The ongoing activity of gathering testing metrics and progress data to compare actual status against the test plan and verify satisfaction of exit criteria.

Test Control

The activity that uses information from test monitoring to issue guidance and corrective actions (control directives) to keep testing on track to meet objectives.

Configuration Management (CM)

A discipline that identifies, controls, versions, and tracks work products (test items, testware, baselines) to ensure consistency and maintain traceability across testing activities.

Defect Report

A work product recording an observed anomaly during testing, containing details such as identifier, title, reproduction steps, expected versus actual results, severity, and status.

Test Automation

The use of software tools to control test execution, manage test data, compare actual outcomes with predicted outcomes, and report test outcomes automatically.