Free ISTQB Foundation Exam Flashcards

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.