Готова ли форма к рекламе? Проверяем с ИИ
Автор: MashaGPT • 20 октября 2026 • Нейросети
До запуска рекламы форму нужно пройти до получателя заявки. Зелёное сообщение на сайте ещё не объясняет, получил ли менеджер контакт и что посчитала аналитика. ИИ поможет составить сценарии и разобрать протокол, а маркетолог и разработчик проверят их в браузере и CRM. На выходе нужен список подтверждений и блокирующих дефектов, по которому можно принять решение о старте.
Где и как проводить проверку
Начните с рекламной посадочной страницы, её параметров и каждой формы, куда ведут кнопки. Запишите версию страницы, устройство, браузер, обязательные поля, допустимые страны контактов и получателя. Договоритесь, что означает «принято»: сохранение на сервере, постановка в очередь или появление обращения у менеджера. Для очереди задайте свой срок доставки и ответственного за зависшие заявки. Универсального срока здесь нет.
Неверный ввод, повторы и обрывы связи проверяйте на staging, тестовой копии сайта с изолированными интеграциями. Отключите реальные рассылки, звонки и создание задач продавцам; используйте контролируемые контакты и метку TEST-FORM-LAUNCH. Заранее назначьте очистку тестовых записей и исключение тестов из рабочих отчётов. Одна метка сама ничего не исключает.
Поручите ИИ составить сценарии
Дайте нейросети описание полей, тексты подсказок, правила бизнеса и обезличенные снимки состояний. По картинке она может заметить исчезающую подпись, но не подтвердит серверную проверку или доставку в CRM. В плане сразу разделите наблюдаемое в интерфейсе и то, для чего разработчик должен предоставить подтверждение.
Начните с правильного и ошибочного ввода
Сначала отправьте допустимый набор: так появится образец нормального прохождения. Затем меняйте одно условие за раз. Иначе при нескольких ошибках будет трудно понять, что именно остановило отправку. Для каждой попытки фиксируйте ожидаемый результат до нажатия кнопки.
| Учебный тест | Что принять |
|---|---|
| Все обязательные поля заполнены допустимо | Одна заявка доходит получателю с неизменёнными значимыми данными. |
| Пустое обязательное поле; отдельно только пробелы | Понятная ошибка у нужного поля, без ложного успеха и принятой заявки. |
| Пустой необязательный комментарий | Отправка разрешена; скрытой обязательности нет. |
| Имя Анна-Мария; отдельно O'Neil | Результат соответствует согласованным правилам имён, без произвольного удаления символов. |
| Комментарий на предельной длине и на символ длиннее | Граница работает по спецификации; превышение объяснено, молчаливого обрезания нет. |
| Исправление одного ошибочного поля | Остальной ввод сохранён, исправленное поле можно отправить повторно. |
Проверка в браузере помогает посетителю, но её можно обойти. Разработчик отдельно подтверждает на тестовом обработчике, что сервер отклоняет запрещённые значения и размеры. Успех ручного заполнения не заменяет эту проверку и не является аудитом безопасности. Для текста согласуйте допустимые символы и длину, а не запрет всех необычных знаков.
Не сужайте контакты до одной страны
Если реклама обращена к нескольким странам, проверьте контролируемые международные номера каждой нужной страны: с плюсом, пробелами, скобками, вставкой из буфера. Маска только под российский номер может отсечь допустимый контакт. Поле tel само по себе не задаёт всемирную проверку телефона: правила и нормализацию нужно согласовать. Нельзя молча подставлять один код страны или терять цифры при редактировании. Затем введите заведомо недопустимый по спецификации номер, например слишком короткий: ошибка должна объяснять исправление.
Для email разделите формат и возможность связаться. Учебный qa+launch@example.com подходит для обсуждения синтаксиса, но не для проверки получения письма. Отдельно попробуйте адрес без @ и пробел внутри адреса. Принятый формат не доказывает существование ящика и доступ пользователя к нему. Доставку проверяют на контролируемом ящике; необходимость подтверждения адреса определяется задачей.
Описание полей и географии можно разобрать в чате MashaGPT: попросите дополнить ваш план проверки недостающими вариантами ввода. Затем оставьте те случаи, которые соответствуют реальным правилам обслуживания.
Пройдите форму разными способами
На реальном телефоне откройте страницу и заполните её с экранной клавиатурой. Для телефона проверьте удобство ввода плюса, для почты доступность @, затем вставку и автозаполнение. Тип поля может подсказать подходящую клавиатуру, но итог зависит от устройства. Убедитесь, что клавиатура и закреплённая панель не перекрывают ошибку и отправку, а увеличение текста не обрезает подписи.
- Без мыши: пройдите поля клавишами Tab и Shift+Tab, найдите видимый фокус, исправьте ошибку и отправьте форму с клавиатуры.
- Со скринридером: проверьте название поля, обязательность, связь с подсказкой и ошибкой. Исчезающая подсказка внутри поля не заменяет подпись.
- После отправки: найдите первое ошибочное поле или сводку ошибок; проверьте, что сообщение об ожидании и результате доступно скринридеру. Для динамического статуса не обязательно переносить фокус.
Надпись «Ошибка» без способа исправления оставляет человека в тупике. Для неверного email полезнее «Проверьте адрес: нужен символ @». Красная рамка без текста также не объясняет проблему.
Разберите кнопку и повторную отправку
Если кнопка недоступна до заполнения, причина должна быть понятна рядом с формой. У нативной disabled-кнопки нет обычного клавиатурного фокуса, поэтому подсказка только при наведении не решает проблему. Проверьте, что после исправления кнопка становится доступной. Во время отправки должно быть заметно ожидание, а после согласованного тайм-аута нужен понятный способ выяснить результат и продолжить.
На тестовой копии проверьте двойное нажатие и нажатие Enter вслед за кликом. С разработчиком отдельно воспроизведите повтор запроса. Блокировка кнопки уменьшает случайные повторы, но не обеспечивает серверную защиту. Попросите разработчика подтвердить идемпотентность: повтор одной операции с тем же идентификатором не создаёт новую заявку. Проверяйте итог в CRM, включая повторную доставку из очереди.
Срок действия идентификатора и поведение после изменения данных согласует разработчик. Объединять любые обращения по телефону опасно: один человек может отправить две самостоятельные заявки. В этой проверке дублем считается повтор одной операции; похожие контакты сами по себе не повод объединять записи.
Оборвите связь на разных шагах
- После загрузки формы отключите сеть до отправки. Проверьте отсутствие ложного успеха, сохранность ввода и понятный выход из ожидания. Верните сеть и пройдите согласованное восстановление.
- С разработчиком задержите ответ после принятия тестовой заявки сервером. Дождитесь тайм-аута в браузере, затем сверьте идентификатор с сервером и CRM. Так воспроизводится неизвестный для посетителя исход.
- Загрузите страницу заново с блокировщиком рекламы. Проверьте открытие формы, заполнение и доставку, затем повторите с заблокированным счётчиком. Различайте блокировку аналитики и поломку самой формы.
Блокировщики могут мешать счётчику. Это допустимая причина отсутствия аналитического события в таком сценарии, но получение заявки не должно зависеть от callback аналитики. Не обещайте автоматическую отправку после восстановления сети, если отдельный механизм очереди не предусмотрен и не проверен.
Сравните экран, CRM и аналитику
Для каждой тестовой операции сопоставьте три независимых наблюдения. Интерфейс показал определённый статус. CRM получила запись с нужными полями и ответственным. Аналитика зарегистрировала событие выбранного смысла. Совпадение времени помогает поиску, но для проверки доставки надёжнее использовать согласованный тестовый идентификатор.
| Наблюдение | Что оно подтверждает |
|---|---|
| На странице показано «Спасибо» | Только состояние интерфейса; источник этого состояния ещё нужно проверить. |
| Есть запись в CRM | Получение обращения в CRM; отдельно сверьте контакт, услугу и маршрут менеджеру. |
| Зарегистрирована цель Метрики | Выполнено настроенное условие события; оно само не проверяет CRM. |
reachGoal передаёт в Метрику информацию о целевом событии. Если цель названа «принятая заявка», привязывайте её к подтверждённому принятию по вашему договорённому критерию, а не к первому клику. Проверьте нужный счётчик и идентификатор, ошибочный ввод, двойное нажатие и повторное открытие успеха. Сверьте вызовы и доступные диагностические данные: итоговая цифра отчёта не заменяет проверку логики отправки.
Если CRM получает заявки через очередь, экран может честно сообщать о приёме в обработку, а не о получении менеджером. Исчезновение цели при заблокированном счётчике фиксируйте отдельно от доставки. Телефон, email и текст обращения не передавайте в параметры цели.
Согласие проверьте отдельно
По утверждённой спецификации проверьте начальное состояние согласий, доступность текста и ссылок, отметку с клавиатуры и реакцию на отказ. Если согласие обязательно для выбранного сценария, его отсутствие должно обрабатываться и сервером. Отправка без необязательной рекламной подписки проверяется отдельно, если такая подписка есть.
Передайте воспроизводимый дефект
Пишите разработчику, что сделали и что увидели. Предположение о причине держите отдельно. Достаточно тестовой метки, версии страницы, устройства, последовательности действий и обезличенного подтверждения. Реальные клиентские контакты для такого сообщения не нужны.
Решите вопрос запуска по сценариям
В интерактивном листе десять сценариев: шесть критических и четыре рекомендованных. Для каждого выберите «Не проверено», «Пройдено», «Есть ошибка» или «Не применимо». Начальное состояние всех строк - «Не проверено». Основание отметки сохраняйте в своём протоколе: версия формы, шаги, наблюдение и подтверждение результата.
| Сценарий инструмента | Основание для «Пройдено» |
|---|---|
| Критический. Получение заявки | Допустимая заявка появилась у ответственного сотрудника; поля и маршрут проверены. |
| Критический. Серверная проверка | Сервер отклоняет недопустимые данные; при исправлении заполненное не теряется. |
| Критический. Двойная отправка | Двойное нажатие и повтор одной операции не создают две заявки. |
| Критический. Тайм-аут | После обрыва можно выяснить судьбу первой отправки и безопасно продолжить. |
| Критический. Мобильная форма | На телефоне видны поля, ошибки и отправка, в том числе с открытой клавиатурой. |
| Критический. Согласия и юридическая проверка | Работа согласий проверена технически, тексты и основания согласованы с ответственным специалистом. |
| Рекомендованный. Клавиатура и подписи | Поля имеют понятные подписи; форму можно заполнить и отправить без мыши. |
| Рекомендованный. Сообщения об ошибках | Ошибка объясняет исправление и доступна скринридеру. |
| Рекомендованный. Аналитика | Цель соответствует выбранному событию; проверены счётчик, идентификатор и вызовы. |
| Рекомендованный. Блокировщик | Форма работает с блокировщиком и без аналитики; получение заявки подтверждено отдельно. |
Критический сценарий завершён в инструменте только со статусом «Пройдено». «Есть ошибка», «Не проверено» и «Не применимо» оставляют его открытым. Исключение критической проверки требует отдельного согласования ответственного и записи причины в протоколе; выбор «Не применимо» сам по себе блокировку не снимает. Отсутствие доступа к CRM не означает, что получение заявки проверять незачем.
Заголовок «Критические проверки пройдены» относится только к шести критическим строкам. Он может появиться, даже если рекомендованные сценарии ещё не проверены: смотрите число «Всего не проверено». Если все шесть пройдены, но в рекомендованной строке есть ошибка, заголовок дополнится словами «есть замечания». Их критичность автоматически не меняется. Команда может считать ошибку доступности или аналитики препятствием к своему запуску: такое решение фиксируют отдельно, независимо от заголовка сводки.
Каждая строка объединяет несколько проверок из статьи. Контакты, границы длины, необязательные поля и недоступную кнопку продолжайте проверять по подробному протоколу. Отдельно подтвердите разрешённый контроль боевой версии и изоляцию тестовых записей. Эти действия не становятся выполненными от выбора статуса в листе. После изменения формы вручную верните затронутые сценарии в «Не проверено» и повторите их.
Инструмент обрабатывает выбранные статусы в браузере по фиксированным правилам, без вызовов ИИ. Здесь нет поля адреса сайта и автоматического сканирования страниц. Скопируйте итоговый отчёт и приложите подтверждения из своего протокола; решение о запуске принимает ответственный.
