A neighborhood repair station is about to launch an appointment form. A session can accept eight items, each visitor can register one item per session, and online booking closes two hours before the session starts. An agent can draft the tests, but the team still needs three usable outputs: a case table tied to the requirements, a list of boundaries and failure paths, and fixtures it can recreate for the next release.
Turn requirements into cases with observable results
Freeze the requirement version and assign an identifier to each rule. In this example R01 covers capacity, R02 covers duplicate registration, and R03 covers the cutoff. Ask the agent to identify the inputs, initial state, user action, and observable result for each rule. If the requirement only says that the system displays a message when full, record a question about where the message appears and whether the wording is prescribed. The team can still check that the request is rejected and that the existing reservations remain valid.
Put the cases in an executable table with a case ID, requirement ID, setup, input, actions, visible result, and expected stored state. For R01, prepare a session with seven bookings and submit as a new synthetic visitor. Expect a confirmation number and zero places left. Submit again as a different visitor. Expect a rejection and check through an approved backend view that there are still eight active reservations. A confirmation screen and a stored record are separate observations. Note how each one will be checked.
A requirements conversion skill can help create the case table or map requirements into a review diagram. Verify its input formats first. A scanned PDF may need text extraction, and a copied table can lose the footnote that describes the cutoff. Try one short requirement and two manually checked cases before supplying a full document. If the team uses a mind map to review branches, retain the executable table with stable case IDs so defects can point to the exact case and version.
Add boundaries, state changes, and failures
Prepare sessions with zero, seven, and eight active bookings. Verify that the eighth booking succeeds and the ninth is rejected. Use two synthetic visitors to compete for the final place and check that exactly one reservation is confirmed. For the cutoff, control the time zone and test clock. Check one second before closing, the closing instant, and one second after it. If the requirement leaves the exact instant ambiguous, mark that expectation as pending and ask the owner to decide.
Model the reservation as a sequence of states. A new request can become confirmed, then canceled. Write down which actions are allowed from each state. Does canceling release a place? Does repeating the cancellation release it again? Can the visitor rebook? A slow network or repeated click may make the browser send a second request. Check both the visible feedback and the number of active records. Keep distinct cases for duplicate submissions from one visitor and simultaneous requests from different visitors, since they exercise different rules.
A test design skill can propose equivalence classes and state transitions. Ask it to say which failure each proposed case would distinguish, then remove duplicates that exercise the same decision with interchangeable data. Use the associated Webapp Testing skill when executing the browser cases. Provide an approved test address, synthetic accounts, expected feedback, and the allowed actions. Save failure screenshots and reproduction steps. Use an authorized API or backend view for record counts and an appropriate concurrency harness for simultaneous requests.
Generate fixtures you can recreate and clean up
Build the data in dependency order: accounts, sessions, then reservations. Tag everything with a unique run identifier. Set up one session with seven active reservations, one with eight, and one that includes a canceled record. Ensure the identifiers belong to the test namespace and that submitting the records cannot send production messages. For contact format checks, use values approved by the team for its test environment.
For bulk generation, specify field formats, references, row counts, a random seed, and which invalid values are intentional. Import a small batch first. Count active reservations per session, check account uniqueness, and flag broken references. Use deterministic fixtures for boundary cases and separate larger datasets for volume checks. Before cleanup, preview the rows for the run identifier and confirm the count. Clean up only the generated rows in that run.
Rehearse a release that adds a waiting list
The next release adds a waiting list. Run the eighth and ninth booking cases again. The owner confirms that the ninth request now creates a waiting entry without taking an active place. Add a test for cancellation and promotion: free one active spot, confirm that exactly one waiting visitor advances, then repeat the cancellation request and check that there is no second promotion. In the test environment, check where the notification went. Record the new expectation against the new requirement version and keep the previous test result for comparison.
If two visitors receive a success screen while competing for one place, pause the batch and save timestamps, responses, and the session ID. Inspect the active record count. If one record exists, trace how the other screen received a success response. If two exist, reproduce the race with the same setup and a synchronized pair of requests. These failures need different fixes and different evidence before the test can pass.
Common questions
Why are there many cases but still gaps?
Start with the rule map. Look for rules without an explicit pass condition, then check time boundaries, state changes, and recovery. Track unresolved expectations as questions. Prioritize the cases that can expose distinct failures.
Can we generate fixtures from actual appointments?
Make synthetic records that preserve the conditions required to reproduce the problem. For a capacity issue, that may be the session limit, request order, and reservation states. Use new identifiers and verify the environment and notification settings before running the case.
Why review a release if the browser tests passed?
Look at what each check could observe. Browser tests establish visible feedback and page state. Record checks establish whether a reservation was stored and whether capacity was updated. For a release that changes booking behavior, reconcile both results and retain the tested time zone, locale, and permissions.