Quick answer
Seven techniques cover 95% of real test design: Equivalence Partitioning, Boundary Value Analysis, Decision Tables, State Transition, Use Case, Pairwise, Error Guessing. Combine them — never rely on one alone.
1. Equivalence Partitioning (EP)
Group inputs that the system should treat the same. Test one representative per group — valid and invalid.
Example — age-based ticket price
| Partition | Range | Sample value |
|---|---|---|
| Child | 0–12 | 8 |
| Adult | 13–64 | 30 |
| Senior | 65+ | 70 |
| Invalid (negative) | < 0 | -1 |
| Invalid (non-numeric) | text | "abc" |
2. Boundary Value Analysis (BVA)
Most bugs live at boundaries. For each numeric range, test the value just below, at, and just above every edge.
| Boundary | Values |
|---|---|
| Child / Adult (12 → 13) | 11, 12, 13, 14 |
| Adult / Senior (64 → 65) | 63, 64, 65, 66 |
| Zero-length input | "", " ", "a" |
3. Decision Tables — for combinational logic
When behaviour depends on multiple conditions, enumerate every combination.
Example — free shipping rule
| Cart ≥ $50 | Member | Coupon | Free ship? |
|---|---|---|---|
| Y | Y | Y | Yes |
| Y | Y | N | Yes |
| Y | N | Y | Yes |
| Y | N | N | Yes |
| N | Y | Y | Yes |
| N | Y | N | No |
| N | N | Y | No |
| N | N | N | No |
4. State Transition Testing
For workflows: order, subscription, ticket lifecycle. Model states and transitions, then test every valid path and every invalid attempt.
Order states: Draft → Placed → Paid → Shipped → Delivered
↓
Cancelled
Valid transitions to test:
Draft → Placed (submit)
Placed → Paid (pay success)
Placed → Cancelled (user cancel)
Paid → Shipped (warehouse)
Shipped → Delivered (courier scan)
Invalid transitions to reject:
Delivered → Cancelled
Draft → Shipped
Paid → Draft5. Use Case Testing
Cover realistic end-to-end user journeys, including the main flow, alternate flows, and exception flows.
- Main flow: User adds item, checks out, receives email.
- Alternate: User applies a valid coupon before checkout.
- Exception: Payment declined — user retries or cancels.
6. Pairwise / All-pairs Testing
With 5 parameters × 3 values each you'd have 243 combinations. Pairwise finds a subset (~10) that covers every pair of values at least once — proven to catch most interaction defects.
| Browser | OS | Payment | Currency | Language |
|---|---|---|---|---|
| Chrome | Windows | Card | USD | EN |
| Chrome | macOS | PayPal | EUR | FR |
| Firefox | Windows | PayPal | GBP | EN |
| Firefox | Linux | Card | USD | FR |
| Safari | macOS | Card | EUR | EN |
| Safari | iOS | PayPal | USD | FR |
allpairs, PICT (Microsoft), or a spreadsheet template.7. Error Guessing — structured intuition
- Empty string, whitespace only, single character
- Null, undefined, missing field
- Zero, negative, very large numbers, floats where int expected
- Unicode: emoji, right-to-left, combining accents
- Timezones, DST switch, leap year Feb 29
- Extremely long input (10k+ chars)
- SQL / HTML / script injection strings
- Fast repeat clicks (double submit)
- Slow / flaky network, offline mode
8. Which technique for which situation
| Situation | Best technique |
|---|---|
| Numeric ranges (age, price, quantity) | EP + BVA |
| Business rules (discount, permission) | Decision Table |
| Workflows (order, ticket status) | State Transition |
| End-to-end scenarios | Use Case |
| Many independent parameters | Pairwise |
| After all else — sanity | Error Guessing |
9. Hands-on task (40 minutes)
- 1
Pick a real feature
Choose a login form. Apply EP + BVA to email (min length, format) and password (length, complexity).
- 2
Build a decision table
For a coupon system with 3 conditions, enumerate all 8 rows and note the expected result.
- 3
Model states
Pick an order lifecycle in your app. Draw the state diagram and list every valid + invalid transition.
- 4
Generate pairwise combos
Use
PICTagainst your browser × OS × payment matrix. Compare test count vs full factorial.
You've completed the QA Learning Path. Reinforce with the Practice Hub or head to the AI Mock Interview.