Проверять надо поведение, не только надписи
Форма может красиво показать «сообщение отправлено», хотя сервер вернул ошибку и запись не создана. Поэтому перед генерацией тестов опишите ожидаемый путь: какие поля обязательны, что происходит после отправки, где появляется номер обращения и может ли пользователь безопасно повторить действие. Возьмите тестовый стенд, а не рабочий сайт с настоящими клиентами. Если доступа к серверным журналам нет, попросите ответственного сотрудника подтвердить созданную запись. Без этого тест проверит только экран, а не доставку сообщения.
Сделайте таблицу допустимого ввода
Для каждого поля запишите минимальную и максимальную длину, тип данных и то, что должно произойти при нарушении. Например, пустая тема, email с пробелом, сообщение на границе лимита и текст длиннее лимита. Не придумывайте ограничение в 500 символов, если продукт его не определил. Нейросеть попросите предложить случаи исходя из вашей таблицы и пометить те, где правило не задано. Неустановленное правило — вопрос команде, а не повод модели решить за неё. Для CSV-импорта аналогичную дисциплину показывает проверка пустых и кривых строк.
Проверьте крайние значения и странные символы
Сначала выполните обычную отправку с валидными полями. Потом пробуйте пустое сообщение, строку из одного символа, точно предельную длину, один символ сверх предела, переносы строк, кириллицу, эмодзи и кавычки. Важный тест — вставка большого текста из буфера: счётчик символов может отличаться от того, что принимает сервер. Для email проверяйте не только наличие знака @, но и то, что система не обрезает адрес. При этом не превращайте тест в попытку перечислить все мыслимые адреса мира. Нужны случаи, которые покрывают реальные правила вашей формы.
Повторная отправка и медленная сеть
Откройте форму на телефоне или в режиме ограниченной сети, нажмите «отправить» и сразу повторите нажатие. Посмотрите, появилось ли одно обращение или два, сохранился ли текст при ошибке и понятен ли статус пользователю. Если соединение разорвалось после передачи данных, интерфейс не должен уверенно утверждать, что ничего не дошло. Проверка должна учитывать идентификатор запроса или иной способ выяснить результат. Не обещайте идеальную защиту от дублей, пока не проверили серверную сторону. Тест на быстрые двойные клики часто находит баг, который не виден в статическом макете.
Безопасность и приватность
Не вводите в тестовую форму реальные телефоны, адреса, пароли и жалобы клиентов. Используйте вымышленные данные и проверьте, не попадают ли они в URL, аналитические события и общедоступные логи. Сообщение с HTML-тегами и специальными символами должно отображаться как текст, а не менять страницу. Это не полноценный аудит безопасности, но простой тест защищает от очевидных проблем. При наличии файлового поля отдельно согласуйте типы, размер и обработку опасных вложений. Нейросеть может составить чек-лист, но не заменяет испытаний в браузере и проверки серверного кода.
Проверка доступности одновременно с валидацией
Ошибка формы — не только неверно принятый email. Пользователь клавиатуры должен дойти до каждого поля, понять сообщение об ошибке и вернуться к исправлению. Проверьте порядок фокуса, видимый курсор и связку подписи с полем. На телефоне посмотрите, не закрывает ли виртуальная клавиатура кнопку отправки и текст ошибки. Модель может предложить такой чек-лист, но сама текстовая генерация не заменяет реальное прохождение формы человеком. Для важных сервисов привлеките пользователя вспомогательных технологий к проверке доступности.
Набор после исправления
Когда дефект устранён, повторите не только один проблемный ввод, но и соседние случаи. Исправление длинного сообщения может сломать переносы строк; новая валидация email — отклонить корректный адрес; защита от двойного клика — заблокировать повтор после сетевой ошибки. Сохраните десять–пятнадцать базовых сценариев в репозитории с понятными ожидаемыми результатами. При следующем изменении формы прогоните их на тестовом стенде и сравните запись на сервере с экраном. ИИ помогает обновить список, но решение о выпуске продукта принимает команда после фактического прогона.
Критерий завершения проверки
Согласуйте заранее, кто принимает результат теста. Если экран показывает успех, а запись не создана, выпуск блокируется. Если сообщение об ошибке непонятно, задача возвращается дизайнеру и разработчику. Чёткое правило завершения не даёт спрятать важный дефект в длинной таблице зелёных отметок.
Как фиксировать результат
Для каждого теста храните ввод, ожидаемое поведение, фактический результат, браузер и снимок экрана при ошибке. Не записывайте только «прошёл/не прошёл»: без примера сбой трудно повторить. Попросите модель помочь превратить найденные ошибки в понятные задачи разработчику, но сверяйте формулировку с собственным наблюдением. После исправления повторите минимальный регрессионный набор на форме целиком. Важный критерий — не число сгенерированных тестов, а то, что ни одно обращение не теряется молча.
FAQ
Можно ли полностью поручить проверку ИИ-агенту? Агент может ускорить прогоны, но доступ к рабочим данным и отправкам следует ограничить, а результаты подтвердить вручную. Нужен ли снимок каждого успешного случая? Обычно достаточно журнала и версии стенда; снимки важнее для дефектов. Что делать, если правила формы не написаны? Сначала согласуйте их с владельцем продукта. Тест не может доказать корректность требования, которого никто не определил. Итог — небольшая воспроизводимая матрица, а не длинный список случайных подсказок.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.