Module 01 · Testing basics · 15 min

Exercise: one criterion, end to end

The description-length rule of ClaimTriage, from its decided limits to its full list of cases, each at its level.

Review

From the previous lesson: the routing function returns queue-A for every critical claim. At which level is that proven, and why not through the screen?

Your answer

The rule

The product owner has decided it, and the decision is in the backlog:

Description length. Given an agent pastes a claim description, when they submit it, then ClaimTriage accepts it if it has from 20 to 2,000 characters, both included. Otherwise ClaimTriage rejects it with the error DESC_LENGTH, shows the agent the accepted range, and sends nothing to the model.

1. The boundaries

Five figures from the length rule

a. The shortest description that must be acceptedcharacters

b. The length just below it, which must be rejectedcharacters

c. The longest description that must be acceptedcharacters

d. The length just above it, which must be rejectedcharacters

e. The number of equivalence classes for the lengthclasses

2. The cases

List the test cases for this rule. For each: what is typed, the expected result, the technique it comes from, and its level. Then name one question the rule does not answer.

Your answer

The course's answer

Case	Technique	Expected result	Level
300 characters	Nominal, valid class	Accepted, the card is produced	Component
19 characters	Boundary, below	`DESC_LENGTH`, range shown, nothing sent	Component
20 characters	Boundary, on the limit	Accepted	Component
2,000 characters	Boundary, on the limit	Accepted	Component
2,001 characters	Boundary, above	`DESC_LENGTH`, nothing sent	Component
Empty description	Error, an extreme of the "too short" class	`DESC_LENGTH`, nothing sent	Component
19 characters through the screen	One system case	The agent sees the error and the accepted range	System
Nothing reaches the model on a rejection	Error path, the seam with the model	No call is made to the model	Integration

Questions the rule does not answer, each to confirm with the product owner: do spaces at the start and end count? Are line breaks characters? Is an emoji one character or two? What does the message say exactly? A case that types " Burst pipe in kitchen. " has two possible expected results until someone decides.

	Your list
A	All four boundary values, the empty description, most cases at component level, one or two higher up for what only exists there, and at least one open question with its owner	✅
B	The boundaries, but every case through the screen	⚠️ Right cases, wrong level: the rule is the unit's own logic
C	Only valid lengths, or only 0, 300 and 5,000	❌ No case on a limit: a `<` written instead of `<=` passes all of them
D	Expected results you added for the open questions, such as "spaces are not counted"	❌ Plausible and invented. They stay to confirm

Compare it with yours. Where do you stand?

3. Your own case

Your own case · Part 1, module 01

The test cases of one of your criteria

Pick one acceptance criterion from a product you work on, one with at least one limit in it. Rewrite it if it is not testable, and leave "to confirm" what nobody has decided, with who decides. Then list its cases: nominal path, equivalence classes, boundary values, errors. For each case, its expected result, where that result comes from, and the lowest level that can prove it.

Saved in this browser. It goes into your record.

That is the first module. You know what a test proves, where its expected result must come from, how to derive cases and at which level to run them. The next module is about running them: a campaign, its verdicts, its defects, and the moment someone asks where it stands.

Get in touch