Overview
Test design techniques are systematic methods for selecting and structuring test cases. Rather than testing every possible input (which is impossible), these techniques help you choose a minimal set of test cases that gives maximum defect coverage. All four techniques covered here are black-box — you test based on what the software is supposed to do, not how it does it internally.
Partitioning
Analysis
Transition
Table
Used for range inputs | Used for edge values | Used for state-based systems | Used for complex conditions
1. Equivalence Partitioning (EP / ECP)
Equivalence Partitioning divides input data into groups (partitions) where all values in a group are expected to behave the same way. You test one representative value from each partition instead of every possible value — drastically reducing test count while maintaining coverage.
The Core Idea
If the system behaves the same for inputs 1, 50, and 99 in a valid range (1–100), you only need to test one of them. Any one value from the partition is equally good at finding defects.
Test: 0 or 10
Test: 30 or 45
Test: 70 or 100
3 partitions → minimum 3 test cases instead of 100+
Real-World Example — Login Age Validation
Suppose a system only allows users aged 18–60 to register. Instead of testing every age from 0–120, EP gives you:
| Partition | Range | Sample Input | Expected Result |
|---|---|---|---|
| Invalid (too young) | Below 18 | 10 | Error: "Age must be 18 or older" |
| Valid | 18 – 60 | 35 | Registration accepted |
| Invalid (too old) | Above 60 | 75 | Error: "Age must be 60 or below" |
| Invalid (non-numeric) | Letters/symbols | "abc" | Error: "Please enter a valid age" |
Only 4 test cases cover what would otherwise require hundreds.
2. Boundary Value Analysis (BVA)
Boundary Value Analysis is an extension of EP that focuses specifically on the edges of each partition. Defects are statistically most likely to occur at boundary values — off-by-one errors are extremely common in code.
The Rule
For each boundary, test: the value just below, the boundary itself, and the value just above. For a range of 1–100:
Below min
Min boundary
Just above min
Just below max
Max boundary
Above max
6 boundary test cases instead of 100 values — highest defect probability at the edges
Real-World Example — Password Length (6–20 characters)
| Test Value | Characters | Type | Expected Result |
|---|---|---|---|
| 5 characters | "pass1" | Invalid (below min) | Error: too short |
| 6 characters | "pass12" | Valid boundary (min) | Accepted |
| 7 characters | "pass123" | Valid (just inside min) | Accepted |
| 19 characters | "pass1234567890abcd" | Valid (just inside max) | Accepted |
| 20 characters | "pass1234567890abcde" | Valid boundary (max) | Accepted |
| 21 characters | "pass1234567890abcdef" | Invalid (above max) | Error: too long |
if age > 18 instead of if age >= 18 will be caught by BVA (testing exactly 18) but not by EP (which might only test 30).
3. State Transition Testing
State Transition Testing is used when a system's behaviour changes depending on its current state and the event that occurs. The same action can produce different results depending on what state the system is currently in.
Key Concepts
- State: A condition the system can be in (e.g., Logged Out, Logged In, Account Locked)
- Event/Trigger: Something that causes a transition (e.g., user submits password)
- Transition: Moving from one state to another
- Action/Output: What the system does during a transition
State Transition Table — Login System
| Current State | Event/Input | Next State | Output |
|---|---|---|---|
| Logged Out | Correct password | Logged In | Dashboard shown |
| Logged Out | Wrong password (attempt 1) | Logged Out | "Invalid credentials" warning |
| Logged Out | Wrong password (attempt 2) | Logged Out | "2 attempts left" warning |
| Logged Out | Wrong password (attempt 3) | Account Locked | "Account locked" message |
| Logged In | Logout click | Logged Out | Session cleared, redirect to login |
| Account Locked | Any password attempt | Account Locked | "Contact admin" message |
| Account Locked | Admin unlocks | Logged Out | Account restored |
Test cases are derived from each row of this table. You should also test invalid transitions — e.g., trying to access a dashboard while logged out.
4. Decision Table Testing
Decision Table Testing is the most powerful technique for testing systems with multiple conditions that combine to produce different results. It forces you to enumerate every possible combination of conditions and map them to the correct output.
Structure
A decision table has conditions (rows at the top) and actions/outcomes (rows at the bottom). Each column represents one unique combination — one test case.
Real-World Example — Loan Eligibility
A bank loan system checks: Is the applicant employed? Is their credit score above 700? Do they have existing debt?
| Condition / Action | TC1 | TC2 | TC3 | TC4 | TC5 | TC6 | TC7 | TC8 |
|---|---|---|---|---|---|---|---|---|
| Employed? | Y | Y | Y | Y | N | N | N | N |
| Credit score > 700? | Y | Y | N | N | Y | Y | N | N |
| Existing debt? | N | Y | N | Y | N | Y | N | Y |
| Loan Approved | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
From this table you can immediately see the business rule: a loan is only approved when the applicant is employed AND has a good credit score (debt doesn't matter if those two are met). Each column becomes a test case — and decision tables prevent you from missing any combination.
Which Technique to Use?
| Technique | Best For | Example Scenarios | Key Benefit |
|---|---|---|---|
| Equivalence Partitioning | Range/group inputs | Age fields, salary bands, discount tiers | Reduces test cases without losing coverage |
| Boundary Value Analysis | Numeric or date ranges | Password length, file size limits, date pickers | Catches off-by-one errors in conditions |
| State Transition | State-dependent behaviour | Login systems, e-commerce order flow, ATM | Ensures correct behaviour across all states |
| Decision Table | Multiple conditions + rules | Loan eligibility, insurance policies, access control | Covers all condition combinations explicitly |
In practice, experienced testers use multiple techniques on the same feature. Start with EP to define partitions, apply BVA at the edges, use State Transition if there's flow between modes, and Decision Table where multiple conditions interact.
Combining Techniques on Real Projects
No single test design technique covers the full range of defects that a real system can produce. Experienced QA engineers combine techniques deliberately — using each one where it provides the most coverage, then layering the others to close the gaps. Understanding not just what each technique does but when to reach for it is what separates systematic testers from those who test by instinct alone.
Why No Single Technique Is Enough
Equivalence Partitioning reduces the number of test cases by grouping inputs, but it will not catch an off-by-one boundary error. Boundary Value Analysis catches off-by-one errors but does not cover the combinations of multiple conditions. Decision Tables handle multiple conditions exhaustively but are not designed for systems where behaviour changes based on sequence or state. State Transition Testing covers sequence and state but tells you nothing about how input ranges are handled within any given state. Each technique has a blind spot. The combination eliminates them.
Worked Example: Testing a Login Form with All Four Techniques
Consider a standard login form with a username field, a password field (minimum 8 characters, maximum 64 characters), and optional multi-factor authentication (MFA). Here is how all four techniques apply together:
- Equivalence Partitioning: Partition the username into valid (registered user) and invalid (unregistered, empty). Partition the password into valid (correct password for that user) and invalid (wrong password, empty). This gives you four input combinations covering the most common paths with minimal test cases.
- Boundary Value Analysis: Apply BVA to the password length constraint. Test 7 characters (one below minimum), 8 characters (minimum boundary), 9 characters (just inside), 63 characters (just inside maximum), 64 characters (maximum boundary), and 65 characters (one above maximum). These six tests will catch the most common off-by-one implementation errors.
- State Transition: Map the login states: Logged Out → Logged In → Session Timeout → Logged Out. Test each valid transition and verify that invalid transitions are rejected — for example, that a user cannot reach an authenticated page from the Session Timeout state without re-entering credentials.
- Decision Table: Combine the three independent conditions: valid username (Y/N), valid password (Y/N), MFA enabled (Y/N). Eight combinations result. Define the expected outcome for each — which grant access, which show an error, and which trigger an MFA prompt. Any combination the developer has not handled will produce an unexpected result that this table exposes.
Choosing the Right Technique for the Input Type
As a practical rule of thumb, match the technique to the nature of the input or system under test:
| Technique | Best For | Example Scenario | Typical Test Count |
|---|---|---|---|
| Equivalence Partitioning | Grouped or categorised inputs | User role tiers (Free, Pro, Enterprise) | 1 per partition (3–6 typical) |
| Boundary Value Analysis | Numeric ranges, dates, lengths | Password length, file size, age range | 6 per boundary pair (2 boundaries × 3 values) |
| State Transition | Systems with states and sequences | Order lifecycle, login/lock/unlock flow | 1 per valid transition + invalid transitions |
| Decision Table | Multiple independent conditions | Eligibility rules, access control policies | 2ⁿ columns (n = number of conditions) |
On any project with more than trivial complexity, the correct approach is to start with EP to understand the input space, apply BVA at every numeric or length constraint, use State Transition if the feature has a defined flow or mode, and build a Decision Table when two or more independent conditions combine to produce different outcomes. This discipline makes your test coverage systematic, traceable, and far more likely to catch the defects that matter.
References
- ISTQB Foundation Level Syllabus — Chapter 4: Test Techniques
- Myers, G. J. — The Art of Software Testing, Wiley
- Beizer, B. — Black-Box Testing: Techniques for Functional Testing of Software and Systems
- ISTQB Glossary of Testing Terms — glossary.istqb.org
Back to Blog