| name | test-design-techniques |
| description | Test design technique reference for QA test engineers. Use when selecting, applying, or validating test design techniques including Equivalence Partitioning (EP), Boundary Value Analysis (BVA), Decision Table, State Transition, Use Case Testing, Error Guessing, Pairwise testing, and Input Field Validation. Covers when to use each technique and common misuse warnings. |
| user-invocable | false |
Test Design Techniques Reference
Apply techniques strategically — only when the acceptance criteria warrants them.
Quick Selection Guide
| AC Scenario Type | Recommended Technique |
|---|
| Numeric ranges, dropdowns, enums, role-based | Equivalence Partitioning (EP) |
| Min/max values, limits, thresholds, file sizes | Boundary Value Analysis (BVA) |
| Multiple conditions mapping to distinct outcomes | Decision Table |
| Workflow states, status changes, toggle states | State Transition |
| End-to-end user journeys, primary flows | Use Case Testing |
| Invalid inputs, error paths, edge failure modes | Error Guessing |
| 3+ input parameters with multiple values each | Pairwise (Combinatorial) |
| Form inputs, field constraints, formats | Input Field Validation |
1. Equivalence Partitioning (EP)
Purpose: Reduce test redundancy by testing one representative value per partition.
Apply for: Numeric fields, dropdowns, enums, ranges, role-based access.
Technique:
- Identify valid and invalid input partitions
- Select one representative value per partition
- Generate one test case per partition (not per value)
Example: Field accepts 1–100 → test 0 (invalid low), 50 (valid mid), 101 (invalid high)
2. Boundary Value Analysis (BVA)
Purpose: Verify correct behavior at exact boundaries and just beyond.
Apply for: Min/max constraints, character limits, date ranges, file sizes, numeric thresholds.
Technique:
- Identify minimum and maximum boundary values
- Test: min−1, min, min+1, typical nominal, max−1, max, max+1
- Focus on the exact boundary — bugs cluster at edges
Example: Max upload 25MB → test 24.9MB (below), 25MB (exact), 25.1MB (above)
3. Decision Table Testing
Purpose: Efficiently cover all combinations of business rules.
Apply for: Multi-condition logic with 2+ conditions and defined outcome combinations.
Technique:
- List all conditions and their possible values
- Map outcomes for each valid combination
- Generate one test case per unique rule combination
Example: User Role (Admin/User) + Subscription (Active/Expired) → Access Level (Full/Limited/Denied)
4. State Transition Testing
Purpose: Validate system behavior as it moves between defined states.
Apply for: Workflows, feature toggles, status fields, approval chains, onboarding steps.
Technique:
- Identify all possible system states
- Identify events/triggers that cause transitions
- Create test cases for: valid transitions, invalid transitions, boundary/terminal states
Example: Feature Toggle OFF → ON → Feature Visible → Toggle OFF → Feature Hidden
5. Use Case Testing
Purpose: Derive test cases from real-world user journeys.
Apply for: Complete feature flows, primary happy paths, multi-step user workflows.
Technique:
- Identify the primary actor and their goal
- Define the main flow (happy path)
- Define alternative flows (different paths to same goal)
- Define exception flows (error recovery paths)
Example: Create Template → Configure Fields → Preview → Save → Export → Verify Output
6. Error Guessing
Purpose: Identify defects using tester experience with common failure modes.
Apply when: AC explicitly mentions invalid inputs, error handling, or negative behavior.
Safe Usage:
- Limit to failure-prone areas implied by the AC
- Do NOT hallucinate errors outside AC rules
- Do NOT add error guessing test cases for ACs that describe purely positive behavior
Valid examples: Special characters in numeric fields, null/blank inputs, duplicate submissions, concurrent modifications
7. Pairwise (Combinatorial) Testing
Purpose: Ensure pairwise coverage of multiple parameter combinations with fewer test cases.
Apply only when: AC explicitly has 3+ independent input parameters each with 2+ values.
Do NOT apply: For single or dual parameter scenarios — exhaustive coverage is fine there.
Example: Platform (iOS/Android/Web) × User Role (Admin/User) × Feature State (ON/OFF)
8. Input Field Validation
Purpose: Validate input constraints, formats, and system-enforced field rules.
Apply for: Forms, text inputs, dropdowns, date pickers, file uploads, search fields.
Test areas:
- Mandatory fields: blank (should fail) / filled (should succeed)
- Optional fields: empty (valid) / valid input / invalid input
- Character limits: 0 chars, max chars, max+1 chars
- Allowed vs disallowed characters (special chars, whitespace, unicode)
- Default states and placeholder values
- Error messages on invalid input — verify exact message text
Example: Text field max 50 chars → test "" (blank), "a"×50 (max), "a"×51 (over limit)
Technique Misuse Warnings
| Anti-Pattern | Correct Approach |
|---|
| Applying BVA to non-numeric/non-constrained fields | Use Input Field Validation instead |
| Error Guessing for scenarios not implied by ACs | Restrict to AC-defined failure modes |
| Decision Table for single-condition logic | Use Use Case Testing or EP |
| Pairwise for 1–2 parameters | Exhaustive combinations are manageable — use them |
| Labelling a test "Error Guessing" when it's just a negative EP case | Use EP and call it a negative partition |
