magnus919_agent-skills/qa-methodology/references/test-design-techniques.md

Test Design Techniques

Systematic methods for deriving test cases from specifications. Load when designing test cases for a specific feature, choosing which technique fits a scenario, or reviewing test coverage gaps. Not for test strategy allocation (that's test-strategy.md) or exploratory discovery (that's exploratory-testing.md).

Technique Overview

Technique	Input Model	Strength	Weakness
Equivalence Partitioning (EP)	Input domains	Reduces test count with representative coverage	Misses boundary defects
Boundary Value Analysis (BVA)	Numeric/ordered ranges	Catches off-by-one, overflow, edge behavior	Only useful at boundaries
Decision Tables	Business rules with conditions	Complete combinatorial logic coverage	Explosion with many conditions
State Transition	Stateful workflows	Catches invalid transitions, dead states	Requires accurate state model
Pairwise / Combinatorial	Multi-parameter configurations	Covers all 2-way interactions with O(n log n) tests	Misses 3+ way interactions
Error Guessing	Experience, defect history	Finds "obvious" bugs fast	Unsystematic; depends on tester skill

Equivalence Partitioning (EP)

Divide the input domain into classes where behavior should be identical. Test one representative from each class.

Worked Example: Age Field (0–120, integer)

Partition	Range	Representative	Expected
Invalid (below)	< 0	-1	Reject
Valid (child)	0–12	6	Accept, category=child
Valid (adult)	13–64	30	Accept, category=adult
Valid (senior)	65–120	70	Accept, category=senior
Invalid (above)	> 120	121	Reject
Invalid (type)	non-integer	"abc", 3.5	Reject

5 tests instead of 121 exhaustive values. Each partition's representative exercises the same code path as all other members.

Boundary Value Analysis (BVA)

Defects cluster at boundaries. Test the values adjacent to partition edges.

2-Value vs 3-Value BVA

Approach	Values Tested	When to Use
2-value (edge)	min, max	Quick coverage; most defects are at the boundary itself
3-value (edge + just outside)	min-1, min, max, max+1	When off-by-one is likely; stronger assurance

Worked Example: Order Quantity (1–999)

Value	Type	Expected
0	Below minimum (3-value)	Reject
1	Minimum boundary	Accept
999	Maximum boundary	Accept
1000	Above maximum (3-value)	Reject

Add EP representatives for interior partitions (e.g., 500) if behavior differs within the range.

Decision Tables

When business logic depends on combinations of conditions, a decision table ensures every combination is tested.

Worked Example: Discount Rules

Condition	Rule 1	Rule 2	Rule 3	Rule 4
Premium member?	Y	Y	N	N
Order > $100?	Y	N	Y	N
Action	20% off	10% off	5% off	0%

4 rules from 2 binary conditions (2² = 4). Each rule becomes at least one test case.

Managing Complexity

Conditions	Rules	Strategy
≤ 4	≤ 16	Full decision table
5–8	32–256	Collapse don't-care combinations; use pairwise for remaining
> 8	256+	Pairwise testing (below) + risk-based selection

State Transition Testing

Model the system as states + transitions. Test every valid transition and verify that invalid transitions are rejected.

Worked Example: Order Lifecycle

[Created] --pay--> [Paid] --ship--> [Shipped] --deliver--> [Delivered]
    |                 |                                    |
    +--cancel--> [Cancelled] <--cancel-- [Paid]           +--return--> [Returned]

Test	Path	Expected
Happy path	Created → Paid → Shipped → Delivered	Success at each step
Cancel from Created	Created → Cancelled	Order voided, no charge
Cancel from Paid	Paid → Cancelled	Refund issued
Invalid: ship unpaid	Created → Shipped (attempt)	Reject; state unchanged
Invalid: pay cancelled	Cancelled → Paid (attempt)	Reject; state unchanged
Return path	Delivered → Returned	Return processed

Coverage criteria: at minimum, cover every state (0-switch) and every transition (1-switch). For critical workflows, cover 2-switch (pairs of consecutive transitions).

Pairwise (Combinatorial) Testing

When parameters interact, full combinatorial testing explodes (e.g., 5 params × 4 values = 1024 tests). Pairwise covers every pair of parameter values in far fewer tests.

Tool: PICT

PICT (Microsoft) generates pairwise test sets from a model file:

# model.txt — PICT format
OS:      Windows, macOS, Linux
Browser: Chrome, Firefox, Safari
Network: WiFi, Cellular, Offline
Locale:  en-US, de-DE, ja-JP

pict model.txt > pairwise-tests.txt
# Produces ~12–15 tests covering all pairs (vs 81 exhaustive)

When Pairwise Is Sufficient

Interaction Depth	Technique	Test Count
1-way (each value)	EP representatives	N
2-way (all pairs)	Pairwise / all-pairs	O(N log N)
3-way (all triples)	t-wise (t=3)	O(N² log N)
N-way (exhaustive)	Full combinatorial	Product of all values

Most defects are triggered by 1- or 2-way interactions (empirical evidence from NIST studies). Pairwise is the default; escalate to t=3 only for high-risk configuration surfaces.

Error Guessing

Systematic intuition: use defect history, code complexity, and experience to target likely failure points.

Structured Error-Guessing Checklist

Category	Examples to Try
Empty / null inputs	"", null, undefined, [], {}
Extreme values	MAX_INT, empty string, 10MB upload, 0-length list
Special characters	Unicode, emoji, SQL metacharacters, path separators
Concurrency	Double-submit, back-button during save, parallel edits
Timing	Midnight boundary, DST transition, leap second, month-end
State corruption	Kill process mid-write, network drop during transaction
Permission edges	Read-only filesystem, expired token, revoked role

Error guessing complements systematic techniques — run it after EP/BVA/decision tables to catch what structured methods miss.

When to Use Which Technique

Scenario	Primary Technique	Secondary	Rationale
Numeric input field with ranges	BVA (3-value)	EP	Boundaries are the highest-yield targets
Form with many optional fields	Pairwise (PICT)	EP for each field	Interactions between fields cause most form bugs
Business rules with 2–4 conditions	Decision table	EP for each condition value	Complete logic coverage with manageable size
Stateful workflow (order, ticket, session)	State transition	Error guessing (invalid transitions)	Invalid transitions are the #1 stateful bug class
API with enum parameters	EP	Pairwise if multiple enums	Each enum value is a partition
Legacy code with defect history	Error guessing	BVA on known-problem fields	History predicts future defect locations
Configuration matrix (OS × browser × env)	Pairwise	—	Exhaustive is infeasible; pairs catch most bugs

Technique Selection Flowchart

Is the input numeric or ordered?
  YES → BVA + EP
  NO  → Does behavior depend on condition combinations?
          YES → ≤ 4 conditions? → Decision table
                 > 4 conditions? → Pairwise
          NO  → Is the system stateful?
                  YES → State transition
                  NO  → EP + error guessing

Level-Mapping Guidance

These techniques apply at any test level (unit, integration, E2E). The following mapping is a typical starting point — adapt to your context:

Technique	Typical Level	Adaptation Note
EP / BVA	Unit (input validation)	Also applies at integration (API contracts) and E2E (form validation)
Decision tables	Unit / integration	Business rules often span services; test at integration level
State transition	Integration / E2E	Workflow state is usually service-level, not function-level
Pairwise	E2E / system	Configuration surfaces are system-wide
Error guessing	Any level	Most valuable at integration and E2E where interactions emerge

Note: This is a heuristic default, not a prescription. A state machine inside a single function is best tested at unit level; a simple input boundary may be best caught by an integration test. Context determines placement, not technique identity. See test-strategy.md for the pyramid-as-heuristic framing.

Gotchas

Gotcha — EP without boundary testing: Equivalence partitioning alone misses off-by-one errors at partition edges. Always pair EP with BVA on numeric or ordered inputs.

Gotcha — Decision table explosion: Adding a 5th binary condition doubles the table. Before adding conditions, ask: does this condition independently affect the outcome? If not, collapse it.

Gotcha — Pairwise as a substitute for understanding: Pairwise generates combinations but doesn't tell you what's wrong. You still need oracles (expected results) for every generated test. A pairwise suite without assertions is just coverage theater.

Exit Condition

You are done applying this reference when: (1) each testable input or behavior is assigned a primary technique, (2) boundary values are tested for all numeric/ordered inputs, (3) stateful workflows have transition coverage (at least 1-switch), and (4) configuration matrices use pairwise reduction rather than exhaustive enumeration.

Composition Links

• Test strategy and allocation by risk tier: test-strategy.md
• Exploratory testing for areas where techniques don't yet apply: exploratory-testing.md
• Risk-based prioritization of which areas get exhaustive design: risk-based-testing.md
• Test automation of designed cases: test-automation.md

---

Sources: ISTQB Foundation Level Syllabus 2023 (test design techniques), PICT (Microsoft, github.com/microsoft/pict), NIST pairwise studies (Kuhn et al., 2004), Cem Kaner et al. "Lessons Learned in Software Testing" (Wiley, 2002), Rex Black "Managing the Testing Process" (Wiley, 2009).