ISTQB Foundation cheat sheet

Testing shows the presence of defects, not their absence; exhaustive testing is impossible, so risk-based prioritization is used.

Seven principles: presence of defects, exhaustive testing impossible, early testing, defect clustering, pesticide paradox, context dependence, absence-of-errors fallacy.

Cause chain: error (human action) → defect (flaw in a work product) → failure (incorrect behavior during execution); root cause analysis addresses the origin.

Verification checks conformance to specified requirements; validation checks fitness for intended use.

Test process: planning → monitoring and control → analysis → design → implementation → execution → completion.

Test conditions are derived during analysis; test cases and test scripts are created during design and implementation.

Testing is product-oriented; quality assurance is process-oriented and focuses on preventing defects.

Traceability between test basis, test conditions, test cases, and results supports coverage measurement and impact analysis.

Sequential models such as waterfall and the V-model define distinct phases; iterative and agile models deliver increments with continuous testing.

The V-model pairs each development phase with a test level: component, integration, system, and acceptance testing.

Component testing checks individual components, often by developers; integration testing checks interfaces and interactions between components or systems.

System testing evaluates end-to-end behavior of a complete system against requirements; acceptance testing assesses readiness for deployment and user needs.

Shift-left moves test design and static testing earlier, reducing the cost of late defect discovery.

Agile testing is whole-team, iterative, and feedback-driven, with practices such as TDD, ATDD, and continuous regression automation.

Confirmation testing (retesting) verifies a fix; regression testing verifies that changes did not break unchanged functionality.

Maintenance testing is triggered by enhancements, corrections, environment changes, migration, or retirement; impact analysis determines its scope.

Static testing does not execute code; it comprises reviews and static analysis and can find defects early in the lifecycle.

Review types in increasing formality: informal review, walkthrough, technical review, inspection.

Review process: planning, review initiation, individual review, communication and analysis, fixing and reporting.

Formal review roles include manager, author, moderator, scribe, reviewers, and review leader.

Inspection is the most formal review, uses entry and exit criteria and checklists, and records findings for follow-up.

Static analysis detects defects such as unreachable code, undefined variables, inconsistent interfaces, security weaknesses, and standards violations.

Reviews are more effective with small chunks, defined objectives, checklists, and participants with appropriate skills.

Static testing finds defects that dynamic testing may miss, such as ambiguities in requirements and maintainability issues.

Black-box techniques derive tests from specifications; white-box techniques use internal structure; experience-based techniques use tester knowledge.

Equivalence partitioning divides inputs into partitions expected to behave identically; use one value per partition, covering valid and invalid partitions.

Boundary value analysis tests each boundary and its nearest neighbors on both sides; boundaries include minimum, maximum, and internal edges.

Decision tables capture condition combinations and actions; coverage is measured by the proportion of feasible rules exercised.

State transition testing exercises states, events, and transitions; coverage types include all states and all valid transitions.

Use case testing derives tests from use case flows, including basic and alternative paths.

Statement coverage = (statements executed / total executable statements) × 100%; decision coverage = (decisions exercised / total decisions) × 100%.

Experience-based techniques include exploratory testing, error guessing, and checklist-based testing; they complement, not replace, systematic techniques.

Risk level = likelihood × impact; product risks affect quality, while project risks affect schedule, budget, and resources.

Risk-based testing allocates effort to high-risk items first and uses risk to select techniques, coverage, and independence.

Test planning defines scope, objectives, approach, resources, schedule, entry and exit criteria, and risks.

Test monitoring compares actual progress with the plan; control takes corrective action when deviations occur.

Metrics include planned versus actual effort, test case execution, pass and fail rates, defect density, and requirements coverage.

Incident reports include identifier, summary, environment, steps to reproduce, expected and actual results, severity, and priority.

Configuration management keeps testware and software versions consistent and supports reproducible testing.

Test estimation may use expert judgment, analogy, wideband Delphi, planning poker, or three-point estimation.

Tool categories include test management, static testing, test design and implementation, test execution, performance testing, monitoring, and specialized tools.

Test execution tools run scripts, compare actual and expected results, and support regression testing and continuous integration.

Static analysis tools examine code without execution to detect standards violations, complexity, and security weaknesses.

Test management tools support requirements traceability, testware organization, execution tracking, and reporting.

Automation reduces repetitive effort but introduces costs for scripting, maintenance, and tool administration; it does not replace human judgment.

Tool selection should follow needs assessment, evaluation against criteria, a pilot, and a decision on adoption.

Test automation architectures separate test scripts, test libraries, and the system under test to improve reuse and maintainability.