Создайте свободный номер в тестовом расписании и попробуйте забронировать его на одни даты из двух независимых сеансов браузера. Сайт должен подтвердить только одну бронь, а второму гостю предложить другие варианты. Затем проверьте журнал бронирований: на экране результат порой выглядит верным, хотя система сохранила лишнюю запись. Ниже — порядок проверки для небольшого отеля, в том числе при бронировании через агрегаторы и при изменении уже оформленной заявки.
Дата публикации: 09.11.2026
Что именно считать двойной бронью в отеле?
Сначала выберите, что продаёт сайт: конкретный номер или место в категории. Если в категории несколько одинаковых свободных номеров, два подтверждения на одни даты ещё не означают ошибку. Конфликт появляется, когда подтверждённых броней больше, чем доступных номеров, либо когда система обещает двум гостям один конкретный номер на пересекающиеся ночи.
Запишите правило для теста простыми словами: «На эти даты доступен один номер; после первой подтверждённой брони второму гостю его больше не предлагают». Учитывайте весь срок проживания. Бронь с заездом на следующий день после первой всё ещё конфликтует, если первая охватывает эту ночь. При этом заезд в день выезда другого гостя оценивайте по правилам вашего отеля, а не только по совпадению дат на экране.
Отдельно определите, что означает сообщение после нажатия кнопки. Если сотрудник ещё проверяет наличие вручную, назовите результат заявкой и укажите, когда гость получит ответ. Надпись «номер забронирован» до такой проверки создаёт риск двойной продажи (SGI24).
Как проверить две заявки с сайта на одни даты?
Проводите проверку в тестовой копии сайта с отдельным номерным фондом. Сначала убедитесь, что тестовые заявки не попадают в рабочее расписание и не отправляют гостям сообщения. Если копии пока нет, попросите разработчика подготовить её до проверки: удалять случайные брони из действующего календаря сложнее, чем заранее отделить тест.
- Оставьте в тестовом расписании один доступный номер на выбранный период.
- Откройте форму бронирования в обычном и приватном окнах. В обоих выберите те же даты и дойдите до последнего шага.
- Отправьте заявки почти одновременно. Сохраните сообщения на экране и ответы сервера, затем проверьте список броней со стороны администратора.
- Повторите попытку без обновления страницы второго гостя: он мог открыть календарь до того, как первый занял номер.
Успешный результат выглядит так: один гость получает подтверждение, второй видит, что номер уже занят, а в расписании остаётся одна активная бронь. Если оба получили подтверждение, сохраните даты, тип номера и последовательность действий. Если победил только один, вывод пока осторожный: ручные нажатия могли разойтись по времени, и ошибка просто не проявилась.
Попросите разработчика отправить конкурирующие запросы в тестовой среде с минимальным разрывом и показать итог в базе бронирований. Такая проверка находит ситуацию, когда оба запроса сначала видят свободный номер и лишь потом каждый создаёт бронь. Скрытая кнопка на одной странице здесь не помогает: другой гость уже открыл свою форму. Похожий приём для записи клиентов на одно время разобран в статье на tit.by; для отеля в тесте нужно учитывать ещё и весь период проживания.
Как проверить брони из разных каналов?
Сайт редко работает отдельно от остальных каналов продаж. Поэтому повторите сценарий, в котором номер занимает заявка с сайта, а сотрудник в это же время вносит бронь из другого канала. Проверьте, когда и где меняется остаток доступных номеров. Если система передаёт сведения агрегатору с задержкой, сам сайт способен пройти предыдущий тест, но номер всё равно останется доступным за его пределами.
Для малого отеля полезно составить короткую карту: откуда приходит бронь, кто меняет её статус и какой календарь показывает итоговую доступность. На этом этапе помогает сверка сайта, карт и агрегаторов: гостю важны одинаковые условия и понятный путь бронирования, а администратору — ясный источник каждой заявки.
Проверьте также изменение существующей брони через агрегатор. Возможен отдельный сбой: после изменения дат система управления отелем создаёт вторую запись вместо обновления первой. В таком случае сначала убедитесь, что у агрегатора осталась одна изменённая бронь, затем сверьте записи в системе отеля (Smart Order). Для теста достаточно взять одну бронь, изменить её даты в тестовом канале и проследить, сохранилась ли одна активная запись.
Не ограничивайтесь сообщением гостю. В описанном белорусским изданием случае человек получил SMS после бронирования через сайт, но по приезде бронь не нашлась в гостинице (Недвижимость Onlíner). Это повод при каждой проверке сопоставлять три вещи: подтверждение для гостя, запись у администратора и доступность номера для следующего покупателя.
Как принять исправление перед запуском сайта?
Попросите разработчика показать, в каком месте сервер окончательно закрепляет номер за гостем. Проверка свободного номера и создание брони должны работать вместе: когда первый запрос занял последний номер, второй получает отказ. Если продаётся категория с несколькими номерами, система должна уменьшать доступный остаток без ухода в отрицательное значение. Конкретное решение зависит от того, как устроены сайт и его календарь.
Проверьте ещё один сценарий: гость нажал кнопку повторно, потому что страница долго отвечала. В расписании должна остаться одна бронь по этой заявке. Затем сверьте экран с календарём администратора. Сообщение об ошибке на странице тоже требует внимания, если сервер уже создал бронь: гость попробует оформить её снова.
Зафиксируйте результат проверки в коротком задании: тестовые даты и номер, действия двух гостей, ответы сайта, итоговые записи в календаре. Сохраните автоматический тест, чтобы запускать его после правок формы и календаря. Перед этим проверьте бронирование на сайте с телефона: на мобильном экране гость проходит тот же путь, но ошибка в выборе дат или повторное нажатие могут проявиться иначе.
Типичные ошибки при проверке
- Отправлять заявки по очереди. Подведите обе формы к подтверждению заранее и проверьте конкурирующие запросы в тестовой среде.
- Судить только по экрану гостя. После каждого теста открывайте календарь администратора и считайте активные брони.
- Проверять лишь одинаковые даты заезда. Добавьте брони с разными датами начала, у которых пересекается хотя бы одна ночь.
- Забывать про изменение брони. Проверьте, обновляет ли система запись после смены дат в другом канале.
- Считать скрытый номер достаточной защитой. Повторите отправку из окна, где страница была открыта до первой брони.
Добавьте сегодня в задачу на проверку одну строку: «На один доступный номер и пересекающиеся даты подтверждение получает только один гость; в календаре остаётся одна активная бронь».
