test-design-techniques

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:

1. Identify valid and invalid input partitions
2. Select one representative value per partition
3. 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:

1. Identify minimum and maximum boundary values
2. Test: min−1, min, min+1, typical nominal, max−1, max, max+1
3. 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:

1. List all conditions and their possible values
2. Map outcomes for each valid combination
3. 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:

1. Identify all possible system states
2. Identify events/triggers that cause transitions
3. 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:

1. Identify the primary actor and their goal
2. Define the main flow (happy path)
3. Define alternative flows (different paths to same goal)
4. 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