Catalog
concept#Quality Assurance#Reliability#Observability#Software Engineering

Test Design Techniques

Overview of established test design techniques for systematically deriving and prioritizing test cases from requirements and system states.

Test design techniques provide structured approaches to selecting and composing test cases based on requirements, specifications, and system states.
Established
Medium

Classification

  • Medium
  • Technical
  • Design
  • Intermediate

Technical context

Continuous Integration (e.g. Jenkins, GitHub Actions)Test management tools (e.g. TestRail, PractiTest)Requirement management / issue tracker (e.g. Jira)

Principles & goals

Tests should map directly to requirements and risks.Combining multiple techniques improves defect detection.Automatability and maintainability must be considered in design decisions.
Build
Team, Domain

Use cases & scenarios

Compromises

  • Wrong prioritization leads to insufficient risk coverage.
  • Oversized test suites increase run-time and maintenance costs.
  • Excessive focus on automation can neglect exploratory testing.
  • Combine techniques (equivalence, boundary, state models) instead of relying on a single method.
  • Prioritize tests by risk and business criticality.
  • Automate deterministic tests and keep exploratory tests manual.

I/O & resources

  • Requirement specification or user stories
  • System or component specifications
  • Existing tests and CI results
  • Prioritized list of test cases
  • Automated test suites or scripts
  • Mapping between tests and requirements/risks

Description

Test design techniques provide structured approaches to selecting and composing test cases based on requirements, specifications, and system states. They reduce redundant tests, increase defect detection probability, and support risk-based testing. Practitioners must balance technique choice, test scope, and degree of automation.

✔

  • Higher defect detection rate through systematic test derivation.
  • Reduction of redundant tests and more efficient test scope.
  • Better traceability of tests to requirements.

✖

  • Not all techniques suit highly exploratory or UI-heavy tests.
  • Requires effort to model and maintain test cases.
  • Edge cases can be missed if technique selection is inappropriate.

  • Defect detection rate

    Share of defects found per number of executed tests or requirements.

  • Test coverage (requirements)

    Percentage of requirements covered by test cases.

  • Mean Time to Detect (MTTD)

    Average time to detect a defect after a change is introduced.

E-commerce Checkout Module

Use of boundary value analysis and state transition tests to secure payment and shipping logic.

REST API Validation

Requirement-based testing of the specification, plus equivalence classes for input variants.

Order Status State Machine

State-oriented tests to cover all valid and invalid transitions.

1

Analyze requirements and identify critical areas

2

Select suitable test design techniques per area

3

Derive concrete test cases and map them to requirements

4

Automate, prioritize and integrate into CI

5

Measure, review and iteratively adjust the test base

⚠️ Technical debt & bottlenecks

  • Fragmented tests without a common design principle.
  • Insufficient automation coverage of critical paths.
  • Outdated test data and lack of environment isolation.
Test runtimeMaintenance effortWrong prioritization
  • Creating extensive test sets for low-criticality functions.
  • Using a single technique (e.g. only equivalence classes) everywhere.
  • Not adapting tests to changed requirements.
  • Overestimating automatability of complex scenarios.
  • Ignoring non-functional requirements in test design.
  • Missing linkage between tests and requirements/risks.
Basic knowledge of test methodology and designDomain understandingExperience with automation frameworks
Coverage of critical pathsFast feedback cycles in CI/CDMaintainability and stability of tests
  • • Limited test time budget before release
  • • Legacy code complicates isolated testing
  • • Partially missing or unclear requirements