Skip to content
wannacode

Boundary values

In short: A boundary is the last value of one partition and the first of the next. With two points you test the boundary and its neighbour from the other partition: 49.99 and 50.00 €. With three points, the neighbours on both sides too: 49.99, 50.00 and 50.01 €. That catches ">" instead of ">=", rounding and off-by-one bugs, which a representative from the middle of the partition never sees.

Problem

The tests passed, the boundary did not

From the previous lesson you have three delivery tests: 0 €, 30 € and 80 €. They all pass. The developer wrote:

delivery is free if the total is > 50

A cart of 50.00 € pays 4.90 €. The test with 80 € is from the same partition and passes, because 80 is both > 50 and >= 50. A representative from the middle of the partition cannot see where exactly the partition ends.

The idea

The boundary

The delivery partitions are ordered: empty, paid, free. Where one partition ends and the next begins is the boundary:

Partition From To
empty cart 0 € 0 €
paid delivery 0.01 € 49.99 €
free delivery 50.00 € no upper boundary

The boundary values are the smallest and largest value of each partition. Bugs are densest here, because this is where the developer decides ">" or ">=", rounds, counts from 0 or from 1. One wrong stroke in the code moves the boundary by one step. The step for amounts is one cent.

Boundary value analysis only works for ordered partitions: amounts, counts, dates. A payment method has no "before" and "after".

The idea

Two points and three points

There are two ways.

With two points: for every boundary you test the boundary value and its neighbour from the other partition. For delivery: 0 and 0.01 €; 49.99 and 50.00 €. Four tests.

With three points: for every boundary value you test it and both its neighbours. Around 50.00 €: 49.99, 50.00 and 50.01 €.

Why three? Imagine code saying "delivery is free if the total is exactly 50". With two points: 49.99 pays, 50.00 is free. It passes. With three points, 50.01 € has to be free, and the code charges 4.90 €. Caught.

Three points cost more tests and catch more bugs. Which one to choose depends on the risk: for payment they are worth it, for the colour of a button they are not.

More precisely, if you are curious

ISTQB CTFL v4.0.1 describes the technique in section 4.2.2 (boundary value analysis) with both variants: 2-value BVA and 3-value BVA. Coverage is the number of tested boundary values (with their neighbours for three points) over all of them. According to the syllabus three points are more rigorous: they catch bugs that two points miss.

The technique builds on equivalence partitions. Without partitions it is not clear where the boundaries are, and without boundaries partitions miss the most common bugs.

Try it

Which values?

1. The boundary between paid and free delivery is at 50.00 €. Which values does two-value analysis give?
2. Which values does three-value analysis give around 50.00 €?
3. The developer wrote "the total is exactly 50 → free" instead of "from 50 up". Which value catches the bug?
4. What are the boundaries of the "paid delivery" partition?

The idea

49.99 is not 30

49.99 € and 30 € are in one partition. So why is 49.99 the better test?

Because some bugs only show next to the boundary. If the code rounds the total to whole euros before comparing, 49.99 € becomes 50 € and delivery becomes free. 30 € rounded is still 30, and the test passes.

A good test sits where the bug would show itself. The middle of the partition is the safest place, and that is why it is the worst place for a test.

Try it

The boundaries of delivery

Write the tests for the boundaries of delivery, with two points. Catch all the bugs with as few rows as you can.

The rule: Delivery is free for an order from 50 € inclusive, otherwise it is 4.90 €. An empty cart cannot be ordered.

InputExpectedThe correct system
#Cart totalRefusedDelivery

An empty result cell is not checked. Amounts are written like 49.99.

The idea

Boundaries are everywhere

Wherever a rule has a number, it has a boundary:

  • Counts: at most 10 of a product. 10 is accepted, 11 is refused. And from below: you add at least 1 item, so 0 is refused.
  • Days: returns within 14 days of receipt. Received on 1 October: 15 October is accepted, 16 October is refused.
  • Time: the code is valid until 31 October. 23:59, and 00:00 on 1 November. And by whose clock?
  • Two boundaries at once: the limit is on the items in the cart, not on what is added. 9 in the cart plus 1 is 10 and is accepted. 10 plus 1 is 11 and is refused.

A boundary value often opens a question the requirement did not ask. "Within 14 days": inclusive? From receipt or from delivery? That is reviewing too: test design done early is the best checklist for requirements.

Exercise

The boundaries of the limit and of the days

1. The cart limit. There are two boundaries: on the quantity added and on the items in the cart after adding.

Write the tests for the two boundaries of the limit: how many are added (0 and 1) and how many end up in the cart (10 and 11). Check what stays in the cart too.

The rule: The cart can hold at most 10 of one product. Adding beyond 10 is refused with a message, and the cart stays the same. You add at least 1 item.

InputExpectedThe correct system
#In the cartAddingRefusedIn the cart after

An empty result cell is not checked. Amounts are written like 49.99.

2. Days and counts. Find the boundary values.

1. The rule: "Returns within 14 days of receipt." The parcel was received on 1 October. Which days does two-value analysis give?
2. The promo code is valid until 31 October inclusive. Which moment is the most important test?
3. The cart can hold at most 10 of a product. What are the boundary values of the items in the cart after adding?

Test

Check yourself

1. Why are bugs densest at the boundaries?
2. When do boundary values apply?
3. What does 49.99 € catch that 30 € does not?
4. How many boundary values does the delivery rule have with two-value analysis?

Made by Ivo Gergov as part of Evo Tech's campaign for accessible programming education ·