ISTQB CTFL Static Testing Basics: Work Products, Value and Static vs Dynamic Testing
Static testing is the examination of work products such as requirements, code, test plans and models without executing the software, either manually through reviews or with tools through static analysis. This CTFL lesson covers which work products static testing can examine, why it is valuable (early, cheap defect detection, defects dynamic testing cannot find, shared stakeholder understanding) and how it compares with dynamic testing.
On this page8 sections
- What is static testing?
- What are the objectives of static testing?
- Which work products can be examined by static testing?
- Why is static testing valuable?
- Are reviews worth their cost?
- What does static analysis add?
- How do static and dynamic testing differ?
- Which defects are easier and cheaper to find with static testing?
- Define static testing and name its two forms: reviews and tool-supported static analysis
- Recognize the work products that can be examined by static testing, the exception for third-party executable code, and what static analysis needs from a work product
- Explain the value of static testing: early defect detection, defects only static testing can find, shared stakeholder understanding and lower total project cost
- Describe what static analysis adds, including its place in continuous integration and its role for maintainability and security
- Compare static and dynamic testing: defects versus failures, executable versus non-executable work products, rarely executed paths and quality characteristics
- Classify typical defects that are easier and cheaper to find with static testing
What is static testing?
Static testing is testing that examines a work product without executing the software. Nothing is run: people or tools read the work product and look for defects and quality problems in it. Dynamic testing is the opposite: it executes the test object with inputs and compares what happens with what should happen.
Static testing has two forms:
- Reviews are performed manually by people, who read the work product and raise anomalies. The review process, review roles and review types are covered in the next lesson on feedback and the review process.
- Static analysis is tool-supported. A tool checks the work product against rules, so it needs no test cases and no running system.
The dividing line is execution: if an activity needs the test object to run, it is dynamic testing by definition.
What are the objectives of static testing?
The objectives of static testing are to improve quality, detect defects and assess characteristics of a work product such as its readability, completeness, correctness, testability and consistency. These are properties you can judge by reading the work product as it is written.
Static testing serves both verification and validation. Checking that a design follows its specification is verification; business representatives confirming that a requirements specification describes what they actually need is validation. Treating static testing as verification-only is a common misreading.
Every one of these objectives is judged against the work product as it is written, not against the behaviour of a running system.
Which work products can be examined by static testing?
Almost any work product that can be read and understood can be examined by static testing. Typical examples are:
- requirements specifications and user stories with their acceptance criteria
- product backlog items
- source code
- test plans, test cases and test charters
- project documentation
- contracts, including supplier contracts
- models, such as design or state models
The exception is a work product that is difficult for humans to interpret and should not be analysed by tools, for example third-party executable code, where legal reasons (such as licence terms) rule out analysing it.
What does static analysis need from a work product?
Reviews only need a human-readable work product, but static analysis needs a structure a tool can check against: models, code or text with a formal syntax. Source code or a UML model can be checked by a tool because their syntax is defined; a narrative vision statement or a prose business case has no such syntax, so people review it instead.
Why is static testing valuable?
Static testing is valuable because it finds defects early, finds defects that dynamic testing cannot, and improves shared understanding between stakeholders.
- Evaluating quality and building confidence. Static testing provides the ability to evaluate the quality of work products and to build confidence in them before they are used as the basis for further work.
- Earliest detection. Static testing can start as soon as a work product exists, such as a requirements specification written before any code. This fulfils the early testing principle: a defect found in a requirement costs far less to fix than the same defect after it has spread into design, code and tests.
- Defects dynamic testing cannot find. Static testing identifies defects that never produce a failure, such as unreachable code, design patterns not implemented as desired and defects in non-executable work products like an ambiguous requirement.
- Shared understanding. Reviewing documented requirements lets stakeholders confirm that the requirements describe their actual needs. Because people from different roles examine the same work product, communication improves and the team builds a shared understanding of what is being built. For this reason a wide variety of stakeholders should be involved.
In Agile teams this collaboration is routine: testers, business representatives and developers work together during example mapping, collaborative user story writing and backlog refinement so that user stories meet defined criteria such as the Definition of Ready. Review techniques are applied to make sure user stories are complete and understandable and include testable acceptance criteria.
Are reviews worth their cost?
Yes. Reviews do cost time and effort, and the syllabus says so openly. The case for them is total project cost: overall project costs are usually much lower when reviews are performed, because less time and effort is spent fixing defects later in the project.
What does static analysis add?
Static analysis detects code defects more efficiently than dynamic testing, because a tool checks the code against rules without test cases or an execution environment. The usual result is fewer code defects and lower overall development effort. Static analysis can also find problems before dynamic testing starts, with less effort.
Static analysis is often built into continuous integration (CI), so code is checked automatically on every change. Besides defects it can evaluate maintainability (for example code complexity) and security (for example certain vulnerabilities).
Examples of static analysis tools include:
- code analysers run in a CI pipeline
- spelling checkers applied to documents
- readability tools that score a document's readability
What makes all of these static analysis is that a tool examines the work product against rules while nothing is executed.
How do static and dynamic testing differ?
Static and dynamic testing are complementary: they share objectives such as detecting defects and assessing quality, but each finds some defect types that only it can find. Neither replaces the other. The syllabus lists these differences:
| Point of comparison | Static testing | Dynamic testing |
|---|---|---|
| How defects are found | Finds defects in work products directly | Causes failures; the associated defects are found by subsequent analysis |
| Work products it applies to | Executable and non-executable work products (documents, models, user stories, source code) | Executable work products only |
| Rarely executed code paths | Finds defects on rarely executed or hard-to-reach paths more easily | Only reveals defects on paths a test actually reaches |
| Quality characteristics | Characteristics that do not depend on execution, e.g. maintainability | Characteristics that depend on execution, e.g. performance efficiency |
Defects versus failures in practice
When a test of a booking form rejects a valid date, that rejection is a failure; the off-by-one comparison a developer then locates in the date check is the defect, found by analysing the failure. A code review could have pointed at the same comparison directly, with no failure ever occurring. Getting the direction right matters: static testing finds defects directly, dynamic testing reveals failures first.
Hard-to-reach paths
A branch that runs only on the last day of a leap year, or only when a rarely used configuration flag is set, is easy for test execution to miss: dynamic testing reveals a defect only on paths a test actually reaches. Reviewing or statically analysing the source examines that branch just like any other line of code.
Quality characteristics
Maintainability shows in the code's structure, such as complexity, modularity and adherence to standards, so it can be judged without running anything. Performance efficiency, by contrast, describes how the system behaves while it runs, so it needs dynamic testing.
Which defects are easier and cheaper to find with static testing?
The syllabus lists typical defects that are easier and cheaper to find through static testing than dynamic testing. Learn the categories with their examples, because questions often ask you to classify a defect:
| Category | Typical examples |
|---|---|
| Requirements defects | Inconsistencies, ambiguities, contradictions, omissions, inaccuracies, duplications |
| Design defects | Inefficient database structures (for example missing indexes on frequently queried columns), poor modularization |
| Certain coding defects | Variables with undefined values, undeclared variables, unreachable or duplicated code, excessive code complexity |
| Deviations from standards | Not following naming conventions in coding standards |
| Incorrect interface specifications | Mismatched number, type or order of parameters between components |
| Specific security vulnerabilities | Buffer overflows |
| Gaps or inaccuracies in test basis coverage | Missing tests for an acceptance criterion |
Tip. Questions on this topic are mostly short recall and understanding items, often with an uppercase qualifier such as BEST, NOT, LEAST or CORRECT. Expect to identify which work product is unsuitable for static testing or best suited to tool-based static analysis, to explain the value of static testing (early detection, cost, defects only static testing finds, stakeholder understanding) and to compare static with dynamic testing on defects versus failures, executable versus non-executable work products, hard-to-reach code paths and quality characteristics. Some items list several defects or statements in roman-numeral or matching format and ask you to select the correct set or classify each defect into the syllabus categories, and a few scenarios combine two of these facts to choose an approach.
- Static testing examines work products without executing the software; its two forms are manual reviews and tool-supported static analysis.
- Its objectives are improving quality, detecting defects and assessing readability, completeness, correctness, testability and consistency; it serves both verification and validation.
- Almost any readable work product can be reviewed, including contracts, test charters and backlog items; third-party executable code is the exception, for legal reasons.
- Static analysis needs a formal structure to check against (models, code, text with a formal syntax); plain-text work products are reviewed instead.
- Static testing finds defects in the earliest lifecycle phases, which fulfils the early testing principle and lowers the cost of fixing them.
- Only static testing finds defects that cause no failure: unreachable code, design patterns not implemented as desired, defects in non-executable work products.
- Reviews cost effort, but total project costs are usually much lower than without them; static analysis in CI usually means fewer code defects and lower development effort.
- Static testing finds defects directly and applies to non-executable work products; dynamic testing causes failures, needs executable work products and measures execution-dependent characteristics such as performance efficiency.
Frequently asked questions
What is the difference between static and dynamic testing in ISTQB CTFL?
Static testing examines work products without executing the software and finds defects directly, while dynamic testing executes the software, causes failures and finds the underlying defects through subsequent analysis. Static testing can be applied to non-executable work products such as requirements, whereas dynamic testing needs an executable test object. The two are complementary because each finds some defect types the other cannot.
Which work products cannot be examined by static testing?
In the CTFL syllabus, almost any work product that can be read and understood can be examined by static testing, including requirements, code, test plans, test charters, backlog items, contracts and models. The exception is a work product that is difficult for humans to interpret and should not be analysed by tools for legal reasons, such as third-party executable code.
Is static testing used for verification or validation?
Static testing is used for both. Checking a work product against its specification is verification, and having stakeholders such as business representatives confirm that reviewed requirements describe their actual needs is validation.
What defects can only static testing find?
Static testing can find defects that never cause a failure, so dynamic testing cannot reveal them. Examples are unreachable code, design patterns that were not implemented as desired, and defects in non-executable work products such as an ambiguous or contradictory requirement.
Are reviews worth the effort if they are expensive?
The ISTQB syllabus accepts that reviews can be costly, but overall project costs are usually much lower than without reviews because less time and effort is spent fixing defects found later in the project. Reviews reduce later fixing effort rather than removing it.
What are examples of static analysis tools?
Examples of static analysis tools include code analysers that run automatically in a continuous integration pipeline, spelling checkers applied to documents and readability tools that score a document. Each examines a work product against rules without executing the software under test.
Which quality characteristics can static testing evaluate?
Static testing evaluates quality characteristics that do not depend on executing code, such as maintainability, which shows in code complexity, modularity and adherence to standards. Characteristics that depend on execution, such as performance efficiency, need dynamic testing.
Source
This lesson covers the "Static Testing" domain of the official CTFL exam guide. Vendors revise their guides — check the source for the current version.
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.