3.1 Static Testing Versus Dynamic Testing

ISTQB Certified Tester Foundation Level CTFL v4.0

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Fundamentals of Testing

1.1 What Testing Does 1.2 Verification, Validation, and Debugging 1.3 Testing, Quality, and Risk Reduction 1.4 The Seven Testing Principles 1.5 Test Process, Testware, and Traceability 1.6 Tester Skills, Roles, and Independence

2 Chapter 2: Testing Throughout the Software Development Lifecycle

2.1 SDLC Models and Good Testing Practices 2.2 Shift-Left, Test-First, and DevOps Testing 2.3 Test Levels: Component Through Acceptance 2.4 Test Types: Functional, Non-Functional, White-Box, and Change-Related 2.5 Confirmation, Regression, and Maintenance Testing 2.6 Collaboration Across the Lifecycle

3 Chapter 3: Static Testing

3.1 Static Testing Versus Dynamic Testing 3.2 Work Products and Static Analysis 3.3 Review Process and Roles 3.4 Review Types 3.5 Successful Review Practices

4 Chapter 4: Test Analysis and Design

4.1 Technique Selection and Coverage 4.2 Equivalence Partitioning 4.3 Boundary Value Analysis 4.4 Decision Table Testing 4.5 State Transition Testing 4.6 White-Box Coverage 4.7 Experience-Based Testing 4.8 Collaborative Test Design

5 Chapter 5: Managing the Test Activities

5.1 Test Planning, Strategy, Entry Criteria, and Exit Criteria 5.2 Test Estimation and Prioritization 5.3 Risk-Based Testing 5.4 Monitoring, Control, and Reporting 5.5 Configuration Management and Traceability 5.6 Defect Management 5.7 Test Completion and Retrospectives

6 Chapter 6: Test Tools

6.1 Test Tool Classification 6.2 Automation Benefits and Risks 6.3 Selecting and Introducing Tools 6.4 Tool Support Exam Traps

3.1 Static Testing Versus Dynamic Testing

Key Takeaways Explain This Topic AI

Static testing evaluates work products manually or with tools without executing the software under test.

Dynamic testing executes software and observes failures that may reveal underlying defects.

Static and dynamic testing are complementary because each detects different defect types efficiently.

Static testing can begin very early in the SDLC, supporting shift-left and reducing the cost of fixing defects.

CTFL questions often test whether a defect is found directly by examination or inferred from a runtime failure.

Last updated: June 2026

Execution Is the Main Divider

Static testing examines a work product without executing the software under test. A team may review a user story, inspect source code, analyse a model, or check a test case for missing coverage. The object being examined may itself be executable code, but execution is not part of the technique. ISTQB recognises two main forms of static testing: reviews (people examine a work product) and static analysis (a tool examines a structured work product against rules).

Dynamic testing requires execution. A tester supplies inputs, observes outputs or behaviour, and compares actual results with expected results. If the software crashes, returns the wrong value, or violates a performance target, dynamic testing has revealed a failure — an externally observed deviation from expected behaviour. The defect (the flaw in the work product) that caused that failure still has to be located through debugging, which is a developer activity, not a testing activity.

• Point of comparison Static testing Dynamic testing
• Software execution Not required Required
• Typical objects Requirements, stories, code, models, tests, plans Executable software or system components
• Main evidence Anomalies, review comments, analysis findings Failures, logs, outputs, measured behaviour
• Defects found Directly, in the work product Indirectly, inferred from observed failures
• Timing Can start very early, before code exists Starts when something executable exists

Quality characteristics Maintainability, readability, consistency, completeness Functional behaviour, performance, reliability

A common CTFL trap is to assume static testing is only document review. Static testing includes both reviews and static analysis. A tool can scan source code for unreachable code, duplicated logic, high cyclomatic complexity, coding-standard violations, or certain security weaknesses before a single test case runs.

Why Both Are Needed

Static and dynamic testing share the common objective of improving quality and detecting defects as early and cheaply as possible, but they detect different kinds of defects, which is why the syllabus stresses they are complementary rather than competing.

Static testing detects defects directly in the work product. A reviewer can find an ambiguous acceptance criterion, a requirement that contradicts another, a missing interface parameter, deviations from standards, incorrect interface specifications, security vulnerabilities, gaps in test-basis coverage, or maintainability problems in code. Crucially, many of these — such as requirement ambiguities — are very hard or impossible to expose by execution alone, because there may be nothing to run.

Dynamic testing detects defects indirectly : it exposes failures, and analysis then identifies the underlying defect. It is the only way to reveal behaviour that depends on the running environment — integration behaviour, timing and concurrency issues, memory leaks under load, performance, and user-visible runtime failures.

Static strengths: early feedback; finds defects in non-executable products; cheap to fix because change is early.

Dynamic strengths: confirms real behaviour; finds emergent runtime/environment defects; validates the system end to end.

Static testing usually finds defects directly: a reviewer sees that two requirements specify different timeout values for the same session. Dynamic testing usually exposes failures first: if a login screen accepts an expired password, the tester observes the incorrect behaviour, then debugging locates the cause.

Exam questions often hinge on the words early , executable , failure , defect , and work product . If the scenario happens before execution, or involves reading and analysing a product, think static . If it depends on running the software and checking actual behaviour, think dynamic . Remember the syllabus pairing: static finds defects directly; dynamic finds failures from which defects are inferred.

Error, Defect, Failure, and Anomaly

The exam expects precise vocabulary, because static and dynamic testing relate to these terms differently. An error (mistake) is a human action that produces an incorrect result — for example, a developer misreads a requirement. That mistake can introduce a defect (also called a fault or bug) into a work product. When defective executable code runs, it may cause a failure : an event in which the component or system does not do what it should. Not every defect causes a failure — some are never triggered, depend on rare conditions, or sit in code that is never executed.

Static testing acts on the defect end of this chain. A reviewer or analysis tool inspects the work product and locates the defect (or the error in reasoning behind it) directly, without ever causing a failure. Because of this, static testing can find defects that would never surface as a failure during normal dynamic testing — for instance, unreachable code, or a contradiction between two requirements that no test case would ever exercise.

Dynamic testing acts on the failure end of the chain. It triggers failures by executing the software, then a person must analyse the failure to find the defect that caused it (debugging). This indirection is why dynamic testing is described as finding defects indirectly .

The broader umbrella term is anomaly : any condition that deviates from expectation, whether or not it is later confirmed to be a defect. Reviews and static-analysis tools report anomalies; human judgement then classifies each as a true defect, a false positive, or merely an improvement suggestion.

• Term Definition Found by
• Error / mistake A human action producing an incorrect result (the root human cause)
• Defect / fault / bug A flaw in a work product that can cause a failure Static testing, directly
• Failure An event where behaviour deviates from expectation Dynamic testing, when triggered
• Anomaly Any condition deviating from expectation Reviews and static analysis

Understanding this chain explains the syllabus claim that static and dynamic testing are complementary: one attacks defects before they ever execute, the other catches the failures that slip through into running software.