Decision Tables vs Equivalence Partitioning vs Boundary Value Analysis

Every QA course teaches equivalence partitioning, boundary value analysis, and decision tables as if they're interchangeable. They're not. Each technique targets a different class of defect. Using the wrong one wastes time. Using only one leaves gaps. This post explains what each technique actually catches, when to use each, and how to combine them without duplicating work.

What Each Technique Is Actually Doing

Equivalence Partitioning (EP)

EP divides the input space into partitions where every value in a partition is expected to behave identically. You test one representative from each partition. The assumption is that if one value works, all values in that partition work.

What it catches: Logic that incorrectly handles an entire category of input — treating all negative numbers as invalid when only some should be, failing all strings over 255 characters instead of just those over the actual limit, rejecting all non-US addresses instead of just those missing required fields.

What it misses: Defects at the boundaries between partitions. A partition boundary is where the implementation is most likely to have an off-by-one error.

When to use it: Single-input validation. Input fields with obvious categories (valid/invalid, age ranges, country codes). Any time you need to reduce a large input space to a manageable number of test cases without worrying about combinations.

Boundary Value Analysis (BVA)

BVA focuses specifically on the edges of equivalence partitions. For a partition "order total between $50 and $100", BVA tests at $49.99, $50.00, $100.00, and $100.01.

What it catches: Off-by-one errors. Incorrect use of < vs <=. Floating-point rounding at thresholds. The implementation correctly handles the middle of a range but fails at its edges.

What it misses: Combinations of multiple inputs. BVA applied to a single input doesn't tell you what happens when two inputs are both at their boundaries simultaneously.

When to use it: Numeric inputs with range constraints. Date fields. Any field where the specification uses >, >=, <, <= comparisons. Almost always used alongside EP, never instead of it.

Decision Tables

Decision tables test combinations of conditions. They enumerate how multiple independent inputs interact to produce outputs.

What they catch: Missing cases in conditional logic. Incorrect precedence between conditions (AND vs OR confusion). Cases where the developer correctly handled each condition in isolation but failed for a specific combination. Silent failures when an unhandled combination reaches code that doesn't know what to do.

What they miss: Invalid values within a partition (EP's job) and off-by-one errors at partition boundaries (BVA's job). A decision table with condition "Order total >= $100" as Y/N doesn't test what happens at $99.99 vs $100.00.

When to use it: Any system with multiple independent conditions that combine to produce different outcomes. Business rules. Authorization logic. Pricing engines. Workflow routing.

Side-by-Side Comparison

When to Use Each Technique

Use this decision framework:

Use EP when: You have a single input with categorically different behaviors for different ranges or types of values, and you need to efficiently cover the space without testing every value.

Use BVA when: The specification uses comparison operators on numeric or ordered values, and you already know the partition boundaries from EP.

Use decision tables when: Multiple conditions independently affect the output, and the behavior depends on the combination — not just on each condition in isolation.

Use all three when: You have a complex feature with multiple numeric inputs that interact with each other. This is common and is not redundant — each technique catches different things.

Combining the Techniques: Decision Framework

Does the feature have multiple independent conditions 
that combine to produce different outputs?
    YES → Start with a decision table
    NO  → Go to next question

Does any input have categorically different valid behaviors
(e.g., free shipping vs paid shipping tiers)?
    YES → Apply EP to identify partitions; use one representative per partition
    NO  → Go to next question

Does any condition use numeric thresholds (>=, <=, >, <)?
    YES → Apply BVA at each threshold identified by EP/decision table
    NO  → Your technique selection is complete

The key insight: decision tables tell you which combinations to test. EP tells you which value to use to represent each partition within those combinations. BVA tells you which specific values to use at the boundaries.

Worked Example: SaaS Plan Upgrade Feature

A SaaS product with these rules for displaying an upgrade prompt:

• Users on the Free plan see an upgrade prompt after 5 project creations
• Users on the Starter plan see an upgrade prompt after 20 project creations
• Users on the Pro plan never see an upgrade prompt
• Trial users see an upgrade prompt immediately (on first login after trial expires)
• Users with SSO login never see upgrade prompts (handled by their organization)

Inputs:

• Plan type: Free / Starter / Pro / Trial (expired) / SSO
• Project count: 0 to N
• SSO login: Y / N

Step 1: Build the Decision Table

Seven rules. SSO being Y is a knockout — it overrides plan type and project count. Pro plan is a knockout for no prompt. Trial expired is a knockout for always prompt.

Step 2: Apply EP to Project Count

For the Free plan condition "project count < 5", the equivalent partition is {0, 1, 2, 3, 4}. Pick one representative: 3. For "project count >= 5", partition is {5, 6, 7, ...}. Representative: 10.

For the Starter plan: "< 20" partition representative: 10. ">= 20" representative: 25.

Step 3: Apply BVA to Project Count Thresholds

The Free plan threshold is 5. Test at: 4, 5 (the two critical boundary values). The Starter plan threshold is 20. Test at: 19, 20.

This adds 4 targeted test cases on top of the decision table test cases, specifically guarding against off-by-one errors in the implementation.

Step 4: Complete Test Suite

From the decision table (7 rules), pick concrete values:

From BVA:

Total: 11 test cases that cover combination logic, representative partitions, and boundary values. This is genuinely comprehensive coverage for this feature.

Notice what each layer catches:

• BVA-2 catches an implementation that uses > 5 instead of >= 5
• DT-7 catches an implementation that checks plan type before SSO status (wrong order)
• DT-6 catches an implementation that treats trial-expired the same as Free

No single technique would catch all three of these.

Common Mistakes When Combining Techniques

Mistake 1: Using EP values for BVA. EP says "pick one representative from each partition." BVA says "test at the boundary." These are different test cases with different purposes. Don't conflate them.

Mistake 2: Applying BVA to non-ordered conditions. BVA is for numeric thresholds and ordered sequences. Applying it to categorical conditions (plan type, country code) doesn't make sense — there's no "boundary" between Free and Starter.

Mistake 3: Building a decision table and then deriving redundant EP tests. If your decision table already covers the "Free plan with low project count" case, you don't need a separate EP test for the Free plan. The decision table subsumed it.

Mistake 4: Forgetting to apply BVA to decision table numeric conditions. This is the most common gap. Engineers build a complete decision table with "order > $100" as a condition and then never test at $99.99 and $100.00. Add BVA explicitly for every numeric condition in your decision table.

Practical Recommendation

For any feature with business rules:

1. Build the decision table first. This gives you your test case skeleton.
2. Identify all numeric thresholds in the conditions. Apply BVA at each one.
3. Check whether any condition has multiple valid categories within a partition. Apply EP to pick representatives.
4. Review the combined set for redundancy. Remove duplicates.

This takes longer than picking a single technique and running with it. It also catches 3x more defects. The time spent in test design is almost always paid back in bugs caught before code ships.