CRITICAL
Действия клиента
- Открыть публичную входную точку, проверить auth route, legal pages и намеренно открыть несуществующий URL для проверки 404.
- Зарегистрировать Client A на новом email с валидными данными и войти в кабинет.
- Выйти из аккаунта.
- Выйти и прогнать password reset для Client A.
- Попробовать войти со старым паролем.
- Войти в аккаунт новым паролем и передать админу точный email клиента.
Подсценарий 1A. Ошибки регистрации
- Попробовать пустую форму.
- Попробовать невалидный email.
- Попробовать слабый или несовпадающий пароль.
- Попробовать зарегистрировать уже существующий email.
Ожидание: ошибки понятные, частично созданный аккаунт не появляется, форма остаётся управляемой.
CRITICAL
Действия клиента
- Создать Request A с валидными полями.
- Создать Request B с отличающимися параметрами, чтобы админ мог легко отличить его от Request A.
- Создать Request C с отличающимися параметрами, чтобы админ мог легко отличить его от Request A и B.
- После создания не редактировать request-ы, пока админ не подтвердит intake или пока следующая фаза явно не потребует изменений.
Пока ждёшь админа
- Обновить список заявок и убедиться, что Request A, B и C не исчезают после reload.
- Открыть каждую карточку заново из списка и проверить, что статусы и поля не перемешаны.
Подсценарий 2A. Валидации request-формы
- Попробовать submit без обязательной даты или другого ключевого поля.
- Ввести очень длинный notes/comment и убедиться, что текст не теряется.
- Проверить, что после ошибки уже заполненные поля не обнуляются без причины.
Ожидание: request не создаётся с неполными данными, а форма даёт понятную обратную связь.
Подсценарий 2B. Double submit и reload
- После одного успешного submit обновить страницу или вернуться назад браузером.
- Проверить, не создаётся ли дубль случайным повторным действием.
Ожидание: система не плодит дубликаты из-за refresh, back или повторного клика.
HIGH
Действия клиента
- На Request A дождаться первого сообщения от админа и отправить осмысленный ответ клиентом.
- На Request B отправить request changes: изменить один реальный параметр, например дату, бюджет, комментарий или другой доступный ключевой атрибут.
- После каждого сообщения обновить страницу и заново открыть карточку, чтобы проверить повторное чтение таймлайна.
- Сравнить, что история Request A не попала в Request B и наоборот.
- Если есть email или in-app уведомления, проверить их.
Пока ждёшь админа
- Проверять timestamps сообщений и их порядок до и после reload.
- Держать Request C без изменений, чтобы позже убедиться, что его состояние не затронулось соседними действиями.
Подсценарий 3A. Пустые и длинные сообщения
- Проверить, можно ли отправить пустое сообщение или пустой change request.
- Отправить длинный текст и убедиться, что он не обрезается некорректно.
Ожидание: невалидные действия блокируются, длинные сообщения сохраняются без поломки layout.
Подсценарий 3B. Reload после ответа админа
- Сразу после входящего ответа обновить страницу.
- Проверить, что последнее сообщение и текущий статус перечитались корректно.
Ожидание: история не откатывается и не требует ручного восстановления через повторную отправку.
Подсценарий 3C. Изоляция между Request A/B/C
- Открыть по очереди Request A, B и C после серии сообщений.
- Убедиться, что статусы и треды не смешиваются между карточками.
Ожидание: каждая заявка живёт своей отдельной жизнью, а клиент легко понимает, что происходит где.
CRITICAL
Действия клиента
- Открыть первую версию Booking A и намеренно не approve-ить её сразу: использовать client-side request changes один раз.
- После того как админ пришлёт revised proposal по A, заново открыть карточку из списка и только затем нажать approve.
- Открыть Booking B и одобрить его сразу, без дополнительных правок.
- Проверить, что оба booking-а читаются отдельно и не меняют статусы друг друга.
- Не оплачивать booking-и до тех пор, пока админ не подтвердит, что видит финальные approve states у себя.
Пока ждёшь админа
- Переоткрывать список booking-ов и requests, чтобы проверить, что A и B не исчезают после approve/change loop.
- Держать Request C как контрольный объект и не переводить его дальше без синхронизации с админом.
- Фиксировать промежуточные статусы: waiting, changes requested, approved или аналогичные им значения.
Подсценарий 4C. Повторное открытие и idempotency
- После approve вернуться в список и снова открыть A и B.
- Проверить, что повторный клик не создаёт второй approve или вторую сущность.
Ожидание: статусы стабильны, а клиент не может случайно удвоить подтверждение.
CRITICAL
Действия клиента
- Оплатить Booking A успешным sandbox-путём и зафиксировать момент submit и момент возврата в кабинет.
- Для Booking B сначала пройти одну контролируемую неуспешную попытку оплаты и убедиться, что booking не помечен как paid ошибочно.
- Повторить оплату Booking B успешным тестовым способом и зафиксировать итоговый статус.
- Открыть invoice, contract, summary, receipt или другие доступные документы на A и B до и после reload.
- Вернуться в список booking-ов и убедиться, что возврат из платёжного потока не создал дублей.
Пока ждёшь админа
- Обновлять экран до тех пор, пока webhook или другой платёжный sync не доведёт статусы до ожидаемого состояния.
- Проверить поведение кнопок back/forward браузера после выхода из платёжного окна.
CRITICAL
Действия клиента
- На уже оплаченном Booking B отправить cancellation request с причиной или комментарием, если форма это поддерживает.
- Проверить, как меняются карточка booking-а, история, документы и доступные действия после cancellation request.
- После ответа или обработки со стороны админа обновить Booking B и сравнить итоговый статус в списке и в карточке.
- Проверить, что Booking A не затронут cancellation-логикой B.
Пока ждёшь админа
- Обновлять Booking B и общий список booking-ов, чтобы проверить сохранность derived status после reload.
- Сравнивать, одинаково ли cancellation-related состояние видно в списке, карточке и документах, если они ещё доступны.
- Не инициировать повторную отмену, если первый запрос уже отправлен и ожидает обработки.
Подсценарий 6A. Duplicate protection
- После отправки cancellation request попробовать нажать то же действие ещё раз, если интерфейс всё ещё это позволяет.
- Проверить, что система не создаёт второй запрос на отмену.
Ожидание: отмена не дублируется повторными кликами и не плодит лишние записи в истории.
Подсценарий 6B. Reload persistence
- После cancellation request обновить страницу.
- Снова открыть booking из списка и сравнить статус с тем, что был до reload.
Ожидание: derived status не исчезает и не откатывается до старого состояния.
HIGH
Действия клиента
- Открыть все доступные email-уведомления, которые пришли по ходу прогона: регистрация, password reset, новые сообщения, proposal/booking, payment, cancellation. Проверить отправителя, тему, язык и ссылки.
- В профиле или настройках сменить email у Client A на новый тестовый адрес и пройти подтверждение, если продукт его требует.
- Выйти и попробовать войти по старому email, затем войти по новому email.
- Сменить пароль в профиле или security settings и убедиться, что старый пароль отклоняется, а новый работает.
- Если self-service удаление аккаунта доступно, удалить тестовый аккаунт в самом конце прогона. Если удаление доступно только через админа, дождаться удаления и затем проверить эффект со стороны клиента.
Пока ждёшь админа
- Обновлять профиль и security screens, чтобы убедиться, что новый email и новый пароль переживают reload.
- После удаления аккаунта попробовать открыть прямой URL приватного раздела и снова войти в удалённый аккаунт.
Подсценарий 7A. Email-уведомления
- Проверить письма на регистрацию, reset, booking/payment/cancellation, если они реально отправлялись в этой сборке.
- Открыть ссылки из писем и убедиться, что они ведут в правильное окружение и не ломаются после использования.
Ожидание: письма приходят из ожидаемого домена, не теряют контекст и не ведут на битые или чужие URL.
Подсценарий 7B. Смена email и пароля
- Проверить, что старый email и старый пароль больше не дают доступ.
- Проверить, что новый email и новый пароль работают после logout/login и после reload.
Ожидание: ротация данных аккаунта не создаёт параллельных валидных идентификаторов входа.
Подсценарий 7C. Удаление аккаунта
- Подтвердить удаление тестового аккаунта через UI клиента или через действие админа.
- Проверить, что сессия завершается, логин больше не работает, а приватные маршруты перестают быть доступными.
Ожидание: удаление аккаунта требует явного подтверждения и действительно закрывает доступ в систему.