Static Testing Basics
You don't always need to run the code to find bugs. This topic covers static testing - examining requirements, designs, and code by reading them - and why it's the backbone of catching defects as early as possible.
~8 min read
The core ideas, explained
Work Products Examinable by Static Testing
Static testing can be applied to almost any document or artifact produced during the SDLC - if it can be read, it can be statically tested. That includes requirement specifications (epics, user stories, business requirements), design and architecture artifacts (database schemas, UML diagrams, API specs), code itself (source code, configuration files, Infrastructure as Code scripts), testware (test plans, test cases, test data, automated scripts), and even user manuals and contracts, checked against the system's intended behavior.
Reviewing a user story and realizing it never says what should happen if a user enters a negative number - a defect caught by reading the story, long before anyone writes code against it.
The Value of Static Testing
Static testing delivers benefits dynamic testing can't achieve alone: early defect detection (a defect caught in a requirement costs pennies; the same defect caught in production costs thousands), detecting hidden defects that are difficult to find by running the software (dead code, architectural flaws, coding-standard violations, missing encryption), improving quality and maintainability by enforcing standards, reducing dynamic testing effort (fewer trivial crashes blocking testers from complex scenarios), and improving team communication, since reviewing work products together builds shared understanding across developers, testers, and business analysts.
A static analysis tool scans a Java codebase and flags a hardcoded password before the code is ever compiled - a security defect that might otherwise have shipped straight to production.
Differences Between Static and Dynamic Testing
Static and dynamic testing both aim to improve quality, but they are complementary, not interchangeable. Static testing finds the defect - the root cause - directly in the artifact; dynamic testing finds the failure, the observable incorrect behavior that a defect causes once the software actually runs. Static testing never executes the software; dynamic testing requires running it. Defects found statically are usually cheaper and faster to fix, since they're pinpointed directly in the source document or code, while dynamic testing requires debugging to trace a failure back to its root defect. And they measure different things: static testing measures adherence to standards (like requirement coverage or structural complexity); dynamic testing measures actual runtime behavior, performance, and memory use.
Static testing finds a direct contradiction in a requirements document (the defect). Dynamic testing later observes the application crashing when a specific button is clicked (the failure) - two different techniques, catching two different kinds of problems.
Key points to remember
- Static means no execution - the moment you're running the software, you're doing dynamic testing instead.
- Static testing finds defects directly; dynamic testing finds the failures those defects eventually cause.
- Testware is a work product too - test cases and automated scripts deserve review, just like application code.
- Static and dynamic testing are complementary, not competitive - neither replaces the other, since they catch different kinds of problems.
- Static testing is the primary technique behind Shift-Left, since it lets teams find defects before the software is ever run.
Terminology
A few terms from this topic worth knowing precisely.
Examining a work product - requirements, design, code, or testware - without executing it, typically through review or static analysis.
Testing that requires actually running the software and observing its behavior - the complement to static testing.
The underlying flaw or root cause present in a work product, such as a contradiction in a requirement or a bug in code.
The observable, incorrect behavior that appears when a defect is actually executed under the right conditions.
Any artifact produced during the SDLC that can be examined - a requirement, a design document, source code, or a piece of testware.
The practice of moving testing activities as early as possible in the SDLC, so defects are caught and prevented before they're built further into the system.
Automated, tool-driven static testing (e.g. a linter or a tool like SonarQube) that examines code or artifacts without a human manually reviewing them - as opposed to a manual review.
Code that can never be executed given the program's structure - notoriously hard to find by running the software, but often obvious during a static review.
Summary
Static testing evaluates work products - manually through reviews, or automatically through static analysis tools - without ever running the software. It's a powerful Shift-Left technique that catches defects directly at their source, whether in requirements, design, or code, drastically reducing the time and cost of late-stage debugging while also improving team communication and maintainability.
| Concept | One-line memory hook |
|---|---|
| Static testing | Testing by looking, reading, and analyzing - no execution |
| Work products | Any SDLC document - requirements, code, architecture, testware |
| Defects vs. failures | Static finds the actual bug; dynamic finds the crash it causes |
| Cost efficiency | Cheaper to fix a typo in a requirement than a bug in production |
| Hidden defects | Finds what dynamic testing misses - dead code, poor maintainability |
| Complementary approach | Static and dynamic are partners; neither replaces the other |
Check your understanding
10 quick questions - click an option to see if you got it right.