Test Design Techniques: An Overview
Why picking test cases at random wastes effort, and the systematic approach the next several lessons will each teach in depth.
What you'll learn
- Explain why systematic test design finds more defects per test case than ad hoc guessing
- Name the four structured test design techniques this course covers
- Identify which technique fits a given kind of input or logic
Prerequisites
Explanation
Given a field that accepts an integer from 1 to 100, how many test cases do you need? A tester without a technique might type in five or six numbers that feel reasonable and call it done — 50, 25, 75, maybe 1 and 100 if they're careful. A tester with a technique can explain, precisely, why a specific small set of numbers gives strong confidence, and can defend that choice to a skeptical reviewer.
That's the entire point of test design techniques: they are systematic methods for choosing a small, defensible set of test cases out of what is often an effectively infinite space of possible inputs, while still catching the defects most likely to occur. Testing every possible integer from 1 to 100 individually would take 100 tests and mostly duplicate effort — most of those numbers behave identically. A technique tells you which few numbers actually matter and why.
This course covers four structured techniques, each suited to a different shape of problem:
Equivalence partitioning groups inputs into classes that should all be treated the same way by the system, then tests one representative from each class instead of every possible value.
Boundary-value analysis focuses specifically on the edges of those classes — the values right at, just below, and just above a limit — because off-by-one errors cluster at boundaries far more than they cluster in the middle of a range.
Decision tables handle logic driven by multiple independent conditions combining together (a discount that depends on both loyalty status and order size and a promo code), where partitioning one input at a time would miss the combinations.
State transition testing handles systems that behave differently depending on what already happened — an order that can be "pending," "paid," "shipped," or "cancelled," where the same action (like "cancel") is valid in some states and invalid in others.
None of these techniques is universally "best" — the skill is recognizing which shape of problem you're facing and reaching for the technique built for it, which is exactly what the next four lessons practice one at a time.
Example
Two very different-looking approaches to testing the same range — one ad hoc, one systematic. Both run; only one scales and explains itself.
function isValidAge(age) {
return Number.isInteger(age) && age >= 1 && age <= 100;
}
// Ad hoc: "feels" reasonable, hard to defend as complete.
console.log(isValidAge(42));
// Systematic: one value from each meaningful region, chosen deliberately.
console.log(isValidAge(0)); // just below the valid range
console.log(isValidAge(1)); // the lower edge
console.log(isValidAge(50)); // comfortably inside
console.log(isValidAge(100)); // the upper edge
console.log(isValidAge(101)); // just above the valid rangeTry it yourself
Add one more systematic test case below (e.g. a non-integer like 50.5) and predict the result before running.
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Guided exercise
Guided exercise
For each scenario, choose which technique from 'equivalence-partitioning', 'boundary-value-analysis', 'decision-table', or 'state-transition' fits best: scenarioA = 'testing a coupon field that groups inputs into valid-format vs invalid-format codes'. scenarioB = 'testing an order object that can only move from pending to shipped, never the reverse'.
Checks: correctly matches scenario A · correctly matches scenario B
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
Choose the right technique for two more scenarios: scenarioC = 'testing the exact edges of an age field that accepts 18 to 65'. scenarioD = 'testing a discount that depends on three independent yes/no conditions combined together'.
Checks: correctly matches scenario C · correctly matches scenario D
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Picking test values that "feel" representative without being able to explain which equivalence class each one represents.
- Applying only one technique to every problem out of habit, rather than matching the technique to the shape of the input or logic.
- Believing more test cases always means better coverage — a systematic small set often finds more real defects than a large unsystematic one.
Knowledge check
Takeaway
Structured test design techniques replace guesswork with a small, explainable set of test cases — the skill is recognizing which technique fits the shape of the problem in front of you.
Summary
This lesson previewed the four structured test design techniques covered next — equivalence partitioning, boundary-value analysis, decision tables, and state transition testing — and how to recognize which fits a given scenario.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.