Build acceptance examples before implementing a change

A requirement can sound settled until two people predict different results for the same situation. Acceptance examples expose that disagreement before implementation. Use a shared document for the cases and discuss them together in your virtual office. The useful output is an agreed behavior description, not evidence that software already implements it.

Choose one rule with a disputed edge

For this fictional practice example, a booking rule says: requests can be changed before the start. It leaves several questions open. Which clock defines the start? Does a request submitted exactly at that time qualify? Is the rule about changing the date, the participants, or any field?

Choose one uncertainty first: whether a date-change request submitted at the scheduled start is accepted. Record the booking's state and the time zone alongside the rule. Avoid adding cancellation, permissions, and notifications to the same discussion before the original edge has a defined meaning.

Write cases with complete starting conditions

Describe an ordinary case: a confirmed booking starts at 10:00 UTC, and its owner requests a date change at 09:59 UTC. Then write the boundary case at exactly 10:00 UTC and a counterexample at 10:01 UTC. Keep all other conditions identical so the time boundary is the difference being examined.

For each case, record the starting state, action, expected response, and resulting booking state. A response alone is insufficient: an error message with a silently changed booking would not match an expectation that the change is rejected and the original booking remains intact.

Predict before discussing

Ask each participant to predict the three results independently. Compare answers only after everyone has made a first attempt. Someone may interpret before as strictly earlier; another may expect a short grace period. Those interpretations are evidence of ambiguity, not evidence that either person misunderstood an agreed rule.

Have contributors explain which phrase supports their prediction. If a grace period is proposed, label it as a new requirement rather than inserting it into the expected result without discussion. Send unresolved policy choices to the actual requirement owner instead of letting the loudest interpretation become the contract.

Revise the rule and cases together

Suppose the fictional owner chooses a strict boundary. Rewrite the rule to say the request time must be earlier than the scheduled start, using UTC for this example. Mark the 09:59 case accepted, and the 10:00 and 10:01 cases rejected with the booking unchanged.

Add a case that distinguishes request submission from later processing if that difference matters. If the relevant timestamp is not defined, leave that case unresolved. A precise sentence about one clock cannot settle a separate question about which event supplies the timestamp.

Hand off an inspectable case set

Keep the final rule, each case, its rationale, and any open decision together. Ask a fresh reader to predict the boundary result without hearing the discussion. If their answer differs, inspect the wording and starting conditions before assuming the examples are clear.

Developers and reviewers can later decide how to represent these cases in their own test process. The document itself is not an automated test run, a passing implementation, or release approval. Its value is a small set of explicit expectations that makes a later behavior review possible.