Overview
Static testing evaluates work products such as requirements, user stories, designs, code, test plans and contracts without executing them, either manually through reviews or with tools through static analysis. The chapter explains which work products qualify, why finding defects this early is cheaper, which defects static testing finds more easily than dynamic testing (ambiguous requirements, unreachable code, interface mismatches, deviations from coding standards), and how the two approaches complement each other.
The second section turns to feedback and reviews. It starts with the value of early and frequent stakeholder feedback, then describes a generic review process based on ISO/IEC 20246 (planning, review initiation, individual review, communication and analysis, fixing and reporting), the review roles, the four review types from informal review to inspection, and the factors that make reviews succeed. It builds on the shift-left ideas in Chapter 2 and feeds defect reporting in Chapter 5.
How it's tested
Static testing questions are recall and comparison: which role does this task, which review type fits these objectives, which defect is static testing more likely to find, which factor contributes to a successful review. Scenarios are short. The deciding words are usually the person leading the review, the stated objective and the degree of formality described.
-
Match the review type
A description of who leads, how formal the process is and what the main objective is, and you name the review type: informal review, walkthrough, technical review or inspection.
-
Match the role
A task such as recording anomalies, mediating the meeting or deciding what is reviewed, and you name the role: manager, author, moderator, scribe, reviewer or review leader.
-
Static versus dynamic
A list of defects or characteristics, and you pick the one static testing finds more easily, such as unreachable code, or the one only dynamic testing can measure, such as performance efficiency.
A stem describes a review led by the author, whose goals include educating reviewers and gaining consensus, with no requirement for individual preparation. A technical review also seeks consensus, and an inspection is the most formal, but neither is led by the author. The author-led meeting with educational goals and optional preparation identifies a walkthrough. The clue is who leads, not how many people attend.
Syllabus sections 2
Official syllabus sections from the ISTQB outline, in outline order.
3.1 Static Testing BasicsWhich work products can be examined statically, the value of static testing, and how it differs from dynamic testing.
- What it means
- Almost any work product that can be read and understood can be reviewed: requirement specifications, source code, test plans, test cases, product backlog items, test charters, project documentation, contracts and models. Static analysis additionally needs a structure to check against, such as code, models or text with a formal syntax. Work products that humans cannot interpret and should not be analyzed by tools, such as third-party executable code for legal reasons, are not suitable.
- What to understand
- Static testing finds defects early, when they are cheapest to fix, and finds defects that dynamic testing cannot, such as unreachable code, design patterns not implemented as intended, and defects in non-executable work products. It also builds shared understanding among stakeholders and helps verify and validate requirements. Static testing finds defects directly, while dynamic testing causes failures from which defects are found by analysis. Static testing can measure characteristics that do not depend on execution, such as maintainability, while dynamic testing can measure those that do, such as performance efficiency.
- How it shows up
- A K2 question lists defect types and asks which is typically easier or cheaper to find with static testing, for example mismatched parameter order in an interface specification, an undeclared variable or a missing test for an acceptance criterion.
- Common confusion
- Believing static testing applies only to code; reviews apply to any readable work product, and only static analysis needs a formal structure.
3.2 Feedback and Review ProcessEarly stakeholder feedback, the review process activities, roles, review types and success factors.
- What it means
- Early and frequent stakeholder feedback prevents misunderstandings about requirements, makes requirement changes understood sooner and keeps the team focused on the features with most value. The generic review process has five activities: planning (scope, purpose, quality characteristics, focus areas, exit criteria, effort and timeframes), review initiation (access, roles understood, materials provided), individual review (each reviewer finds anomalies, recommendations and questions, using techniques such as checklist-based or scenario-based reviewing), communication and analysis (anomalies discussed, status, ownership and actions decided, often in a review meeting) and fixing and reporting (defect reports created, exit criteria checked, results reported).
- What to understand
- The principal roles are the manager (decides what is reviewed and provides resources), author (creates and fixes the work product), moderator or facilitator (runs meetings, mediates, manages time, keeps the environment safe), scribe or recorder (collates anomalies and records decisions), reviewer (performs reviews) and review leader (takes overall responsibility, decides who is involved, organizes when and where). The review types range from informal review (no defined process or formal output) through walkthrough (led by the author), technical review (technically qualified reviewers, led by a moderator, seeking consensus and decisions on technical problems) to inspection (most formal, full process, aims to find the maximum number of anomalies, collects metrics, author cannot be review leader or scribe).
- How it shows up
- K1 questions ask which role is responsible for a task or which factor contributes to success; K2 questions describe a review and ask which type it is, or ask you to put review activities in order.
- Common confusion
- Confusing the moderator, who runs the meeting, with the review leader, who takes overall responsibility for organizing the review; and treating an anomaly as automatically a defect before communication and analysis.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Static testing
Evaluating work products without executing them, manually through reviews or with tools through static analysis.
- Remember
- It finds defects directly, early and cheaply, and can examine non-executable work products such as requirements and test plans.
- Tested as
- K2 explain-the-value questions.
- Trap
- Thinking static testing means only code analysis tools.
-
Defects easier to find statically
Requirement defects (inconsistencies, ambiguities, omissions), design defects (inefficient database structures, poor modularization), certain coding defects (undefined values, undeclared variables, unreachable or duplicated code, excessive complexity), deviations from standards, incorrect interface specifications, some security vulnerabilities such as buffer overflows, and gaps in test basis coverage.
- Remember
- Static testing more easily finds defects on code paths that are rarely executed or hard to reach dynamically.
- Tested as
- Pick-the-defect questions.
- Trap
- Choosing slow response time, which needs execution and so belongs to dynamic testing.
-
Anomaly
A finding raised during a review, which may or may not turn out to be a defect.
- Remember
- Anomalies are analyzed in communication and analysis, where their status, ownership and actions are decided; defect reports follow in fixing and reporting.
- Tested as
- Review process activity questions.
- Trap
- Assuming every logged anomaly becomes a defect report.
-
Review process activities
Planning, review initiation, individual review, communication and analysis, fixing and reporting.
- Remember
- Exit criteria are set during planning, and the work product can be accepted once they are met during fixing and reporting.
- Tested as
- K2 summarize questions and ordering questions.
- Trap
- Placing the decision on scope and exit criteria in review initiation rather than planning.
-
Moderator
Also called the facilitator: ensures review meetings run effectively, including mediation, time management and a safe review environment.
- Remember
- The moderator runs meetings; the review leader takes overall responsibility for the review.
- Tested as
- K1 role-responsibility questions.
- Trap
- Picking the moderator for "decides who will be involved", which is the review leader.
-
Scribe
Also called the recorder: collates anomalies from reviewers and records review information such as decisions and new anomalies found during the meeting.
- Remember
- In an inspection, the author cannot act as scribe or review leader.
- Tested as
- K1 role questions.
- Trap
- Assigning recording duties to the moderator.
-
Manager and review leader
The manager decides what is to be reviewed and provides resources such as staff and time; the review leader takes overall responsibility for the review, such as who is involved and when and where it takes place.
- Remember
- Resources come from the manager, organization from the review leader.
- Tested as
- K1 role questions that separate the two.
- Trap
- Thinking the manager runs the review.
-
Walkthrough
A review led by the author that can serve many objectives: evaluating quality, educating reviewers, gaining consensus, generating ideas, motivating authors and detecting anomalies.
- Remember
- Reviewers may prepare individually beforehand, but it is not required.
- Tested as
- K2 compare-review-types questions.
- Trap
- Saying a moderator leads a walkthrough.
-
Technical review
A review by technically qualified reviewers, led by a moderator, whose objectives are gaining consensus and making decisions on a technical problem, as well as detecting anomalies and evaluating quality.
- Remember
- The defining objective is technical consensus and decisions.
- Tested as
- K2 review-type questions.
- Trap
- Choosing inspection whenever reviewers are technical experts.
-
Inspection
The most formal review type, following the complete generic process with the main objective of finding the maximum number of anomalies.
- Remember
- Metrics are collected and used to improve the SDLC and the inspection process, and the author cannot be the review leader or scribe.
- Tested as
- K2 review-type questions.
- Trap
- Thinking an inspection is mainly for educating or reaching consensus.
-
Review success factors
Clear objectives and measurable exit criteria, the right review type, small chunks, feedback to stakeholders and authors, adequate preparation time, management support, a culture of learning, training, and facilitated meetings.
- Remember
- Evaluating participants should never be a review objective.
- Tested as
- K1 recall of success factors.
- Trap
- Choosing "use review metrics to appraise authors" as a success factor.
-
Early and frequent stakeholder feedback
Regular feedback from stakeholders throughout development, not only at the end.
- Remember
- It prevents misunderstandings about requirements, makes changes understood earlier, improves the team's understanding of what it is building, and keeps focus on the most valuable features.
- Tested as
- K1 identify-the-benefit questions.
- Trap
- Choosing a benefit about reducing the need for testing.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Informal review vs. walkthrough vs. technical review vs. inspection
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Informal review | No defined process and no formal documented output | Main objective is detecting anomalies | Thinking informal reviews have no value |
| Walkthrough | Review led by the author | Broad objectives including education and consensus; individual preparation optional | Attributing leadership to a moderator |
| Technical review | Technically qualified reviewers, led by a moderator | Aims at consensus and decisions on a technical problem | Calling it an inspection because experts take part |
| Inspection | Most formal type, following the complete generic process | Aims to find the maximum number of anomalies and collects metrics; author cannot lead or scribe | Thinking the author may act as review leader |
Static testing vs. dynamic testing
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Static testing | Examines work products without execution | Finds defects directly, applies to non-executable work products, measures characteristics such as maintainability | Assuming it cannot find code defects |
| Dynamic testing | Executes the test object | Causes failures from which defects are found by analysis, measures execution-dependent characteristics such as performance efficiency | Assuming it finds unreachable code |
Moderator vs. review leader vs. manager
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Moderator (facilitator) | Ensures review meetings run effectively | Mediation, time management, safe environment | Giving the moderator responsibility for choosing participants |
| Review leader | Takes overall responsibility for the review | Decides who is involved and organizes when and where | Confusing this with chairing the meeting |
| Manager | Decides what is to be reviewed | Provides resources such as staff and time | Assuming the manager runs or leads the review |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Moderator leads the walkthrough
- What candidates pick
- Technical review for an author-led session that explains a design to new team members.
- Why it looks right
- Design documents are technical, and technical reviews involve experts.
- Why it's wrong
- A review led by the author, with goals such as educating reviewers, is a walkthrough; technical reviews are led by a moderator and aim at technical consensus and decisions.
Clue to watch for The author is presenting or leading.
-
Moderator equals review leader
- What candidates pick
- Moderator as the role that decides who takes part and when the review happens.
- Why it looks right
- Both roles sound like they are in charge.
- Why it's wrong
- The review leader takes overall responsibility and organizes participants, time and place; the moderator ensures meetings run effectively.
Clue to watch for Organizing and deciding participants points to the review leader; running and mediating the meeting points to the moderator.
-
Static means code only
- What candidates pick
- "Static testing cannot be applied to requirements or contracts."
- Why it looks right
- Static analysis tools are usually associated with source code.
- Why it's wrong
- Reviews apply to any readable work product, including requirements, test plans, product backlog items and contracts; only static analysis needs a formal structure.
Clue to watch for A non-code work product is mentioned in the options.
-
Performance found statically
- What candidates pick
- Slow response under load as a typical defect found by static testing.
- Why it looks right
- Inefficient code can sometimes be spotted by reading it.
- Why it's wrong
- Characteristics that depend on execution, such as performance efficiency, are measured by dynamic testing; static testing measures characteristics like maintainability.
Clue to watch for The option names a runtime behavior such as response time or throughput.
-
Reviews to appraise people
- What candidates pick
- Using review findings to evaluate authors' performance as a success factor.
- Why it looks right
- Metrics seem to make reviews more rigorous and accountable.
- Why it's wrong
- The syllabus states that evaluating participants should never be an objective; doing so destroys the safe environment reviews depend on.
Clue to watch for Any option linking reviews to individual appraisal.
-
Anomaly equals defect
- What candidates pick
- "Every anomaly found in individual review is logged as a defect report."
- Why it looks right
- Anomalies sound like defects.
- Why it's wrong
- Anomalies are analyzed in communication and analysis to decide status, ownership and actions; some are not defects, and defect reports are created for defects during fixing and reporting.
Clue to watch for The question asks what happens to anomalies or in which activity defect reports are created.
Answer framework
For a Chapter 3 question about a review, use these steps to identify the type, role or activity being described.
- Identify who leads the review: the author points to a walkthrough, a moderator to a technical review, and an inspection never lets the author lead.
- Identify the main objective: maximum anomalies with metrics means inspection, technical consensus and decisions means technical review, education means walkthrough.
- Check how formal the process is, and whether individual preparation, metrics and documented outputs are required.
- For a task question, map it to a role: resources to manager, organization to review leader, meeting facilitation to moderator, recording to scribe.
- For static versus dynamic, ask whether the defect or characteristic can be seen without running the software before choosing.
Practice question
Want more like this? The ISTQB CTFL practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with 3.2, because review roles and review types produce most of this chapter's questions. Build a one-line card for each of the six roles and each of the four review types, and on each type card write who leads it, how formal it is and its main objective. Then practice turning short descriptions into a type: "author-led, educational" to walkthrough, "moderator-led, technical decision" to technical review, "maximum anomalies, metrics" to inspection.
Next, learn the five review process activities in order and note what happens to an anomaly at each step. Then cover 3.1: the list of work products, the defects static testing finds more easily, and the static versus dynamic contrast in how defects are found and which quality characteristics each can measure.
Candidates commonly underestimate the success factors list, which is a simple K1 mark if memorized, and the manager versus review leader split. Afterward, do a short set of role and review-type questions, then move to Chapter 4, where test analysis and design picks up from the defects reviews uncover in the test basis.
FAQ
How many CTFL questions are on static testing?
The official exam structure gives Chapter 3 four of the 40 questions, two at K1 and two at K2, which is 10% of the exam.
What is the difference between a walkthrough and an inspection?
A walkthrough is led by the author and can serve broad objectives such as education and consensus. An inspection is the most formal type, aims to find the maximum number of anomalies, collects metrics, and does not let the author act as review leader or scribe.
Who leads a technical review?
A moderator leads it, and the reviewers are technically qualified. Its main objectives are gaining consensus and making decisions on a technical problem, alongside detecting anomalies.
Can static testing be applied to requirements?
Yes. Reviews can be applied to any work product that people can read and understand, including requirements, user stories, test plans and contracts. Static analysis tools need a formal structure such as code or models.
Which review process standard does the syllabus use?
The review process in the syllabus is based on ISO/IEC 20246, which describes a generic process that is tailored to the review type and context.
What should never be an objective of a review?
Evaluating the participants. Using reviews to appraise authors undermines the safe environment and open discussion that make reviews effective.
How does static testing relate to the rest of the exam?
It is the main shift-left practice from Chapter 2, it uses the defect concepts from Chapter 1, and the defect reports it produces follow the defect management process in Chapter 5.
Other Quality Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have just covered the review process, the six review roles and the four review types, plus what static testing finds that dynamic testing cannot. Check that you can name the role and review type from a short description.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ISTQB CTFL AI tutor Get any concept explained your way