Every Friday a community food bank updates the pickup calendar for the coming week. Before the schedule goes live, volunteers compare the approved roster with a preview of the booking site and hand exceptions to the shift lead. Rehearse with three fictional slots: one open, one canceled and one at capacity. These cases exercise three different parts of an autonomous workflow: finding a suitable tool, acting on a known event, and coordinating several steps into a report that another person can verify.
Find tools from the expected result
Start with the handoff. The shift lead needs one row per slot, with its identifier, expected state, observed state, check time, and evidence when the two states disagree. Work backwards from those columns. Reading the roster, interpreting timestamps, interacting with the website, and producing the report are separate capabilities. An existing spreadsheet reader can check duplicate identifiers without starting a browser. A browser is useful when the task asks whether a person can actually select a slot or what message appears when it fills up.
Search the approved catalog for those capabilities. Compare the inputs that each candidate accepts, the permissions it requires, and whether its output can fill the handoff. Use the linked Webapp Testing skill for the preview step. Prepare a reachable test site, a roster already loaded into the preview, and a test account if the preview requires one. Give the browser runner an expected outcome for each interaction. The roster reader owns the input validation, and the shift lead owns the decision to publish the schedule.
If the catalog lacks support for the incoming file format, record the gap and request a known export format. When an external search turns up a candidate, note its source, version, required permissions and what data it receives. Evaluate it with a fictional roster. A tool that only prints page text may be enough for reading a cancellation notice, but testing whether the corresponding button can submit a reservation requires interaction. Keep that distinction in the catalog so the next run can pick a tool based on the action it needs.
Act when an approved roster arrives
Start with a specific trigger: an approved roster version has arrived in the test folder. Validate the required columns and approval marker before scheduling any checks. Use the roster version as part of the run key. If the same file arrives again, return the existing report. If an amended roster arrives, create a new run and mark the earlier report as superseded. During rehearsal, submit the same roster twice and then submit a version with one new slot. Verify that the first pair produces one report and that the update produces its own record.
Generate three cases from the roster. An open slot should be selectable. A canceled slot should show the cancellation message and prevent selection. A full slot should show the agreed full or waitlist state. Use Webapp Testing to open each test page and record the sequence of actions and the resulting screen. If a slot appears open and then rejects the test booking as full, retain the screen before and after the click. Ask the shift lead to check whether another test changed the fixture during the run. That comparison separates a moving test fixture from a UI bug.
Give each automatic step a reason to stop. If the preview is still syncing, allow a limited number of status checks and record the version seen on each attempt. If the account cannot sign in, keep the roster results and route the browser step to the person who manages the test account. If the page renders the wrong state against the right fixture, report the mismatch with its evidence. Rehearse with an expired test account to confirm that the report still exposes completed work and identifies who can resume the blocked step.
Coordinate the branches and hand off exceptions
The roster reader and preview availability check can run independently. Start row comparisons when both report the same batch version. Merge results by slot identifier and date because two pickup locations can share a display name. Show passed, failed, skipped and awaiting review as separate states. If the preview has synced only part of the roster, preserve the completed comparisons and leave the missing slots pending.
Suppose Tuesday morning slot A17 was open in the previous version and canceled in the new one. If the preview is still serving the earlier version, record both versions and rerun the browser check for A17 after sync. Verify the cancellation text, disabled action and displayed local time. If the cancellation notice appears and the test account can still submit a booking, preserve the reproduction steps and route the case to the booking system maintainer. The shift lead should review the exact schedule version before releasing it to visitors.
Write the handoff so another volunteer can resume it during the next shift. Include the test environment, input version, run ID, checked slot identifiers and each exception owner. After adjusting a rule, replay a case that failed and a case that previously passed. This catches fixes that correct one unusual row at the expense of the normal booking path.
Rehearse a time boundary and a connection loss
Set a fictional booking window to open at 9 a.m. on Friday. Check the same slot shortly before and after the opening time. If the preview supports a controlled clock, use the same input at 8:59 and 9:01. Otherwise record the actual check times and time zones. If results disagree with the roster, compare the time basis used by the file, browser and booking service before deciding where the defect belongs.
Then interrupt the connection after the roster check has succeeded. The report should retain the completed input check and show that the browser branch needs a retry. Restore the connection and retry the branch against the same roster. Record the original run ID and the new attempt number. If a revised roster arrives meanwhile, start a new run so results from the old preview cannot be counted toward acceptance of the new schedule.
Troubleshooting and handoff questions
Can a newly discovered tool run immediately?
Check its expected inputs, access needs and output using a test fixture. Record what it can read or upload and the version you evaluated. Approve it for a defined step once someone can reproduce the result. If it requests access to the live roster, make that a separate decision for the data owner.
Why are the same slots repeatedly skipped?
Group the skips by cause. Missing time zones go to the roster maintainer, incomplete sync goes to the preview owner, and expired test accounts go to the shift lead. Once the input is repaired, rerun the affected slots and retain the original skip reason in the audit trail. A recurring missing field belongs in intake validation.
What should the shift lead receive?
Provide a versioned report with row-level outcomes, evidence for every reproducible mismatch, and an owner for each unresolved item. Keep one open, one canceled and one full fixture as the baseline for next week's check. The report should identify the reviewed roster version clearly enough that the lead can match it to the release they approve.