Test design techniques are structured methods for selecting test cases that prove measurable coverage of a system under test. They fall into four groups: data-oriented (equivalence partitioning, boundary value analysis), condition-oriented (decision tables), process-oriented (path testing), and appearance-oriented (syntactic and non-functional testing). Knowing at least one technique per group prevents applying the wrong method to a given problem.
Key Takeaways
- Grouping test design techniques into four categories (data, condition, process, appearance) lets testers diagnose which category fits their problem before selecting a specific technique.
- Teaching too many techniques at once backfires: TMAP reduced its required techniques from 19 to five in the foundational course so learners reach actual working proficiency rather than exam-only recall.
- Condition-oriented techniques like decision tables fail when the underlying problem is data-oriented, so choosing the wrong category produces low-value test cases regardless of how rigorously the technique is applied.
- Decision coverage is more meaningful than line coverage for unit testing because decisions, not move statements, carry the real risk in software logic.
Why testers learn test design techniques and then never use them
Most testers can name a handful of test design techniques. Few of them apply these techniques in their daily work. Rik Marselis, who has taught test design techniques for almost 25 years, names two reasons for this gap.
The first is that nobody asks for them. When a system is in poor shape, you find defects by pressing a button. There is no obvious need for a structured technique because the bugs surface on their own.
The second reason carries more weight in the long run. The value of test design techniques shows up when quality is already good, or when you need to give a convincing answer about quality. A technique lets you demonstrate what coverage you actually have, tied to the risk you care about.
Too many techniques is part of the problem
Teaching 15 to 20 techniques produces testers who pass exams and apply nothing. Across ISTQB Foundation, Advanced Test Analyst, and Advanced Technical Test Analyst, a learner meets somewhere between 15 and 20 test design techniques. Research by Rik and his colleague Bert put the total field at roughly 25 to 30 techniques, with the exact count open to debate because some are variants of others rather than techniques in their own right.
That volume is the trap. Earlier TMAP certifications expected proficiency in 19 techniques and approaches, which is not realistic inside a three-day course. What you really learn there is how to mark the correct A, B, C, or D on an exam, not how to use a technique when the situation is messier than any exam question.
A revised TMAP certification scheme cut the starting set down hard. The first course, Quality for Cross-Functional Teams, teaches five techniques and one approach, with more time and more exercises so a learner can actually apply them at a beginner’s level. The point is to clear the hurdle of learning one technique properly, because many testers never get past it.
The four groups that make techniques easy to navigate
Every test design technique fits into one of four groups, and knowing the groups matters more than memorizing the catalogue. Rik and Bert found this structure in their research, and it gives a tester a map instead of a long list.
- Process-oriented techniques cover flows through a system. Path testing with its levels of path coverage belongs here, as does state transition testing with state coverage and transition coverage.
- Condition-oriented techniques work from conditions to outcomes. The decision table is the clearest example, where conditions determine the test cases.
- Data-oriented techniques handle data items and their partitions. Equivalence partitioning sits here.
- Appearance covers how the system shows itself to the outside world. That ranges from syntactic testing (button placement, font, colors, the style guide) to non-functional aspects like performance and usability.
The practical rule is to know at least one or two techniques per group. If you only know techniques from a single group, you will reach for the wrong tool.
Rik coached a team that had settled on the elementary comparison test, a powerful condition-oriented technique with high efficiency and effectiveness. They wanted to use it everywhere. When it kept failing them, the cause was simple: their problem was data-oriented, and a condition-oriented technique cannot solve a data-oriented problem.
The five-technique starter set
A practical toolbox starts with one technique per group plus an experience-based approach. The TMAP starter course teaches five techniques drawn across the four groups:
| Group | Technique |
|---|---|
| Data | Equivalence partitioning, boundary value analysis |
| Process | Path testing |
| Condition | Decision table |
| Appearance | Syntactical testing |
| Experience-based approach | Exploratory testing |
A second course, High-Performance Quality Engineering, adds another technique per group. After both, a tester carries about ten techniques and two approaches. That set covers what roughly 90 percent of testers will need across a career.
How templates make a hard technique teachable
A good template removes the hardest part of learning a technique: building the structure from scratch. Decision table testing was always difficult to teach, by the admission of one long-time TMAP teacher. A downloadable template changed that.
With the template, you no longer teach people how to draw the table. You show them what the table looks like and where each part goes. They fill in conditions, fill in actions, then work out the expected outcome from the true-false combinations. The expected outcome is the core of any test case, and the template clears the path straight to it.
The same step-by-step logic applies to path testing. Follow the steps and you arrive at your test cases, and you can show the coverage you achieved.
How to choose the right technique for the problem
Four factors decide which technique fits, and risk is only one of them. The TMAP book names all four, and a tester who weighs them avoids defaulting to a favorite.
Start with the kind of testing problem you face, which tells you the group to select from. Then the quality characteristic: performance, for example, leads you quickly into the appearance group. Third comes risk, where three levels are enough.
On risk, resist the urge to quantify. When someone insists on a percentage, ask whether 72 percent is meaningfully different from 69. Low, medium, high is sufficient, because the techniques themselves rarely offer more than three levels of coverage. Higher risk means more coverage and a more thorough technique.
The fourth factor is the skills of the people involved. If the team does not know a technique, you have two options: pick a technique they already know, or teach them the one that fits.
Coverage and experience belong together
Coverage proves you tested everything that matters; experience catches what coverage misses. Neither replaces the other. TMAP’s standing advice is to combine experience-based techniques like exploratory testing with structured test design techniques.
Rik saw this play out while guiding business analysts who run functional acceptance testing. They had good process flows, which made them a natural fit for path testing, also known as process cycle testing. He taught them in a session of about an hour and a half, ran an exercise, then returned for a two-hour session with one of their real process flows and built the test cases from it.
When they noticed a specific situation their paths did not cover, the answer was not to abandon the structure.
Please go ahead and add an extra test case based on your experience, but don’t throw away another one because you need your coverage. — Rik Marselis
That is the meeting point of coverage-based and experience-based testing. The technique guarantees the baseline. Experience adds what the technique cannot foresee.
Why developers need more than line coverage
A claim of “100 percent coverage” says nothing until you ask which coverage. Developers in unit testing often focus on code coverage and stop at line coverage. That number is easy to game. Put five statements on one line, execute one of them, and you already report 100 percent coverage of that line.
Move up to statement coverage so that every statement is exercised. Better still is decision coverage, because the decisions are the most important statements in the code. A move statement that assigns a value to a variable is low risk. The if statements and while loops are where you want to know that the good case and the fault case both work.
Simple techniques get you there. Equivalence partitioning gives you a class for the right result and a class for the wrong result, and a test case for each. The recurring problem is that many developers test only the happy path and forget the fault situation.
This is a matter of awareness more than instruction. Tell a developer to test what happens when input is wrong, and the response is usually agreement, followed by the realization that it doubles the test cases. It does. That is the point.
The techniques are old, but path testing stays underused
Test design techniques have not changed in decades; how widely they are used is the open question. The foundational techniques appear in books more than 20 years old. Glenford Myers described boundary value analysis and equivalence partitioning in The Art of Software Testing some 45 years ago. Boris Beizer’s work and the earlier TMAP books form the rest of the lineage that ISTQB still references.
One gap stands out. ISTQB teaches state transition testing as its process-oriented technique, which centers on states. Not many systems have meaningful states, and acceptance testing is usually about flows, the business flows through a system. Path testing covers exactly those flows, yet it has not been adopted as widely as it could be. The business analysts Rik guided took to it precisely because it matched how they already saw the system.
When the strongest coverage is worth the effort
The elementary comparison test gives the highest coverage available, at the cost of complexity. It earns a place among Rik’s top three techniques alongside path testing and decision tables, but it is not a casual pick.
Decision tables are strong for testing every possibility, with one limit: they grow out of hand past roughly five conditions. In practice few outcomes depend on five conditions at once, so the technique usually holds up.
The elementary comparison test tests multiple decision points, and for each decision point it applies modified condition decision coverage to produce the test situations. Those situations are then combined across all decision points into full test cases from start to end. Where path testing would collapse several condition combinations onto the same path into a single test case, the elementary comparison test exercises all the combinations. It yields more test cases and the strongest confidence that the system works when they pass. Learning it well takes about a one-day workshop, and templates carry the structure.
