Boundary Value Analysis: Finding Bugs at the Edges

Boundary Value Analysis: Finding Bugs at the Edges is a critical discipline in modern software quality assurance. According to NIST, software bugs cost the US economy $59.5 billion annually, with about 80% preventable through better testing (NIST Software Testing Study). According to research by Capers Jones, finding and fixing a defect after deployment costs 10-100x more than finding it during design (Capers Jones Software Engineering Best Practices). This guide covers practical approaches that QA teams can apply immediately: from core concepts and tooling to real-world implementation patterns. Whether you are building skills in this area or improving an existing process, you will find actionable techniques backed by industry experience. The goal is not just theoretical understanding but a working framework you can adapt to your team’s context, technology stack, and quality objectives.

TL;DR

• Test early and often — the cost of fixing defects grows exponentially after deployment
• Risk-based testing ensures the highest-impact areas get the most testing attention
• Good bug reports with reproduction steps and expected/actual behavior accelerate fix times

Best for: QA engineers building or improving testing processes Skip if: Teams with fully automated, mature testing suites needing no process improvement

Why Boundaries Matter #

Consider this real-world bug from a banking application:

Transfer Amount Validation:

- Minimum: $1.00
- Maximum: $10,000.00

Bug: Transferring exactly $10,000.00 resulted in error:
"Amount exceeds maximum limit"

Root Cause: Developer used "amount < max" instead of "amount <= max"

This bug only appeared at the exact boundary value. Testing $5,000 or $9,999 would never have caught it. Only testing at and around the boundary ($9,999.99, $10,000.00, $10,000.01) would reveal the issue.

“Testing is a skill, not just a checklist. The most effective testers I’ve worked with combine deep domain knowledge with structured thinking — they can predict where software will break before writing a single test case.” — Yuri Kan, Senior QA Lead

The BVA Principle #

For any input range with boundaries, test these values:

This gives you 6 test cases instead of testing thousands of values randomly.

Basic BVA Example: Age Validation #

Requirement: Age field accepts values from 18 to 65 (inclusive)

Traditional Testing Approach (Inefficient) #

Test values: 25, 30, 35, 40, 45, 50, 55, 60
Result: All pass, but limited coverage

BVA Approach (Efficient) #

Test values:

- 17 (min - 1) → Expected: Rejected ❌
- 18 (min) → Expected: Accepted ✅
- 19 (min + 1) → Expected: Accepted ✅
- 64 (max - 1) → Expected: Accepted ✅
- 65 (max) → Expected: Accepted ✅
- 66 (max + 1) → Expected: Rejected ❌

Result: 6 focused tests with higher defect detection rate

BVA Test Case Template #

**Test Case ID**: TC-BVA-AGE-001
**Feature**: Age Validation
**Boundary**: 18-65 (inclusive)

| Test ID | Input Value | Position | Expected Result | Actual Result | Status |
|---------|------------|----------|----------------|--------------|--------|
| 1 | 17 | min - 1 | Error: "Age must be 18-65" | [To be filled] | |
| 2 | 18 | min | Accepted | [To be filled] | |
| 3 | 19 | min + 1 | Accepted | [To be filled] | |
| 4 | 64 | max - 1 | Accepted | [To be filled] | |
| 5 | 65 | max | Accepted | [To be filled] | |
| 6 | 66 | max + 1 | Error: "Age must be 18-65" | [To be filled] | |

Types of Boundaries to Test #

1. Numeric Ranges #

Example: Discount percentage (0% - 100%)

BVA Test Values:

- -1% → Invalid
- 0% → Valid (boundary)
- 1% → Valid
- 99% → Valid
- 100% → Valid (boundary)
- 101% → Invalid

Real Code Example:

def apply_discount(price, discount_percent):
    # Buggy version
    if discount_percent > 0 and discount_percent < 100:  # ❌ Bug: excludes 0 and 100
        return price * (1 - discount_percent / 100)
    else:
        raise ValueError("Invalid discount")

# BVA would catch this bug:
apply_discount(100, 0)    # ❌ Raises error (should work!)
apply_discount(100, 100)  # ❌ Raises error (should work!)

# Fixed version
def apply_discount(price, discount_percent):
    if 0 <= discount_percent <= 100:  # ✅ Correct: includes boundaries
        return price * (1 - discount_percent / 100)
    else:
        raise ValueError("Invalid discount")

2. String Length Boundaries #

Example: Username field (3-20 characters)

BVA Test Values:

- 2 chars: "ab" → Invalid
- 3 chars: "abc" → Valid (min boundary)
- 4 chars: "abcd" → Valid
- 19 chars: "abcdefghijklmnopqrs" → Valid
- 20 chars: "abcdefghijklmnopqrst" → Valid (max boundary)
- 21 chars: "abcdefghijklmnopqrstu" → Invalid

Automation Example:

describe('Username Validation - BVA', () => {
  test('should reject username with 2 characters (min - 1)', () => {
    expect(validateUsername('ab')).toBe(false);
  });

  test('should accept username with 3 characters (min)', () => {
    expect(validateUsername('abc')).toBe(true);
  });

  test('should accept username with 4 characters (min + 1)', () => {
    expect(validateUsername('abcd')).toBe(true);
  });

  test('should accept username with 19 characters (max - 1)', () => {
    expect(validateUsername('a'.repeat(19))).toBe(true);
  });

  test('should accept username with 20 characters (max)', () => {
    expect(validateUsername('a'.repeat(20))).toBe(true);
  });

  test('should reject username with 21 characters (max + 1)', () => {
    expect(validateUsername('a'.repeat(21))).toBe(false);
  });
});

3. Date/Time Boundaries #

Example: Booking system (reservations 1-365 days in advance)

Today: 2025-10-02

BVA Test Values:

- Today (day 0) → Invalid (must be at least 1 day in advance)
- Tomorrow (day 1) → Valid (min boundary)
- 2 days ahead (day 2) → Valid
- 364 days ahead → Valid
- 365 days ahead → Valid (max boundary)
- 366 days ahead → Invalid

4. Array/Collection Boundaries #

Example: Shopping cart (1-99 items)

BVA Test Values:

- 0 items → Invalid (empty cart)
- 1 item → Valid (min boundary)
- 2 items → Valid
- 98 items → Valid
- 99 items → Valid (max boundary)
- 100 items → Invalid (exceeds limit)

5. File Size Boundaries #

Example: Profile picture upload (Max 5 MB)

BVA Test Values:

- 0 KB → Invalid (empty file)
- 1 KB → Valid (min realistic boundary)
- 4.99 MB (5,242,879 bytes) → Valid
- 5 MB (5,242,880 bytes) → Valid (max boundary)
- 5.01 MB (5,252,415 bytes) → Invalid

Two-Point vs Three-Point BVA #

Two-Point BVA (Minimal) #

Tests only the boundary values:

For range 18-65:

- 18 (min)
- 65 (max)

Pros: Fastest approach Cons: May miss off-by-one errors

Three-Point BVA (Standard) #

Tests boundary ± 1:

For range 18-65:

- 17 (min - 1)
- 18 (min)
- 19 (min + 1)
- 64 (max - 1)
- 65 (max)
- 66 (max + 1)

Pros: Best balance of coverage and efficiency Cons: More test cases than two-point

Robust BVA (Comprehensive) #

Adds invalid boundaries beyond ±1:

For range 18-65:

- 0 (absolute invalid min)
- 17 (min - 1)
- 18 (min)
- 19 (min + 1)
- 64 (max - 1)
- 65 (max)
- 66 (max + 1)
- 999 (absolute invalid max)
- null
- negative values
- special characters (if numeric field)

Pros: Maximum defect detection Cons: More time-consuming

BVA for Multiple Input Fields #

When testing forms with multiple fields, apply BVA to each field independently.

Example: Loan Application Form

Test Strategy:

1. Individual Field Testing: Test each field’s boundaries while other fields have valid mid-range values
2. Combined Boundary Testing: Test combinations of boundary values (advanced)

Test Case Example:

TC-LOAN-001: Test minimum age boundary
- Age: 18 (boundary)
- Income: $100,000 (mid-range)
- Loan Amount: $10,000 (mid-range)
Expected: Approved

TC-LOAN-002: Test maximum loan amount boundary
- Age: 35 (mid-range)
- Income: $100,000 (mid-range)
- Loan Amount: $50,000 (boundary)
Expected: Approved (if income qualifies)

Real-World BVA Examples #

Example 1: E-commerce Discount Code #

Requirement: Discount code valid for orders $50-$500

def apply_discount_code(order_total, code):
    if order_total >= 50 and order_total <= 500:
        return order_total * 0.9  # 10% off
    else:
        raise ValueError("Order total must be $50-$500 to use this code")

# BVA Test Cases:
assert raises_error(apply_discount_code(49.99, "SAVE10"))    # Just below min
assert apply_discount_code(50.00, "SAVE10") == 45.00        # Exactly min
assert apply_discount_code(50.01, "SAVE10") == 45.01        # Just above min
assert apply_discount_code(499.99, "SAVE10") == 449.99      # Just below max
assert apply_discount_code(500.00, "SAVE10") == 450.00      # Exactly max
assert raises_error(apply_discount_code(500.01, "SAVE10"))   # Just above max

Example 2: Password Strength Meter #

Requirement: Password must be 8-32 characters

BVA Test Cases:

| Password Length | Input | Expected Strength | Should Accept |
|----------------|-------|------------------|---------------|
| 7 chars | "Pass123" | - | ❌ Rejected |
| 8 chars | "Pass1234" | Weak | ✅ Accepted |
| 9 chars | "Pass12345" | Weak | ✅ Accepted |
| 31 chars | "P" + "a"*30 | Strong | ✅ Accepted |
| 32 chars | "P" + "a"*31 | Strong | ✅ Accepted |
| 33 chars | "P" + "a"*32 | - | ❌ Rejected |

Example 3: Pagination #

Requirement: Display 10 items per page, max 100 pages

BVA Test Scenarios:

Page Navigation:

- Page 0 → Invalid (redirect to page 1)
- Page 1 → Valid (first page)
- Page 2 → Valid
- Page 99 → Valid
- Page 100 → Valid (last page)
- Page 101 → Invalid (show error or redirect)

Items Per Page:

- If total items = 1000:
  - Page 1: Items 1-10
  - Page 100: Items 991-1000
  - Page 101: Should not exist

Common BVA Mistakes #

❌ Mistake 1: Testing Only Valid Boundaries #

Bad approach:

- Test age = 18 ✅
- Test age = 65 ✅
- Miss testing: 17 ❌, 66 ❌

Fix: Always test invalid boundaries (min-1, max+1)

❌ Mistake 2: Forgetting Data Types #

For numeric field 1-100:

- Don't forget to test: null, "", "abc", -1, 0.5, 100.5

❌ Mistake 3: Ignoring Implicit Boundaries #

Example: Year field (no explicit max stated)
- Implicit boundaries: 1900-2100 (realistic range)
- Test: 1899, 1900, 2100, 2101
- Also test: 0, -1, 9999

❌ Mistake 4: Not Testing Boundary Combinations #

For a date range picker (start date - end date):

- Test when start_date = end_date (boundary case)
- Test when end_date = start_date + 1 day
- Test when start_date > end_date (invalid)

BVA + Equivalence Partitioning: Powerful Combo #

BVA works best when combined with Equivalence Partitioning.

Example: Age groups for ticket pricing

Age Ranges:

- Child (0-12): $5
- Teen (13-17): $8
- Adult (18-64): $12
- Senior (65+): $8

Equivalence Partitions + BVA:

Child partition:

- BVA: 0 (min), 1, 11, 12 (max), 13 (invalid)

Teen partition:

- BVA: 12 (invalid), 13 (min), 14, 16, 17 (max), 18 (invalid)

Adult partition:

- BVA: 17 (invalid), 18 (min), 19, 63, 64 (max), 65 (invalid)

Senior partition:

- BVA: 64 (invalid), 65 (min), 66, 100, 120 (max realistic)

BVA in Automation #

Boundary Value Analysis is ideal for automation:

import pytest

@pytest.mark.parametrize("age,expected", [
    # Below minimum boundary
    (17, "Invalid age"),
    # Minimum boundary
    (18, "Valid"),
    # Just above minimum
    (19, "Valid"),
    # Just below maximum
    (64, "Valid"),
    # Maximum boundary
    (65, "Valid"),
    # Above maximum boundary
    (66, "Invalid age"),
])
def test_age_validation_bva(age, expected):
    result = validate_age(age)
    assert result == expected

When to Use BVA #

✅ Use BVA When: #

• Input has defined ranges (min/max)
• Testing numeric values
• Testing string lengths
• Testing dates/times
• Testing quantities (items in cart, file sizes, etc.)
• Limited testing time (high ROI technique)

❌ Don’t Use BVA When: #

• Input has no boundaries (free text description)
• Testing binary choices (checkbox: checked/unchecked)
• Testing unordered sets (list of countries)
• Input is purely qualitative (color preferences)

Conclusion #

Boundary Value Analysis is one of the most effective test design techniques because:

1. High Defect Detection: Bugs cluster at boundaries
2. Efficient: Test 6 values instead of hundreds
3. Systematic: No guesswork, clear test values
4. Automatable: Perfect for regression suites
5. Risk-Based: Focuses on high-risk areas

Remember the golden rule: If it has a boundary, test it at the edges, not just the middle.

Quick Reference: BVA Checklist #

For any input with boundaries:

□ Identify min and max values
□ Test min - 1 (should be invalid)
□ Test min (should be valid)
□ Test min + 1 (should be valid)
□ Test max - 1 (should be valid)
□ Test max (should be valid)
□ Test max + 1 (should be invalid)
□ Consider data type boundaries (null, empty, negative, decimals)
□ Document expected results clearly
□ Automate BVA tests for regression

Further Reading #

• ISTQB Syllabus: Black-Box Test Techniques
• “Software Testing Techniques” by Boris Beizer
• IEEE 829: Standard for Software Test Documentation
• Companion article: “Equivalence Partitioning: Dividing Data into Classes”

Official Resources #

• REST API Tutorial
• HTTP Specification
• ISTQB Syllabus

FAQ #

What is the difference between verification and validation? Verification checks that you built the product correctly (meets specifications). Validation checks that you built the correct product (meets user needs). Both are essential parts of QA.

When should you stop testing? Stop testing when: risk has been reduced to acceptable levels, time/budget constraints require it, or defined exit criteria (e.g., 95% test coverage, zero critical defects) are met.

What makes a good bug report? A good bug report includes: precise reproduction steps, actual vs expected behavior, environment details (OS, browser, version), severity classification, and if possible, a minimal reproduction case.

How do you prioritize testing when time is limited? Use risk-based testing: identify the highest-risk areas (new code, complex logic, customer-facing features) and test those first, documenting what was skipped and the associated risk.

See Also #

• Test Case Design Techniques - Master all systematic test design approaches
• Black Box Testing - Complete guide to specification-based testing methods
• Exploratory Testing Guide - Combine BVA with exploratory techniques
• API Testing Mastery - Apply boundary analysis to API request parameters
• Bug Reports Developers Love - Document boundary-related defects effectively