Тестирование контактной формы: чек-лист перед запуском

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

1. Основной сценарий - с реального сайта

Отправьте настоящий тестовый запрос с развёрнутого production-URL, а не с localhost. Только этот тест проверяет то, что нельзя проверить локально: DNS, TLS и, прежде всего, CORS - если ваш бэкенд форм использует allowlist источников (а он должен), только в продакшене вы обнаружите, что домена в нём нет. Протестируйте и www, и корневой домен, если обслуживаете оба.

Проверьте все три звена: состояние успеха отображается в браузере, отправка появляется в дашборде, а уведомление (push или e-mail) действительно приходит на устройство, которое вы реально будете носить с собой.

2. Валидация - попробуйте её сломать

• Отправьте форму пустой. Каждое поле required должно выдавать предупреждение в нужном месте, на языке, соответствующем сайту (сербский сайт с англоязычными сообщениями браузера по умолчанию - классический промах; настройте собственные сообщения, если это важно).
• Отправьте not-an-email в поле e-mail.
• Вставьте по-настоящему длинное сообщение - 5000 символов - и убедитесь, что оно принимается или корректно отклоняется с чёткой границей, а не тихо обрезается.
• Если есть поле для файла: правильный тип, неправильный тип и слишком большой файл. Слишком большой файл должен отклоняться с сообщением, в идеале ещё до завершения медленной загрузки.

3. Путь отказа - тест, который все пропускают

Временно направьте форму на бессмысленный эндпоинт (или заблокируйте запрос в devtools) и отправьте её. Что видит посетитель? Неприемлемый ответ - «ничего»: кнопка, которая ничего не делает, или бесконечный спиннер. Должно быть состояние ошибки с запасным вариантом («или напишите нам на …»). Именно это состояние встречают ваши реальные пользователи во время сбоя или неудачного деплоя, и именно это отличает потерянного лида от спасённого. Проверьте ответы об ошибках вашего бэкенда, чтобы обработка соответствовала тому, что он на самом деле возвращает.

4. Защита от спама - убедитесь, что она включена, но не слишком

• Honeypot: заполните скрытое поле через devtools и отправьте - оно должно быть молча проглочено, никогда не появляясь в дашборде.
• Ограничение частоты: отправьте форму несколько раз подряд быстро; убедитесь, что троттлинг срабатывает и что лимит достаточно щедрый для легитимной ситуации «исправил и отправил заново».
• Turnstile (если включён): протестируйте в обычном окне и в приватном; убедитесь, что путь отказа токена показывает понятное человеку сообщение.

(Как работает каждый слой: защита от спама для форм обратной связи.)

5. Мобильные устройства, клавиатура и остальная негламурная рутина

• Полная отправка с реального телефона: правильные клавиатуры (type="email" вызывает клавиатуру с @), удобная для нажатия кнопка, видимое состояние успеха без прокрутки в поисках его.
• Проход только с клавиатуры: разумный порядок Tab, Enter отправляет форму, состояния фокуса видимы - и Tab должен пропускать honeypot (если попадает на него, добавьте tabindex="-1").
• Автозаполнение: дайте браузеру заполнить форму; убедитесь, что поля сопоставляются осмысленно.
• Редирект на страницу благодарности, если он есть, срабатывает и не блокируется валидацией редиректов бэкенда.

6. Оставьте канарейку

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

Общее время: около пятнадцати минут при запуске, тридцать секунд в месяц после. Самая дешёвая страховка в веб-разработке.