iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Dynamic testing evaluates software by running it and observing what it does. It can reveal failures, unexpected results, crashes, or runtime security issues under the inputs and conditions a team chooses—but it cannot prove that untested behavior is defect-free.
What dynamic testing means
Dynamic testing is testing that involves executing the software or other test item. The ISTQB definition is quoted in a third-party lexicon mirror; see the ISTQB glossary entry as surfaced by MissionWares. In practical terms, a tester supplies inputs, runs an operation, and checks the resulting behavior.
Static testing examines work products without executing the software—for example, reviewing requirements or source code. Dynamic testing instead observes behavior during execution. The two approaches address different evidence: a code review can identify a suspicious condition without running it, while a dynamic test can show what happens when a particular input reaches a running program. See ASTQB’s explanation of static testing.
Dynamic testing is an activity, not a single tool or test level. It can be applied to a component, integrated system, API, or user-facing application. Its findings apply to the inputs, paths, conditions, build, and environment exercised—not to every possible use of the software.
What dynamic testing can reveal
Running software lets a team examine runtime outcomes, including changes that execution causes in the system. NIST describes dynamic analysis as executing software and monitoring resulting system changes; tests can use dangerous or incorrect inputs to exercise potential vulnerabilities. Its DevSecOps guidance, Appendix C, also cautions that dynamic analysis may be difficult to implement for some software and that execution can have dangerous effects.
- Functional failures: an operation produces the wrong result, fails to complete, or behaves differently than expected.
- Crashes and edge cases: unusual or invalid inputs trigger errors or expose fragile assumptions.
- Runtime security issues: a running application mishandles input, access, sessions, configuration, or errors in a way that creates risk.
- Operational faults: controlled fault injection can probe the effects of file corruption or resource, network, system, and user-interface failures. NIST lists these among the capabilities of dynamic analysis tools.
These are possibilities, not guaranteed outcomes. The cited sources do not establish a universal defect-reduction rate or cost saving, and a test result is evidence about the scenario run rather than proof that a system has no defects.
Dynamic testing technique families
ISTQB groups test techniques into black-box, white-box, and experience-based families. These describe how testers derive tests; they are not a list of test levels such as unit, integration, or acceptance testing. A team can combine them.
| Technique family | How tests are derived | Useful when |
|---|---|---|
| Black-box (specification-based) | From specified behavior, without relying on internal implementation details. | Checking required behavior that should remain valid even if the implementation changes. |
| White-box (structure-based) | From internal structure and processing; test design depends on knowledge of the design or implementation. | Exercising specific internal logic or structures. |
| Experience-based | From tester knowledge and experience. | Applying informed judgment to complement specification- and structure-based tests; effectiveness depends on tester skill. |
ASTQB’s ISTQB test-technique explainer describes these families. They can be used in dynamic testing when the resulting cases are executed.
Practical dynamic testing approaches
Predetermined test cases
Define inputs and expected outcomes in advance, then run the cases against the software. Include critical paths and, where safe, incorrect or dangerous inputs to see whether the system handles them as intended. A clear expected result makes it easier to distinguish a failure from behavior that is merely unexpected to the tester.
Fuzz testing
Fuzzing repeatedly supplies random, unexpected, or specially crafted inputs to look for edge cases and failures. It can explore many variations beyond a small set of hand-written cases, but useful results still depend on what component is reachable, which inputs are generated, and whether failures can be reproduced. NIST discusses fuzzing in its DevSecOps guidance.
Rank #4
Fault injection
Fault injection deliberately introduces a failure condition—such as a network or resource fault—to observe how the software responds. NIST’s Dynamic Analysis Tools resource also lists file corruption and system and user-interface fault injection. Because such tests can disrupt operations or damage data, they belong in an isolated, representative test environment, not on a live system.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsDynamic application security testing (DAST)
DAST interacts with a running application, often through automated black-box checks. ISTQB’s Security Test Engineer Syllabus v1.0.1 (2025) describes dynamic security testing areas including input validation, fuzzing, authentication and authorization, configuration and deployment, session management, error handling, and cryptography.
Best Value
Automation can make checks repeatable, including in a DevSecOps pipeline, but a scan is not comprehensive security assurance. The ISTQB syllabus says DAST does not reliably cover all issues in the OWASP Top 10 or SANS CWE Top 25. A scan should therefore be treated as one source of findings alongside other security testing, not as evidence that an application is secure.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to plan and interpret a dynamic test
- Define the question. Name the behavior or risk you want to assess and the result that would count as expected.
- Choose inputs and a technique. Derive cases from specified behavior, internal structure, or tester experience. Use fixed cases for known scenarios, fuzzing for varied inputs, or fault injection for controlled failures.
- Prepare a representative environment. Match relevant operating conditions, but isolate tests that could corrupt data, consume resources, or expose information. NIST recommends a test environment that mimics operations because dynamic analysis can have dangerous effects.
- Capture enough detail to reproduce findings. Record the build, environment, inputs, observed behavior, and reproduction steps. Without this context, a failure may be difficult to investigate.
- State the scope of the result. Report what paths and conditions were exercised, what was observed, and what remains untested. For DAST, explicitly avoid treating an automated scan as full coverage.
When comparing dynamic approaches or tools, focus on the risk targeted, visibility into internals, input-generation method, environment and setup needs, automation and repeatability, reproducibility of findings, and coverage limits. Those are practical comparison criteria, not a published ranking of tools.
What dynamic testing does not establish
A passing run means only that the exercised cases produced the observed results under the tested conditions. Unreached behavior, untried inputs, different environments, and failures outside the test’s scope may still contain defects. Dynamic testing is most useful when its findings are reported with that boundary clearly stated and combined with other ways of evaluating software.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
