Manual Testing
Beginner 12 min read Manual Testing

Test Case Design Techniques

Black-box design techniques turn requirements into thorough, minimal test sets. Apply equivalence partitioning, boundary value analysis, decision tables, state transition and pairwise testing to maximize coverage per test case.

equivalence partitioningboundary value analysisdecision tablestate transitionpairwisetest data
Prerequisites: Testing Fundamentals
Introduction

What is this?

Test case design techniques systematically derive test cases from requirements instead of guessing. Equivalence partitioning splits inputs into classes that behave the same; boundary value analysis focuses on the edges of those classes, where defects cluster. Decision tables and state transition modeling capture complex business rules and stateful behavior that happy-path tests miss.

Motivation

Why do you need it?

  • They give structure to coverage: you know exactly what was tested and why.
  • Boundary analysis finds most range and off-by-one defects because they cluster at edges.
  • Equivalence partitioning shrinks suites dramatically — one representative per class instead of every value.
  • Decision tables catch combinations of conditions that linear step-through testing misses.
  • Pairwise testing tames combinatorial explosion: most defects are triggered by a pair of conditions.
Think about it

Mental model

Imagine

A locksmith testing keys

Think of

A tester applying boundary values

A locksmith does not try every key, only the ones at the edges of the plausible shape space — too short, too long, correct cut pattern. Testing works the same: verify the edges and one representative from the middle of each equivalence class.

Mechanics

How it works

  • Identify each input condition and partition it into valid and invalid equivalence classes.
  • Select one representative value from each class — one test case covers the whole class.
  • Add boundary value tests at the minimum, maximum, just above and just below each boundary.
  • For interacting conditions, build a decision table and write one test per unique rule column.
  • For stateful systems, model the state diagram and test each legal and illegal transition.

Equivalence partitioning and boundary value analysis applied to an age field (valid range 18-65).

Input: age (18-65)
Invalid: age < 18
Valid: 18-65
Invalid: age > 65
Boundaries 17/18/65/66
Execute ~6 focused cases
Reference

Key commands

pip install allpairspy

Install a Python library for pairwise (all-pairs) test generation.

curl -s -X POST https://staging.example.com/api/signup -H 'Content-Type: application/json' -d '{"age":17}'

Probe the invalid lower boundary (17) against the signup API.

{"errors":{"age":["Must be at least 18"]}}
curl -s -X POST https://staging.example.com/api/signup -H 'Content-Type: application/json' -d '{"age":18}'

Probe the first valid boundary (18).

{"ok":true}
curl -s -X POST https://staging.example.com/api/signup -H 'Content-Type: application/json' -d '{"age":65}'

Probe the upper valid boundary (65).

{"ok":true}
curl -s -X POST https://staging.example.com/api/signup -H 'Content-Type: application/json' -d '{"age":66}'

Probe the invalid upper boundary (66).

{"errors":{"age":["Must be at most 65"]}}
curl -s -X POST https://staging.example.com/api/signup -H 'Content-Type: application/json' -d '{"age":30,"plan":"pro","promo":"FRIENDS10"}' | jq '.discount'

Verify one decision-table rule end to end.

10
Hands-on

Examples

A decision table for a discount rule

A decision table for a discount rule
Conditions              | Rule 1 | Rule 2 | Rule 3 | Rule 4
Order amount > $100     |   Y    |   Y    |   N    |   N
Customer is premium     |   Y    |   N    |   Y    |   N
---------------------------------------------------------
Discount offered        |  20%   |  10%   |   5%   |   0%

Each column is one rule — a unique combination of conditions — and becomes a single test case. Rule 1 (premium plus large order) is the only case where the 20% tier applies; enumerating every combination proves the discount logic is complete and reveals exactly which column a failure belongs to.

Real world

In production

  • Boundary value analysis drives validation rules for passwords, loan amounts, age gates and tax brackets.
  • Decision tables encode business rules in insurance, banking and eligibility systems.
  • Pairwise testing keeps configuration matrices (OS x browser x currency) manageable.
  • State transition testing verifies order-lifecycle and workflow systems such as new, processing, shipped and cancelled.
Guidelines

Best practices

  • Start with equivalence partitioning to shrink the suite, then add boundaries to the surviving classes.
  • Always include invalid classes — how the system handles bad input is behavior too.
  • Design one test per decision-table column so failures map to a specific business rule.
  • Document which technique produced each test case so coverage is reviewable.
  • Trace every test case back to a requirement to keep traceability alive.
Watch out

Common mistakes

  • Testing only boundary values and skipping representative mid-class values.
  • Defining equivalence classes by guesswork instead of from the actual specification.
  • Forgetting invalid inputs and error-handling paths in the decision table.
  • Testing one field in isolation when the rules depend on combinations of fields.
Root cause analysis

Common issues

Error
A valid boundary value is rejected
Root cause

Wrong comparison operator (>= vs >) or a type mismatch (string vs number)

Fix

Confirm the operator and type in code; add boundary tests for each side of the limit.

Error
The decision table has 100+ rules
Root cause

Impossible combinations were kept and no simplification was applied

Fix

Merge rules with identical actions using boolean algebra, and mark impossible combinations out.

Error
The pairwise suite is still too large
Root cause

Too many levels per parameter

Fix

Reduce levels by merging equivalent options, such as browsers that share a rendering engine.

When things break

Debugging tips

  • When a boundary test fails, check the comparison operator (<= vs <) — off-by-one is the classic root cause.
  • Probe a failing boundary with values just inside and outside to confirm the exact cut-off.
  • Test the same data directly at the API to separate server-side from client-side validation.
  • Inspect the input regex or type conversion when a valid boundary value is rejected.
Interviews

Interview checkpoint

Practice

Hands-on lab

Design Test Cases for a Sign-Up Form
40 min · beginner
In progress
Objectives
  • Apply equivalence partitioning to a sign-up form
  • Add boundary value tests for ranged fields
  • Build and execute a decision table for a business rule
  • Record results mapped to the technique that produced them

Design Test Cases for a Sign-Up Form

40 min · beginner

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

An input field accepts integers from 1 to 100. Which of the following is a valid equivalence partition?

2

Boundary value analysis requires testing only the minimum and maximum valid values.

3

A system charges a 5% fee only when account type is 'business' AND balance exceeds $10,000. Which technique best models this rule?

Quick reference

Cheat sheet

Technique picker
One input, continuous rangeEquivalence partitioning + BVA
Multiple interacting conditionsDecision table
System changes state over timeState transition
Many parameters, few levelsPairwise testing
Data validity cut-offsBoundary value analysis
Experience-based guessingError guessing
Go deeper

Official documentation

Testsigma — Test Case Design Techniques
docs
Software Testing Help — How to Write Test Cases
docs
Software Testing Help — Decision Table Testing
docs
Software Testing Help — State Transition Testing
docs