Начните с тестового расписания: попросите двух участников одновременно записаться к одному мастеру на один интервал. Для индивидуального приёма система должна подтвердить только одну бронь, а второму клиенту предложить другое время. Затем проверьте результат в календаре администратора. Такая проверка помогает обнаружить конфликт, но для приёмки сайта понадобится ещё подтверждение защиты на сервере. Ниже — порядок действий для владельца салона: как подготовить проверку, что поручить разработчику и по каким признакам принять работу.
Что проверить в расписании до первого теста?
Уточните, откуда сайт получает свободное время. Если администратор ведёт запись в одной программе, а сайт хранит отдельный календарь, сначала разберитесь, как они обмениваются изменениями. Две независимые записи создают риск конфликта: клиент выбирает время, которое администратор уже отдал другому посетителю. Этот принцип разбирает SGI24 в материале о CRM для салона красоты.
Зафиксируйте единое правило доступности. Для индивидуальной услуги мастер занят на протяжении всей процедуры, включая перерыв на подготовку рабочего места, если салон предусматривает такой перерыв. При групповой услуге нужно отдельно задать допустимое число участников. Единое расписание и правила доступности — основа защиты от двойных бронирований (MySlot).
Проверьте, что происходит с записью по телефону. Попросите администратора занять тестовый интервал привычным способом и посмотрите, исчезнет ли он из доступного времени на сайте. Затем отмените запись и проверьте обратное изменение. Если выбираете новую систему, включите этот сценарий в проверку сервиса онлайн-записи для салона красоты до подключения к рабочему расписанию.
Отдельно опишите, что именно нельзя бронировать одновременно. Иногда ограничение связано с мастером, иногда — с кабинетом или общим оборудованием. Для начала выберите один понятный случай: индивидуальная услуга у одного мастера. Так будет проще понять причину ошибки.
Как безопасно проверить одновременную запись?
Попросите разработчика подготовить тестовую копию сайта с отдельным расписанием. Уточните, что заявки из неё не попадают в рабочий календарь и не запускают сообщения настоящим клиентам. Проверку можно начинать после подтверждения этих условий.
- Создайте тестового мастера и свободный интервал, который целиком занимает выбранная услуга.
- Откройте форму записи в двух независимых сеансах браузера, например в обычном и приватном окне без общего входа.
- В обоих окнах выберите одинаковые условия и остановитесь перед последним подтверждением.
- Отправьте заявки почти одновременно, затем дождитесь окончательного ответа в каждом окне.
- Откройте календарь администратора и сверьте число активных записей с ответами на экране.
Если оба участника получили подтверждение на один интервал, сохраните снимки экранов и записи в календаре. Этого достаточно, чтобы передать разработчику воспроизводимый дефект. Запишите также услугу, мастера и порядок действий, иначе при повторной проверке легко выбрать другие условия.
Если система подтвердила только одну заявку, ручной сценарий пройден. Однако запросы могли прийти с разницей, которой хватило для последовательной обработки. Поэтому такой результат ещё не доказывает, что сайт справится с одновременными обращениями.
Повторите сценарий со старой страницей: один участник открывает свободное время, другой занимает его, после чего первый отправляет заявку без обновления календаря. Сервер должен повторно проверить доступность перед тем, как подтвердить запись.
Что поручить разработчику после ручной проверки?
Попросите проверить участок, где сервер закрепляет время за клиентом. Ошибка возникает, когда приложение сначала узнаёт, свободен ли интервал, а затем отдельно создаёт бронь. Между этими действиями успевает прийти другая заявка. В итоге обе заявки получают доступ к одному времени.
Сформулируйте задачу через результат для салона. Разработчику понадобится проверить конкурентные запросы, то есть обращения, которые претендуют на один интервал почти одновременно. Проверка должна охватывать всю длительность услуги: запрет одинакового времени начала не защищает от частичного пересечения процедур.
Текст для задачи можно сформулировать так: «В тестовом расписании проверьте одновременные заявки разных клиентов к одному мастеру. Подтверждение должна получить только одна заявка. Проверьте также частичное пересечение услуг и повторную отправку одной заявки после задержки ответа. Сохраните ответы сервера, итоговое расписание и инструкцию для повторного запуска проверки».
Попросите разработчика объяснить, какой механизм исключает конфликт. Выбор зависит от базы данных и устройства приложения. Для фиксированных слотов подходит ограничение на повторное занятие слота; для услуг разной длительности нужна защита от пересечения интервалов. В обоих случаях сервер должен закреплять время так, чтобы конкурирующая заявка не получила подтверждение на уже занятый интервал.
Технический сценарий после доработки сайта или сборки с помощью ИИ подробнее разобран в статье на tit.by. Владельцу салона достаточно согласовать критерии приёмки и получить результат проверки вместе с объяснением серверной защиты.
Если одновременно идут подозрительные массовые обращения, отдельно проверьте признаки AI-ботов на сайте салона. Ограничение таких обращений решает другую задачу: две обычные клиентские заявки тоже не должны занимать один интервал.
По каким признакам принять работу?
Сверяйте подтверждение на сайте с фактической записью в календаре. Сообщение об успехе без брони оставит клиента без визита. Обратная ситуация тоже требует исправления: если сайт показывает ошибку, хотя запись уже появилась, человек повторит попытку и получит непонятный результат.
- При одновременной записи на индивидуальную услугу подтверждение получает один клиент, в календаре остаётся одна активная бронь.
- Второй клиент видит понятное сообщение о занятом времени и может выбрать другой интервал.
- Услуги с разным временем начала не пересекаются у одного мастера, если правила салона запрещают такое пересечение.
- Повторная отправка той же заявки после задержки ответа не создаёт дополнительную запись.
- Разработчик передаёт способ повторного запуска теста и показывает результат после всех ответов сервера.
Проверку повторной отправки проводите отдельно от борьбы разных клиентов за одно время. Это разные ситуации: в первой человек повторяет свою заявку, во второй два посетителя выбирают один интервал. Исправление одного сценария не подтверждает защиту второго.
Сохраните тест в проекте и договоритесь запускать его после изменений календаря, длительности услуг или связи сайта с системой записи. Все такие запуски должны обращаться только к тестовому расписанию.
Если владельцу сложно перевести правила салона в техническое задание, полезен отдельный разбор процесса записи с консультантом. Результатом такого разбора должен стать документ: кто меняет расписание, где хранится доступность и какие сценарии проверяют перед запуском. С ним проще обсуждать доработку и обучать администратора.
Типичные ошибки при проверке двойного бронирования
- Отправлять заявки по очереди. Сервер успевает занять время, поэтому тест не проверяет конфликт одновременных обращений.
- Считать отключённую кнопку защитой. Она ограничивает действия на одной странице, но не мешает другому посетителю отправить свою заявку.
- Проверять только одинаковое начало. Добавьте услуги, которые начинаются в разное время, но частично пересекаются.
- Оценивать результат только по экрану клиента. После завершения запросов откройте календарь администратора и проверьте активные записи.
- Принимать один успешный запуск за гарантию. Попросите разработчика показать серверный механизм защиты и сохранить повторяемый тест.
За ближайшие две минуты добавьте в задачу разработчику критерий приёмки: «Два клиента одновременно бронируют один интервал у одного мастера; подтверждение получает только один, а в расписании остаётся одна активная запись».
