What Is Dynamic Testing?

Dynamic testing is the process of evaluating software by executing it. You provide inputs to the running system, it processes them, and you observe whether the actual outputs and behaviors match expectations.

Every time you click a button in an application and check whether it did the right thing, you are performing dynamic testing. Every time an automated test framework launches a browser, fills in a form, and asserts the result, that is dynamic testing.

The key word is execution. If the code runs, it is dynamic. If you only read or analyze the code (or any other artifact) without running it, that is static.

How Dynamic Testing Complements Static Testing

Static and dynamic testing are not competitors — they are partners. Each catches defects the other cannot.

Static testing finds: Coding standards violations, unreachable code, potential null pointer issues, security patterns (like SQL concatenation), requirements ambiguities, design inconsistencies.

Dynamic testing finds: Actual runtime failures, performance bottlenecks, memory leaks under load, integration failures between real components, user experience problems, race conditions, environment-specific issues.

The Complementary Relationship

graph TB subgraph Static Testing S1[Requirements Review] S2[Code Review] S3[Static Analysis Tools] end subgraph Dynamic Testing D1[Unit Testing] D2[Integration Testing] D3[System Testing] D4[Performance Testing] end S1 -->|Validates requirements before| D3 S2 -->|Catches code issues before| D1 S3 -->|Identifies patterns before| D2 style S1 fill:#60a5fa,color:#000 style S2 fill:#60a5fa,color:#000 style S3 fill:#60a5fa,color:#000 style D1 fill:#34d399,color:#000 style D2 fill:#34d399,color:#000 style D3 fill:#34d399,color:#000 style D4 fill:#34d399,color:#000

A practical example: Static analysis can detect that a SQL query is built using string concatenation (potential SQL injection). But only dynamic testing can confirm that a crafted input actually exploits the vulnerability by running the application with malicious input and observing the result.

Static vs. Dynamic Testing: Comparison

DimensionStatic TestingDynamic Testing
Code executionNoYes
When possibleFrom requirements phaseFrom implementation phase
Typical activitiesReviews, walkthroughs, static analysisUnit tests, integration tests, system tests
Environment neededNone (just the artifact)Runtime environment required
Defect types foundStandards violations, potential bugs, design issuesActual failures, performance issues, integration bugs
Cost to find defectsLower (earlier in SDLC)Higher (requires environment, execution)
Feedback speedFast (minutes for tools)Varies (seconds for unit, hours for E2E)
Can find runtime issuesNo (predicted only)Yes (observed directly)
Can verify non-functional requirementsLimitedYes (performance, usability, reliability)

Dynamic Testing Techniques Overview

Dynamic testing encompasses many techniques that you have encountered (or will encounter) throughout this module:

By code knowledge:

  • Black-box (Lesson 2.27) — Tests based on requirements, no code knowledge
  • White-box (Lesson 2.26) — Tests based on code structure
  • Grey-box (Lesson 2.28) — Tests with partial internal knowledge

By testing level:

  • Unit testing — Testing individual components
  • Integration testing — Testing component interactions
  • System testing — Testing the complete application
  • E2E testing — Testing full user workflows
  • Acceptance testing — Business validation

By testing purpose:

  • Functional testing — Does it do what it should?
  • Performance testing — Does it perform well enough?
  • Security testing — Is it secure?
  • Usability testing — Is it user-friendly?
  • Reliability testing (Lesson 2.25) — Does it work consistently over time?

By approach:

  • Scripted testing — Pre-designed test cases executed step by step
  • Exploratory testing (Lesson 2.32) — Simultaneous learning, design, and execution
  • Ad hoc testing (Lesson 2.33) — Unplanned, intuition-based testing

When to Start Dynamic Testing

A common misconception is that dynamic testing starts only after the full application is built. In reality, dynamic testing should begin as soon as there is executable code:

SDLC PhaseDynamic Testing Activity
ImplementationDevelopers write and run unit tests
IntegrationIntegration tests verify component interactions
System testingQA executes functional and non-functional tests
UATBusiness users validate in a production-like environment
ProductionSmoke tests, synthetic monitoring, chaos engineering

In Agile teams, all of these happen within a single sprint. A developer writes a function, adds a unit test, pushes the code, integration tests run in CI, and QA tests the feature — all within days.

The Dynamic Testing Process

Regardless of the specific technique, dynamic testing follows this cycle:

  1. Plan — Identify what to test, select techniques, prepare test data
  2. Design — Create test cases with inputs, steps, and expected results
  3. Set up — Prepare the test environment, deploy the build, configure test data
  4. Execute — Run the tests, observe actual results
  5. Compare — Compare actual results with expected results
  6. Report — Document findings: pass, fail, or blocked
  7. Retest — After fixes, verify the defect is resolved

Exercise: Classify Testing Activities

For each activity below, classify it as static or dynamic testing and explain your reasoning.

  1. A developer runs pytest to execute unit tests for a Python module
  2. A QA engineer reads through a user story to check if all acceptance criteria are clear and testable
  3. SonarQube scans a Java project and reports 15 code smells
  4. A tester opens the web application, enters valid credentials, and verifies successful login
  5. A team conducts a code walkthrough for a new payment processing module
  6. An automated Playwright test navigates to the checkout page and verifies the total price
  7. A security tool (SAST) scans the codebase for hardcoded API keys
  8. A performance test tool sends 1,000 concurrent requests to an API endpoint and measures response times
  9. A developer reads a pull request diff and comments on the error handling approach
  10. A QA engineer runs Postman to send a POST request to the /users API and checks the response status code
  11. An ESLint configuration checks for unused variables across the project
  12. A mobile tester installs the app on a device, opens it, and tests the onboarding flow
HintThe single question to ask: "Does the software need to be running for this activity?" If yes → dynamic. If the activity only examines an artifact (code, document, configuration) without running it → static.
Solution

  1. Dynamic — pytest executes the code and checks actual outputs against expected values. The software runs.

  2. Static — The QA engineer reads a document (user story) without executing any software. This is a requirements review.

  3. Static — SonarQube analyzes source code without executing it. It reads the code files and applies rules to find patterns.

  4. Dynamic — The tester interacts with the running application, providing inputs and checking outputs.

  5. Static — A code walkthrough is a review activity where the team reads and discusses code without executing it.

  6. Dynamic — Playwright launches a browser, the application runs, and the test interacts with the live UI.

  7. Static — SAST (Static Application Security Testing) scans source code without executing it, looking for patterns like hardcoded secrets.

  8. Dynamic — The performance tool sends real HTTP requests to a running application and measures actual response times.

  9. Static — The developer reads code (the PR diff) and provides feedback without executing anything.

  10. Dynamic — Postman sends an actual HTTP request to a running API server and receives a real response.

  11. Static — ESLint reads JavaScript/TypeScript source files and checks them against rules without executing the code.

  12. Dynamic — The tester runs the actual app on a real device and interacts with it.

Summary: Activities 1, 4, 6, 8, 10, 12 are dynamic (code executes). Activities 2, 3, 5, 7, 9, 11 are static (no execution).

Why Both Matter: A Real-World Example

Consider a function that calculates shipping costs:

Static analysis might find:

  • The function has a cyclomatic complexity of 25 (too high, hard to maintain)
  • A variable is assigned but never used
  • A branch condition is always true (dead code)

Code review might find:

  • The function does not handle international shipping (missing requirement)
  • The discount logic contradicts the product requirements document

Dynamic unit test might find:

  • For an order of $49.99, free shipping was incorrectly applied (boundary value bug)
  • Negative quantities result in a negative shipping cost instead of an error

Dynamic integration test might find:

  • The shipping service returns weights in kilograms but the calculator expects pounds
  • When the external shipping API times out, the function hangs instead of returning a default

Each technique reveals different problems. Relying on only one leaves significant gaps.

Key Takeaways

  • Dynamic testing requires executing the software; static testing does not
  • Both approaches are essential — they catch different types of defects at different costs
  • Dynamic testing begins as soon as there is executable code, not only after the full application is built
  • Static testing catches potential issues earlier and cheaper; dynamic testing confirms actual behavior
  • Non-functional requirements (performance, security, reliability) can only be fully validated through dynamic testing
  • Modern teams combine static analysis in CI with dynamic tests at multiple levels for comprehensive quality assurance