Test Methods and Types
This article is a glossary entry on test methods and their classification – including exam questions and tags.
In a Nutshell
Who tests? – Human (manual) vs. machine (automated), developer vs. user.
What is tested? – Unit (component), integration, system (E2E).
How is it tested? – Bottom‑Up/Top‑Down, static/dynamic, blackbox/whitebox, exploratory.
When is it tested? – Before/after, acceptance.
Why is it tested? – Regression, load/performance, smoke.
Compact Technical Description
Who tests?
- Developer: Unit, integration, contract, static analysis, TDD
- QA/Tester: System tests, E2E, exploratory tests, acceptance
- Machine: Automated regression, load tests, CI pipelines
What is tested?
- Unit test: isolated class/function
- Integration test: collaboration of components (DB, network)
- System/E2E test: complete user flow via UI & infrastructure
How is it tested?
- Bottom‑Up: small units first, then integration
- Top‑Down: stubs first, then real components
- Static: code analysis without execution (lint, security scan)
- Dynamic: code is executed (unit, integration, E2E)
- Blackbox: only via interfaces, no knowledge of internals
- Whitebox: knowledge of internal structure, branch/path coverage
- Exploratory: experience‑based, unscripted testing
When & Why
- Before (development phase): TDD, unit, static analysis
- After: System tests, acceptance, regression
- Regression: Ensure changes don’t break anything
- Load/stress: Check behavior under peak load
- Smoke: quick check that core functions work after deployment
Exam‑Relevant Key Points
- Test classification (Who, What, How, When, Why) clearly distinguished
- Unit vs. integration vs. E2E clearly separated
- Blackbox vs. whitebox applied (examples)
- Test doubles: stubs vs. mocks
- Characteristics of good unit tests (correct, isolated, fast, meaningful, maintainable)
- Test case derivation: equivalence classes, boundary value analysis, branch/path coverage
- Test process: selection, criteria, data, protocol, evaluation
- TDD: red‑green‑refactor cycle
- Regression, load, smoke as typical test types
Core Components
- Test classification (Who, What, How, When, Why)
- Test levels (unit, integration, system)
- Test approaches (bottom‑up, top‑down, blackbox, whitebox)
- Test doubles (stub, mock, fake, spy)
- Test case derivation (equivalence classes, boundary values, coverage)
- Test automation (frameworks, CI, reporting)
- Test data management (fixtures, factories, seed)
- Test process (planning, execution, evaluation, protocol)
- Quality assurance (reviews, audits, metrics)
- Tools (test frameworks, mock libraries, CI/CD)
Practical Example (Order Processing)
Unit (Whitebox):
- Class: DiscountService
- Method: calculateDiscount(customer, item)
- Test case: New customer, standard item → expect 0%
- Coverage: all branches (customer type, item type)
Integration (Blackbox):
- Components: service → repository → DB
- Test: save/read an order with real DB container
- Criterion: persisted data = expected data
E2E (Top‑Down):
- Flow: browser → portal → API → DB → message broker
- Scenario: place order, simulate payment
- Expectation: confirmation visible, DB entry, event
Regression (automated):
- Before: order with 5 items, 10% discount → €110
- After: same scenario → must remain €110
Load test:
- Load profile: 500 users simultaneously, 10 s
- Criterion: 95th percentile response time <300 ms, no errors
Smoke:
- After deployment: login, search items, add to cart
- Criterion: all 3 actions successful
Advantages and Disadvantages
Advantages
- Systematic coverage of risks
- Early error detection (unit/TDD)
- Traceable quality (regression tests)
- Reduced failure costs (load tests)
Disadvantages
- Effort for test maintenance
- Flaky tests with unclear dependencies
- Focus on “numbers” instead of value without clear goals
Typical Exam Questions (with Short Answer)
- Blackbox vs. whitebox? Blackbox: only via interfaces; whitebox: knowledge of internal structure.
- Unit vs. integration? Unit: isolated; integration: real collaboration of components.
- What is TDD? Test‑driven development: red (test fails) → green (test passes) → refactor.
- Characteristics of good unit tests? Correct, isolated, fast, meaningful, maintainable, easy to run.
- Test case derivation methods? Equivalence classes, boundary value analysis, branch/path coverage.