--- name: test-design-techniques description: Systematic test case design techniques including Equivalence Partitioning, Boundary Value Analysis, Decision Tables, State Transition Testing, and Pairwise Testing. Use when deriving optimal Gherkin scenarios or unit/integration test cases from requirements. --- # Test Design Techniques Skill > Reference for systematic test case design in Coder Sura SDD workflow. ## Overview Test design techniques are systematic methods for deriving test cases from requirements. They ensure comprehensive coverage while avoiding explosion of test cases. ## Technique Selection Matrix | Technique | Best For | Avoid When | |-----------|----------|------------| | Equivalence Partitioning | Large input ranges | Few discrete values | | Boundary Value Analysis | Numeric ranges, dates | Boolean flags | | Decision Table | Complex business rules | Simple conditions | | State Transition | Workflows, lifecycles | Stateless operations | | Pairwise Testing | Multiple parameters | Strong dependencies | ## 1. Equivalence Partitioning (EP) **Purpose:** Divide inputs into classes where all values behave identically. ### Concept ``` Input Domain: 0-150 ├── Invalid (< 0) → One test case ├── Valid (0-100) → One test case ├── Warning (101-150) → One test case └── Invalid (> 150) → One test case ``` ### Example: Age Validation ```gherkin Feature: Age-based access control # Partition: Minor (< 18) Scenario: Deny access to minors Given a user with age 10 When the user attempts to access restricted content Then access is denied with message "Must be 18 or older" # Partition: Adult (18-64) Scenario: Allow access to adults Given a user with age 35 When the user attempts to access restricted content Then access is granted # Partition: Senior (65+) Scenario: Allow access to seniors with discount Given a user with age 70 When the user attempts to access restricted content Then access is granted with senior discount applied ``` ### Rules - Pick ONE representative value per partition - Cover ALL partitions (valid and invalid) - Don't test multiple values from same partition ## 2. Boundary Value Analysis (BVA) **Purpose:** Test at the edges where bugs are most likely. ### Concept ``` Range: 1-100 Test points: ├── 0 (just below minimum - invalid) ├── 1 (minimum - valid) ├── 2 (just above minimum - valid) ├── 99 (just below maximum - valid) ├── 100 (maximum - valid) └── 101 (just above maximum - invalid) ``` ### Example: Quantity Validation ```gherkin Feature: Order quantity limits # Below minimum Scenario: Reject zero quantity Given an order with quantity 0 When the order is submitted Then error "Minimum quantity is 1" is displayed # At minimum (boundary) Scenario: Accept minimum quantity Given an order with quantity 1 When the order is submitted Then the order is created successfully # At maximum (boundary) Scenario: Accept maximum quantity Given an order with quantity 999 When the order is submitted Then the order is created successfully # Above maximum Scenario: Reject over-limit quantity Given an order with quantity 1000 When the order is submitted Then error "Maximum quantity is 999" is displayed ``` ### Rules - Test at boundary AND one step outside - Combine with EP for efficiency - Pay attention to off-by-one errors ## 3. Decision Table Testing **Purpose:** Handle complex combinations of conditions and actions. ### Concept ``` ┌─────────────┬───┬───┬───┬───┐ │ Conditions │ 1 │ 2 │ 3 │ 4 │ ├─────────────┼───┼───┼───┼───┤ │ Premium │ Y │ Y │ N │ N │ │ Order > $50 │ Y │ N │ Y │ N │ ├─────────────┼───┼───┼───┼───┤ │ Actions │ │ │ │ │ ├─────────────┼───┼───┼───┼───┤ │ Free Ship │ Y │ Y │ Y │ N │ │ 10% Disc │ Y │ Y │ N │ N │ └─────────────┴───┴───┴───┴───┘ ``` ### Example: Shipping Rules ```gherkin Feature: Shipping cost calculation Scenario Outline: Determine shipping and discount Given a customer And an order totaling $ When checkout is initiated Then free shipping is And 10% discount is Examples: | membership | amount | free_shipping | discount | | premium | 75 | applied | applied | | premium | 40 | applied | applied | | standard | 75 | applied | not applied | | standard | 40 | not applied | not applied | ``` ### Rules - Identify all conditions and possible values - Create truth table with all combinations - Eliminate impossible combinations - Each row = one scenario ## 4. State Transition Testing **Purpose:** Test systems that change state based on events. ### Concept ``` States: Draft → Submitted → Approved → Active → Archived ↓ Rejected ``` ### State Transition Table ``` ┌───────────┬───────────┬───────────┬──────────┐ │ Current │ Event │ Next │ Action │ ├───────────┼───────────┼───────────┼──────────┤ │ Draft │ Submit │ Submitted │ Notify │ │ Submitted │ Approve │ Approved │ Activate │ │ Submitted │ Reject │ Rejected │ Notify │ │ Approved │ Activate │ Active │ Start │ │ Active │ Archive │ Archived │ Close │ │ Draft │ Archive │ -INVALID- │ Error │ └───────────┴───────────┴───────────┴──────────┘ ``` ### Example: Order Lifecycle ```gherkin Feature: Order state transitions # Valid transition Scenario: Submit draft order Given an order in "Draft" state When the order is submitted Then the order state is "Submitted" And a notification is sent to the approver # Valid transition Scenario: Approve submitted order Given an order in "Submitted" state When the order is approved Then the order state is "Approved" # Invalid transition Scenario: Cannot archive draft order Given an order in "Draft" state When archiving is attempted Then error "Cannot archive draft orders" is displayed And the order remains in "Draft" state # Invalid event in wrong state Scenario: Cannot approve archived order Given an order in "Archived" state When approval is attempted Then error "Order is already archived" is displayed ``` ### Rules - Test ALL valid transitions - Test key INVALID transitions (security-critical) - Test sequences (0-switch, 1-switch coverage) ## 5. Pairwise Testing **Purpose:** Efficiently test multiple parameters when full combination is too large. ### Problem ``` Parameters: - Browser: Chrome, Firefox, Safari, Edge (4) - OS: Windows, Mac, Linux (3) - Resolution: 1080p, 4K, Mobile (3) - Language: EN, ES, FR (3) Full combination: 4 × 3 × 3 × 3 = 108 combinations Pairwise: ~15-20 combinations (covers all pairs) ``` ### Pairwise Table (Generated) ``` ┌─────────┬─────────┬────────────┬──────────┐ │ Browser │ OS │ Resolution │ Language │ ├─────────┼─────────┼────────────┼──────────┤ │ Chrome │ Windows │ 1080p │ EN │ │ Chrome │ Mac │ 4K │ ES │ │ Chrome │ Linux │ Mobile │ FR │ │ Firefox │ Windows │ 4K │ FR │ │ Firefox │ Mac │ Mobile │ EN │ │ Firefox │ Linux │ 1080p │ ES │ │ Safari │ Windows │ Mobile │ ES │ │ Safari │ Mac │ 1080p │ FR │ │ Safari │ Linux │ 4K │ EN │ │ Edge │ Windows │ 1080p │ EN │ │ Edge │ Mac │ Mobile │ FR │ │ Edge │ Linux │ 4K │ ES │ └─────────┴─────────┴────────────┴──────────┘ ``` ### Example: Compatibility Matrix ```gherkin Feature: Cross-browser compatibility Scenario Outline: Dashboard renders correctly Given a user on browser And running operating system And display resolution And language set to When the user opens the dashboard Then the dashboard renders without errors Examples: | browser | os | resolution | language | | Chrome | Windows | 1080p | EN | | Chrome | Mac | 4K | ES | | Firefox | Mac | Mobile | EN | | Safari | Mac | 1080p | FR | | Edge | Windows | 1080p | EN | ``` ### Tools - PICT (Microsoft): `pict model.txt > pairs.txt` - AllPairs (online): https://www.satisfice.com/tools - Hexawise: Commercial tool ## Combined Strategy For comprehensive coverage, **layer techniques**: ``` 1. Equivalence Partitioning └── Identify valid/invalid classes 2. Boundary Value Analysis └── Add edge cases for numeric ranges 3. Decision Table └── Cover business rule combinations 4. State Transition └── Cover lifecycle flows 5. Happy Path + Negative Cases └── Ensure basic flows work ``` ### Example: Complete Test Set ```gherkin Feature: Loan application # EP: Valid income range Scenario: Accept application with valid income Given an applicant with income $75,000 ... # BVA: Minimum income boundary Scenario: Reject below minimum income Given an applicant with income $29,999 ... # Decision Table: Approval rules Scenario Outline: Loan approval decision Given income and credit score When application is submitted Then decision is Examples: | income | score | result | | 80000 | 750 | approved | | 80000 | 600 | review | | 40000 | 750 | review | | 40000 | 600 | denied | # State Transition: Application lifecycle Scenario: Submit draft application Given an application in "Draft" state ... ``` ## Scenario Count Guidelines | Complexity | Techniques | Scenarios | |------------|------------|-----------| | Simple field | EP + BVA | 3-5 | | Business rule | Decision Table | 4-8 | | Workflow | State Transition | 5-10 | | Integration | Combined | 10-15 | **Maximum per feature file: 15 scenarios** If you exceed 15, split by sub-feature. ## Integration with Coder Sura The **Scenario Designer 🎯** agent uses these techniques: ``` ┌─────────────────────────────────────────────┐ │ Scenario Designer 🎯 │ ├─────────────────────────────────────────────┤ │ 1. Analyze acceptance criteria │ │ 2. Select applicable techniques: │ │ ├─ EP for ranges │ │ ├─ BVA for boundaries │ │ ├─ DT for rules │ │ └─ ST for workflows │ │ 3. Generate Gherkin scenarios │ │ 4. Enforce quantity limits (≤15/file) │ └─────────────────────────────────────────────┘ ``` ## References - Companion Skill: `gherkin-spec` (activate when formatting scenarios into `.feature` files) - [ISTQB Foundation Syllabus - Test Design](https://www.istqb.org)