Static testing

Chapter summary

Chapter 3 of the ISTQB Foundation Level syllabus covers testing that does not involve executing the software. This includes reviews of work products like requirements and designs, and static analysis tools that examine code without running it. The chapter carries 80 minutes of training time and accounts for 4 of the 40 exam questions (10% of the exam).

This page covers the main concepts in the chapter at a level that complements the full Chapter 3 guide.

What static testing is

Static testing examines work products directly without executing the software. This covers a wide range of work products: requirements specifications, user stories, design documents, test plans, test cases, code, contracts, and any other written artifact that can be reviewed. Dynamic testing executes the software and observes its behavior. Static testing reads or analyzes the artifact itself.

The practical implication is that static testing can start before any code exists. A requirements review can catch ambiguities, contradictions, or missing information before they are built into the design, the code, and the test cases. Finding a defect in a requirements document takes minutes to fix. The same defect found during system testing can take much longer to trace and correct.

Static testing finds different kinds of defects than dynamic testing does. Requirements defects, design inconsistencies, coding standard violations, interface specification errors, and certain security vulnerabilities are all things static testing can find directly. Dynamic testing can only find defects that cause an observable failure when the software runs.

Reviews

Reviews are the main static testing technique for most work products. A review involves one or more people examining a work product with the goal of finding defects, improving quality, and building shared understanding.

The syllabus describes a general review process with five activities: planning (defining the scope, selecting participants, setting entry and exit criteria for formal reviews), initiating the review (distributing materials and explaining the goals), individual review (each participant examines the work product independently), issue communication and analysis (discussing and classifying findings in a meeting or through tool-based comments), and fixing and reporting (the author addresses issues and metrics are recorded).

Review types

The syllabus defines four review types, from least formal to most formal:

An informal review has no defined process. It can be as simple as asking a colleague to read something and provide feedback. The cost is low and it can be useful early in a document's life.

A walkthrough has the author guiding participants through the work product to build shared understanding and gather feedback. The structure is flexible and the focus is on shared understanding rather than defect-finding alone.

A technical review brings together technically qualified peers to evaluate the technical content of a work product, such as a design or a solution. It is more structured than a walkthrough and focused on technical quality.

An inspection is the most formal review type. It has defined roles, defined entry and exit criteria, a structured preparation phase where participants review the work product independently before the meeting, and a follow-up step to verify that issues have been addressed.

Review roles

Six roles appear in a formal review. The author created the work product being reviewed. Management decides whether reviews happen and allocates time and resources. The facilitator (sometimes called the moderator) ensures the review runs effectively and mediates between different viewpoints. The review leader is responsible for the review overall, including planning and follow-up. Reviewers are the participants who examine the work product and identify potential defects. The scribe records the issues found during the session.

In informal reviews, several of these roles may be filled by the same person or omitted entirely.

Success factors

Reviews are more likely to be useful when the objectives are clear from the start, the right review type is chosen for the work product and its risk level, participants feel comfortable raising issues without fear of personal criticism, management allocates time for reviews and does not use results to evaluate individual performance, and defects are actually tracked and addressed after the review ends.

Exam weight and K-levels

Chapter 3 contributes 4 questions to the exam (10%). All learning objectives are K1 or K2. The most testable distinctions are between static and dynamic testing, and between the four review types. See the full Chapter 3 guide for a complete breakdown and the learning objectives page for the full objective-by-objective breakdown.

By Christian Stevens, ISTQB Certified Tester Foundation Level

Last reviewed: June 2026.