Test Design Techniques — Black-Box
Black-box techniques let you design powerful tests without reading the code. Master equivalence partitioning, boundary value analysis, decision tables, and state transition testing with real examples.
📚 This is Part 6 of the ISTQB Foundation Level series. Previous posts covered the fundamentals of testing, test levels, and test types.
1. Introduction — Designing Tests, Not Just Running Them
There’s a pattern that shows up on almost every QA team at some point: tests written by clicking around the application until something broke, driven by intuition and experience rather than systematic thinking.
This approach — called ad-hoc testing — has real value. An experienced tester’s intuition catches things that no test plan would anticipate. But it doesn’t scale. It produces uneven coverage, misses the same kinds of bugs repeatedly, and can’t be reproduced, reviewed, or handed off to another tester.
Test design techniques solve this problem. They give you a systematic way to derive test cases from specifications — without relying on gut feeling, and without needing to read a single line of implementation code.
This is the essence of black-box testing: you treat the system under test as an opaque box. You know what goes in (inputs) and what should come out (expected outputs). You don’t know — and don’t need to know — how the box works internally.
ISTQB defines four primary black-box techniques at Foundation Level:
- Equivalence Partitioning (EP)
- Boundary Value Analysis (BVA)
- Decision Tables
- State Transition Testing
There is also Use Case Testing, which we’ll cover briefly. Let’s go through each one with real examples.
2. Equivalence Partitioning (ISTQB 4.2.1)
Concept
When a system accepts a range of inputs, testing every single possible value is impractical. An age field that accepts integers from 0 to 120 has 121 possible valid values — and thousands of invalid ones. You can’t test them all.
Equivalence Partitioning (EP) is based on the observation that inputs with the same behaviour can be grouped into partitions. If testing any value within a partition produces the same result, you only need to test one representative value from that partition.
Partitions can be valid (inputs the system should accept) or invalid (inputs the system should reject).
Example
Scenario: An insurance application accepts customers aged 18 to 65. Younger or older applicants are rejected.
| Partition | Range | Valid? | Representative Value |
|---|---|---|---|
| Below minimum | age < 18 | ❌ Invalid | 10 |
| Within range | 18 ≤ age ≤ 65 | ✅ Valid | 40 |
| Above maximum | age > 65 | ❌ Invalid | 80 |
With EP, three test cases cover all three partitions. You don’t need to test age = 5, 6, 7, 8… — they all belong to the same invalid partition and should all produce the same “rejected” result.
When to Use
EP is best suited for:
- Fields with numeric ranges (age, salary, quantity)
- Categorical inputs (status codes, country codes, payment types)
- String length validation
- Any scenario where the specification defines distinct valid and invalid ranges
:::tip[ISTQB Exam Tip] The key exam point about equivalence partitioning is that it reduces the number of test cases without reducing coverage — because you choose one representative from each partition rather than exhaustively testing all values. ISTQB also requires you to test both valid and invalid partitions. :::
3. Boundary Value Analysis (ISTQB 4.2.2)
Concept
Experience shows that defects cluster at the edges of input ranges, not in the middle. A developer who implements age >= 18 AND age <= 65 might accidentally write age > 18 (missing the boundary value 18) or age <= 64 (missing the boundary value 65).
This is the classic “off by one” error — so common it has its own name.
Boundary Value Analysis (BVA) extends EP by focusing test cases on the boundaries of each partition: the boundary value itself and the value just outside it.
ISTQB Foundation defines two variants:
2-value BVA: Test the boundary value and the value just beyond it.
3-value BVA: Test the value just below the boundary, the boundary itself, and the value just above it.
Example
Using the same age 18–65 scenario:
2-value BVA:
| Boundary | Test Values |
|---|---|
| Lower boundary (18) | 17 (invalid), 18 (valid) |
| Upper boundary (65) | 65 (valid), 66 (invalid) |
3-value BVA:
| Boundary | Test Values |
|---|---|
| Lower boundary (18) | 17 (invalid), 18 (valid), 19 (valid) |
| Upper boundary (65) | 64 (valid), 65 (valid), 66 (invalid) |
3-value BVA gives you more confidence at the cost of more test cases. ISTQB Foundation Level focuses on 2-value BVA as the default.
Combining EP + BVA
In practice, you almost always use EP and BVA together:
- Use EP to identify the partitions
- Use BVA to select test values — choosing from the boundaries of each partition rather than arbitrary middle values
This combination gives you the best test coverage per test case.
:::tip[ISTQB Exam Tip]
On exam questions about BVA, look carefully at whether the boundary is inclusive or exclusive. age >= 18 (inclusive) means 18 is valid; age > 18 (exclusive) means 18 is invalid. The boundary values change accordingly.
:::
4. Decision Tables (ISTQB 4.2.3)
Concept
Some systems make decisions based on combinations of conditions. A single input isn’t enough — the outcome depends on whether multiple conditions are simultaneously true or false.
Decision tables model this explicitly. Each column in the table represents one rule (a unique combination of condition values). The rows represent either conditions or the resulting actions.
Example
Scenario: A bank approves or rejects loan applications based on two conditions:
- Income > €50,000 per year
- Credit score > 700
With 2 binary conditions, there are 4 possible rules:
| Rule 1 | Rule 2 | Rule 3 | Rule 4 | |
|---|---|---|---|---|
| Income > €50k | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| Credit score > 700 | ✅ Yes | ❌ No | ✅ Yes | ❌ No |
| → Loan approved | ✅ Yes | ❌ No | ❌ No | ❌ No |
This table tells you: the loan is approved only when both conditions are met. Each rule becomes one test case, giving you 4 test cases that cover every combination.
For n binary conditions, the full table has 2ⁿ rules. With 3 conditions you get 8 rules; with 4, you get 16.
Collapsed tables: When some conditions don’t affect the outcome (e.g., the loan is always rejected if income is too low, regardless of credit score), you can merge those rules using a “don’t care” value (often written as –). This reduces the number of test cases without losing coverage.
When to Use
Decision tables are the right tool when:
- The specification defines business rules with multiple conditions
- The outcome depends on combinations, not individual values
- You’re testing pricing matrices, eligibility rules, discount logic, or routing rules
:::tip[ISTQB Exam Tip] A common exam question asks you to count how many test cases a decision table requires. For n binary conditions, the maximum is 2ⁿ rules. ISTQB also expects you to recognise when a collapsed table is appropriate. :::
5. State Transition Testing (ISTQB 4.2.4)
Concept
Some systems behave differently depending on their current state. The same input produces different outputs depending on what happened previously. A classic example: submitting a payment form works the first time, but not if the session has expired.
State transition testing models this by defining:
- States: distinct modes the system can be in
- Transitions: movements between states, triggered by events
- Events: inputs or actions that trigger transitions
- Actions: outputs produced during transitions
Example
Traffic Light System:
| Current State | Event | Next State | Output |
|---|---|---|---|
| Red | Timer expires | Green | Show green light |
| Green | Timer expires | Yellow | Show yellow light |
| Yellow | Timer expires | Red | Show red light |
| Red | Emergency vehicle | Red | Flash red |
This system has three normal states (Red, Yellow, Green), three normal transitions, and one emergency transition. Each row in the table becomes a test case.
Coverage criteria for Foundation Level:
- All states coverage: every state is visited by at least one test case
- All transitions coverage: every transition is exercised by at least one test case (stronger criterion — it subsumes all states coverage)
For Foundation Level, ISTQB focuses on all-transitions coverage as the standard criterion.
When to Use
State transition testing applies whenever:
- The system has explicit states (account status: active / suspended / closed)
- Behaviour depends on previous actions (3 failed login attempts → account locked)
- You’re testing workflows, wizards, or multi-step processes
- You’re testing protocol implementations (ATM: card inserted → PIN entry → transaction → logout)
:::tip[ISTQB Exam Tip] ISTQB expects you to be able to draw a state transition diagram and derive test cases from it. Focus on achieving all-transitions coverage — it subsumes all-states coverage and is the standard Foundation Level criterion. :::
6. Use Case Testing (ISTQB 4.2.5)
Use case testing derives test cases from use cases or user stories — descriptions of how a user interacts with the system to achieve a goal.
Each use case has:
- A main flow (the happy path — everything works as expected)
- Alternative flows (valid variations, e.g., paying by card vs bank transfer)
- Exception flows (error conditions, e.g., payment declined)
For each use case, you design test cases covering all three flow types. This ensures that testing reflects real user scenarios rather than isolated functional units.
Use case testing bridges the gap between requirements and tests, making it particularly valuable when acceptance criteria are expressed as user stories — which is standard in Agile teams.
:::tip[ISTQB Exam Tip] Use case testing is especially relevant for system testing and acceptance testing, where the focus is on end-to-end user journeys rather than individual functions. :::
7. Choosing the Right Technique
In practice you’ll rarely use just one technique. The choice depends on what the specification looks like and what kinds of bugs you’re trying to find.
| Scenario | Recommended Technique |
|---|---|
| Numeric input with a defined range | EP + BVA |
| Categorical input (e.g., payment type) | EP |
| Decision depends on multiple conditions | Decision Tables |
| System has modes or states | State Transition Testing |
| Testing an end-to-end user journey | Use Case Testing |
| Complex business rules with many conditions | Decision Tables |
| Workflow with strict ordering (wizard, checkout) | State Transition + Use Case |
| Edge cases in a validated field | BVA |
A common real-world workflow:
- Start with use case testing to identify the main scenarios
- Apply EP and BVA to all input fields in those scenarios
- Apply decision tables to any complex multi-condition business rules
- Apply state transition testing if the system has explicit states
8. Conclusion
Black-box techniques transform test design from guesswork into engineering. They give you a systematic, repeatable process for deriving test cases directly from requirements — without implementation knowledge, and with clear coverage criteria.
Quick reference:
| Technique | ISTQB Reference | Key Idea |
|---|---|---|
| Equivalence Partitioning | 4.2.1 | Group inputs by behaviour; test one per group |
| Boundary Value Analysis | 4.2.2 | Test at and just beyond partition boundaries |
| Decision Tables | 4.2.3 | Cover all condition combinations |
| State Transition Testing | 4.2.4 | Cover all states and transitions |
| Use Case Testing | 4.2.5 | Cover main, alternative, and exception flows |
Practical exercise: Take the acceptance criteria for one story in your current sprint. Apply EP to identify input partitions, then apply BVA to select specific test values. Notice how systematically you can now justify why each test case exists and what it covers.
This is Part 6 of the ISTQB Foundation Level series.