What Are Test Design Techniques?
A test design technique (test technique for short) is a structured procedure for deriving concrete test conditions and test cases from the test basis, that is, from requirements, models, rules or experience. The path from requirements document to test case becomes traceable, repeatable and verifiable, instead of depending on the gut feeling of whoever happens to be testing.
Why the effort? Three reasons. A systematic derivation overlooks less, because the method forces you to touch every aspect of the test object at least once. It can be defended, to the product owner just as much as to an auditor. And it gives the team a shared vocabulary for agreeing on test scope without talking past each other.
What this feels like shows in every refinement session. A fare calculator in a rail booking app depends on four parameters, each with three values: ticket type, customer class, booking channel, day of travel, 81 combinations in total. Someone suggests testing “the most important cases”, and the team is already debating which ones those are. With pairwise testing, the debate becomes unnecessary: nine deliberately constructed test cases cover every pairing of two parameter values, and the selection is justified rather than negotiated.
Black-Box, White-Box and Experience-Based
Swipe right or use the arrow keys to see the full graphic.
Test techniques can first be sorted into three categories. Black-box test techniques derive test cases from the specification and the observable behaviour; the inner structure of the system stays out of it. White-box techniques work the other way round, with the code structure, statement and branch coverage for instance. Experience-based techniques use the knowledge and intuition of testers to look precisely where structured test cases walk past.
Most techniques on this page are black-box test techniques: they need requirements, rules or models as a test basis, not source code. That is exactly why they work on every test level, from component testing to system testing, and why they can be prepared early, often before the first line of code exists. The experience-based techniques complement this structured core. They cannot replace it, and the reverse holds as well.
The sorting on this page follows a second, finer classification. It comes from the Advanced Level syllabus for the Test Analyst and groups the techniques by their starting point: data, behaviour, rules or experience. The two classifications do not contradict each other; they sit at right angles. Almost everything that follows is black-box in the sense of the first classification; what differs is the question of where the test cases come from.
A note for everyone heading toward a certification: of these techniques, the Foundation Level contains equivalence partitioning, boundary value analysis, decision table testing, state transition testing and checklist-based testing. Combinatorial testing, random testing, CRUD testing, scenario-based testing, metamorphic testing and crowd testing only appear in the Advanced Level Test Analyst.
The Four Groups of Techniques
Swipe right or use the arrow keys to see the full graphic.
Eleven techniques together cover almost every testing task. What sets them apart is their starting point: data, behaviour, rules or experience.
Data-based techniques
Here the input values are the starting point. Equivalence partitioning and boundary value analysis work as a pair and aim at the places where input defects actually sit: the partition boundaries with their off-by-one defects. Pairwise testing, the most common form of combinatorial testing, checks the interplay of several parameters with a fraction of the full combination. Random testing generates large volumes of inputs automatically and opens up input spaces where manual testing fails, in fuzz testing and property-based tests for example.
Behaviour-based techniques
Here sequences of actions take centre stage. CRUD testing walks through all data operations (create, read, update, delete) on all entities with all actors; its foundation is a CRUD matrix, which above all makes authorisation gaps visible. State transition testing works with formal state models and uncovers sequence and status defects, with clearly defined coverage measures. Scenario-based testing follows typical usage paths, from user story to multi-step business process, which makes it the technique closest to the user’s perspective.
Rule-based techniques
Here the logic of the test object is the starting point. Decision table testing writes business rules with several linked conditions down as a table: every column is a rule, every rule becomes a test case, no combination goes undiscussed. Metamorphic testing checks relations between inputs and outputs and therefore works even where nobody knows the correct result: search, recommendation systems, numerical algorithms and AI models.
Experience-based testing
Here what counts is what people see who have seen a lot. Session-based testing gives exploratory testing a frame: time-boxed sessions, a test charter as the assignment, a debriefing at the end. Experience-based checklists condense the knowledge from earlier releases and bug databases into a manageable number of focused checkpoints. Crowd testing spreads the testing across many parallel testers and delivers real diversity of devices, browsers and usage habits, paid for with lower reproducibility.
The Eleven Techniques Compared
Swipe right or use the arrow keys to see the full graphic.
| Technique | Group | Main use case | Typical strength |
|---|---|---|---|
| Equivalence partitioning and boundary value analysis | data-based | input validation with defined value ranges | finds off-by-one defects at partition boundaries |
| Pairwise testing | data-based | several interacting parameters | checks parameter interactions with few test cases |
| Random testing | data-based | very large input spaces, robustness, fuzz testing | large-scale automation |
| CRUD testing | behaviour-based | data-driven systems with entities and actors | uncovers authorisation gaps systematically |
| State transition testing | behaviour-based | systems with a clearly defined lifecycle | finds sequence and status defects, measurable coverage |
| Scenario-based testing | behaviour-based | end-to-end tests, acceptance tests, business processes | closest to the user’s perspective |
| Decision table testing | rule-based | business rules with several conditions | leaves no combination of conditions undiscussed |
| Metamorphic testing | rule-based | systems with a test oracle problem (search, AI, numerics) | checks consistency where no expected result exists |
| Session-based testing | experience-based | exploratory investigation of new software | finds usability and perception defects |
| Experience-based checklists | experience-based | recurring tasks such as smoke tests | preserves experience in a checkable form |
| Crowd testing | experience-based | end-user software with high device diversity | real diversity of devices and usage habits |
How Do You Choose the Right Technique?
Swipe right or use the arrow keys to see the full graphic.
No single test technique does everything. Work exclusively with equivalence partitions and you miss state defects. Test only scenarios and you miss edge cases in the input values. Only explore and you miss systematic logic defects. An effective test approach emerges from deliberate combination, not from any one technique.
Three questions lead to the selection. The first: which risks and quality characteristics are at stake? High risks justify several complementary techniques, with overlapping coverage if need be; low risks tolerate leaner, often experience-based testing. The second: what does the test object look like? Clearly defined value ranges point to equivalence partitioning and boundary value analysis, linked business rules to a decision table, a defined lifecycle to state transition testing, results that are hard to predict to metamorphic testing. The third: what do budget, tools and team experience allow? A technique nobody masters and no tool supports remains theory, however well it fits.
As a repeatable procedure, per release for instance:
- Identify risks. Which product risks matter in this undertaking, at which risk level?
- Map quality characteristics. Which characteristics are affected, and how deeply?
- Derive candidate techniques. For each risk, determine the techniques that fit structurally.
- Assess effort and tooling. Which candidates are realistic to implement?
- Combine and record. Document the chosen combination, with its rationale, in the test approach.
Typical Mistakes in Selecting Techniques
Swipe right or use the arrow keys to see the full graphic.
Two opposite patterns keep showing up. The first: the favourite technique, applied to everything. Work on every task with the same tool and you produce blind spots exactly where the tool falls short. The second: trying to do everything at once. Run six techniques in parallel and none of them gets carried through cleanly. Three or four fitting techniques, applied consistently, beat half a dozen half-hearted ones.
An effective countermeasure is a simple risk-technique matrix: risks in the rows, chosen techniques in the columns. One glance shows which risk is covered by what, which risk still stands there without a technique, and which technique serves no risk at all. That last one is often a hint at effort nobody needs.
And the selection does not hold forever. Whether business rules, interfaces, security or device diversity dominate changes from release to release, and with them the fitting combination of techniques. Make the selection once and then extend it mechanically, and you lose exactly the adaptability that makes the techniques valuable.
Going Deeper
The five most important techniques are described here in detail: equivalence partitioning and boundary value analysis, pairwise testing, state transition testing, decision table testing and metamorphic testing. If you would rather listen than read: the podcast has conversations on test design methods and on test design with AI.