Building an Examples Table

Learning Objectives

By the end of this lesson you will be able to:

Distinguish a well-designed Examples table from a handful of arbitrary rows
Choose rows that cover happy path, invalid boundary, and type-mismatch cases
Explain how a well-built Examples table functions as a reviewable test-design matrix

An Examples Table Is Not "A Few Random Numbers"

Knowing the Scenario Outline syntax doesn't automatically make you good at filling in the Examples: table underneath it. It's tempting to throw in three or four values that "feel representative" and call it done. That's how you end up with a table that looks thorough but quietly skips the exact edge case that later breaks in production.

Good row design starts with the same discipline as any boundary-value analysis: identify the boundary, then pick values on both sides of it, plus one value that breaks the expected type entirely.

A Worked Example: Age Validation

Suppose the rule is: an applicant must be 18 or older to register, ages are whole numbers, and anything unparseable should be rejected as an error rather than silently accepted or silently rejected.

Scenario Outline: Age validation on registration
  Given an applicant with age <age>
  When the applicant submits the registration form
  Then the result is <expected>

  Examples:
    | age  | expected |
    | 18   | accepted |
    | -5   | rejected |
    | 17.9 | error    |
    | abc  | error    |

Each row earns its place for a specific reason:

18 — the happy path, exactly at the accept boundary. Proves the "at least 18" rule works at its edge, not just comfortably above it.
-5 — a negative number. Proves the system rejects clearly invalid input rather than, say, treating a negative age as "under 18" and accepting it by accident.
17.9 — a decimal just under the boundary. This is the row most naive test designs skip. It checks that the system treats a fractional age as a distinct case (an error, per this rule) rather than truncating it to 17 or 18 and getting the "right" answer for the wrong reason.
abc — a complete type mismatch. Confirms the system has explicit handling for non-numeric input instead of crashing or silently defaulting.

Four rows, four distinct reasons to exist. None of them is "just another example" — each one is there to catch a specific way the implementation could go wrong.

The Table IS the Test-Design Matrix

This is the payoff of doing the row design carefully: the finished Examples: table isn't just test data anymore, it's the complete specification of every case that matters, laid out as a matrix a business analyst can read without touching a line of code. A BA reviewing this table doesn't need to trust that "edge cases are covered somewhere" — they can see every boundary explicitly, and add a row for a case they think of that a tester missed, without needing to write a new scenario from scratch.

Pro Tip: When you're building a table and you can't articulate in one sentence why a row exists, that's a sign either the row is redundant or you haven't found the real boundary yet.

Key Takeaways