Not all testing requires running the software. Static testing examines the work products without executing them; dynamic testing exercises the running system. Both find different kinds of defects, which is why strong teams use them together.
Static Testing
- No code execution.
- Reviews, walkthroughs, inspections.
- Static analysis tools / linters.
- Finds defects early — in requirements, design, and code.
Dynamic Testing
- Code is executed.
- Unit, integration, system, acceptance tests.
- Observes actual behaviour and outputs.
- Finds defects that only appear at run time.
The power of catching defects early
Static testing is remarkably cost-effective because it can find problems before a single line of code runs — an ambiguous requirement, a flawed design, a risky piece of logic. Dynamic testing then confirms that the running system actually behaves correctly. The two are complementary, not competing.
Tip: a code review (static) might catch a logic error the author overlooked, while a test run (dynamic) catches an integration problem no reviewer could predict. You want both nets.
Conclusion
Static testing inspects; dynamic testing executes. Using both means you catch defects at the cheapest possible moment and confirm real behaviour at run time — a combination that no single approach can match.