Boundary Value Analysis for Better Edge Coverage

What Boundary Value Analysis (BVA) Is

Boundary Value Analysis (BVA) is a test design technique that focuses on values at the edges of allowed input ranges. Instead of testing many “typical” values, you deliberately test the minimum and maximum limits and the values immediately around them.

BVA is especially useful when requirements define constraints such as “between X and Y”, “at most N characters”, “must be at least 1”, or “date must be within the next 30 days”.

Why defects often appear at limits

• Off-by-one errors: developers may code < instead of <=, or start counting from 0 instead of 1.
• Validation gaps: UI validation may differ from API validation, or validation may be missing for pasted values.
• Data type and formatting issues: rounding, integer overflow, leading zeros, locale date formats, and trimming whitespace can behave differently at extremes.
• Boundary conversions: bytes vs KB/MB, inclusive vs exclusive date ranges, timezone boundaries (midnight), and character counting (graphemes vs bytes) can cause unexpected failures.

How to Select Boundaries from Requirements

Start by scanning requirements and acceptance criteria for constraint language. Then translate each constraint into a set of boundary test values.

Step-by-step: Extract boundaries

• Step 1: Identify the constrained field (e.g., password length, quantity, upload size, delivery date).
• Step 2: Find the rule type: min/max length, numeric range, date window, file size limit, allowed set, etc.
• Step 3: Determine inclusivity: is the boundary included (e.g., “1–99”) or excluded (e.g., “must be less than 100”)? If unclear, treat it as a risk and test both interpretations or clarify.
• Step 4: Choose boundary values: for each boundary, test just-below, at, and just-above.
• Step 5: Decide expected results: what error message, what UI state, what API response, what stored value.

Common boundary sources (with examples)

• Min/max length: “8–20 characters” for password, “max 140 characters” for a bio.
• Numeric ranges: “quantity 1–99”, “discount 0–50%”.
• Dates: “start date cannot be in the past”, “booking date within 30 days”.
• File sizes: “upload up to 10 MB”, “attachment max 25 MB”.

Writing Boundary Tests: Just-Below, At, Just-Above

For a single boundary, the classic BVA set is:

• Just-below: one step below the boundary (often invalid)
• At: exactly the boundary value (often valid if inclusive)
• Just-above: one step above the boundary (often invalid)

For a range with both minimum and maximum, apply this around both ends. You typically end up with 6 key values: min-1, min, min+1, max-1, max, max+1. You can reduce or expand depending on risk and step size (e.g., dates use days; file sizes use bytes).

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Worked Example 1: Password Length 8–20 Characters

Requirement: Password length must be between 8 and 20 characters (inclusive). Assume only length is being validated in this example.

Identify boundaries

• Minimum length: 8
• Maximum length: 20

Choose boundary values

Use min-1, min, min+1, max-1, max, max+1.

| Case | Length | Example input (illustrative)      | Expected result                          | Notes                     |
|------|--------|----------------------------------|-------------------------------------------|---------------------------|
| 1    | 7      | Abc123!                           | Rejected: “Password must be 8–20 chars”   | just-below min            |
| 2    | 8      | Abc123!@                          | Accepted                                  | at min                    |
| 3    | 9      | Abc123!@#                         | Accepted                                  | just-above min            |
| 4    | 19     | Abc123!@#Abc123!@#Abc             | Accepted                                  | just-below max            |
| 5    | 20     | Abc123!@#Abc123!@#Abc1            | Accepted                                  | at max                    |
| 6    | 21     | Abc123!@#Abc123!@#Abc12           | Rejected: “Password must be 8–20 chars”   | just-above max            |

Practical notes for length boundaries

• Count what the system counts: some systems count bytes, others count characters; some treat emojis as multiple bytes.
• Include whitespace behavior if relevant: leading/trailing spaces might be trimmed, changing effective length.
• UI vs API: confirm the same boundary is enforced in both layers if both exist.

Worked Example 2: Quantity Range 1–99

Requirement: Quantity must be an integer from 1 to 99 (inclusive).

Identify boundaries

• Minimum: 1
• Maximum: 99

Choose boundary values

| Case | Quantity | Expected result                         | Notes                     |
|------|----------|------------------------------------------|---------------------------|
| 1    | 0        | Rejected: “Quantity must be 1–99”        | just-below min            |
| 2    | 1        | Accepted                                 | at min                    |
| 3    | 2        | Accepted                                 | just-above min            |
| 4    | 98       | Accepted                                 | just-below max            |
| 5    | 99       | Accepted                                 | at max                    |
| 6    | 100      | Rejected: “Quantity must be 1–99”        | just-above max            |

Optional boundary-related follow-ups (when requirements mention them)

• Type boundary: if the field is numeric, try 1.0, 1.5, or "1" only if the requirement discusses integer-only behavior or input parsing.
• Empty vs zero: "" (empty) is not the same as 0; treat as separate if validation rules mention required fields.

Other Boundary Types You’ll Meet Often

Dates

Requirement example: Delivery date must be between today and 30 days from today (inclusive).

Define “today” precisely (system timezone) and pick boundaries:

| Boundary point | Value to test            | Expected result (typical) |
|----------------|--------------------------|----------------------------|
| just-below min | yesterday                | Rejected                   |
| at min         | today                    | Accepted                   |
| just-above min | tomorrow                 | Accepted                   |
| just-below max | today + 29 days          | Accepted                   |
| at max         | today + 30 days          | Accepted                   |
| just-above max | today + 31 days          | Rejected                   |

If the requirement uses business days, cut-off times, or time-of-day constraints, boundaries may include 23:59 vs 00:00 and timezone conversions.

File sizes

Requirement example: Upload size must be at most 10 MB.

Clarify whether “10 MB” means 10,000,000 bytes or 10,485,760 bytes (10 MiB). If not clarified, treat as risk and test around both if feasible.

| Case | File size (bytes)         | Expected result                 |
|------|----------------------------|----------------------------------|
| 1    | limit - 1                  | Accepted                         |
| 2    | limit                      | Accepted                         |
| 3    | limit + 1                  | Rejected: “Max file size 10 MB”  |

Also consider compression, metadata, and server-side limits (reverse proxies) if uploads fail before application validation.

How to Record Boundary-Focused Test Data in a Test Case

When documenting boundary tests, make the boundary intent visible so reviewers can see coverage quickly. Record both the boundary rule and the exact test data.

Recommended way to capture boundary data

• Reference the rule: “Password length 8–20 inclusive”.
• Label the boundary position: “min-1”, “min”, “min+1”, “max-1”, “max”, “max+1”.
• Store exact values: the literal string, number, date, or file size used.
• Expected validation outcome: accepted/rejected plus the specific message or error code if defined.

Example: boundary test data recorded as a compact table

| Test ID | Field     | Rule            | Boundary position | Test data                         | Expected result |
|---------|-----------|-----------------|-------------------|-----------------------------------|----------------|
| BVA-01  | Password  | length 8–20     | min-1             | "Abc123!" (7 chars)               | Reject         |
| BVA-02  | Password  | length 8–20     | min               | "Abc123!@" (8 chars)              | Accept         |
| BVA-03  | Password  | length 8–20     | max               | "Abc123!@#Abc123!@#Abc1" (20)     | Accept         |
| BVA-04  | Password  | length 8–20     | max+1             | "Abc123!@#Abc123!@#Abc12" (21)    | Reject         |

This format makes it easy to expand coverage later (e.g., add whitespace-trim boundaries) without rewriting the whole test.

Exercise: Find Boundaries and Draft Test Cases

Use the acceptance criteria below. For each criterion, identify the boundaries and draft boundary test cases using just-below, at, and just-above values.

Acceptance criteria

• Username: must be 3–15 characters.
• Age: must be between 18 and 120 (inclusive).
• Event date: must be scheduled from tomorrow up to 90 days from today.
• Profile photo: JPG or PNG, maximum size 5 MB.

Your tasks

• List the min and max boundaries for each field (and any format/type boundaries you see, such as allowed file types).
• Create a boundary value table for each field with min-1, min, min+1, max-1, max, max+1 (or the date/file-size equivalents).
• Draft test cases that record: rule, boundary position, exact test data, and expected result (including the expected error message if specified).

Template to fill in

| Test ID | Field | Rule | Boundary position | Test data | Expected result |