Specification-based
Derive cases from externally observable behavior. The internal code is not needed.
- Equivalence partitioning
- Boundary value analysis
- Decision tables
- State transitions
- Use-case testing
SE401 · Chapter 09 · Exam-ready breakdown
Test Design Techniques
A practical map for turning a large input space, a specification, or a model into a small set of powerful test cases—without confusing a technique with a test level.
Specification-basedStructure-basedExperience-based
Test basis
→Conditions
Technique
→Cases
Coverage
→Confidence
§ 01 — THE MAP
Choose the technique from the information you have
Test techniques give a systematic way to identify test conditions, test cases, and test data. They reduce arbitrary guessing and make the intended coverage visible.
Memory hook: S–S–E. Specification tells you what the system should do; Structure shows how it does it; Experience predicts where it will fail.
Structure-based
Derive cases from statements, branches, conditions, paths, or data flow in the implementation.
- Statement coverage
- Decision/branch coverage
- Condition coverage
Experience-based
Use tester skill, defect history, risk, and domain knowledge to anticipate failures.
- Error guessing
- Exploratory testing
- Checklist-based testing
§ 02 — EQUIVALENCE PARTITIONING
Test representatives, not every value
Divide the input or output domain into partitions whose members are expected to be processed in the same way. Test at least one representative from every identified partition.
Identify the domain
Read the functional specification and list valid and invalid ranges, sets, formats, and business categories.
Form independently testable partitions
Every value belongs to one partition for the rule being tested. Separate classes whenever the expected behavior changes.
Select representative values
Choose a typical member from each partition, then define the expected result from the test oracle.
Age accepts 18–65
P1: age < 18 → invalid
P2: 18 ≤ age ≤ 65 → valid
P3: age > 65 → invalid
P2: 18 ≤ age ≤ 65 → valid
P3: age > 65 → invalid
Representatives might be 12, 40, and 72. One happy-path value alone misses both invalid classes.
Partitions are behavior groups
Do not split merely because values look different. Split when the specification implies different processing or results. Include invalid partitions—they often expose weak validation.
§ 03 — BOUNDARY VALUE ANALYSIS
Defects cluster at the edges
BVA extends partitioning by selecting values at, immediately below, and immediately above each boundary. It is especially useful for ordered numeric and sequential domains.
Memory hook: below, on, above. For a boundary b, think b−1, b, b+1 when the domain is discrete.
| Rule | Boundary targets | Why each matters |
|---|---|---|
| 18 ≤ age ≤ 65 | 17, 18, 19 and 64, 65, 66 | Exercises each side of both lower and upper boundaries. |
| Password length 8–20 | 7, 8, 9 and 19, 20, 21 characters | Finds off-by-one and incorrect comparison operators. |
| Quantity 1–99 | 0, 1, 2 and 98, 99, 100 | Separates invalid, valid, and invalid partitions at their closest points. |
Two-value BVA
Exercise the boundary and its nearest neighbor in the adjacent partition. This is smaller but may provide less diagnostic detail.
Three-value BVA
Exercise the boundary and one value on either side. This directly checks below/on/above behavior.
Do not use blindly
If values have no meaningful order or adjacency—such as colors or account roles—equivalence partitioning is more natural than BVA.
§ 04 — DECISION TABLE TESTING
Expose combinations of business rules
A decision table connects conditions to actions. Each feasible rule column is a combination to test, making omissions and contradictory requirements easier to see.
| Conditions / actions | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Member? | Y | Y | N | N |
| Order ≥ 200? | Y | N | Y | N |
| Apply discount | ✓ | — | — | — |
| Free shipping | ✓ | — | ✓ | — |
Workflow: list conditions → list actions → create combinations → mark impossible rules → assign actions → derive one or more tests per remaining rule.
Use it when
Behavior depends on combinations: pricing, permissions, eligibility, insurance, workflow routing, or validation rules.
Collapse carefully
A dash means “don’t care.” Merge columns only when the ignored condition cannot change the action.
Watch combinatorial growth
n Boolean conditions can produce 2ⁿ combinations. Eliminate infeasible rules and prioritize by risk without hiding a required outcome.
§ 05 — STATE TRANSITION TESTING
Behavior depends on history
Model states, events, transitions, and actions. A test checks not just the current input, but whether an event is valid from the current state and leads to the correct next state.
current state + event → action + next state
Valid transitions
Locked + successful administrator reset → unlock account → Active.
Invalid transitions
Locked + ordinary password login → reject attempt → remain Locked.
Transition paths
Active → three failed logins → Locked → reset → Active. Sequence testing catches history-dependent defects.
Coverage choices: every state, every valid transition, every event, every transition pair, and selected invalid transitions. State coverage alone is weaker than transition coverage.
§ 06 — USE-CASE TESTING
Test complete user journeys
Derive end-to-end scenarios from actors, preconditions, the main success path, alternate flows, exceptions, and postconditions.
Main success scenario
Start with the normal actor goal and verify the promised postcondition.
Alternate flows
Cover legitimate choices: another payment method, saved address, retry, cancel, or return.
Exception paths
Cover failures and recovery: timeout, invalid credentials, unavailable inventory, declined payment, or interrupted service.
Distinction: a use case describes a goal-oriented interaction; a test case adds concrete data, execution conditions, and expected results.
§ 07 — EXPERIENCE-BASED TECHNIQUES
Use human insight systematically
Experience-based testing complements formal models. It is strongest when guided by risk and recorded so the learning can be reused.
Predict likely mistakes
Attack nulls, empty strings, duplicates, overflow, malformed formats, zero, negative numbers, lost connections, and repeated submissions based on defect history.
Learn, design, execute
These activities happen together in a time-boxed session. A charter defines the mission; notes and debriefing preserve evidence and discoveries.
Reuse lessons
Apply a maintained list derived from standards, recurring defects, domain risks, and team experience. Checklists should evolve rather than become ceremonial.
§ 08 — EXAM REVIEW
Choose, justify, and combine
No single technique proves absence of defects. Use the test objective, risk, test basis, lifecycle constraints, and available skills to select a complementary set.
| If the question emphasizes… | Think first… | Typical target |
|---|---|---|
| Ranges or categories | Equivalence partitioning | One representative per valid/invalid class |
| Minimum, maximum, limit | Boundary value analysis | Values around each edge |
| Combinations of rules | Decision table | Each feasible rule column |
| Status, mode, history | State transition | States, transitions, invalid events |
| Actor goal or workflow | Use-case testing | Main, alternate, exception flows |
| Known weak spots or little documentation | Experience-based | Risks, defect patterns, discoveries |
Quick self-check
A representative can reveal behavior for its class, but partitions may be missing or incorrectly defined, and the oracle may be wrong. Other combinations, sequences, and structural paths can remain untested.
EP selects representatives from behaviorally equivalent groups. BVA targets the borders between ordered groups because defects frequently occur at limits.
Use a decision table when the outcome depends on a combination of simultaneous conditions. Use a state model when the outcome depends on the current state or prior event sequence.
A clear charter, time box, risk focus, purposeful test design, notes, evidence, and a debrief. It is simultaneous learning and testing—not random clicking.