Stop 02 · Manual Testing FundamentalsTopics · 3/11

Test Case Design Techniques

In short

You can't test every possible input. Design techniques help you pick a small set of tests that still catches most bugs, instead of guessing.

Structured methods for deriving effective test cases from requirements — rather than guessing randomly, techniques like equivalence partitioning and decision tables systematically cover the input space.

The purple blob as a teacher picks a few cards out of a big pile of question cards on a desk.

Think of it like this

Picking questions for a test paper

A teacher can't ask every question in the textbook. So she picks one from each chapter, a couple of tricky ones at the edges of the syllabus, and the ones students always get wrong. That's test design.

Watch it happen

The main design techniques

Test design

Spec-based

Experience

Equivalence

Boundaries

Decision table

State transition

Error guessing

1/5Spec-based (black box) techniques work from the requirement, not the code.

The big ideas

What you need to know

Fewer, smarter tests

The goal is the most bugs found per test, not the most tests.

Decision tables for rules

When behaviour depends on several yes/no conditions, a table makes sure no combination is forgotten.

States for workflows

Anything with a status (orders, tickets, accounts) benefits from testing allowed and forbidden moves.

Experience fills gaps

Techniques give coverage. Your instinct for what usually breaks finds the rest.

See it in code

Walk through the code

text

1Rule:  Free delivery if logged in AND cart >= 4992 3              R1     R2     R3     R44Logged in     Y      Y      N      N5Cart >= 499   Y      N      Y      N6Delivery fee  0      40     login  login7                                   prompt

1/3Start from the business rule in the requirement.

A decision table: two conditions give four combinations, and each column becomes one test case.

Save yourself the pain

Common mistakes

Oops

Writing tests only for the happy path the developer showed you.

Do this instead

Use a technique to cover invalid inputs, edges and combinations too. That's where bugs hide.

Oops

Using every technique on every feature.

Do this instead

Pick what fits: ranges need boundaries, rules need decision tables, workflows need state transitions.

Your mission

Build a decision table

~20 min

Quick check

A feature's behaviour depends on three yes/no conditions. How many columns does a full decision table need?

Go deeper

1Learn the names and purposes of 3-4 common test case design techniques.
2Practice applying one technique to a sample requirement.
3Understand these techniques exist to maximize coverage with a manageable number of test cases.