Test Case Design Techniques: Equivalence Partitioning, Boundary Values, Decision Tables and State Transitions

Four proven techniques that tell you exactly which test cases to write, worked through on one real feature.

For QA engineers who want a systematic way to choose test cases, and leads who want the same rigour across a team.

Why Design Techniques Matter

Design techniques turn a requirement into a short, complete list of test cases. They group values that behave the same way and point you to the places that deserve the closest attention: the edges of ranges, combinations of rules, and changes of status.

The result is a smaller set of cases with better coverage, and a set you can explain. When someone asks why a case exists, the answer is a partition, a boundary, a rule, or a transition.

Every example on this page uses one feature: a promo code field at checkout. Codes are 6 to 12 letters or digits, a minimum order of 50.00 applies, first orders get 15% off, and other orders get 10% off.

Equivalence partitioning

Group inputs that the system treats the same way, then test one value per group.

Boundary value analysis

Test the values at and next to each limit, where off-by-one errors live.

Decision tables

List every combination of conditions and the outcome each one should produce.

State transitions

Map the statuses an object moves through and test each allowed and blocked move.

1. Equivalence Partitioning

Split each input into partitions: groups of values the system should treat identically. If one value in a partition works, the others should too, so one representative value per partition is enough. Always include the invalid partitions; they are where validation messages get tested.

Input	Partition	Valid?	Test value
Code length	Fewer than 6 characters	Invalid	SAVE1
Code length	6 to 12 characters	Valid	SPRING25
Code length	More than 12 characters	Invalid	SPRINGSALE2026X
Characters	Letters and digits only	Valid	WELCOME10
Characters	Contains a space or symbol	Invalid	SAVE-25
Presence	Empty field	Invalid	(blank)

Six partitions give six cases. Testing an invalid partition on its own matters: a code that is both too short and contains a symbol would only show you one of the two error messages.

2. Boundary Value Analysis

Defects cluster at the edges of partitions, usually because a developer wrote < where the rule needed <=. Boundary value analysis tests each limit with the value just below it, the value at it, and the value just above it.

Limit	Just below	At the limit	Just above
Minimum length (6)	5 characters: rejected	6 characters: accepted	7 characters: accepted
Maximum length (12)	11 characters: accepted	12 characters: accepted	13 characters: rejected
Minimum order (50.00)	49.99: no discount	50.00: discount applied	50.01: discount applied

Use the smallest step the field allows: one character for lengths, one cent for amounts, one day (or one minute) for dates. The 49.99 case is the one that usually finds the bug.

3. Decision Tables

When the outcome depends on several conditions at once, list the conditions as rows and each combination as a column, called a rule. Use Any where a condition makes no difference to collapse rules that share an outcome. Each remaining column becomes one test case.

Condition	Rule 1	Rule 2	Rule 3	Rule 4
Code recognised	Yes	Yes	Yes	No
First order	Yes	No	Any	Any
Cart total at least 50.00	Yes	Yes	No	Any
Outcome	15% off	10% off	Message: Minimum order 50.00	Message: Code not recognised

Three yes/no conditions have eight raw combinations; collapsing gives four rules and four cases. A decision table also exposes gaps in the requirement itself: if nobody can fill in an outcome cell, the rule was never specified, and that question belongs with the Product Owner before testing starts.

4. State Transition Testing

Some objects move through statuses: orders, subscriptions, approvals, promo codes. List each status, the events that move it, and the status it lands in. Test every valid transition, then the invalid ones that matter most, where an event should change nothing.

From	Event	To	What to check
Scheduled	Start date reached	Active	Code is accepted from the first minute of the start date.
Active	End date passes	Expired	Code is rejected with an expiry message.
Active	Usage limit reached	Exhausted	The redemption that hits the limit succeeds; the next one is rejected.
Active	Admin disables code	Disabled	Code is rejected immediately, including in open carts.
Disabled	Admin re-enables code	Active	Code is accepted again within its dates.
Expired	Customer applies code	Expired (no change)	Invalid transition: the code stays expired and is rejected.

The usage limit row combines two techniques: the redemption that reaches the limit is a boundary inside a state transition.

A Note on Pairwise Testing

When settings multiply

Three browsers, three payment methods, and two customer types make 18 combinations. Most combination defects involve just two settings interacting, so a pairwise set, where every pair of values appears in at least one case, covers them in about 9 cases. Use it for configuration and environment coverage, alongside the techniques above.

Which Technique for Which Requirement

Most features need more than one technique. Read each acceptance criterion and match it to the pattern it describes:

If the requirement says...	Use	You get
A field accepts a range or a set of formats	Equivalence partitioning	One case per valid and invalid group
A rule has a number, length, date, or amount limit	Boundary value analysis	Cases just below, at, and just above each limit
The outcome depends on several conditions together	Decision table	One case per rule (column)
An object moves through statuses over time	State transition	One case per valid transition, plus key invalid ones
Many settings combine (browser, role, payment method)	Pairwise	A small set that covers every pair of values

Writing each case well once you know which ones you need is a separate skill, covered in How to Write Test Cases That Actually Catch Bugs.

Using the Techniques with AI Test Generation

Design techniques and AI generation work well together: the techniques define what a complete set looks like, and generation drafts the cases quickly. In Evaficy Smart Test:

Put the partitions and limits in the Requirement field

Text in the Requirement custom field is mandatory for generation: every case must respect it, and the set must cover it. Writing "codes are 6 to 12 letters or digits; minimum order 50.00" there gives the generator the exact edges to work from.

Run a Boundary Edge Case pass for the limits

Choose the Boundary Edge Case test type to ask for cases focused on limits and edge values, and Functional for the decision table rules.

Review the result against your tables

Tick each partition, boundary, rule, and transition off against the generated cases. Anything left unticked becomes a case you add by hand or the focus of another pass.

For more on shaping generation inputs, see Writing Effective Inputs for AI Generation.

Common Questions

Are these black-box or white-box techniques?

All four are black-box techniques: they are derived from the requirement and the observable behaviour, so testers can apply them without reading the code.

Should I test two or three values per boundary?

Two values (at the limit and just past it) catch most off-by-one errors. Adding the value just inside the limit is worth it for high-risk rules such as prices, permissions, and dates.

Do I need all four techniques on every feature?

Use the ones the requirement calls for. A simple form may only need partitions and boundaries; a pricing rule needs a decision table; a workflow needs state transitions.

How do these relate to test types like Regression or Smoke?

Test types describe the purpose of a suite; design techniques describe how to choose the cases inside it. See Software Testing Types Explained for the types themselves.

Related reading: Software Testing Types Explained.

Key Takeaways

Equivalence partitioning: one test value per group of inputs the system treats the same, valid and invalid.
Boundary value analysis: test just below, at, and just above every limit, using the smallest step the field allows.
Decision tables: one case per combination of conditions, collapsed with Any where a condition does not matter.
State transitions: one case per valid status change, plus the invalid changes that must be blocked.
Pairwise testing keeps configuration combinations to a manageable set.
Write partitions and limits into the Requirement field, then review generated cases against your tables.

Put the techniques to work on your own feature

Create your free account, add your limits to the Requirement field, and generate a boundary-focused set to review. The Basic plan includes 5 AI generations.

Create your free account