Takeaways:
- Static testing reviews code, documents, and designs without running software. Dynamic testing executes software and observes its behavior. They catch different defect types at different stages.
- Capers Jones' research found that testing alone (dynamic) has a defect removal ceiling of about 50%. Adding static analysis and code inspections is only path to 95%+ removal efficiency.
- Smoke testing, white box testing, and unit testing all fall under dynamic testing. Code reviews, static analysis, and requirements walkthroughs fall under static. Most QA teams lean heavily toward one side and underinvest in other.
Static testing vs dynamic testing comes down to one question: are you running software or not? Static testing examines artifacts (code, requirements, design docs) without executing anything. Dynamic testing runs application and checks whether it behaves correctly.
Both find bugs. They find different bugs, at different costs, at different points in development cycle.
What static testing catches
Static testing looks at source material before execution. No builds, no environments, no test data required. The techniques include:
- Code reviews and inspections: Developers or peers read through code manually, looking for logic errors, security flaws, standards violations, and unclear intent.
- Static analysis tools: Automated scanners that parse source code and flag issues like null pointer risks, unused variables, unreachable code, race condition patterns, and security vulnerabilities.
- Requirements reviews: Walkthroughs of spec documents to catch ambiguity, contradictions, missing edge cases, and untestable requirements before any code is written.
- Design reviews: Evaluating architecture documents for scalability gaps, coupling issues, and misaligned data flows.
Static analysis tools by language:
- Java: SonarQube, SpotBugs, PMD
- JavaScript/TypeScript: ESLint, SonarQube
- Python: Pylint, Bandit (security), Ruff
- Swift: SwiftLint
- Kotlin: Detekt, Ktlint
The bugs static testing catches tend to be structural: dead code, security holes, standards violations, spec ambiguities. These defects exist before application ever runs, and they're cheaper to fix at this stage. According to Code Complete by Steve McConnell, formal code inspections find an average of 60% of defects, while informal reviews catch less than 50%.
What dynamic testing catches
Dynamic testing runs application. Every type of test that involves executing code is dynamic, including:
- Unit tests: Test individual functions or methods in isolation. Fast, cheap, developer-owned. This is white box testing at smallest scope: tester knows internal code structure.
- Integration tests: Test how two or more components interact over real connections (APIs, databases, message queues).
- Smoke tests: A quick pass over application's critical paths to confirm build is stable enough for deeper testing. Smoke testing answers one question: "Is this build worth testing further?"
- System tests: Full application tested against requirements in an environment that resembles production.
- Acceptance tests (UAT): End users or product owners verify software meets business needs.
- Performance and load tests: Execute application under simulated traffic to find bottlenecks, memory leaks, and breaking points.
Dynamic testing catches behavioral bugs: wrong outputs, broken workflows, crashes under load, race conditions that only appear at runtime, and UI defects that static analysis can never see.
Static testing vs dynamic testing: comparison
Why static testing and dynamic testing need each other
Capers Jones' research across thousands of software projects measured how effective each testing approach is at removing defects before release:
- Dynamic testing alone (all test stages combined): ~50% defect removal efficiency
- Adding static analysis: pushes removal to 55-65%
- Adding formal code inspections: pushes removal to 85%+
- Combining all three (inspections + static analysis + dynamic testing): only path to 97%+ removal
The takeaway is blunt: teams that skip static testing and rely entirely on running tests will miss roughly half of all defects. No amount of additional test automation closes that gap. The defect types that static analysis and inspections catch (requirements misunderstandings, logic errors visible in code, security patterns) simply don't surface during execution-based testing.
For QA leads, this means automated regression testing is necessary but not sufficient. Pair it with mandatory code reviews and static analysis on every PR, and defect escape rate drops.
Where common test types sit on spectrum
Teams often search for specific test types without realizing they fall under one of these two categories. A quick map:
Static testing:
- Code reviews (manual and automated)
- Static analysis (SonarQube, ESLint, SpotBugs)
- Requirements walkthroughs
- Design document inspections
- Compliance audits against coding standards
Dynamic testing:
- Unit tests
- Integration tests
- Smoke testing (quick build verification)
- Regression tests
- Performance and load tests
- White box testing (examining internal logic while executing)
- Black box testing (testing from user's perspective)
- User acceptance testing (UAT)
- Exploratory testing
White box testing is worth calling out specifically. It's dynamic (code runs), but tester uses knowledge of internal code structure to design test cases. Static analysis also looks at code structure, but without executing it. The distinction is execution: white box testing runs code and checks outputs, static analysis reads code and checks patterns.
How Drizz handles dynamic testing on mobile
Drizz operates on dynamic testing side, specifically at E2E and regression layers for mobile apps. It runs application on a real device and validates what appears on screen.
A smoke test in Drizz for a post-deploy check:
Launch app
Validate "Home" is visible
Tap on "Search"
Type "running shoes" in search field
Validate search results are visible
Tap on first product
Validate "Add to Cart" is visible
Seven steps. Runs in under a minute on a real device. Confirms build is functional across critical path. If any service behind app is down or returning errors, this smoke test surfaces it immediately.
For deeper dynamic testing, Drizz supports:
- Full regression suites across multiple devices in parallel via Drizz Cloud
- Conditional logic (IF/ELSE) for testing different app states
- Adaptive wait logic that replaces explicit sleep timers
- A built-in popup agent that handles permission dialogs and system alerts without extra code
Static analysis tells you code is clean. Drizz tells you app works on device in your user's hand. Different questions, both worth answering.
FAQ
What is difference between static and dynamic testing?
Static testing reviews code and documents without execution. Dynamic testing runs software and checks its behavior and outputs.
Is smoke testing static or dynamic?
Dynamic. Smoke testing executes application to verify build is stable enough for further testing.
Is white box testing static or dynamic?
Dynamic. It runs code, but tester uses knowledge of internal structure to design test cases.
Can static testing replace dynamic testing?
No. Static testing catches structural and specification defects. Dynamic testing catches behavioral and runtime bugs. Both are needed.
What static analysis tools should QA teams use?
SonarQube for multi-language coverage, ESLint for JavaScript, SpotBugs for Java, Pylint for Python, SwiftLint for Swift.
How much do static and dynamic testing overlap?
Minimally. Research from Capers Jones shows each approach catches different defect types, which is why combining them exceeds 95% removal.
