Three-Value BVA, Robust BVA and Worst-Case Testing Strategies

📚 QA Engineering 📂 Chapter 11: BVA and Equivalence Partitioning — Advanced Applications and Real-World Scenarios 📄 Lesson 11030 Intermediate 🕒 March 17, 2026

Basic BVA tests at two points per boundary — the value at the edge and the value just past it. But more rigorous variations exist that increase defect detection at the cost of additional test cases. Three-value BVA adds one more point per boundary. Robust BVA extends testing to include values far outside the valid range. Worst-case testing combines boundary values from multiple variables simultaneously. Understanding when to apply each strategy lets you calibrate your testing depth to the risk level of the feature.

BVA Variations — From Basic to Worst-Case

Each BVA variation offers a different trade-off between the number of test cases and the probability of catching defects.

# BVA variations applied to a field: valid range 1-100

RANGE_MIN = 1
RANGE_MAX = 100

# ── Basic (Two-Value) BVA ──
# Test at: boundary and one step inside
basic_bva = [
    {"value": 0,   "label": "Below min",  "expected": "Invalid"},
    {"value": 1,   "label": "At min",     "expected": "Valid"},
    {"value": 100, "label": "At max",     "expected": "Valid"},
    {"value": 101, "label": "Above max",  "expected": "Invalid"},
]

# ── Three-Value BVA ──
# Test at: one below, at boundary, one above
three_value_bva = [
    {"value": 0,   "label": "Min - 1",    "expected": "Invalid"},
    {"value": 1,   "label": "At min",     "expected": "Valid"},
    {"value": 2,   "label": "Min + 1",    "expected": "Valid"},
    {"value": 99,  "label": "Max - 1",    "expected": "Valid"},
    {"value": 100, "label": "At max",     "expected": "Valid"},
    {"value": 101, "label": "Max + 1",    "expected": "Invalid"},
]

# ── Robust BVA ──
# Three-value BVA PLUS extreme values outside valid range
robust_bva = three_value_bva + [
    {"value": -999,     "label": "Extreme low",   "expected": "Invalid"},
    {"value": 0,        "label": "Zero",           "expected": "Invalid"},
    {"value": 999999,   "label": "Extreme high",   "expected": "Invalid"},
    {"value": -1,       "label": "Negative",       "expected": "Invalid"},
]

# ── Worst-Case BVA (two variables) ──
# Cross-product of boundary values for TWO fields
# Field A: 1-100, Field B: 1-50
field_a_boundaries = [0, 1, 2, 50, 99, 100, 101]
field_b_boundaries = [0, 1, 2, 25, 49, 50, 51]

worst_case_count = len(field_a_boundaries) * len(field_b_boundaries)

print("BVA Variations Compared — Field: Valid Range 1-100")
print("=" * 60)
print(f"\n  Basic (Two-Value) BVA:   {len(basic_bva):>3} test values")
print(f"  Three-Value BVA:         {len(three_value_bva):>3} test values")
print(f"  Robust BVA:              {len(robust_bva):>3} test values")
print(f"  Worst-Case (2 fields):   {worst_case_count:>3} test combinations")

print(f"\nThree-Value BVA Test Values:")
print(f"  {'Value':>6}  {'Label':<12} {'Expected'}")
print(f"  {'-'*40}")
for t in three_value_bva:
    print(f"  {t['value']:>6}  {t['label']:<12} {t['expected']}")

# When to use which strategy
print(f"\n\nSelection Guide:")
print(f"  Basic BVA:      Low-risk fields, limited testing time")
print(f"  Three-Value:    Standard choice for most fields")
print(f"  Robust BVA:     Security-sensitive or financial fields")
print(f"  Worst-Case:     Critical multi-field interactions (e.g. pricing engine)")

Note: Three-value BVA is generally considered the standard practice because it tests on both sides of every boundary. Basic (two-value) BVA can miss defects where the boundary itself is correct but the value immediately after it is handled incorrectly — for example, a rounding error that only appears at min+1 but not at min. The extra two test values per boundary (one on each side) are a small investment that significantly increases defect detection.

Tip: Use robust BVA for any field that affects money, security, or data integrity. Testing with extreme values like -999999 and 999999 catches integer overflow defects, unhandled negative values in financial calculations, and buffer overflows in older systems. These extreme-value defects are rare but catastrophic when they occur — a negative price causing a credit instead of a charge, or an extremely large input crashing the database.

Warning: Worst-case BVA generates a very large number of test cases because it creates the cross-product of boundary values across all fields. For 3 fields with 7 boundary values each, that is 7 × 7 × 7 = 343 combinations. Reserve worst-case testing for the most critical feature interactions — pricing engines, tax calculations, or dosage calculators — where every combination genuinely matters. For most features, three-value BVA on individual fields plus pairwise multi-variable EP is sufficient.

Common Mistakes

Mistake 1 — Always using basic BVA regardless of risk level

❌ Wrong: Applying basic two-value BVA to a financial calculation field where rounding errors at boundary+1 could cause incorrect charges.

✅ Correct: Using robust BVA for financial and security-critical fields (including extreme values) and three-value BVA as the standard for general fields.

Mistake 2 — Applying worst-case BVA to every multi-field form

❌ Wrong: Generating 343 worst-case boundary combinations for a low-risk address form.

✅ Correct: Using worst-case BVA selectively for critical multi-field calculations (pricing, tax, insurance premium) and pairwise EP for standard forms.

🧠 Test Yourself

A payment processing field accepts amounts from $0.01 to $10,000.00. Which BVA strategy is most appropriate?

Robust BVA — because financial fields require testing at boundaries, near boundaries, AND at extreme values to catch overflow errors, rounding defects, and unhandled edge cases. Test values should include $0.00 (below min), $0.01 (at min), $0.02 (above min), $9,999.99 (below max), $10,000.00 (at max), $10,000.01 (above max), plus extreme values like -$1.00, $0, $999,999.99, and $-999,999.99. Financial calculations are high-risk — a defect at any boundary could cause incorrect charges, credits, or system crashes. The additional test cases from robust BVA are a small cost compared to the potential impact of a financial defect in production.
Basic two-value BVA — boundary testing at $0.01 and $10,000.00 is sufficient.
No BVA needed — the payment gateway handles validation automatically.
Worst-case BVA across all payment form fields simultaneously.

BVA Variations — From Basic to Worst-Case #

Common Mistakes #

Mistake 1 — Always using basic BVA regardless of risk level #

Mistake 2 — Applying worst-case BVA to every multi-field form #

🧠 Test Yourself #

📚 More in this Tutorial Series

BVA Variations — From Basic to Worst-Case

Common Mistakes

Mistake 1 — Always using basic BVA regardless of risk level

Mistake 2 — Applying worst-case BVA to every multi-field form

🧠 Test Yourself