Follow the user path.
Account, slot, appointment, test payment, and receipt are treated as one journey rather than a pile of disconnected screenshots.
RomeoApps-owned / synthetic QA lab
A booking flow should fail in a named place.
This small appointment surface shows how I exercise a SaaS, isolate expected stops, and re-test the path before touching a customer's account or repository.
Synthetic account. Test-mode payment. No network requests, credentials, production data, or automatic booking action.
05 deterministic cases
04 expected pass paths
01 payment stop
00 credentials or network
The useful seam
Test the journey, then name the boundary.
The buyer does not need another generic “I can test your website” claim. They need to see which path was exercised, what a failure looks like, and what evidence comes back after a fix.
Make bad states visible.
Missing inventory, duplicate submission, and a declined test payment stop at the first safe boundary instead of creating a false success.
Return a re-test matrix.
Each accepted fix gets a before/after result, viewport, browser, fixture, and remaining uncertainty. Production access comes later, if it is needed at all.
Interactive local bench
Run the booking route yourself.
This is a deterministic browser surface, not a live booking system. Choose a path, inspect the stop line, then run the five-case suite.
01 / ACCOUNT
Sign in with a synthetic account.
The account is a fixture. It never leaves this page and carries no real customer identity.
Ready. No test has run.
A paid first unit
Start with the smallest surface that can be accepted.
The live buyer brief asks for a broad application audit. A credible first milestone needs a supplied staging surface, safe fixtures, and a named reviewer before the code or account is touched.
INPUTsafe staging or test build
One test account, one approved fixture set, and payment test mode.
CHECKcore booking journey
Auth, create, reschedule, cancel, responsive layout, and the agreed browser matrix.
FIXhighest-impact defects
One or two confirmed in-scope fixes, with regression coverage where it belongs.
HANDOFFfound / fixed / re-tested
Evidence, changed-file note, remaining risks, and the next written decision.
Truthful boundary
Proof is not a client claim.
Proven here
- Five deterministic checks run locally.
- Expected failure states stop without false success.
- Responsive and accessibility structure is inspectable.
- Public JSON receipt describes the exact fixture.
Not claimed here
- No client repository, account, payment provider, or customer data.
- No booking, notification, or production mutation.
- No buyer selection, payment, delivery, or settled revenue.
- No promise to repair an entire application without scope.
Next safe step
Bring one failing path, not your whole production account.
Send a written fit brief with a safe staging route, the wanted outcome, and the acceptance owner. I will confirm the first deliverable before any access or payment path.