Improve reservations without crossing office boundaries
Use a concrete business rule to expose an error a polished interface might hide.
What is difficult today?
A new bulk-move action appears to work: reservations move to the selected date. But the new endpoint could accidentally accept an identifier belonging to another office. A visible success message does not prove that the permission boundary remained intact.
The owner-approved rule becomes a protected scenario. Rehearsal compares permitted and forbidden cases, links the failed result to evidence and sends the candidate for correction. External messaging is simulated separately so the test cannot send real customer notices.
A sequence with accountable decisions.
The owner defines the target. The engineering work keeps the relevant business rules and returns evidence at each acceptance boundary.
Approve the office rule
One office must not change another office’s customer records.
Implement bulk move
Update dates within the authorized office and validate capacity.
Exercise a forbidden identifier
Try the same action on another office’s reservation.
Return the violated rule
Block acceptance and explain the specific evidence.
Verify the corrected candidate
Repeat both the allowed and forbidden cases.
Data, rules and proof—not only screens.
Data involved
- Synthetic reservations in two offices.
- Defined capacity, time zone and test notification adapter.
Rules to preserve
- Office scope is enforced by the server.
- A retry does not move or notify twice.
- Mocked messaging is not reported as a live-delivery test.
Evidence to inspect
- Allowed move succeeds.
- Cross-office move is denied and leaves data unchanged.
- Capacity conflict has a clear result.
- The corrected release is separately retested.
Owner decisions
- What happens when the destination is full?
- Which cases require a manager’s approval?
The forbidden path is part of the product contract
A reservation move can look successful while modifying a record from another office. Build the example around two offices, two authorized users and records belonging to each office. The normal move should succeed. Changing the identifier to a record in the other office must not bypass the access check. Verify persisted data after the attempted operation rather than relying only on the response message.
Keep the approved rule outside arbitrary changes by the implementation agent. If the task changes the ownership model deliberately, the owner reviews that change first and the scenario version follows it. Otherwise a failing test produces a correction, not a weaker assertion. External SMS delivery may remain simulated during the test. Show that boundary directly: the application’s intended message can be checked without claiming that a live provider delivered it. The result is evidence for the reviewed release, not a guarantee about every future version.
Follow a related example from start to release.
A worked example showing decisions, implementation and verification.
The video could not be loaded. Try again later.
Prepare the next decision.
One Product, several Projects: where business knowledge belongs
Keep modernization, features and AI adaptation connected without mixing their scope.
Read the guide →Write business rules before trusting the generated tests
An executable check needs an independent statement of what the software should do.
Read the guide →Start with a product.
Keep building a business.
Bring an idea or the software you already own. Give the next improvement a clear path from intent to evidence.