Test Design Techniques

Classical test design techniques have been taught since the 1970s and remain the backbone of test case derivation. Every interviewer expects you to know them, and every experienced QA engineer uses them — often instinctively — when deciding which test cases to write. These techniques answer the question: "I cannot test every possible input. Which inputs should I choose?"

Boundary Value Analysis (BVA)

Test at the edges of input ranges, where bugs cluster. Off-by-one errors are the most common numerical bug in software, and BVA is specifically designed to catch them.

The Principle

For any input with a valid range, test:

• The value just below the lower boundary (invalid)
• The lower boundary itself (valid)
• The value just above the lower boundary (valid)
• The value just below the upper boundary (valid)
• The upper boundary itself (valid)
• The value just above the upper boundary (invalid)

Example: Age Field (accepts 18-65)

Additional Boundaries to Consider

• Zero: Does the field accept 0? What about negative numbers?
• Empty string vs null: Different things in most systems
• Maximum length: For text fields, what happens at max length, max + 1?
• Data type limits: Integer overflow (2,147,483,647 for 32-bit signed int)
• Date boundaries: End of month (28/29/30/31), year boundaries, leap years

BVA in Practice

GIVEN a registration form with age field (valid range: 18-65)
WHEN  the user enters age = 17 and submits
THEN  the form shows validation error "Age must be between 18 and 65"

GIVEN a registration form with age field (valid range: 18-65)
WHEN  the user enters age = 18 and submits
THEN  the form accepts the input and proceeds to the next step

Equivalence Partitioning (EP)

Divide inputs into groups (partitions) where all values in a partition are expected to behave the same. Test one representative value from each partition.

The Principle

If the system treats all values in a range identically, testing one value is sufficient to represent the entire range. This dramatically reduces test count while maintaining meaningful coverage.

Example: Same Age Field (18-65)

EP for Non-Numeric Inputs

Equivalence partitioning works for any input type:

Combining EP and BVA

EP reduces test count. BVA sharpens the selection within partitions. Use them together:

1. First, identify partitions with EP
2. Then, within each partition boundary, apply BVA

For the age field: EP gives you three partitions. BVA refines the boundary between partitions to specific values (17, 18, 65, 66).

Decision Tables

When business logic involves combinations of conditions, a decision table ensures full coverage. Each column represents a unique combination of conditions and its expected outcome.

Building a Decision Table

1. List all conditions (inputs/states)
2. List all actions (outputs/behaviors)
3. Calculate combinations: 2^n for n boolean conditions
4. Fill in the expected action for each combination
5. Look for rules that can be merged (if a condition does not affect the outcome)

Example: Shipping Rules

This table reveals that Rule 3 (non-premium customer with large order) gets free shipping — is that intentional? Decision tables surface business logic questions that might otherwise go unnoticed.

More Complex Example: Loan Approval

From this table, derive one test case per rule. This ensures complete combinatorial coverage of the business logic.

State Transition Diagrams

Model features that have distinct states and transitions between them. State transition testing ensures that the system correctly moves between states and blocks invalid transitions.

Drawing the Diagram

[Draft] --submit--> [Pending Review] --approve--> [Published]
                                      --reject---> [Draft]
[Published] --archive--> [Archived]
[Archived] --restore---> [Draft]

Deriving Test Cases

From the diagram above, derive test cases for:

Valid transitions (positive tests):

• Draft -> Pending Review (submit)
• Pending Review -> Published (approve)
• Pending Review -> Draft (reject)
• Published -> Archived (archive)
• Archived -> Draft (restore)

Invalid transitions (negative tests):

• Draft -> Published directly (should be blocked)
• Archived -> Published directly (should require going through Draft first)
• Published -> Draft (should require archiving first)
• Pending Review -> Archived (should be blocked)

Transition loops:

• Draft -> Pending -> Draft -> Pending -> Published (rejection loop works correctly)

State coverage:

• Every state is reached at least once
• Every transition is exercised at least once

State Transition Table Format

Pairwise Testing (Bonus Technique)

When you have many input parameters, testing all combinations is impractical. Pairwise testing (also called all-pairs) ensures that every pair of parameter values is tested at least once.

Example

Testing a web form with: Browser (Chrome, Firefox, Safari), OS (Windows, Mac, Linux), Language (EN, ES, FR).

Full combinatorial: 3 x 3 x 3 = 27 test cases. Pairwise: approximately 9 test cases cover every pair.

Tools like PICT (Microsoft), AllPairs, or online pairwise generators create the optimal test set.

Choosing the Right Technique

In practice, experienced QA engineers combine these techniques. For a single feature, you might use EP to identify the partitions, BVA to select specific values, and a decision table to handle the business rule combinations.

Practical Exercise

You are testing a discount system with these rules:

• Employees get 20% off
• Orders over $200 get 10% off
• Discounts do not stack (employee discount takes precedence)
• Discount codes can add an additional 5% (stacks with either discount)

1. Build a decision table covering all condition combinations
2. Identify any ambiguous rules the table reveals
3. Write test cases for each rule using Given/When/Then format
4. Apply BVA to the $200 threshold (test at $199.99, $200.00, $200.01)

Key Takeaways

• BVA catches off-by-one errors at range boundaries
• EP reduces test count by grouping equivalent inputs
• Decision tables ensure complete coverage of business logic combinations
• State transition diagrams verify valid paths and block invalid ones
• Combine techniques for thorough coverage with minimal test count