Skip to contentTalk to us
العربيةLog inStart free
For restaurants & booking

Two guests, one table, 7 pm. Who finds the problem first?

A double booking does not show up while you try your system on your own. It shows up on a busy evening, with two guests standing at the same table. Fanann’s QA engineer tries that situation before they do: it books the table twice in a real browser, documents what happened with evidence, then makes sure the fix really ended the problem.

Start freeHow it works
Illustrative example: Rose CaféTest bookings only with your permissionPart of the paid plans
Why it matters

Booking bugs show up at the worst time

1

One table, two guests

Two guests booked at the same moment and the system accepted both. One of them will stand waiting, and their review will not mention that the food was good.

2

A booking at closing time

The system accepts a booking after closing time, or at an hour when Friday hours are different. The guest arrives to a locked door.

3

A form that rejects the phone number

A guest typed their number in Arabic digits and the form rejected it with no explanation. They will not call to complain; they will book somewhere else.

1The test

It books the table twice, as your guests might

In the Rose Café example the owner asks one question, and the QA engineer proposes a double-booking test and asks first: may I create test bookings? Once you agree, it uses test accounts, on a staging copy of the system where one exists. It then submits two overlapping bookings for table 4 at 7:00 pm and checks the result on screen, and through the API when you allow it.

  • Asks before creating any data
  • Test accounts and a staging copy where possible
  • You watch the steps as they run
2The evidence

A documented bug, not an opinion

The system accepted both bookings. A bug card appears with enough for the owner to understand it and the developer to fix it: two confirmations, the same table, the same time, with both screenshots and the steps that reproduce it. Expected: the second booking is refused or another table is offered. Actual: both guests got a confirmation.

  • Both confirmation screenshots side by side
  • Steps that reproduce it every time
  • The business impact on the first line
3Fix and verify

It runs the same test again after the fix

If your system was built with Fanann, you ask Fanann to fix the bug from its card. If it was built elsewhere, your developer takes the report and fixes it. Either way the QA engineer runs the same double-booking test again, along with the booking cases around it: cancel then rebook, and a booking for another table at the same time. Only then is “verified fixed” written.

  • The case is saved and re-run after every change
  • Neighbouring booking cases are tested with it
  • If the bug returns it is marked “regressed”
Other checks worth asking for

What else should you ask it to test in your restaurant?

Double booking is the famous one, but not the only one. These are requests you can write as they are.

Times and limits

A booking in the past, a booking after closing, Friday hours and a party larger than the table seats. A healthy system refuses them with a message people understand.

Try booking a time that has passed, after closing, and for ten people at a table for four.

Cancel, then book again

Does the table become available again after a cancellation? And does the confirmation message carry the right name, time and table?

Book a table, cancel it, and make sure it is available again and the confirmation message is correct.

Menu and ordering on a phone

The menu and ordering at phone screen size: are the items readable, do the buttons respond, and does the phone field accept Arabic digits?

Open the menu at phone size, order a meal and type the phone number in Arabic digits.
The steps

The Rose Café example, step by step

An illustrative example of how it works, not a real customer story.

  1. 1

    The owner asks in plain words

    They write: “Check: can two guests book the same table at 7 pm?” No settings and no jargon.

  2. 2

    The QA engineer proposes and asks permission

    It proposes a double-booking test, explains that it will create test bookings and waits for approval. It uses test accounts and a staging copy where one exists.

  3. 3

    Two bookings for table 4 at 7:00 pm

    It submits the two overlapping bookings in a real browser and checks the result on screen, and through the API when allowed.

  4. 4

    Both were accepted: a bug with its evidence

    A bug card opens: two confirmations, the same table, the same time, with screenshots, the steps that reproduce it and expected vs actual.

  5. 5

    The fix

    A system built with Fanann: you ask Fanann to fix it from the card. An external system: your developer fixes it using the report.

  6. 6

    The retest, then the stamp

    The same test runs again with the booking cases around it. Is the second booking refused this time? Only then: “verified fixed”.

Plainly: what you should know

Illustrative exampleRose Café is an example that explains how it works, not a real customer and not a result taken from a particular restaurant.
Test dataTest bookings are created only with your approval. Without it, cases that change data are skipped, and the report says so.
External systemsA booking system not built with Fanann only needs its address added, and Fanann does not change its code: the fix is your developer’s.
Out of scopeIt does not simulate hundreds of guests at once and does not test native mobile apps on devices. It tests the flows in a real browser.
FAQ

Questions people ask

How do I test my restaurant booking system?
Tell Fanann’s QA engineer what worries you in your own words, such as: can the same table be booked twice? It proposes a test plan you review, runs it in a real browser on your system and gives you a report of what passed and what failed, with evidence.
What is a double booking and how do I detect it?
A double booking is when the system accepts two bookings for the same table at the same time. You detect it by deliberately submitting two overlapping bookings and watching the result: a healthy system refuses the second or offers another table. That is what the QA engineer does, and documents with screenshots.
Will testing create real bookings in my system?
No bookings are created without your permission. The QA engineer asks before any test that changes data, and uses test accounts and a staging copy where one exists. If you do not allow writes, those cases are skipped and the report says so.
Does it work with a booking system I did not build with Fanann?
Yes. Add the site’s address and start, then set what may be changed, and the QA engineer tests it in a real browser. The difference is that Fanann does not change an external system’s code: you get a report with the steps, the evidence and a likely cause, and your developer fixes it.
Is Rose Café a real customer?
No. Rose Café is an illustrative example we use to explain how the QA engineer works in a situation every restaurant owner recognises. No customer names or figures from real restaurants are shown here.
What else should be tested in a restaurant app?
Bookings in the past or after closing, Friday hours, a party larger than the table seats, cancelling then rebooking, the content of the confirmation message, the menu and ordering at phone size, and Arabic digits in the phone field.
Is booking system testing free?
Signing up to Fanann is free, and the QA engineer is part of the paid plans. Testing external sites and scheduled runs depend on your plan.
QA Engineer

What else can the QA engineer test for you?

QA Engineer

The main page: an AI QA engineer that plans tests, runs them in a real browser, documents every bug with evidence and tells you whether your app is ready to launch.

Meet the QA engineer

Website testing

Is your site built outside Fanann? Add its address and have the QA engineer test its pages, forms and flows in a real browser.

See the details

API testing

Upload the API description file and the QA engineer checks that every request returns what it should: status, fields, permissions and error messages.

See the details

Regression testing

Every test case is saved and re-run. After any change you know in minutes whether what worked still works, and when it broke.

See the details

Bug tracking

Every bug is a card with impact, steps, expected vs actual and a screenshot, and it stays open until a retest proves it fixed.

See the details

Test before launch

Built your app with Fanann? Test it from the publish window itself, ask Fanann to fix what turns up, then publish knowing where it stands.

See the details

Guides to read before you test

What is software testing?

An explanation for business owners, without jargon: what gets tested, the kinds of testing that actually matter to you, and when manual testing is enough and when it is not.

Read the guide

Website testing checklist

A practical list to go through before you announce your site: sign-up, forms, checkout, mobile, Arabic, messages and what comes after launch.

Read the guide

How to write a bug report

A ready template and examples: a clear title, steps that reproduce the bug, expected vs actual, evidence, and how to set severity without exaggerating.

Read the guide
Fanann for restaurants & cafésBuild a booking system with FanannTest your existing websiteGuide: website testing checklist
From the blog

Guides to testing and AI QA

All Testing & AI QA guides
PASSPASSBUGPASSPASSWhat is an AI QA agent? How it tests your site like a careful person9 min readAn AI product team in one place: plan, build and test without hiring11 min readPASSPASSBUGPASSPASSAI QA agent or a human tester: who should test what?9 min read

Find the double booking before your guests do.

Write what worries you about your booking system in your own words; the QA engineer tests it in a real browser and documents every bug with evidence. Part of the paid plans, and signing up is free.