Test Design Techniques: Complete Guide for QA Interviews

Master all test design techniques with practical examples. From Equivalence Partitioning to State Transition - everything you need to pass QA interviews

🎯 Why This Article?

At almost every QA interview you’ll hear:

“What test design techniques do you know? Give me an example.”

Many candidates can name techniques but struggle with real examples. This article will teach you:

• ✅ All major test design techniques
• ✅ Real-world examples for each
• ✅ When to use which technique
• ✅ Common interview questions with answers
• ✅ Practice exercises

By the end, you’ll confidently answer any test design question in interviews.

📋 Table of Contents

1. What is Test Design?
2. Equivalence Partitioning
3. Boundary Value Analysis
4. Decision Table Testing
5. State Transition Testing
6. Pairwise Testing
7. Error Guessing
8. Use Case Testing
9. Exploratory Testing
10. Interview Questions & Answers
11. Practice Exercises

🎨 What is Test Design?

The Problem

Imagine testing a simple login form with:

• Username (1-50 characters)
• Password (8-20 characters)
• “Remember me” checkbox

How many test cases do you need?

If you try ALL possible combinations:

• Username: billions of combinations
• Password: even more
• Checkbox: 2 states

Result: Infinite tests, impossible to execute!

The Solution: Test Design Techniques

Test design techniques help you:

• ✅ Reduce test cases to a manageable number
• ✅ Maximize test coverage
• ✅ Find bugs efficiently
• ✅ Save time and resources

Black-Box vs White-Box

Black-Box Testing (focus of this article):

• Test without knowing internal code
• Based on requirements and specifications
• Techniques: Equivalence Partitioning, Boundary Value, etc.

White-Box Testing:

• Test with knowledge of code
• Based on code structure
• Techniques: Statement Coverage, Branch Coverage, etc.

📦 Equivalence Partitioning (EP)

What is it?

Divide input data into groups (partitions) where all values in a group should behave the same way.

Key Idea: If one value in a partition works, all values in that partition should work.

Real Example: Age Validation

Requirement: User must be 18-65 years old to register.

Without EP: Test ages 1, 2, 3, 4… 100 = 100 test cases

With EP: Divide into partitions:

Result: Only 4 test cases needed!

Test Cases

Test Case 1: Age = 10
  Input: age = 10
  Expected: Error "You must be at least 18 years old"
  Partition: Invalid (too young)

Test Case 2: Age = 30
  Input: age = 30
  Expected: Registration successful
  Partition: Valid

Test Case 3: Age = 70
  Input: age = 70
  Expected: Error "Maximum age is 65"
  Partition: Invalid (too old)

Test Case 4: Age = -5
  Input: age = -5
  Expected: Error "Invalid age"
  Partition: Invalid (negative)

Another Example: Email Validation

Requirement: Valid email format required

Partitions:

When to Use EP?

• ✅ Input fields with ranges
• ✅ Dropdown selections
• ✅ Any input with valid/invalid categories
• ✅ When you need to reduce test cases

🎯 Boundary Value Analysis (BVA)

What is it?

Test at the edges (boundaries) of equivalence partitions. Bugs love to hide at boundaries!

Key Idea: Test minimum, maximum, and values just inside/outside the boundary.

The Bug Zone

        Invalid    |     Valid     |    Invalid
    ←-------------|---------------|-------------→
                 18               65
                  ↑               ↑
              BOUNDARY         BOUNDARY
              
    Most bugs occur HERE at the boundaries!

Real Example: Age Validation (continued)

Requirement: User must be 18-65 years old

BVA Test Values:

Test Cases

Test Case 1: Age = 17 (boundary - 1)
  Input: age = 17
  Expected: Error "You must be at least 18"
  
Test Case 2: Age = 18 (lower boundary)
  Input: age = 18
  Expected: Success
  
Test Case 3: Age = 19 (boundary + 1)
  Input: age = 19
  Expected: Success
  
Test Case 4: Age = 64 (boundary - 1)
  Input: age = 64
  Expected: Success
  
Test Case 5: Age = 65 (upper boundary)
  Input: age = 65
  Expected: Success
  
Test Case 6: Age = 66 (boundary + 1)
  Input: age = 66
  Expected: Error "Maximum age is 65"

Another Example: Password Length

Requirement: Password must be 8-20 characters

BVA Test Values:

EP + BVA Together

Best Practice: Always combine EP and BVA!

Step 1: Identify partitions (EP)
  - Invalid: < 8 characters
  - Valid: 8-20 characters
  - Invalid: > 20 characters

Step 2: Test boundaries (BVA)
  - 7 characters (boundary - 1)
  - 8 characters (lower boundary)
  - 9 characters (boundary + 1)
  - 19 characters (boundary - 1)
  - 20 characters (upper boundary)
  - 21 characters (boundary + 1)

Step 3: Test one value from each partition (EP)
  - 5 characters (invalid partition)
  - 15 characters (valid partition)
  - 25 characters (invalid partition)

📊 Decision Table Testing

What is it?

Test combinations of conditions and their corresponding actions. Perfect for complex business rules!

Key Idea: Organize conditions and actions in a table to ensure all combinations are tested.

Real Example: Shipping Cost Calculator

Business Rules:

• If order > $100 AND premium member → Free shipping
• If order > $100 AND regular member → $5 shipping
• If order ≤ $100 AND premium member → $5 shipping
• If order ≤ $100 AND regular member → $10 shipping

Decision Table:

Test Cases from Decision Table

Test Case 1: Rule 1
  Conditions:
    - Order amount: $150 (> $100)
    - Member type: Premium
  Expected: Free shipping ($0)

Test Case 2: Rule 2
  Conditions:
    - Order amount: $150 (> $100)
    - Member type: Regular
  Expected: $5 shipping

Test Case 3: Rule 3
  Conditions:
    - Order amount: $50 (≤ $100)
    - Member type: Premium
  Expected: $5 shipping

Test Case 4: Rule 4
  Conditions:
    - Order amount: $50 (≤ $100)
    - Member type: Regular
  Expected: $10 shipping

Another Example: Login System

Business Rules:

• Valid username AND valid password → Login success
• Valid username AND invalid password → Show “Wrong password”
• Invalid username AND any password → Show “User not found”
• Empty username OR empty password → Show “Please fill all fields”

Decision Table:

When to Use Decision Tables?

• ✅ Multiple conditions affecting outcomes
• ✅ Complex business rules
• ✅ Different combinations produce different results
• ✅ Payment systems, discounts, permissions

🔄 State Transition Testing

What is it?

Test how a system behaves as it moves through different states based on events/actions.

Key Idea: Identify states, events that trigger transitions, and actions that occur.

Real Example: Online Order Status

States:

1. Cart → 2. Pending Payment → 3. Paid → 4. Shipped → 5. Delivered

State Transition Diagram:

    [Cart]
       |
       | (Place Order)
       ↓
[Pending Payment]
       |
       | (Pay)          | (Cancel)
       ↓                ↓
    [Paid]         [Cancelled]
       |
       | (Ship)
       ↓
   [Shipped]
       |
       | (Deliver)
       ↓
  [Delivered]

State Transition Table:

Test Cases

Test Case 1: Happy Path - Complete Order
  States: Cart → Pending → Paid → Shipped → Delivered
  Steps:
    1. Add item to cart
    2. Place order → Status: Pending Payment
    3. Make payment → Status: Paid
    4. Admin ships → Status: Shipped
    5. Delivery confirmed → Status: Delivered

Test Case 2: Cancel Order
  States: Cart → Pending → Cancelled
  Steps:
    1. Add item to cart
    2. Place order → Status: Pending Payment
    3. Cancel order → Status: Cancelled

Test Case 3: Invalid Transition
  Current State: Delivered
  Action: Try to cancel
  Expected: Error "Cannot cancel delivered order"

Another Example: ATM PIN Validation

States:

• Unlocked (card inserted, 3 attempts left)
• Locked (too many wrong PINs)

State Diagram:

                    [Card Inserted]
                          |
                    3 attempts left
                          |
        Wrong PIN         |         Correct PIN
     ←-------------[Attempt 1]-------------→ [Unlocked]
           |              ↓
           |        2 attempts left
           |              |
           |    Wrong PIN |         Correct PIN
           ←-------[Attempt 2]-------------→ [Unlocked]
           |              ↓
           |        1 attempt left
           |              |
           |    Wrong PIN |         Correct PIN
           ←-------[Attempt 3]-------------→ [Unlocked]
                          ↓
                      [Locked]
                    Card retained

Test Cases for ATM

Test Case 1: Correct PIN on first try
  Initial: Card inserted, 3 attempts
  Action: Enter correct PIN
  Expected: Account unlocked

Test Case 2: Correct PIN on second try
  Initial: Card inserted, 3 attempts
  Action: Wrong PIN → Correct PIN
  Expected: Account unlocked, warning shown

Test Case 3: Card locked after 3 wrong attempts
  Initial: Card inserted, 3 attempts
  Action: Wrong PIN × 3
  Expected: Card locked and retained

🔗 Pairwise Testing (All-Pairs)

What is it?

Test all possible pairs of input parameters. Based on the fact that most bugs are caused by interactions between two parameters.

Key Idea: Instead of testing all combinations, test every pair at least once.

The Problem

Testing a browser compatibility:

• OS: Windows, macOS, Linux (3 options)
• Browser: Chrome, Firefox, Safari, Edge (4 options)
• Language: English, Spanish, French (3 options)

All combinations: 3 × 4 × 3 = 36 test cases

Pairwise Solution

Pairwise covers all pairs with fewer tests:

Result: Only 9 test cases instead of 36!

Verifying Coverage

Let’s check that all pairs are covered:

OS + Browser pairs:

• Windows + Chrome ✅ (Test 1)
• Windows + Firefox ✅ (Test 2)
• Windows + Safari ✅ (Test 3)
• macOS + Chrome ✅ (Test 4)
• … (all covered)

OS + Language pairs:

• Windows + English ✅ (Test 1)
• Windows + Spanish ✅ (Test 2)
• … (all covered)

Tools for Pairwise

• PICT (Microsoft) - Free command-line tool
• AllPairs - Online generator
• Hexawise - Commercial tool

When to Use Pairwise?

• ✅ Many input parameters
• ✅ Configuration testing
• ✅ Compatibility testing
• ✅ When full coverage is too expensive

🔮 Error Guessing

What is it?

Use experience and intuition to guess where bugs might hide. Not a formal technique, but very effective!

Key Idea: Think like a tester - where would YOU expect bugs?

Common Error-Prone Areas

1. Empty/Null Values

- Empty string ""
- Null value
- Only spaces "   "
- Only special characters "!@#$%"

2. Boundary Values (Extreme)

- 0
- Negative numbers (-1)
- Very large numbers (999999999)
- Maximum integer (2147483647)
- Decimal precision (0.00001)

3. Special Characters

- Quotes: ' " ` 
- HTML: < > & 
- SQL: ; -- ' OR 1=1
- Unicode: 中文 العربية 🎉
- Escape: \n \t \r

4. Date/Time Edge Cases

- Leap year (Feb 29)
- Month boundaries (Jan 31 + 1 day)
- Time zones
- Daylight saving time
- Year 2000, 2038 problems

5. File Upload Issues

- Empty file (0 bytes)
- Very large file (1GB+)
- Wrong extension
- Executable files (.exe, .bat)
- Double extensions (image.jpg.exe)

Example: Testing a Search Function

What would you test?

Obvious tests:
- Valid search term → Results found
- No matches → "No results" message

Error guessing tests:
- Empty search → How does it handle?
- Only spaces → "   " 
- Very long query → 1000+ characters
- Special characters → <script>alert('xss')</script>
- SQL injection → ' OR '1'='1
- Unicode → 日本語 العربية
- Numbers only → 12345
- Single character → "a"

Error Guessing Checklist

Always test these:

📖 Use Case Testing

What is it?

Test complete user scenarios from start to finish. Based on how real users actually use the system.

Key Idea: Test realistic user journeys, not just individual features.

Use Case Structure

Use Case: [Name]
Actor: [Who performs the action]
Preconditions: [What must be true before]
Main Flow: [Step-by-step happy path]
Alternative Flows: [Variations]
Postconditions: [What is true after]

Example: Online Shopping Purchase

Use Case: Complete a Purchase

Actor: Registered Customer

Preconditions:
- User is logged in
- User has items in cart
- User has valid payment method

Main Flow (Happy Path):
1. User views shopping cart
2. User clicks "Checkout"
3. System displays shipping options
4. User selects shipping method
5. System displays payment options
6. User enters payment details
7. User clicks "Place Order"
8. System processes payment
9. System displays order confirmation
10. System sends confirmation email

Alternative Flows:
A1. Empty Cart (at step 1):
    - System shows "Your cart is empty"
    - Flow ends

A2. Payment Declined (at step 8):
    - System shows "Payment declined"
    - Return to step 6

A3. Out of Stock (at step 7):
    - System shows "Item no longer available"
    - Return to step 1

Postconditions:
- Order is created in system
- Payment is processed
- Confirmation email sent
- Inventory updated

Test Cases from Use Case

Test Case 1: Happy Path
  Preconditions: Logged in, items in cart
  Steps: Follow main flow 1-10
  Expected: Order confirmed, email received

Test Case 2: Empty Cart
  Preconditions: Logged in, empty cart
  Steps: Click checkout
  Expected: "Your cart is empty" message

Test Case 3: Payment Declined
  Preconditions: Logged in, items in cart
  Steps: Use invalid card
  Expected: "Payment declined", stay on payment page

Test Case 4: Out of Stock
  Preconditions: Last item in stock
  Steps: Another user buys it first, then checkout
  Expected: "Item no longer available"

🔍 Exploratory Testing

What is it?

Simultaneous learning, test design, and test execution. No predefined test cases - you explore and discover!

Key Idea: Use creativity and curiosity to find bugs that scripted tests miss.

Structure: Session-Based Testing

Time-boxed sessions:

• Duration: 45-90 minutes
• Clear charter (goal)
• Take notes of findings
• Debrief after session

Session Charter Example

Charter: Explore the password reset functionality

Focus Areas:
- Happy path reset flow
- Error handling
- Security considerations
- Edge cases

Time: 60 minutes

Questions to Answer:
- What happens with invalid email?
- Can reset link be used twice?
- Does link expire?
- Can I reset to same password?

Session Notes Template

Session Report
==============
Tester: [Name]
Date: [Date]
Duration: 60 minutes
Charter: Explore password reset

FINDINGS:
---------
Bug #1: Reset link doesn't expire
  Severity: High
  Steps: Use 1-week old reset link
  Expected: "Link expired"
  Actual: Password changed successfully

Bug #2: No confirmation for weak password
  Severity: Medium
  Steps: Reset to "123456"
  Expected: Warning about weak password
  Actual: Password accepted silently

QUESTIONS:
----------
- Is there a limit on reset requests?
- What happens if email doesn't exist?

AREAS NOT COVERED:
------------------
- Multiple reset requests
- Mobile responsive testing

Exploratory Testing Heuristics

SFDPOT Heuristic:

❓ Interview Questions & Answers

Question 1: “What is Equivalence Partitioning?”

Good Answer:

“Equivalence Partitioning is a test design technique where we divide input data into groups that should behave the same way. Instead of testing every possible value, we test one value from each partition. For example, testing an age field with requirement 18-65 years: we create partitions for ‘too young’ (0-17), ‘valid’ (18-65), and ‘too old’ (66+). We only need 3 tests instead of testing every age.”

Question 2: “How is BVA different from EP?”

Good Answer:

“While EP divides inputs into partitions and tests one value from each, BVA specifically focuses on the boundaries between partitions. Bugs often hide at boundaries - the exact minimum, maximum, and values just before/after. For an 18-65 age requirement, BVA would test: 17, 18, 19, 64, 65, 66 - the exact boundary values.”

Question 3: “When would you use Decision Table Testing?”

Good Answer:

“Decision Table Testing is best when we have multiple conditions that create different outcomes. For example, a shipping cost calculator where cost depends on order amount AND membership type. I’d create a table listing all condition combinations and their expected results. This ensures we don’t miss any combination and makes test cases very clear.”

Question 4: “Give me an example of State Transition Testing”

Good Answer:

“A perfect example is an ATM PIN validation. States are: ‘Active’ with 3 attempts, then 2 attempts, then 1 attempt, finally ‘Locked’. Events are ‘correct PIN’ or ‘wrong PIN’. I’d test: correct on first try, correct after one wrong, correct after two wrong, and three wrong PINs leading to locked state. I’d also verify you can’t go from Locked back to Active without card replacement.”

Question 5: “What’s the difference between black-box and white-box testing?”

Good Answer:

“Black-box testing means I test the system without knowing internal code - I focus on inputs and outputs based on requirements. Techniques include EP, BVA, Decision Tables. White-box testing means I can see the code and design tests based on code structure - testing all branches, statements, paths. As a QA, I mostly use black-box techniques, but understanding both helps me communicate with developers.”

Question 6: “How do you decide which technique to use?”

Good Answer:

“I choose based on the feature being tested:

• Simple input fields → EP + BVA
• Complex business rules → Decision Tables
• Workflow/processes → State Transition
• Many configuration options → Pairwise
• New features I’m learning → Exploratory

Often I combine multiple techniques. For a login form, I’d use EP for valid/invalid inputs, BVA for password length boundaries, and Error Guessing for special characters and SQL injection.”

📝 Practice Exercises

Exercise 1: Registration Form

Requirements:

• Username: 3-20 characters, letters and numbers only
• Password: 8-16 characters, must contain at least one number
• Age: 13-120 years
• Email: valid email format

Your Task:

1. Create equivalence partitions for each field
2. Identify boundary values
3. Write at least 10 test cases

Exercise 2: Discount System

Business Rules:

• Orders > $200 AND loyalty member → 20% discount
• Orders > $200 AND not member → 10% discount
• Orders $100-200 AND loyalty member → 10% discount
• Orders $100-200 AND not member → 5% discount
• Orders < $100 → No discount

Your Task:

1. Create a decision table
2. Write test cases for each rule

Exercise 3: Video Streaming States

Requirements: A video player has these states: Stopped, Playing, Paused, Buffering

Actions:

• Play, Pause, Stop, Seek

Your Task:

1. Draw a state transition diagram
2. Create a state transition table
3. Write test cases for valid and invalid transitions

[Stopped] --Play--> [Playing]
[Playing] --Pause--> [Paused]
[Playing] --Stop--> [Stopped]
[Playing] --BufferNeeded--> [Buffering]
[Paused] --Play--> [Playing]
[Paused] --Stop--> [Stopped]
[Buffering] --BufferComplete--> [Playing]

🎯 Key Takeaways

Technique Quick Reference

Interview Tips

1. Always give examples - Don’t just define, demonstrate
2. Explain your thinking - Walk through your approach
3. Combine techniques - Show you know when to use what
4. Be practical - Relate to real-world scenarios
5. Ask questions - Clarify requirements before designing tests

Practice Resources

• Software Testing Help - Free tutorials
• Ministry of Testing - Community and resources
• ISTQB Foundation - Certification prep
• Test Automation University - Free courses

📍 What’s Next?

Now that you understand test design techniques, continue your QA journey:

• Article 1: QA Interview Preparation Fundamentals
• Article 2: Advanced Topics and Practice
• Article 3: DSA for QA Engineers
• Article 4: Test Automation Frameworks
• Article 5: CI/CD for QA Engineers

Was this article helpful? 👏

Questions? Feel free to ask!

Author: AAnnayev — Senior SDET

Tags: #QA #Testing #TestDesign #Interview #ManualTesting #Techniques