Chapter 3 is about finding defects without running the software. It covers what static testing can examine, why it pays off, how it differs from dynamic testing, the review process, the roles people play in a review, the four common review types and what makes reviews succeed. It carries 4 of the 40 exam questions.
ISTQB CTFL › 3. Static Testing Syllabus v4.0.1 · updated 3 Nov 2026
| Exam weight | Questions | K-levels | Training time |
|---|---|---|---|
| 10% | 4 | 2 × K1, 2 × K2 | 80 minutes |
Keywords to remember (K1): anomaly, dynamic testing, formal review, informal review, inspection, review, static analysis, static testing, technical review, walkthrough.
3.1 Static testing basics
In static testing the software is not executed. Work products such as code, specifications or architecture documents are examined either manually (reviews) or with tools (static analysis). The objectives include improving quality, detecting defects and assessing characteristics such as readability, completeness, correctness, testability and consistency. Static testing supports both verification and validation.
In Agile teams, testers, business representatives (product owner, business analyst) and developers work together in example mapping, collaborative user story writing and backlog refinement to make sure user stories meet criteria such as the Definition of Ready. Testers ask questions that expose gaps, so stories end up complete, understandable and with testable acceptance criteria.
Static analysis finds problems before dynamic testing, often with less effort because no test cases are needed. It is usually tool-based and often runs inside CI pipelines. Besides code defects, it evaluates maintainability and security. Spell checkers and readability tools are also static analysis tools.
3.1.1 Work products examinable by static testing (K1)
Almost any work product can be statically tested: requirement specifications, source code, test plans, test cases, product backlog items, test charters, project documentation, contracts and models.
| Technique | What it can examine |
|---|---|
| Review | Anything a person can read and understand |
| Static analysis | Work products with a structure a tool can check: code, models, text with a formal syntax |
Not suitable: work products that are hard for people to interpret and that should not be analysed by tools, for example third-party executable code (for legal reasons).
3.1.2 Value of static testing (K2)
- Finds defects in the earliest phases of the SDLC (early testing principle).
- Finds defects that dynamic testing cannot, such as unreachable code, design patterns not implemented as intended, and defects in non-executable work products.
- Evaluates quality and builds confidence in work products; stakeholders can check that requirements describe their real needs.
- Creates a shared understanding and better communication among stakeholders, so a wide variety of stakeholders should take part.
- Reviews cost effort, but overall project cost is usually much lower than without reviews, because less time is spent fixing defects later.
- Static analysis finds some code defects more efficiently than dynamic testing, leading to fewer defects and less development effort overall.
3.1.3 Static testing vs dynamic testing (K2)
They complement each other and share objectives, but they differ:
| Static testing | Dynamic testing |
|---|---|
| Finds defects directly | Causes failures; defects are then found by analysis |
| Can reach code paths that are rarely executed or hard to reach | Only covers what the tests actually execute |
| Works on non-executable work products too | Works only on executable work products |
| Measures characteristics that do not need execution, for example maintainability | Measures characteristics that need execution, for example performance efficiency |
| Some defect types can only be found statically | Some defect types can only be found dynamically |
Defects that are easier or cheaper to find with static testing:
| Category | Examples |
|---|---|
| Requirements defects | Inconsistencies, ambiguities, contradictions, omissions, inaccuracies, duplications |
| Design defects | Inefficient database structures, poor modularisation |
| Certain coding defects | Variables with undefined values, undeclared variables, unreachable or duplicated code, excessive complexity |
| Deviations from standards | Not following naming conventions |
| Incorrect interface specifications | Wrong number, type or order of parameters |
| Some security vulnerabilities | Buffer overflows |
| Gaps in test basis coverage | A missing test for an acceptance criterion |
3.2 Feedback and review process
3.2.1 Benefits of early and frequent stakeholder feedback (K1)
Early and frequent feedback surfaces quality problems early. Without it, the product may not match what stakeholders originally wanted or want now, leading to costly rework, missed deadlines, blame games and even project failure.
Frequent feedback prevents misunderstandings about requirements, makes sure requirement changes are understood and implemented sooner, helps the team understand what it is building, and lets it focus on the features with the most value and the biggest effect on identified risks.
3.2.2 Review process activities (K2)
The ISO/IEC 20246 standard describes a generic review process that teams tailor. More formal reviews perform more of the tasks. Large work products may need several passes through the process.
| Activity | What happens |
|---|---|
| 1. Planning | Define the scope: purpose, work product, quality characteristics to evaluate, focus areas, exit criteria, supporting information such as standards, effort and timeframe |
| 2. Review initiation | Make sure everyone and everything is ready: participants have access to the work product, understand their roles and have what they need |
| 3. Individual review | Each reviewer examines the work product using review techniques (for example checklist-based or scenario-based reviewing) and logs anomalies, recommendations and questions |
| 4. Communication and analysis | Anomalies are not automatically defects, so they are discussed and a decision is made on status, ownership and actions, typically in a review meeting. The group also decides the quality of the work product and the follow-up actions; a follow-up review may be needed |
| 5. Fixing and reporting | A defect report is created for every defect so corrective action can be tracked. When the exit criteria are met, the work product can be accepted and the review results are reported |
Please Invite Interested Colleagues First: Planning, Initiation, Individual review, Communication and analysis, Fixing and reporting.
3.2.3 Roles and responsibilities in reviews (K1)
| Role | Responsibility |
|---|---|
| Manager | Decides what is reviewed and provides resources (staff and time) |
| Author | Creates and fixes the work product under review |
| Moderator (facilitator) | Runs review meetings effectively: mediation, time management and a safe environment where everyone can speak freely |
| Scribe (recorder) | Collates anomalies from reviewers and records decisions and new anomalies found in the meeting |
| Reviewer | Performs the review; can be a project member, a subject matter expert or any other stakeholder |
| Review leader | Takes overall responsibility for the review: decides who is involved, and organises when and where it takes place |
Manager = what to review and resources. Review leader = who takes part, when and where. Moderator = how the meeting runs. Exam options often swap these.
3.2.4 Review types (K2)
The right level of formality depends on the SDLC, process maturity, criticality and complexity of the work product, legal or regulatory needs and the need for an audit trail. The same work product can be reviewed several times, first informally and later formally.
| Informal review | Walkthrough | Technical review | Inspection | |
|---|---|---|---|---|
| Process | No defined process and no formal documented output | Tailored from the generic process | Tailored from the generic process | Most formal: follows the complete generic review process |
| Led by | Not specified | The author | A moderator | A review leader; the author cannot be the review leader or the scribe |
| Main objective | Detect anomalies | Many: evaluate quality, build confidence, educate reviewers, gain consensus, generate ideas, help authors improve, detect anomalies | Gain consensus and make decisions on a technical problem; also detect anomalies, evaluate quality, build confidence, generate ideas, help authors improve | Find the maximum number of anomalies; also evaluate quality, build confidence, help authors improve |
| Notable detail | Lightweight | Individual review beforehand is possible but not required | Done by technically qualified reviewers | Metrics are collected and used to improve the SDLC, including the inspection process |
Walkthrough → author leads, education. Technical review → moderator leads, technical decisions. Inspection → most formal, maximum anomalies, metrics, author is not the leader or scribe.
3.2.5 Success factors for reviews (K1)
- Clear objectives and measurable exit criteria; evaluating the participants must never be an objective.
- Choose the right review type for the objectives, work product, participants and context.
- Review small chunks so reviewers stay focused.
- Give feedback to stakeholders and authors so they can improve.
- Give participants enough time to prepare.
- Management support for the review process.
- Make reviews part of the organisation’s culture, promoting learning and process improvement.
- Train all participants in their roles.
- Facilitate meetings.
Learning objectives checklist
| LO | Level | You should be able to… |
|---|---|---|
| FL-3.1.1 | K1 | Recognise work products that can be examined by static testing |
| FL-3.1.2 | K2 | Explain the value of static testing |
| FL-3.1.3 | K2 | Compare and contrast static and dynamic testing |
| FL-3.2.1 | K1 | Identify the benefits of early and frequent stakeholder feedback |
| FL-3.2.2 | K2 | Summarise the review process activities |
| FL-3.2.3 | K1 | Recall the responsibilities of the principal review roles |
| FL-3.2.4 | K2 | Compare and contrast the review types |
| FL-3.2.5 | K1 | Recall the factors for successful reviews |
Chapter 3 self-check (10 questions)
Which work product is NOT appropriate for static analysis by a tool?
- A. Source code written by the team
- B. A UML model with a formal syntax
- C. Third-party executable code that the licence forbids analysing
- D. A requirements document checked with a spelling tool
Show answer
Answer: C. Third-party executable code that the licence forbids analysing
Work products that should not be analysed by tools, such as third-party executable code for legal reasons, are not appropriate for static testing.
Which defect is static testing more likely to find than dynamic testing?
- A. A memory leak that appears after 8 hours of use
- B. Unreachable code in a rarely used module
- C. A slow response under 1,000 concurrent users
- D. A crash when the network is disconnected
Show answer
Answer: B. Unreachable code in a rarely used module
Unreachable code cannot be executed, so dynamic testing cannot find it, while static analysis or a code review can. The other options need execution.
Which statement correctly contrasts static and dynamic testing?
- A. Static testing causes failures; dynamic testing finds defects directly
- B. Static testing can only be applied to executable work products
- C. Static testing can measure maintainability; dynamic testing can measure performance efficiency
- D. Static and dynamic testing find exactly the same types of defects
Show answer
Answer: C. Static testing can measure maintainability; dynamic testing can measure performance efficiency
Static testing measures characteristics that do not need execution (such as maintainability) and dynamic testing measures those that do (such as performance efficiency).
What is a likely consequence of little stakeholder involvement during development?
- A. Fewer regression tests are needed
- B. The product may not meet the stakeholders’ vision, causing costly rework
- C. Static analysis tools become more effective
- D. Exit criteria are met sooner
Show answer
Answer: B. The product may not meet the stakeholders’ vision, causing costly rework
Without early and frequent feedback, the product may not match what stakeholders want, leading to rework, missed deadlines, blame and even project failure.
In which review activity do reviewers log anomalies, recommendations and questions using techniques such as checklist-based reviewing?
- A. Planning
- B. Review initiation
- C. Individual review
- D. Fixing and reporting
Show answer
Answer: C. Individual review
During the individual review each reviewer examines the work product with review techniques and logs what they find.
In which review activity are the review’s exit criteria first defined?
- A. Planning
- B. Communication and analysis
- C. Individual review
- D. Fixing and reporting
Show answer
Answer: A. Planning
Planning defines the scope of the review, including its purpose, focus areas and exit criteria. Fixing and reporting checks that the exit criteria are met.
Who decides what is to be reviewed and provides staff and time for it?
- A. Review leader
- B. Moderator
- C. Manager
- D. Scribe
Show answer
Answer: C. Manager
The manager decides what is reviewed and provides resources. The review leader decides who is involved and organises when and where.
Which role ensures the review meeting runs effectively, including time management and a safe environment?
- A. Author
- B. Moderator
- C. Scribe
- D. Reviewer
Show answer
Answer: B. Moderator
The moderator (facilitator) handles mediation, time management and a safe environment where everyone can speak freely.
A review is led by the author, and its main aims are to educate the reviewers and gain consensus. Which review type is it?
- A. Informal review
- B. Walkthrough
- C. Technical review
- D. Inspection
Show answer
Answer: B. Walkthrough
A walkthrough is led by the author and can serve objectives such as educating reviewers and gaining consensus. In an inspection the author cannot lead.
Which is a success factor for reviews?
- A. Using review results to evaluate the performance of the participants
- B. Reviewing the entire specification in one long session
- C. Defining clear objectives and measurable exit criteria
- D. Holding reviews without management involvement
Show answer
Answer: C. Defining clear objectives and measurable exit criteria
Clear objectives and measurable exit criteria are a success factor. Evaluating participants must never be an objective, small chunks work better, and management support is needed.
Next: Chapter 4: Test Analysis and Design.