Проверьте путь заявки от формы до обработки

Выберите одну форму вашего сайта и проверьте, что происходит с обращением после отправки. Результатом урока станет заполненный протокол с доказательством обработки. Сообщение «Спасибо» — только один из наблюдаемых этапов.

Для работы нужны разрешённое тестовое окружение, согласованный получатель и участник с доступом к системе обработки. Если их пока нет, выполните учебный разбор ниже и назовите его учебным. Он поможет подготовить проверку, но не подтвердит работу вашего сайта. Причины возможных сбоев разобраны в руководстве по пути заявки; здесь вы собираете результат проверки конкретного обращения.

Шаг 1. Договоритесь о границах теста

Запишите адрес и версию сайта, страницу формы, язык, браузер, размер экрана и время с часовым поясом. Назовите систему назначения: CRM, почта или другой согласованный приёмник. По карте интеграций уточните, какие промежуточные сервисы участвуют и кто может подтвердить каждый этап.

Согласуйте адрес или номер, которыми можно пользоваться для теста, и заметную метку, например «ТЕСТ ПРИЁМКИ — ЗАЯВКА 01». Не используйте чужие контакты. Предупредите получателей об автоматических письмах и уведомлениях; если тест запускает другие действия, предусмотрите разрешённый тестовый режим. Не отключайте рабочую интеграцию для воспроизведения ошибки на действующем сайте.

До отправки определите, что означает «обработано». Для вашего проекта это может быть запись в CRM с нужными полями и назначенным ответственным, который видит обращение и может выполнить следующий шаг. Получение письма, создание записи и ответ менеджера — разные результаты. Укажите согласованное время ожидания каждого этапа; универсального срока для всех интеграций нет.

Шаг 2. Подготовьте карточку проверки

Скопируйте таблицу в рабочий документ и заполните ожидаемые результаты до теста. Используйте идентификатор обращения, если система его выдаёт; иначе согласуйте сочетание тестовой метки и времени. Секреты и содержимое реальных клиентских заявок в протокол не включайте.

Для каждой строки оставьте место под фактический результат, состояние и следующий шаг. Состояния: «подтверждено», «ошибка», «ожидает обработки», «не проверено», «не применимо». У последних трёх обязательно должна быть причина. «Ожидает» допустимо, когда известно, что обращение принято и ещё находится в обработке; отсутствие сведений само по себе этого не доказывает.

Шаг 3. Отправьте одно обращение и найдите его

Заполните форму согласованными данными и отправьте её один раз. Запишите время и состояние интерфейса. Не создавайте новые обращения только потому, что запись не появилась мгновенно: сначала дождитесь согласованного срока и попросите технического участника проверить исходное обращение.

Проследите тестовую метку до системы назначения. Сверьте не только контакт, но и описание задачи, выбранную услугу и другие поля, которые должны передаваться по вашему заданию. Если проект предусматривает источник обращения, проверьте его отдельно. Неизвестный источник нельзя автоматически назвать прямым заходом.

Попросите ответственного открыть запись под своей обычной рабочей ролью. Проверка под администратором не доказывает, что менеджер увидит обращение. Выполните согласованный следующий шаг: например, назначьте обработку или установите тестовый статус. Ответ реальному человеку для этого упражнения не нужен.

Если письмо входит в критерий, подтвердите его получение в согласованном ящике отдельно от записи CRM. Если аналитический отчёт ещё не обновился, сохраните состояние «не проверено» и время следующего просмотра. Нулевое число в отчёте, отсутствие доступа и задержка обновления требуют разных записей в протоколе.

Шаг 4. Проверьте ошибку и повтор

После основного сценария выполните согласованные проверки в тестовой среде. Не создавайте искусственную нагрузку и не меняйте рабочие настройки. Если для ошибки нужен специальный стенд, поручите его подготовку техническому участнику.

• Оставьте обязательное поле пустым или введите заведомо неподходящий формат. Убедитесь, что сообщение объясняет проблему и понятно, какое поле исправить. Проверка только в браузере не заменяет серверную проверку данных; это отдельно подтверждает разработчик (MDN о валидации форм).
• В разрешённом сценарии временного отказа проверьте сохранение описания, понятность ошибки и доступность повторной отправки. Сообщения об ошибках и успехе должны помогать человеку понять результат действия (W3C о сообщениях формы).
• При неопределённом ответе проверьте повтор исходного обращения по согласованным правилам. Уточните у технического участника, как система отличает повтор доставки от новой заявки. Два обращения с одинаковым email не обязательно являются дублями: человек мог описать другую задачу.

После повтора найдите исходный тест в системе назначения и зафиксируйте число ожидаемых и фактических записей. Требование об отсутствии дублей должно относиться к одному логическому обращению, а не ко всем заявкам одного контакта. Укажите, какие ошибочные сценарии действительно выполнены, а какие остались непроверенными.

Шаг 5. Разберите учебную ситуацию

Это вымышленный пример, не кейс CoreWeb. В учебном проекте форма показывает подтверждение, технический участник находит принятое обращение, а обработчик сообщает об успешной записи в CRM. Администратор видит тест, но назначенный менеджер не может открыть карточку.

Заполните протокол: интерфейс, приём и запись подтверждены; доступ ответственного — ошибка. Весь сценарий обработки ещё не принят. Причину ограничения прав не нужно угадывать: передайте условия ответственному за CRM, зафиксируйте задачу и договоритесь о повторной проверке под ролью менеджера.

Теперь измените условие: доступа к CRM нет ни у одного участника проверки. В этом случае запись и доступ ответственного имеют состояние «не проверено», а не «ошибка» и не «подтверждено». Следующее действие — получить разрешённое подтверждение от владельца системы. До этого нельзя заключить, что заявка потеряна или доставлена.

Результат урока

Проверьте свой документ: указаны окружение и версия, тестовая метка, ожидаемый получатель, фактические результаты по этапам, доказательство обработки и доступ ответственного. Для каждого открытого вопроса назначены следующий шаг и условие повторной проверки. Тестовые записи отмечены, а способ их исключения из оценки реальных обращений согласован.

Добавьте протокол в пакет приёмки сайта. Если тест не дошёл до обработки, результат упражнения — честно зафиксированный разрыв и задача на его проверку. Считать весь путь подтверждённым можно только после завершения согласованного сценария.