Restaurant Software Acceptance Testing Checklist

Convert each scoped outcome into an observable test

For each outcome in scope, write one test with action + expected result + where to verify it.

Example: "Create dine-in order for 2 items with 10% discount > pay by card > verify POS total, payment report, and kitchen ticket match."

Pass = stated result visible in source system. Fail = any mismatch, missing ticket, or unverified total. Owner: test author. Record: test ID + scope reference.

Prepare realistic roles, locations, products, prices, and edge cases

Use real menus, prices, taxes, discounts, and modifiers. Test as cashier, manager, kitchen, and read-only staff in at least two locations/devices if multi-site.

Include: out-of-stock, void before/after payment, partial refund, duplicate tap/submit, closed table/day, changed price mid-service.

Pass = role sees only allowed actions and edge case produces defined receipt/report. Owner: operations lead. Record: role matrix + product/price set used.

Test integrations, permissions, retries, reversals, and fallback

Test POS-payments, printer/KDS, reservations, inventory, and accounting exports end-to-end. Check denied permissions, expired sessions, timeout retry, double-charge prevention, refund/reversal reconciliation, and offline/paper fallback.

Pass = retry does not duplicate charge, reversal reconciles, fallback keeps service running with later sync. Fail = silent loss or unreconciled total. Owners: integration owner + manager approver. Record: log/transaction IDs, before/after totals.

Record evidence, owner, severity, resolution, and retest result

Log for each failure: screenshot/log ID, owner, severity (blocker/major/minor), fix, and retest date + result. Launch blockers require objective exit criteria, e.g. "3 consecutive full dinner-peak runs with zero total mismatches."

Ready to launch = zero open blockers, all majors retested Pass. Owner: release decision-maker. Record: acceptance log with sign-off.