Learning Objectives
By the end of this lesson you will be able to:
- Apply Boundary Value Analysis (BVA) to date and time fields
- Define the equivalence partitions for a typical date restriction field
- Explain the "just inside / just outside" technique at date boundaries
- Design a complete table-driven test set for a date range field
- Identify which test cases are most likely to uncover date restriction bugs
BVA Recap: Why Boundaries Matter
Boundary Value Analysis is a test design technique based on the observation that bugs tend to cluster at the edges of valid input ranges rather than in the middle. A developer who writes if (date < today) is likely to get it right for dates deep in the past or future, but may use the wrong operator at exactly today. BVA exploits this tendency by targeting:
- The minimum valid value
- The value just below the minimum (invalid)
- The maximum valid value
- The value just above the maximum (invalid)
For date fields, "just below" and "just above" means one calendar day before and after the boundary.
Equivalence Partitions for a Date Field
Consider a field that accepts "past dates only" (e.g., a birth date). The input space partitions into:
| Partition | Description | Representative value |
|---|---|---|
| Far past | Many years ago | 1950-01-01 |
| Recent past | Days or weeks ago | Yesterday |
| Today | Exactly today | Today |
| Near future | Days or weeks ahead | Tomorrow |
| Far future | Many years ahead | 2099-12-31 |
For a "past dates only" field, today and everything after are invalid. The boundary is between "yesterday" and "today". BVA requires you to test both sides of this line.
The "Just Inside / Just Outside" Technique
For a field accepting dates from today up to +5 years:
| Position | Value | Expected result |
|---|---|---|
| Just outside minimum | yesterday | Reject |
| Minimum (just inside) | today | Accept |
| Nominal (middle) | today + 2 years | Accept |
| Maximum (just inside) | today + 5 years | Accept |
| Just outside maximum | today + 5 years + 1 day | Reject |
This 5-test set provides strong coverage of boundary behavior with minimal test count. In practice you would also add a far-outside case (e.g., 9999-12-31) to detect crashes.
Table-Driven Test Design
A well-structured date field test table might look like this:
| TC# | Input date | Relation to boundary | Expected | Rationale |
|---|---|---|---|---|
| TC01 | 2019-06-19 | Far past | Reject | Past dates blocked |
| TC02 | Yesterday | Just outside lower | Reject | One day before lower bound |
| TC03 | Today | Lower bound | Accept | Minimum valid date |
| TC04 | Today + 1 day | Just inside lower | Accept | Confirming acceptance above minimum |
| TC05 | Today + 2 years | Nominal | Accept | Typical valid date |
| TC06 | Today + 5 years | Upper bound | Accept | Maximum valid date |
| TC07 | Today + 5y + 1 day | Just outside upper | Reject | One day past upper bound |
| TC08 | 9999-12-31 | Far future | Reject | System robustness |
This table-driven format makes it easy to see coverage and spot gaps.
Which Test Cases Find the Most Bugs?
Research and practice consistently show that boundary tests (TC02, TC03, TC06, TC07 in the table above) find far more bugs than nominal tests. Common bugs at date boundaries:
- Using
<instead of<=(or vice versa) at the lower boundary - Computing the upper bound as "today + 5 years" using a naive calculation that fails in leap years
- Accepting the boundary in the UI but rejecting it on the server (or the reverse)
- Displaying a wrong error message for the just-outside cases
The single most valuable test case for a "no future dates" field is today — because it sits exactly on the boundary and reveals whether the developer included or excluded it correctly.
Summary
Boundary Value Analysis for date fields follows the same logic as for numeric fields, with one calendar day as the atomic unit of granularity. Define your partitions, identify the boundaries, apply the just-inside/just-outside technique, and record everything in a table. The five boundary test cases (below min, at min, nominal, at max, above max) consistently outperform equivalent-class midpoint tests in finding real defects.