Designing the test set before designing the system

A feature is not specified until its failure can be described. Writing the acceptance rows before the system rows forces that description into daylight while it still costs nothing to change — which is the only period when it is cheap.

Three classes of case, and the one that gets skipped

Normal. The task performed as intended, on real data. A class list import that ends with the right number of students and totals that agree with a hand sum.

Reverse. The input that must be refused, flagged, or handed to a person. A record with no identifier. A score sheet headed with a subject that is not in the timetable. A lookup for a record the operator has no permission to see. The correct behaviour is often to stop and ask, and that has to be written down as a pass, not treated as a defect.

Boundary. Empty, zero, missing, duplicated, leading zero, full marks and an absent exam in the same column. Boundaries are where the customer's own data is messiest and where the demo never goes.

Reverse cases get skipped because they force the builder to define "wrong", which is the same definition the customer will use at acceptance. Deferring it moves the definition to the acceptance meeting, where it is settled by whoever is more tired. That is not a negotiation; it is a coin toss with a signature.

The acceptance table: one state per row

The table has three columns — check item, expected result, actual result with evidence — and every row ends in exactly one of four states: pass, fail, unverified, not applicable. The fourth state is the one that saves projects. An interface the original product never implemented is recorded as "not applicable, not implemented in the original", never as pass. A table that treats absence as success is not a weaker acceptance; it is a false one.

A real delivery of a classroom tool used eighteen rows. They included the entry point and browser; a backup taken before import with source and timestamp; the original export left untouched; the class, term and exam set with no sample records mixed in; the count arithmetic of original plus added equals final; identifier uniqueness with same-name students separated; a field sample of at least five records including leading zeros; defaults verified; scores matched by identifier and name; full marks, zero, absent and blank distinguished; a correction affecting only the named exam, student and subject; save, wait, refresh, re-export; a restore performed in an isolated environment and checked against three records; API pagination and permission scope; API idempotency and conflict handling; API failure behaviour under offline, timeout, expiry and rate limiting; historical attendance mapping; and a final backup.

Eighteen rows is not bureaucracy. Each row is a claim someone can falsify in five minutes. A row that needs an hour of setup belongs in an automated script, not in a signed table.

The customer's set is the only acceptance

Two sets exist. The self-test set is handed over so the customer can check for gaps; it is a courtesy, and it also transfers knowledge. The independent set stays with the customer and is not shown before acceptance. That is the real test, for a reason that has nothing to do with distrust: the builder's set encodes the builder's model of the workflow, and the customer's workarounds are precisely what that model leaves out.

A useful design ratio: about 85 percent of items should have a determinate answer, so that a score means something, and the remaining items should record judgement disagreements rather than being scored. The number is a design target, not a legal threshold; its purpose is to keep the score interpretable.

One more sentence belongs in every acceptance report, and it is the sentence teams omit: passing this test does not guarantee next week. Model updates, changed source documents, and a new upstream interface can all move the result. An acceptance report that implies permanence creates a maintenance dispute later.

Two columns that make the record honest

Every delivery should end with a page split in two. The first column lists what was actually verified. The second lists what was not, with no guarantee attached.

In the reference delivery, the verified column named a fixed source commit with thirteen files checked and the licence retained, one browser on one operating system, two fictional students imported and still present after a refresh, an export and a restore, and a local proxy answering on 127.0.0.1:8787 without real vendor credentials. The unverified column named six domestic agent clients' installation and billing, macOS, Linux, mobile, real vendor keys and streaming, every seating rule, and the absence of a full regression because the upstream project had no test suite.

The most useful section sat between them, listing behaviour found and deliberately preserved: a save delay of about 250 milliseconds meant that a very fast refresh after an import lost two students; the backup file could contain an API key; name masking was not anonymisation. Each of these is actionable when written as a known limit, and becomes a defect when the customer discovers it first.

What the signature has to contain

Verifier, date, and unfinished items with a next step. A table signed with the third field blank has not been accepted; it has been stamped. And the signature only counts when it comes from the person who will operate the system, not the person who bought it.

That is why acceptance and the four-week rule are one instrument, not two: the table decides whether the system may be used, and the weeks decide whether it is. Keep every row measurable against the metric table it was derived from, and treat the whole record as part of the handover rather than as a milestone attachment. If a row cannot name its evidence location, delete the row and say why; an honest gap is worth more than a comfortable tick.