The Core Distinction
The simplest way to remember the difference:
- Static testing — examining work products without executing the software
- Dynamic testing — testing by running the software and observing behavior
Both find defects, but they find different kinds at different points in development, and they cost different amounts to run.
Static Testing
What It Is
Static testing evaluates documents, code, and other work products through review or static analysis — without executing any code.
Work products that can be statically tested:
- Requirements documents
- User stories and acceptance criteria
- Architecture and design documents
- Source code (without running it)
- Test plans and test cases
- Database schemas
Why It Matters
Defects found in static testing are found earlier and cost less to fix. A requirement defect caught in review costs a fraction of what it costs to fix after the code is written, tested, and deployed.
Static testing can find defects that dynamic testing often misses:
- Ambiguous or contradictory requirements
- Dead code and unreachable paths
- Security vulnerabilities in code structure
- Inconsistencies between design documents
Static Analysis
Automated static testing — tools analyze source code without running it:
| Tool Type | What It Checks |
|---|---|
| Linters | Code style, simple errors |
| SAST tools | Security vulnerabilities |
| Code coverage analyzers (static) | Structural coverage without execution |
| Complexity analyzers | Cyclomatic complexity, maintainability |
Examples: SonarQube, ESLint, Checkmarx, PMD.
The Review Process
ISTQB defines a formal review process with specific roles and activities. This is heavily tested in Chapter 3.
Review Types (Least to Most Formal)
| Review Type | Formality | Who Leads | Process |
|---|---|---|---|
| Informal review | None | Anyone | No defined process, ad hoc feedback |
| Walkthrough | Low | Author | Author guides reviewers through the document |
| Technical review | Medium | Trained moderator | Structured, peers check technical accuracy |
| Inspection | High | Trained moderator | Most formal, entry/exit criteria, metrics collected |
The Formal Review Process (Inspection)
ISTQB defines these activities for a formal review:
- Planning — define scope, select participants, schedule
- Review initiation — distribute documents, check entry criteria
- Individual review — each reviewer works independently, logs defects
- Communication and analysis — group meeting to discuss findings
- Fixing and reporting — author fixes defects, metrics recorded, exit criteria checked
Review Roles
| Role | Responsibility |
|---|---|
| Author | Created the work product being reviewed |
| Moderator (Facilitator) | Plans and runs the review meeting |
| Scribe (Recorder) | Documents defects and decisions |
| Reviewer | Evaluates the work product |
| Review Leader | Manages the overall review process |
| Management | Decides to conduct reviews, allocates resources |
Note: One person can hold multiple roles (except Author and Reviewer in formal reviews).
What Walkthroughs Are NOT
A walkthrough is led by the author, who presents the work product and gets feedback from the group. It's informal and educational. Compare this to an inspection, where reviewers prepare independently and the author's role during the meeting is mostly to listen and clarify.
Exam trap: Questions often confuse who leads a walkthrough (the author) vs an inspection (the moderator).
Dynamic Testing
What It Is
Dynamic testing executes the software and checks its behavior against expected outcomes. Every type of testing you typically think of — unit tests, integration tests, system tests, user acceptance testing — is dynamic testing.
What Dynamic Testing Finds
- Runtime errors and crashes
- Incorrect outputs for valid inputs
- Performance bottlenecks
- Security vulnerabilities that only appear at runtime
- Integration failures between components
Dynamic Testing Cannot Find Everything
Some defect classes are harder or impossible to detect dynamically:
- Dead code (code that's never executed)
- Inconsistencies in requirements (if both document and code implement the same wrong behavior)
- Security flaws in authentication design (the system behaves consistently but incorrectly)
Side-by-Side Comparison
| Dimension | Static Testing | Dynamic Testing |
|---|---|---|
| Execution required? | No | Yes |
| When applied | Any lifecycle phase | After code exists |
| Work products | Docs, code, designs | Running software |
| Defects found | Design, logic, inconsistency | Runtime failures, incorrect behavior |
| Cost | Lower (earlier detection) | Higher (later in lifecycle) |
| Automation | Static analysis tools | Test automation frameworks |
| ISTQB chapter | Chapter 3 | Chapters 4, 5 |
When to Use Each
Use static testing when:
- Requirements are being written (review them before developers read them)
- Code is in pull request / code review phase
- Architecture decisions are being documented
- Test cases need review before execution
Use dynamic testing when:
- Code is integrated and runnable
- You need to verify actual runtime behavior
- Performance characteristics need to be measured
- End-to-end user flows need to be validated
In practice: The best testing strategies use both. Static analysis in CI pipelines catches code quality issues automatically; manual reviews catch requirements problems early; dynamic testing validates the running system.
ISTQB Exam Focus Areas for Chapter 3
The exam tests these specific points most frequently:
- Which review type matches a description? (walkthrough = author-led, inspection = most formal)
- What defects can static testing find that dynamic cannot? (dead code, requirements inconsistencies)
- What is the sequence of the formal review process? (planning → initiation → individual review → communication → fixing)
- What role does the moderator play? (leads the meeting, NOT the author)
- What work products can be statically tested? (anything written — not just code)
A solid understanding of the review types table and the formal review process steps will cover most of the Chapter 3 exam questions.