Static testing
In software testing, static testing is examining code, requirements, designs and other work products for defects without executing the software. It covers manual reviews, such as walkthroughs and inspections, and automated static analysis, such as linters and type checkers. Dynamic testing is its counterpart: it runs the program and observes how it behaves.
The longer version
The input is an artefact, not a running build. A reviewer reads a requirement and asks whether two sentences contradict each other. A team walks through a design and finds an error path nobody handled. A static analyser parses source code and reports an unused variable, a possible null dereference or a call to a function with the wrong argument types. None of these needs the system to start. Because the work product exists long before the software does, static testing can begin at the first written requirement.
Dynamic testing finds failures: the program runs and produces a wrong result. Static testing finds defects directly, in the text that would cause the failure, so the reviewer lands on the faulty line or sentence instead of working backwards from a symptom. That is why it suits faults that tests reach slowly, such as a requirement gap, an unreachable branch or a security flaw in a code pattern. It cannot show how the code performs under load or in a real browser, because nothing executes.
It fails through ritual and noise. Reviews turned into a signature step rubber-stamp the change. An analyser run with every rule on produces thousands of warnings, the team learns to ignore them, and the one that mattered is among them. A tool run once on the main branch and never in the pull request finds the defect after it has shipped. Findings from static analysis are also sometimes false alarms, so someone must read each before acting on it.
In a team's flow the checks sit before any test run: requirements are reviewed before design, code is analysed on every commit and read by a second person before merge. Dynamic tests then spend their time on behaviour that only shows when the software runs.
Common questions
What is the difference between static and dynamic testing?
Static testing examines work products such as requirements, designs and source code without running the software, through reviews and analysis tools. Dynamic testing executes the software and observes its behaviour. Static testing finds defects in the artefact; dynamic testing finds failures in the running system.
What are examples of static testing?
Reviewing a requirements document, a design walkthrough, a formal inspection, a code review in a pull request, and automated checks such as linters, type checkers and security scanners that read source code. All of them examine an artefact and none of them runs the program.
Is a code review static testing?
A code review is a static technique, since the reviewer reads the change and looks for defects without executing it. Walkthroughs and technical reviews of designs and requirements belong to the same family. Running the code during the review to see what happens makes that part dynamic.
When in the project is static testing done?
As soon as a work product exists, which is earlier than any other testing. Requirements are reviewed before design, designs before code, and code is analysed and reviewed before it merges. A defect found in a requirement costs a sentence to fix, where the same defect found in production costs a release.
Can static testing replace running the tests?
Static testing misses everything that only appears at runtime, such as performance under load, browser differences and the interaction between components. Dynamic tests miss defects in code paths they never reach. The two find different faults, and a team that drops either one leaves a whole category unchecked.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.