What is the difference between two-value and three-value boundary value analysis?
answer
- Count the values within one step
- On the limit, and just outside
- The third value sits just inside
- Half again as many cases per limit
- Ask whether the limit is included
basics
~20 sTwo-value analysis takes the limit itself and the nearest value outside it. Three-value adds the nearest value inside, giving a below/on/above triple per limit — about fifty percent more cases, and it catches a limit that has shifted.
solid answer
~50 sTwo-value boundary analysis probes each stated limit with two cases: the value on the limit and the value one step outside it. That pair proves the constant is right and the comparison points the right way, which is enough for most well-understood rules. Three-value analysis adds the value one step inside the limit, so each boundary is covered by a below/on/above triple. The extra case earns its place when the limit itself may have shifted — if an implementation accepts one value too few or one too many, the two-value pair can still come out green while the just-inside value fails. The cost is roughly half again as many cases per limit, which matters once a rule set has dozens of limits. A common compromise is three-value on limits whose consequence is expensive and two-value everywhere else.
code
pseudocode · 10 linesSPEC: standard week is up to and including 40.00 hours
overtime applies above 40.00 hours
hours are recorded in steps of 0.25
two_value = [40.00, 40.25]
three_value = [39.75, 40.00, 40.25]
expect standard(39.75)
expect standard(40.00)
expect overtime(40.25)go deeper
Know that a limit can be probed with two values or with three, and that the third one sits just inside the accepted side. Be able to list both sets for a simple stated range without hesitating.
Explain what the extra case is hunting — an edge that has shifted inward, or a lookup with a hole near the limit — and show that you check whether a limit is inclusive and what one step of the recorded precision actually is.
Demonstrate a policy rather than a habit: three-value where a wrong edge is expensive or the rule is freshly changed, two-value elsewhere, and evidence from escaped defects moving rules between the tiers.
Own the arithmetic that three-value is one and a half times the cases per limit forever, and be ready to defend where that spend is worth it across a rule set that keeps growing.
## The two forms Every stated limit divides values into accepted and rejected, and there are three values within one step of it: the one immediately below, the one on it, and the one immediately above. Which of those you take defines the two forms of the technique. **Two-value analysis** takes the value on the limit and the value immediately outside it. For a limit written as *accepted up to and including 40*, that is 40 and 41. Two cases per limit, so a range with a lower and an upper limit costs four cases. **Three-value analysis** takes all three: 39, 40 and 41. Three cases per limit, six for a range. The literature sometimes calls this the robust or full form; the important thing is the shape rather than the label. ## What the third case buys Think about the ways an implementation of *accepted up to and including 40* can be wrong. It can use the wrong direction — refusing 40 when it should accept it. The two-value pair catches that immediately, because the on-limit case fails. It can use the wrong constant in the *outward* direction — accepting up to 41. Again the two-value pair catches it, because the just-outside case is accepted when it should have been refused. It can use the wrong constant in the *inward* direction — accepting only up to 39, with 40 and 41 both refused. Here the two-value pair still catches it, since the on-limit case fails. So far three-value has added nothing, and that is the honest starting position: on a single clean limit, the third value is often redundant. Where it starts to pay is when the boundary is not a single comparison but a seam between two rules that both claim values near it, or when the accepted set has a hole just inside the edge — a rounding step, a lookup keyed on the value, a table whose last row was never populated. Those defects sit inside the range rather than across the limit, and only the just-inside case stands on them. ## An example from a payroll engine A payroll engine computes a weekly overtime supplement. The specification says the standard week is up to and including 40 hours and that overtime applies above 40 hours, with hours recorded in quarter-hour steps. The two-value set is 40.00 and 40.25 — the last standard value and the first overtime value. The three-value set adds 39.75. Now suppose the engine looks up an hourly multiplier from a table of quarter-hour rows, and the row for 39.75 was never populated because someone generated the table from a whole-hours list. The 40.00 case passes, the 40.25 case passes, and every case in the middle of the range passes because whole-hour entries are all present. Only the just-inside quarter-hour value exposes the gap. That is the class of defect the third case exists for. ## Open and closed limits Before you can pick either set, you have to know which side of the limit the limit itself falls on. A rule written *at least 40 hours* includes 40; a rule written *over 40 hours* excludes it. These are the closed and open forms of a limit, and they are the single most common place where a boundary set is built correctly against the wrong edge. The precision of the data decides what *the next value* even means. With an open limit at 40 hours and quarter-hour recording, the largest non-overtime entry is 40.00 and the first overtime entry is 40.25 — not 41. If the same rule were recorded to the minute, the first overtime entry would be 40 hours and one minute. Where a rule is written against a continuous quantity but stored at a fixed precision, name the precision in the test, because a case written against the wrong step size silently tests nothing at all. Ambiguous wording deserves a question rather than a guess. Phrases like *between 1 and 60*, *up to 500*, and *no more than a fortnight* do not say whether the end value is in or out. Resolving that with whoever owns the rule is part of doing the technique, and the answer belongs in the specification, not only in the test. ## Choosing between the forms The cost model is simple: three-value is one and a half times the cases of two-value, per limit, forever. On a rule set with a handful of limits that is free. On one with several hundred it is a real slice of the suite budget and of the maintenance load when the rules move. A defensible policy is to run three-value where the consequence of a wrong edge is expensive or the rule is new, tangled or freshly changed, and two-value everywhere else — then let escaped defects move individual rules between the two tiers. What is not defensible is picking one form because it is the one you were taught, without being able to say what the extra case is looking for.
- A rule says a supplement applies over 40 hours and hours are recorded in quarter-hour steps. Which two values form the two-value set?40.00 and 40.25. The word over makes the limit open, so 40.00 is the largest entry that does not attract the supplement and 40.25 is the smallest that does. Picking 40 and 41 would be a case built against the wrong step size: it would still pass on an implementation that wrongly charged the supplement at 40.25, so it proves nothing about where the edge is.
- When is the just-inside value clearly worth its cost?When the value near the edge is looked up or transformed rather than merely compared — a rate table, a rounding step, a banding lookup — because those defects sit inside the accepted range rather than across the limit. It is also worth it on a rule that has just changed, where the edge may have moved by one step and the two-value pair can agree with the shifted edge.
- What do you do when the specification says between 1 and 60 without saying whether the ends are included?Treat it as an open question and get it resolved by whoever owns the rule, then record the answer in the specification rather than only in the test. Guessing produces a suite that enforces one reading while the implementation follows another, and the disagreement surfaces later as a defect report that neither side can settle from the written rule.
saying these in an interview costs you the question
- Cannot say what the third value is looking for
- Treats the value outside a limit as one whole unit away
- Ignores whether the limit itself is included or excluded
- Applies three-value everywhere without weighing the case count
- Guesses at ambiguous wording instead of getting the rule settled