Spend a Small Test Budget Where Risk Lives

A small project still needs a verification strategy, but “test everything” is not a strategy. Time is finite. Spend it where a defect is likely, costly or hard to observe. For an invented request tracker, losing a confirmed request matters more than misaligning a secondary label.

Start with risks in plain language. A valid request may not persist. Two quick confirmations may create duplicates. An illegal state move may be accepted. A failed write may be reported as success. A release may work locally but fail in its served environment. Each risk points to a different kind of evidence.

Begin with acceptance examples

Acceptance examples describe observable behaviour without binding the check to internal structure. Given an empty request list, when a visitor submits a valid subject, then one awaiting request remains after the application is reopened. Given an accepted request, when withdrawal is attempted, then the move is rejected and the accepted state remains.

Use representative values, including boundaries. If a subject permits 1 to 80 characters, examples at 1, 80, 0 and 81 reveal the contract. Do not confuse this with testing every possible sentence. Partition values by behaviour.

Put unit checks around decision density

A unit boundary is useful where inputs map deterministically to outputs: validate a time window, choose an allowed transition, normalise an optional note, classify a failure message. These checks run quickly and make the rule legible.

Avoid checks that merely repeat assignments or private call sequences. Those weld the suite to implementation while saying little about user risk. If a harmless refactor breaks many checks, the boundary may be too intimate.

Cross real boundaries deliberately

Integration checks prove assumptions between parts: can the chosen record round-trip through the relational datastore? Are recorded times read with the intended offset? Does a duplicate key produce the expected rejection? Can a rollback leave no partial row? Use the real boundary under controlled conditions where feasible, not an imitation that agrees with your own misunderstanding.

Keep these checks fewer and more purposeful. One round-trip with a representative nullable value can cover a contract that ten isolated checks cannot. Add a migration check when old records must survive a shape revision.

Reserve smoke checks for assembly

A release smoke check is short and broad. Open the served browser application. Create one request. Reopen it. Make one legal state change. Confirm the visible result. Trigger one safe rejection. It is not a deep regression suite; it catches missing configuration, broken paths and mismatched assembled parts.

Record the release revision, environment, time and result. “It worked earlier” is not evidence about the current release. Nor is a local smoke check evidence about a different environment.

The original test-budget calculation

Assume six hours remain for verification planning and execution. Reserve 25% for investigating and correcting failures found during checks: 6 × 0.25 = 1.5 hours. That leaves 4.5 hours for planned checks.

Score each risk from 1 to 3 on impact, likelihood and uncertainty, then multiply. These values are judgement calls made visible, not measured probabilities.

The budget totals 90 + 60 + 55 + 40 + 25 = 270 minutes, or 4.5 hours. Together with the 1.5-hour correction reserve, that returns to six hours. The allocation is deliberately not proportional to score alone: the persistence risk needs slower boundary setup, while the smoke route is cheap.

Make checks readable as evidence

Name the risk in each check. Use data that exposes the boundary. Keep expected outcomes visible. When a check fails, distinguish a product defect from a bad assumption or an unreliable test environment. Flaky checks consume trust; quarantine and repair them rather than treating occasional green as proof.

Derive risks from the six-pass release card. The state chart supplies transition examples; the failure matrix supplies induced trouble cases. That traceability is the point.