Test Design for Real Applications
In real projects, you don't apply test design techniques in isolation - you combine them strategically based on the feature type, business risk, and available time. This topic demonstrates how professional SDETs pick the right technique (or combination) for real-world feature scenarios, and how to build complete test suites that provide maximum coverage with practical effort.
Technique Selection Guide
- Numeric range input fields → BVA + EP (boundaries + partitions)
- Multiple-option selections → EP (one representative per option)
- Complex business rules with multiple conditions → Decision Table
- Workflow-based features (account management, order process) → State Transition
- User stories and end-to-end scenarios → Use Case Testing
- Multi-parameter compatibility (browser × OS × device) → Pairwise
- Known failure patterns, intuition-driven → Error Guessing
- Unknown & unexplored areas → Exploratory Testing (Module 2)
Complete Test Suite for a Coupon Feature
// Feature: Apply coupon code at checkout
// Requirements:
// - Coupon code format: 6 alphanumeric uppercase characters
// - Valid coupon types: PERCENT_OFF (1-100%), FIXED_OFF ($1-$500)
// - Coupons have expiry dates and usage limits
// - Cannot combine two coupons in the same order
// - Cart total after discount cannot be negative
// ── TECHNIQUE 1: EP + BVA (coupon code format) ────────────────
// EP Partitions:
// Valid: exactly 6 uppercase alphanumeric chars → "SAVE20"
// Invalid: too short (<6) → "SAV2"
// Invalid: too long (>6) → "SAVE200"
// Invalid: lowercase → "save20"
// Invalid: special chars → "SAVE2!"
// Invalid: empty → ""
// BVA on length: 5, 6, 7 chars
// ── TECHNIQUE 2: Decision Table (coupon behaviour matrix) ──────
// R1 R2 R3 R4 R5
// Valid? Y Y Y N N
// Expired? N N Y - -
// Hits limit N Y - - -
// ────────────────────────────────────
// Apply: ✅ ❌ ❌ ❌ ❌
// Message: OK Limit Exp Inv --
// ── TECHNIQUE 3: State Transition (coupon lifecycle) ───────────
// States: ACTIVE → EXPIRED (by date)
// ACTIVE → DEPLETED (usage limit reached)
// ACTIVE → SUSPENDED (admin action)
// Tests: Apply active coupon ✅
// Apply expired coupon ❌
// Apply same coupon after limit hit ❌
// ── TECHNIQUE 4: BVA (discount amount edge cases) ──────────────
// PERCENT_OFF: test 0%, 1%, 99%, 100%, 101%
// FIXED_OFF: test $0, $1, $499, $500, $501
// Cart total after discount: test where discount > cart total
// ── TECHNIQUE 5: Error Guessing ────────────────────────────────
// - Apply coupon, then change cart items (coupon still valid?)
// - Apply coupon in two browser tabs simultaneously
// - Coupon code "DROPTABLE" (SQL injection test)
// - Apply coupon exactly at expiry timestamp (race condition)
// - Rapid-fire apply same coupon 10 times via API (rate limiting)
// ── COMPLETE SUITE SUMMARY ─────────────────────────────────────
// EP/BVA tests: 8 test cases
// Decision table: 5 test cases
// State transition: 5 test cases
// BVA on amounts: 10 test cases
// Error guessing: 5 test cases
// Total: 33 test cases - comprehensive coverage for
// a feature that handles real moneyQuick Quiz - Test Design Techniques
Common Mistakes
- Using only one technique for every feature - each technique has strengths; using all applicable techniques gives the highest coverage
- Skipping test design entirely for 'simple' features - even simple-looking features have boundary bugs; EP and BVA take 10 minutes and are always worth it
- Not considering risk when choosing techniques - high-risk financial or security features deserve Decision Tables AND State Transition AND Error Guessing together
- Treating test design as a one-time activity - test cases must be updated when requirements change; stale test cases don't test what was changed
Tip
Tip
Practice Test Design for Real Applications in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task - (1) Write a working example of Test Design for Real Applications from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Common Mistake
Warning
A common mistake with Test Design for Real Applications is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- In real projects, you don't apply test design techniques in isolation - you combine them strategically based on the feature type, business risk, and available time.
- Numeric range input fields → BVA + EP (boundaries + partitions)
- Multiple-option selections → EP (one representative per option)
- Complex business rules with multiple conditions → Decision Table