ISTQB Foundation Exam Flashcards

Q: What is the ISTQB Foundation passing score?

The ISTQB Certified Tester Foundation Level (CTFL v4.0) exam requires 65% to pass, which equals 26 correct answers out of 40 multiple-choice questions. You have 60 minutes (75 minutes if taking the exam in a non-native language). There is no negative marking, so attempt every question. The exam fee is $229 USD.

Q: What are the six chapters of the CTFL v4.0 syllabus?

CTFL v4.0 has six chapters: Fundamentals of Testing (~17%), Testing Throughout the SDLC (~18%), Static Testing (~13%), Test Analysis and Design / Test Techniques (~22%), Managing the Test Activities (~18%), and Test Tools (~12%). Chapter 4 (test techniques) carries the most weight, so practice equivalence partitioning, boundary value analysis, and decision tables.

Q: Do I need experience to take the ISTQB Foundation exam?

No. ISTQB Foundation is an entry-level certification with no formal prerequisites and no required testing experience. Self-study from the official CTFL v4.0 syllabus is acceptable, though instructor-led training is also available. The exam tests conceptual understanding rather than hands-on tool skills.

Q: Does the ISTQB Foundation certification expire?

No. The ISTQB Foundation Level certification is valid for life with no renewal fee. It is also a prerequisite for all advanced and specialist ISTQB certifications, so passing it is the entry point to the broader ISTQB certification scheme.

Q: What changed between CTFL v3.1 and v4.0?

CTFL v4.0 (released 2023) added Agile, DevOps, and continuous delivery context, collaborative user story and acceptance criteria writing, behavior-driven development, and shift-left testing, and refreshed terminology. The exam format is unchanged: 40 multiple-choice questions with a 65% passing mark. v3.1 was retired, so new candidates take v4.0.

Question 1

What testing can and cannot show

Accepted Answer

Testing can show that defects are present, but it cannot prove that none remain (principle: testing shows the presence of defects, not their absence). Passing tests reduce risk but never guarantee correctness.

Question 2

Error, defect, failure

Accepted Answer

An error (mistake) by a person introduces a defect (fault/bug) in a work product; when executed, the defect may cause a failure (observed incorrect behavior). Not every defect leads to a failure.

Question 3

Verification vs validation

Accepted Answer

Verification asks "are we building the product right?" (meets specifications). Validation asks "are we building the right product?" (meets user needs). Debugging is a development activity that finds and fixes the cause of a failure, not testing.

Question 4

Test objectives

Accepted Answer

Testing aims to evaluate work products, find defects, build confidence, reduce risk, satisfy contractual or legal requirements, and provide information for decisions. Objectives vary by context, level, and project phase.

Question 5

Defects originate from root causes

Accepted Answer

A root cause is the earliest action or condition that led to a defect. Root cause analysis improves the development process so similar defects are prevented, not just fixed once.

Question 6

Exhaustive testing is impossible

Accepted Answer

Principle: testing everything (all input/precondition combinations) is not feasible except for trivial cases. Use risk analysis, test techniques, and prioritization to focus effort instead.

Question 7

Early testing saves time and money

Accepted Answer

Principle: testing activities should start as early as possible in the SDLC (shift-left). Defects found early are far cheaper to fix than the same defects found in later stages or in production.

Question 8

Defect clustering

Accepted Answer

Principle: a small number of modules usually contain most of the defects, or are responsible for most operational failures. Focus extra testing on these high-density, high-risk areas.

Question 9

Pesticide paradox

Accepted Answer

Principle: repeating the same tests stops finding new defects over time. Tests must be reviewed and updated, and new tests written, to find new defects.

Question 10

Testing is context dependent / absence-of-errors fallacy

Accepted Answer

Testing is done differently in different contexts (e.g. safety-critical vs e-commerce). Also, a system with no known defects can still fail to meet user needs — that is the absence-of-errors fallacy.

Question 11

Test activities and the test process

Accepted Answer

The main test activities are test planning, monitoring and control, analysis, design, implementation, execution, and completion. They are iterative and often overlap rather than strictly sequential.

Question 12

Testware

Accepted Answer

Testware is the work products produced during the test process: test plans, test cases, test data, test scripts, test environments, and test reports. It must be maintained under configuration management.

Question 13

Traceability

Accepted Answer

Traceability links test conditions, test cases, and results back to the test basis (requirements, risks). It supports impact analysis, coverage measurement, auditability, and meaningful test reporting.

Question 14

Tester independence

Accepted Answer

Independent testing (by someone other than the author) tends to find different and more defects, but greater independence can reduce collaboration and developer learning. The right level depends on context and risk.

Question 15

Test levels

Accepted Answer

The four test levels are component (unit), integration, system, and acceptance testing. Each level has its own objectives, test basis, and typical defects it is best suited to find.

Question 16

Component vs integration testing

Accepted Answer

Component testing checks an isolated module against its design/spec. Integration testing checks the interfaces and interactions between integrated components or systems, where component testing alone cannot find defects.

Question 17

Acceptance testing types

Accepted Answer

Acceptance testing validates readiness for deployment and includes user acceptance, operational acceptance, contractual/regulatory acceptance, and alpha/beta testing. It focuses on fitness for use, not finding many defects.

Question 18

Functional vs non-functional testing

Accepted Answer

Functional testing checks what the system does (features/behavior). Non-functional testing checks how well it does it (performance, usability, security, reliability). Both can occur at any test level.

Question 19

Confirmation vs regression testing

Accepted Answer

Confirmation (re-testing) verifies that a fixed defect is actually resolved. Regression testing checks that the change did not break previously working functionality. Both are change-related test types.

Question 20

Maintenance testing

Accepted Answer

Maintenance testing tests changes to a system in operation: modifications, upgrades, migrations, and retirement. Its scope depends on the change's risk and the size of the existing system; impact analysis guides it.

Question 21

Shift-left and test-first approaches

Accepted Answer

Shift-left moves testing activities earlier (reviewing requirements, writing tests before code). Test-first practices like TDD, ATDD, and BDD use tests to drive design and clarify expected behavior up front.

Question 22

Static testing definition

Accepted Answer

Static testing examines work products without executing the code (reviews and static analysis). It can be applied early to requirements, designs, and code before anything runs.

Question 23

Benefits of static testing

Accepted Answer

Static testing finds defects early and cheaply, detects issues dynamic testing cannot easily reach (e.g. unreachable or unclear requirements), and improves consistency and team understanding of work products.

Question 24

Static analysis

Accepted Answer

Static analysis uses tools to examine source code or models without executing them, detecting coding standard violations, security weaknesses, complexity, and data-flow anomalies. It complements human reviews.

Question 25

Review process roles

Accepted Answer

Typical review roles: author, manager, facilitator (moderator), review leader, reviewer, and scribe. One person may take several roles; the facilitator keeps the review effective and objective.

Question 26

Review types by formality

Accepted Answer

From least to most formal: informal review, walkthrough (often author-led), technical review (peer experts), and inspection (formal, defined roles, metrics, entry/exit criteria). Formality is chosen by risk and need.

Question 27

Choosing test techniques

Accepted Answer

Technique selection depends on system type, risk, objectives, regulations, contracts, documentation available, tester skill, and time. Techniques are categorized as black-box, white-box, and experience-based.

Question 28

Black-box vs white-box vs experience-based

Accepted Answer

Black-box (specification-based) derives tests from requirements/behavior. White-box (structural) derives tests from code/structure. Experience-based uses the tester's knowledge, skill, and intuition.

Question 29

Equivalence partitioning

Accepted Answer

Inputs are divided into partitions expected to be processed the same way; testing one value per valid and invalid partition gives coverage without testing every value. Each value should belong to exactly one partition.

Question 30

Boundary value analysis

Accepted Answer

Defects cluster at the edges of equivalence partitions. BVA tests the boundary values. Two-value BVA uses each boundary and its nearest neighbor; three-value BVA also adds the value just inside.

Question 31

Decision table testing

Accepted Answer

A decision table lists combinations of conditions and the resulting actions, ensuring combinations of business rules are tested systematically. It is effective when system behavior depends on multiple logical conditions.

Question 32

State transition testing

Accepted Answer

Models the system as states, events, transitions, and actions. Tests cover valid transitions and can also exercise invalid ones. Useful when behavior depends on current state and history, not just current input.

Question 33

Statement vs branch coverage

Accepted Answer

Statement coverage measures the percentage of executable statements exercised; branch (decision) coverage measures the percentage of decision outcomes exercised. 100% branch coverage implies 100% statement coverage, not vice versa.

Question 34

Experience-based techniques

Accepted Answer

Error guessing anticipates likely mistakes based on experience. Exploratory testing combines learning, test design, and execution concurrently. Checklist-based testing uses a checklist of conditions to cover.

Question 35

Collaborative test design

Accepted Answer

User stories with INVEST-style acceptance criteria, the "three amigos" (business, development, testing), and BDD scenarios written collaboratively help define testable behavior before development starts.

Question 36

Test plan and test strategy

Accepted Answer

A test plan documents objectives, scope, schedule, resources, and approach for a test effort. A test strategy describes the general, often organization-level testing approach. Plans are refined as the project evolves.

Question 37

Entry and exit criteria

Accepted Answer

Entry criteria (definition of ready) define preconditions before testing can start; exit criteria (definition of done) define conditions for declaring testing complete. They make start/stop decisions objective.

Question 38

Test estimation techniques

Accepted Answer

Common approaches include estimation based on ratios, extrapolation, the Wideband Delphi (expert) technique, and three-point estimation. Estimates should be revised as more information becomes available.

Question 39

Product risk vs project risk

Accepted Answer

A product risk is a possibility the product fails to satisfy stakeholders' needs (a quality risk). A project risk threatens the project's management (delays, resources, scope). Risk-based testing prioritizes by both.

Question 40

Risk-based testing

Accepted Answer

Risk = likelihood of an event × its impact. Risk-based testing allocates more and earlier testing effort to higher-risk items and may reduce or skip testing for low-risk areas to optimize coverage under constraints.

Question 41

Test monitoring, control, and reporting

Accepted Answer

Monitoring gathers progress and coverage data against the plan; control takes corrective action (re-prioritize, adjust scope); reporting communicates status and findings to stakeholders for informed decisions.

Question 42

Coverage as a metric

Accepted Answer

Coverage measures the proportion of a defined item (requirements, code, risks) exercised by tests, expressed as a percentage. High coverage reduces uncertainty but does not by itself prove quality.

Question 43

Configuration management in testing

Accepted Answer

Configuration management uniquely identifies, version-controls, and tracks testware and test items so tests are repeatable and results trace to a known version of the system under test.

Question 44

Defect report contents

Accepted Answer

A good defect report includes a unique ID, summary, steps to reproduce, expected vs actual results, severity, priority, status, environment, and references. Clear reports speed up triage and fixing.

Question 45

Severity vs priority

Accepted Answer

Severity is the degree of impact a defect has on the system. Priority is how urgently it should be fixed (often business-driven). A defect can be high severity but low priority, or the reverse.

Question 46

Defect lifecycle and workflow

Accepted Answer

A defect moves through states such as new, assigned, in progress, fixed, retested, and closed (or rejected/deferred). A defect management process tracks it and supports root-cause and trend analysis.

Question 47

Test tool categories

Accepted Answer

Tools support different activities: test management, static testing, test design and data preparation, test execution and coverage, performance and monitoring, and support tools (e.g. for DevOps pipelines).

Question 48

Benefits and risks of test automation

Accepted Answer

Benefits: repeatable execution, faster regression, reduced manual effort, objective coverage data. Risks: unrealistic expectations, high maintenance, underestimated tool cost, and over-reliance reducing human insight.

Question 49

Selecting and introducing a tool

Accepted Answer

Tool selection assesses organizational maturity, needs, constraints, and the tool's fit. New tools are introduced via a pilot project, defined usage guidelines, training, and adapting processes before wide rollout.

Question 50

Automation does not replace test design

Accepted Answer

A tool executes tests faster but does not decide what to test or judge ambiguous results. Poorly designed tests automated at scale just produce wrong answers faster; human analysis and design remain essential.

Free ISTQB Foundation Exam Flashcards

Filter by Topic

Jump to Card

About These ISTQB Foundation Flashcards

Topics Covered

Frequently Asked Questions

ISTQB Foundation Level (CTFL)

Explore More ISTQB Certifications

ISTQB Advanced Level Agile Technical Tester (CTAL-ATT)

ISTQB Advanced Level Technical Test Analyst (CTAL-TTA)

ISTQB Advanced Level Test Analyst (CTAL-TA)

ISTQB Advanced Level Test Automation Engineering (CTAL-TAE)

ISTQB Advanced Level Test Management (CTAL-TM)

ISTQB AI Testing Specialist (CT-AI)

More From This Family