Module 01 · Testing basics · 12 min
A criterion someone can test
What makes an acceptance criterion testable, the Given / When / Then form, and what to do with a sentence that is not testable yet.
Review
From the previous lesson: the suite was green for three months. In one sentence, why could it not catch the routing bug?
The course's answer
Its expected queues were copied from what the service returned, so it compared the service with itself. Only expected results taken from a specification someone owns, here the routing table, can catch a defect.
Where the expected result comes from
In a product team, the expected result of a test comes from the acceptance criteria of a user story. If the criterion is vague, the tester has to invent the expected result, and you saw in the previous lesson what an invented expected result is worth.
So the first test happens before any test is written: can this criterion be tested as written?
Three things a testable criterion has
- A starting situation: who, with what data, in what state.
- An action: what happens.
- An outcome someone can observe: a value, a message, a code, a record, a time measured somewhere, and nothing that depends on taste.
Two people reading it must reach the same verdict on the same run. "Fast", "intuitive", "correct", "user-friendly" fail that test: two testers will disagree, and the developer will agree with whichever one passes.
The Given / When / Then form forces the three parts:
Scenario: Refuse a motor claim to an agent without the motor entitlement
Given a front-office agent whose role is not entitled to the motor product line
When they open motor claim 5003 in ClaimTriage
Then ClaimTriage returns the error ENTITLEMENT_DENIED
And no triage card is produced
You do not have to write every criterion in this form. You have to be able to.
What you cannot make testable on your own
Often a criterion is vague because nobody has decided the number or the rule yet. "The description must not be too long": too long is how many characters? That is not a tester's decision, and inventing a plausible number is the trap from the previous lesson in another form: a number nobody approved reads downstream exactly like an approved one.
The honest version keeps the decision open and names who takes it:
Given an agent pastes a description longer than ‹maximum length, to confirm with the product owner› characters, when they submit it, then ClaimTriage rejects it with the error
DESC_LENGTHand nothing is sent to the model.
That criterion is not finished, and it says so. It is still far more useful than "not too long": everyone can see what is missing and who must supply it.
1. Four criteria
Here are four acceptance criteria from ClaimTriage's backlog:
- AC1. The triage card is returned in under 3 seconds for 95% of requests, measured on the test environment.
- AC2. The summary on the card should be user-friendly.
- AC3. Given an agent without the motor entitlement, when they open a motor claim, then they get the error
ENTITLEMENT_DENIEDand no card. - AC4. The routing must be correct.
2. Rewrite one
This criterion is in the backlog: "The claim description must be short enough and the triage should be fast." Rewrite it so it can be tested. You know of no decision about lengths or times.
The course's answer
It holds two behaviours, so it becomes two criteria. And since nobody has decided the numbers, they stay to confirm, with their owner:
Length. Given an agent pastes a description shorter than ‹minimum length› or longer than ‹maximum length› characters, when they submit it, then ClaimTriage rejects it with a documented error and nothing is sent to the model. (Lengths to confirm with the product owner.)
Time. Given a valid description, when the agent submits it, then the triage card is returned within ‹time› seconds for ‹share› of requests, measured on ‹environment›. (Values to confirm with the product owner; the measuring environment with the test lead.)
| You wrote | ||
|---|---|---|
| A | Two criteria, each with an observable outcome, and the numbers left to confirm with who confirms them | ✅ |
| B | Two criteria with numbers you chose, such as 2,000 characters and 3 seconds | ⚠️ Testable, and invented. Ask before you write a number: the next lesson's rule starts from a decided one |
| C | One criterion that still says "fast" or "short enough" | ❌ Two testers would still disagree on the verdict |
The product owner has since decided the lengths: a description is accepted from 20 to 2,000 characters, both included. You will use that decision in the last lesson of this module.