What Test Design Is

A date field accepts millions of values. A booking form, billions of combinations. Principle 2 said you will never test them all — and this chapter is the answer to the question that principle leaves hanging: then which ones? Test design is the craft of choosing the few dozen checks that catch what the millions would — and it is the heart of this book, the heart of the profession, and the single most examined skill in every junior QA interview you will ever sit.

Medicine solved this problem long ago. A doctor can't run every test on every patient — so a checkup is a designed sample: blood pressure, a few markers, specific questions, each chosen because it reveals the most about the whole. Nobody calls a checkup superficial; the design is exactly what makes twenty minutes trustworthy. This chapter teaches you to design the checkup for software.

Why "Just Try Stuff" Fails

Hand an untrained person the stay-length field — 1 to 30 nights, remember — and watch what they do: try 5, try 10, maybe try 15, conclude it works. Three tests, all from the comfortable middle, all exercising the same behavior. Meanwhile the bugs — you'll learn exactly why next topic — sit at 0, at 31, at the empty field, at "two" typed as a word. Untrained testing isn't useless; it's shallow: it finds what's lying on the surface and misses everything that requires aiming. Design is what turns the same number of tests into deliberate, defensible coverage.

Test Conditions, Then Test Cases

The discipline has two steps, and keeping them separate is what separates design from improvisation. First you decide what is worth testing — the industry calls each such thing a test condition: "the stay-length rule enforces its maximum," "the promo code refuses short stays," "cancellation is free outside 48 hours." No values yet, just the list of claims worth checking. Then you decide how exactly to check each one — concrete inputs, steps, and expected results — and each of those is a test case: "book The Juniper Inn for 31 nights; expect the clear over-maximum error."

Why two steps? Because they fail differently. Skip the first and you get beautiful test cases for whatever happened to cross your mind — with entire rules unexamined. Skip the second and you get a pile of vague intentions nobody can execute twice the same way. Conditions give you coverage of the rules; cases make the checking repeatable. Chapter 5 will teach the writing-down; this chapter teaches the choosing.

The Toolbox Ahead

The five topics after this one are five named techniques, and each fits a different shape of problem. Equivalence partitioning — when an input has ranges of values treated the same, test one from each group. Boundary value analysis — bugs live at the edges of those ranges; aim there. Decision tables — when several rules interact, lay out every combination in a grid so none can hide. State transition testing — when a thing has a lifecycle, draw it and test the moves, including the forbidden ones. Pairwise and error guessing — when combinations explode beyond any table, and where experience becomes a technique of its own.

Infinite input spacemillions of values, billions of paths

→

Test conditionswhat is worth checking

→

Techniques appliedpartitions · boundaries · tables · states · pairs

→

Designed test setfew dozen cases, defensible coverage

Coverage: Making "Tested" an Honest Word

Here's what design buys that effort alone never can. After undirected testing, the only claim available is "I tested it" — which means nothing, because it can't be false. After designed testing, you can say: every partition of the stay-length field is covered, every boundary is hit, every column of the discount table has a case. That claim has content. It can be checked, challenged, and — crucially — it tells everyone exactly what was not covered, which Chapter 7 will turn into honest release reporting. "Coverage" is the word that makes testing a measurable engineering activity instead of a vibe, and every technique ahead defines its own version of it.

Design Is Also How You Talk

One more payoff, easy to miss. A designed test set can be explained. When Nadia asks how you'll test the promo-code story, "I'll click around and see" ends the conversation and her confidence together. "Four partitions, boundaries at 3 nights, and a decision table for the member-discount interaction — thirteen cases, here's the list" takes the same thirty seconds and does the opposite. The same holds in interviews: "how would you test this field?" is really "show me you choose deliberately." This chapter's techniques are, among everything else, the vocabulary of that answer.

One promise before we start: every technique will be taught on the Fernway rules you already know — the 1–30 nights, the 1–8 guests, SUMMER15 and its fine print. Plain sentences from Chapter 1 are about to become dozens of precise, aimed checks. Watch what happens to that stay-length field next.