Нейросети для тестировщика: автотесты и чек-листы

Нейросети для тестировщика закрывают две трудоёмкие части работы: перебор сценариев при тест-дизайне и написание кода автотестов. По требованиям модель за минуты составляет чек-лист с граничными значениями и негативными сценариями, а агент в терминале пишет тесты на Playwright или pytest, запускает их и чинит, пока они не пройдут. Именно здесь и прячется главная ловушка: тест, который проходит, ещё не значит тест, который что-то проверяет.

В статье — рабочий процесс тестировщика с нейросетью: от требований до отчёта о дефекте, с промптами и правилами, которые не дают модели создавать видимость покрытия. Отдельный раздел — о том, как тестировать функции продукта, которые сами построены на языковых моделях. Готовые инструкции для агентов — юнит-тесты, e2e, разработка через тесты, ревью кода — собраны на полке скиллов для тестировщика.

Где нейросеть помогает тестировщику

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

Инструменты те же, что у разработчиков: чат с сильной моделью для тест-дизайна, агент в терминале или редакторе — Claude Code, Codex CLI, агент Cursor — для автотестов. Для браузерных тестов полезен MCP-сервер Playwright: агент открывает страницу, кликает, смотрит на результат и по этому пишет тест. Как подключать такие серверы, разобрано в гайде MCP: как подключить сервисы к ассистенту.

Тест-дизайн: чек-листы и тест-кейсы из требований

Классические техники тест-дизайна — классы эквивалентности, граничные значения, таблицы решений, переходы состояний, попарное тестирование — модель знает и применяет по просьбе. Если назвать технику явно, результат получается систематическим, а не случайным набором проверок. Без этого модель выдаёт «проверить, что форма отправляется» и «проверить пустое поле» — полезно, но мало.

Последняя пометка — самая ценная часть результата. Когда модель систематически перебирает комбинации, она натыкается на случаи, которые требования не описывают: что происходит при возрасте ровно 18, если граница записана как «старше 18»; можно ли зарегистрироваться без подтверждения почты, если согласие отмечено. Эти вопросы стоит отправить продакту до начала разработки — дешевле исправить требование, чем баг. Как нейросеть помогает писать сами требования, разобрано в гайде нейросети для продакт-менеджера.

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

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

Последний шаг тест-дизайна — перенос в систему управления тестированием. Модель переводит чек-лист в формат импорта вашей системы — CSV или XML с полями шагов, ожидаемых результатов, приоритета и ссылок на требования — и связывает каждую проверку с пунктом требований. Благодаря этой связи потом видно, какие требования не покрыты ни одной проверкой, а при изменении требования — какие тест-кейсы нужно пересмотреть. Формат импорта дайте модели образцом из 2–3 уже существующих кейсов, иначе она придумает свой.

Автотесты: как получать тесты, которые что-то проверяют

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

Качество тестов сильно зависит от образца. Покажите агенту 2–3 существующих теста проекта с вашими фикстурами, пейдж-обджектами и соглашениями — и новые будут в том же стиле. Правила — запрет на жёсткие паузы, запрет менять ожидаемые значения без согласования, обязательная проверка результата действия, а не только отсутствия ошибки — запишите в файл памяти проекта, который агент читает в начале каждой сессии.

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

Баг-репорты, логи и нестабильные тесты

Из сырых заметок, скриншотов и фрагмента лога модель собирает баг-репорт в формате команды: заголовок по шаблону «где — что — при каком условии», шаги воспроизведения, ожидаемый и фактический результат, окружение, серьёзность. Контролируйте шаги: если в заметках их было 4, а в отчёте стало 6, модель достроила недостающее, и разработчик пойдёт воспроизводить то, чего вы не делали.

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

Нестабильные тесты — отдельная боль автоматизации. Дайте агенту историю запусков за 2–4 недели и попросите сгруппировать падения по причинам: таймауты, гонки при параллельном запуске, зависимость от порядка тестов, внешние сервисы, тестовые данные. Опасный ответ модели на нестабильность — увеличить таймаут или добавить повторный запуск. Иногда это правильно, но чаще маскирует реальную гонку в продукте, которую потом найдут пользователи.

Тестовые данные без персональных данных

Модель генерирует тестовые данные по схеме: клиенты, заказы, адреса, платежи с нужными распределениями и крайними случаями. Это прямой способ избежать использования копий боевой базы. Копия продакшн-базы в тестовом окружении — частая причина утечек: к тесту доступ шире, защита слабее, а персональные данные там настоящие. С 30 мая 2025 года утечка данных о 1000 и более людях обходится организации в штраф от 3 до 5 млн ₽, а повторная — в оборотный штраф.

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

Как тестировать ИИ-функции продукта

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

Критерии бывают трёх видов. Проверяемые кодом: ответ в нужном формате, укладывается в длину, содержит ссылку на источник, не содержит запрещённых слов. Проверяемые другой моделью: ответ опирается на предоставленный документ, не противоречит ему, вежлив. И проверяемые человеком на выборке — для того, что трудно формализовать. Запуск одного входа несколько раз показывает, насколько стабилен ответ: если из 10 запусков 3 неверны, функция не готова.

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

Автор: Артём Беспалов, маркетинговое ИИ-агентство «Термос Беспалова», Калининград.

Источники: Playwright, рекомендации по написанию тестов · КонсультантПлюс о штрафах за утечки с 30.05.2025 (проверено 25.09.2026).