3.1 Static Testing Versus Dynamic Testing
Key Takeaways
- 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.
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.
A reviewer notices that two requirements describe different timeout values for the same session behaviour. Which statement best classifies this finding?
Why does the CTFL syllabus describe static and dynamic testing as complementary?
Which statements correctly compare static and dynamic testing? Select all that apply.
Select all that apply