Testing Methods and Types
This post is a glossary entry on testing methods and their classification—including exam questions and tags.
In a Nutshell
Who tests? – Human (manual) vs. machine (automated), developer vs. end user.
What gets tested? – Unit (component), integration, system (E2E).
How to test? – Bottom‑up/top‑down, static/dynamic, black-box/white-box, exploratory.
When to test? – Before/after, acceptance.
Why test? – Regression, load/performance, smoke.
Core Overview
Who Tests?
- Developers: Unit tests, integration tests, contract tests, static analysis, TDD
- QA/Testers: System tests, E2E tests, exploratory testing, acceptance testing
- Machines: Automated regression, load testing, CI pipelines
What Gets Tested?
- Unit test: isolated class or function
- Integration test: cooperation between components (database, network)
- System/E2E test: complete user journey across UI and infrastructure
How to Test?
- Bottom‑up: small units first, then integration
- Top‑down: stubs first, then real components
- Static: code analysis without execution (linting, security scanning)
- Dynamic: code is executed (unit, integration, E2E)
- Black-box: interface-only, no knowledge of internals
- White-box: knowledge of internal structure, branch/path coverage
- Exploratory: experience-based, unscripted testing
When and Why
- Before (development phase): TDD, unit tests, static analysis
- After: system tests, acceptance testing, regression
- Regression: ensure changes don’t break existing functionality
- Load/stress: verify behavior under peak load
- Smoke: quick check that core features work after deployment
Exam-Relevant Checklist
- Test classification (who, what, how, when, why) must be clearly distinguished
- Unit vs. integration vs. E2E must be well-defined
- Black-box vs. white-box with 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, black-box, white-box)
- 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 (white-box):
- Class: DiscountService
- Method: calculateDiscount(customer, item)
- Test case: new customer, standard item → expect 0%
- Coverage: all branches (customer type, item type)
Integration (black-box):
- Components: service → repository → database
- Test: save and read an order with real database container
- Criterion: persisted data equals expected data
E2E (top‑down):
- Flow: browser → portal → API → database → message broker
- Scenario: place order, simulate payment
- Expectation: confirmation visible, database entry, event
Regression (automated):
- Before: order with 5 items, 10% discount → 110 €
- After: same scenario → must remain 110 €
Load test:
- Load profile: 500 concurrent users, 10 s
- Criterion: 95th percentile response time <300 ms, no errors
Smoke:
- Post-deployment: login, search items, add to cart
- Criterion: all 3 actions succeed
Strengths and Weaknesses
Strengths
- Systematic coverage of risks
- Early defect detection (unit/TDD)
- Traceable quality (regression tests)
- Lower failure costs (load tests)
Weaknesses
- Effort to maintain tests
- Flaky tests with unclear dependencies
- Focusing on “numbers” rather than value without clear goals
Typical Exam Questions (with Brief Answer)
- Black-box vs. white-box? Black-box: interface-only; white-box: knowledge of internal structure.
- Unit vs. integration? Unit: isolated; integration: real cooperation between 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.