CTFL Domain 3: Static Testing (10%) - Complete Study Guide 2026

What Static Testing Covers on the CTFL Exam

Domain 3 of the ISTQB Certified Tester Foundation Level syllabus (v4.0.1, dated 2024-09-15) is titled "Static Testing," and it makes up 10% of the exam - the smallest domain by weight after Test Tools at 5%. On a 40-question exam, that translates to roughly four questions drawn directly from this content area. It's a modest slice, but it's also one of the most conceptually distinct sections of the whole certification, which is exactly why candidates who skim it often lose easy points.

If you haven't yet reviewed how all six domains fit together, the CTFL Exam Domains 2026: Complete Guide to All 6 Content Areas is a useful map before diving into any single domain in depth. This guide assumes you already know the exam format - 40 multiple-choice questions worth 40 points, a 60-minute limit (75 minutes for approved non-native-language candidates), and a passing score of 26 out of 40 (65%) - and focuses purely on what Static Testing demands.

Why This Small Domain Trips Up Candidates

A 10% weighting sounds low-stakes, but Static Testing questions tend to be highly precise. The syllabus draws sharp distinctions between review types and roles, and exam writers exploit that precision. Candidates who studied Domain 4 (Test Analysis and Design, 27.5% of the exam) or Domain 5 (Managing the Test Activities, 22.5%) far more heavily sometimes arrive at the exam having only skimmed Static Testing - and then discover the questions aren't vague at all. They ask you to identify which role writes the review report, or which review type has no meeting at all.

This is a pattern worth understanding before exam day. If you're still calibrating how tough the CTFL exam feels overall, How Hard Is the CTFL Exam? Complete Difficulty Guide 2026 breaks down where candidates typically lose points across all domains, and Static Testing consistently shows up as a domain where preparation quality matters more than raw study time.

Review Types and the Formal Review Process

The core of Domain 3 is the taxonomy of reviews. The CTFL syllabus defines four review types, ordered from least to most formal:

• Informal review: No formal process, no documented output requirement. Could be as simple as a colleague reading over a document.
• Walkthrough: The author leads the session, explaining the work product to a group. Useful for building consensus or knowledge transfer, but still relatively lightweight.
• Technical review: A more structured, documented process typically led by a trained moderator or facilitator, ideally without the author chairing the meeting. Focuses on technical correctness.
• Inspection: The most formal review type, following a defined process with strict roles, metrics collection, checklists, and entry/exit criteria.

You also need the review roles cold: the author created the work product; the moderator/facilitator runs the review and resolves conflicts; the reviewers identify defects; the scribe records issues; and the manager decides whether resources are allocated and reviews take place. Exam questions frequently present a short scenario and ask which role is responsible for a specific action.

Equally important is the generic review process itself, which the syllabus breaks into five activities:

1. Planning: Defining scope, selecting reviewers, setting entry/exit criteria.
2. Kick-off: Distributing documents, explaining objectives to participants.
3. Individual review (preparation): Reviewers examine the work product alone before any meeting.
4. Review meeting/communication: Discussing findings, logging defects, making decisions.
5. Rework and follow-up: The author fixes issues; the moderator confirms exit criteria are met.

Static Analysis vs. Dynamic Testing

The second pillar of this domain is static analysis - the use of tools or manual techniques to evaluate code or other artifacts without executing them. Static analysis can catch issues that dynamic testing might miss entirely, such as unreachable code, undeclared variables, security vulnerabilities, deviations from coding standards, and violations of complexity thresholds. It cannot, however, find defects that only manifest at runtime, such as timing issues, memory leaks under load, or incorrect behavior tied to specific input combinations.

The syllabus draws a clean conceptual line: static testing (reviews plus static analysis) examines work products directly, while dynamic testing (covered more heavily in Domain 4) requires executing the software. Expect at least one question asking you to classify a described activity as static or dynamic, or to identify a defect type that static analysis is well-suited (or poorly suited) to catch.

Key Terms and Concepts You Must Know

Beyond review types and static analysis, make sure these terms are second nature:

• Work product: Any artifact produced during development that can be reviewed - requirements, code, test cases, user stories, architecture documents.
• Entry criteria / exit criteria: Conditions that must be met before a review can start or be considered complete.
• Checklist-based reviewing: Using a predefined list of common defect types to guide reviewers, especially common in inspections.
• Benefits of static testing: Early defect detection, improved development productivity, reduced cost of quality, and improved communication among stakeholders.
• Value of reviews for non-code artifacts: Requirements and design documents can be reviewed long before any code exists, catching ambiguity or contradiction early.

These concepts connect directly to material tested in Domain 1 (Fundamentals of Testing) and Domain 2 (Testing Throughout the Software Development Lifecycle), so a shaky grasp of static testing terminology can quietly cost you points elsewhere too. If you haven't reviewed those domains yet, see CTFL Domain 1: Fundamentals of Testing (20%) - Complete Study Guide 2026 and CTFL Domain 2: Testing Throughout the Software Development Lifecycle (15%) - Complete Study Guide 2026 for the connective tissue.

How Domain 3 Questions Are Actually Worded

ISTQB exam questions are multiple-choice with a single best answer, drawn directly from syllabus-defined terms and concepts - there's no ambiguity or trick phrasing beyond precise terminology. For Static Testing, expect formats like:

• A scenario describing a review meeting, asking you to identify which role performed a described action (e.g., "who is responsible for deciding if the document may proceed to the next phase?").
• A list of defect types, asking which one is least likely to be found through static analysis.
• A description of a review with specific characteristics (no fixed agenda, author-led, exploratory discussion), asking you to name the review type.
• A "benefits of static testing" question asking you to select the option that is NOT a benefit - a common trap format across the whole exam.

Because the questions map so tightly to syllabus wording, practicing with realistic mock exams matters more here than in domains that reward applied reasoning. Working through timed practice questions on our CTFL practice test platform is one of the fastest ways to see exactly how ISTQB phrases these distinctions before you sit the real exam.

Where to Slot Domain 3 Into Your Study Plan

Static Testing is a short domain, so it doesn't need a dedicated week of study - but it does need a focused session where you're not distracted by higher-weight material. Because it accounts for only 10% of the exam, most candidates fold it into an early study week alongside Domain 2, since both domains cover process and lifecycle concepts rather than technique-heavy content like Domain 4's test design or Domain 5's test management.

This sequencing works because Static Testing terminology reinforces concepts you'll see again in Domain 5 discussions of quality assurance versus quality control. For a full week-by-week framework covering the entire syllabus, the CTFL Study Guide 2026: How to Pass on Your First Attempt lays out a complete plan rather than a single-domain slice.

Common Mistakes on Static Testing Questions

• Confusing walkthrough and technical review: Remember, a walkthrough is author-led and less formal; a technical review is moderator-led and more structured.
• Assuming inspections always require a meeting: They do - inspections are the most formal and always include a structured meeting, unlike informal reviews.
• Treating static analysis as a replacement for testing: It's a complement. Static analysis cannot detect runtime-only defects, and exam questions frequently probe this limitation.
• Misassigning the scribe's role: The scribe records issues raised during the meeting; they don't make decisions about exit criteria - that's typically the moderator's call.
• Underestimating how literally the syllabus is quoted: ISTQB questions rarely require inference beyond the defined terms, so approximate understanding often isn't enough to pick the exact right answer among close distractors.

Static Testing knowledge isn't just an exam formality - employers hiring for QA and test analyst roles expect candidates to understand review processes because early defect detection is a real cost-saving practice in software teams. If you're weighing whether the broader certification is worth pursuing for your career, Is the CTFL Certification Worth It? Complete ROI Analysis 2026 covers that in more depth, and CTFL Jobs outlines the roles where this credential shows up in job postings.

FAQ