Test case design

Since exhaustive testing is impossible, test case design is about choosing the subset of tests most likely to find defects with the least effort. These are the fundamental black-box techniques.

Equivalence partitioning

Divide the inputs into groups (partitions) where the system should behave the same, and test a single representative value from each group.

Example: a "contracted bandwidth" field (in Mbps) that accepts 100 to 1000.

Partition	Range	Test value	Valid?
Below minimum	< 100	50	❌ Invalid
Accepted	100–1000	500	✅ Valid
Above maximum	> 1000	2000	❌ Invalid
Non-numeric	"abc"	"abc"	❌ Invalid
Empty	—	""	❌ Invalid

With 5 cases I cover what would be infinite by brute force. Careful: invalid partitions are tested one at a time, so one rejection doesn't mask another.

Boundary value analysis

Bugs live at the edges: the classic > that should have been >=. For each boundary you test the boundary value itself and its immediate neighbors.

For the 100–1000 range: test 99, 100, 101 and 999, 1000, 1001.

This technique is always combined with the previous one: partitions to cover the groups, boundaries to sharpen the edges.

Decision tables

When behavior depends on combinations of conditions, a decision table guarantees no combination slips through.

Example: convergence discount at a telecom operator (a customer adding a mobile tariff).

Condition	R1	R2	R3	R4
Has fiber contracted?	Yes	Yes	No	No
Adds a second mobile line?	Yes	No	Yes	No
Result: discount on the mobile fee	20%	10%	5%	0%

Each column (rule) is a test case. With N binary conditions there are 2^N combinations; you can then collapse the ones that lead to the same result.

State transition

For systems with states (a service order: created → validated → provisioning → active), you model the states and the valid transitions, and test:

• Every valid transition (transition coverage).
• The invalid transitions: what happens if I try to cancel a service order that's already active?

Pairwise (combinatorial)

When there are too many parameters to test every combination (browser × OS × language × currency…), pairwise generates the minimal set of cases covering every pair of values. The empirical justification: the vast majority of combinatorial defects are triggered by the interaction of just 2 parameters.

How I choose the technique

Situation	Technique
Field with numeric or date ranges	Partitions + boundary values
Business rules with several conditions	Decision table
Flows with states and transitions	State transition
Configuration explosion	Pairwise
Ambiguous requirements or unknown territory	Exploratory testing