AI в автотестировании: сценарии, инструменты и правила безопасной работы

В QA-процессе AI лучше держать в роли инженерного помощника без полного контекста проекта. Он может предложить сценарии, написать черновик теста, разобрать ошибку, подобрать локатор, составить SQL-запрос или объяснить странный лог. Но он не знает всех внутренних договоренностей, не понимает цену ошибки и не отвечает за релиз.

На практике схема такая:

• человек формулирует задачу и ограничения;
• AI работает с конкретным источником данных;
• человек проверяет результат, правит архитектурные решения и запускает обычные проверки проекта;
• в репозиторий попадает только то, что прошло ревью и пайплайн.

В QA Automation это особенно заметно: «тест проходит» не равно «тест полезен». Сгенерированный тест может проверять не то поведение, дублировать старый сценарий, зависеть от нестабильных данных или ломать структуру фреймворка.

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

Попросите AI:

• выделить позитивные и негативные сценарии;
• найти неоднозначные формулировки;
• собрать вопросы к аналитику или product owner;
• сравнить требования с текущими тест-кейсами;
• подготовить матрицу: условие, действие, ожидаемый результат, источник в документе.

Просите список тестов с привязкой к источнику. Если модель не может показать, откуда взяла вывод, это не факт, а предположение.

Пример рабочего промпта:

Разбери требования в файле `requirements.md`.

Составь таблицу тестовых сценариев:
- условие;
- действие пользователя или системы;
- ожидаемый результат;
- тип сценария: positive, negative, boundary, security;
- ссылка на раздел или цитату из требований.

Отдельно перечисли:
- противоречия;
- неполные формулировки;
- вопросы к аналитику;
- сценарии, которые выглядят важными, но не подтверждены требованиями.

Не придумывай поведение, которого нет в документе.

После такой подготовки ручной тестировщик получает основу для проверок, а автоматизатор — список сценариев, которые можно перевести в автотесты после уточнения требований.

В API-тестах модели лучше отдавать не экран Swagger UI, а OpenAPI-спецификацию. В ней уже описаны методы, параметры, тела запросов, ответы и коды статусов. Если положить api-docs.json в проект и дать существующие примеры тестов, модель соберет черновик нового покрытия по аналогии.

Веб-страницу модель разбирает хуже. Машинно-читаемое описание API для этого и нужно: оно дает инструментам контракт сервиса без лишнего визуального слоя.

На выходе можно получить:

• request- и response-модели;
• методы API-клиента;
• позитивные сценарии;
• негативные сценарии по валидации;
• проверки статус-кодов, заголовков и тела ответа;
• сценарии с валидным, невалидным и отсутствующим токеном;
• черновик тестовых данных.

Что нужно прописать в правилах:

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

Пример промпта для Java-проекта:

В проекте есть API-тесты на Java.
Используются существующие паттерны клиента, моделей и тестов.

Посмотри `api-docs.json` и найди endpoint `POST /orders`.
Сначала покажи план изменений.

Нужно:
- добавить request- и response-модели;
- не использовать JSON в виде строки;
- добавить метод в существующий API-клиент;
- написать позитивный тест;
- написать негативные тесты на обязательные поля и невалидный токен;
- проверять статус-код, заголовки и тело ответа;
- сохранить стиль arrange-act-assert;
- не менять файлы, которые не относятся к этой ручке.

Если данных в спецификации недостаточно, остановись и перечисли вопросы.

В Java-стеке для таких задач часто используют REST Assured для API-проверок и JUnit как тестовый фреймворк. Но инструмент вторичен. AI должен продолжать архитектуру проекта, а не приносить новую структуру ради одной ручки.

Генерация моделей из JSON — небольшая, но частая задача. Если сервис возвращает большой ответ, вручную заводить классы, поля, типы и вложенные структуры долго. Ошибиться в деталях тоже легко. Модель готовит черновик, а инженер проверяет типы и приводит код к правилам проекта.

При этом черновик нужно проверять:

• корректно ли выбраны типы;
• не потерялись ли nullable-поля;
• не перепутаны ли массивы и объекты;
• совпадают ли имена полей с правилами сериализации;
• не созданы ли лишние универсальные Object, где нужен явный тип;
• не сломана ли уже принятая в проекте схема DTO.

Промпт лучше держать коротким:

Сгенерируй Java-модели для этого JSON-ответа.

Правила:
- используй стиль моделей из пакета `...`;
- сохрани имена JSON-полей через аннотации, если в проекте так принято;
- не используй `Object`, если можно вывести конкретный тип;
- отметь поля, по которым есть сомнения;
- не добавляй бизнес-логику в модели.

Это не сложная инженерная работа. Но именно такие задачи незаметно съедают время в автотестах.

В автотестах часто нужно проверить состояние данных после действия в системе: появилась запись, изменился статус, связались сущности, событие ушло в нужный контур. Если инженер редко пишет SQL, даже обычный JOIN может занять больше времени, чем сама проверка.

С AI можно:

• составить SELECT по схеме таблиц;
• объяснить существующий запрос;
• найти связь между сущностями;
• предложить проверку для теста;
• подсказать, почему запрос работает медленно;
• аккуратно переписать запрос без изменения смысла.

Но здесь риск выше, чем в работе с требованиями или JSON. Нельзя дать публичному AI доступ к рабочей базе и попросить «посмотреть, что там». Минимальные ограничения:

• только локальная или тестовая база;
• обезличенные данные;
• отдельный пользователь с правами только на чтение;
• запрет на INSERT, UPDATE, DELETE, TRUNCATE, DROP, ALTER;
• отсутствие секретов и персональных данных в промпте;
• логирование действий, если инструмент ходит в БД сам.

Здесь уместны MCP-серверы с ограниченным набором операций. Model Context Protocol описывает способ подключать AI-приложения к внешним системам: файлам, базам, поиску, инструментам и рабочим процессам. Для QA это удобная граница: модель получает не полный доступ «ко всему», а конкретный инструмент с понятными правами.

Пример безопасной постановки:

Есть тестовая база Postgres.
Доступ только read-only.

Нужно проверить, что после создания заказа:
- в таблице заказов появилась запись;
- статус стал `CREATED`;
- заказ связан с пользователем по `user_id`.

Сначала покажи, какие таблицы и связи ты используешь.
Потом предложи только SELECT-запрос.

Не выполняй и не предлагай операции изменения данных.
Если схемы недостаточно, задай вопросы.

Такой формат снижает риск: модель не «чинит базу», а помогает составить проверку, которую инженер потом использует в тесте.

UI-автотесты часто падают не из-за бизнес-логики, а из-за состояния страницы, нестабильного локатора, задержки, дублирующихся компонентов или изменения верстки. Здесь одного чтения кода мало: модели нужно увидеть страницу.

Через Playwright MCP модель взаимодействует со страницами через Playwright и структурированные accessibility-снимки. Агент может открыть тестовый стенд, найти элемент, посмотреть доступные роли и текст, воспроизвести сценарий и предложить более устойчивый локатор.

В таких задачах модель может:

• воспроизвести падение UI-теста;
• понять, элемент не найден из-за локатора, состояния страницы или ожидания;
• подобрать более стабильный селектор;
• проверить, не дублируется ли компонент;
• предложить явное ожидание вместо случайного sleep;
• обновить Page Object по существующим правилам проекта.

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

Не просите «починить тест». Ограничьте задачу:

Используй Playwright MCP.

Нужно разобраться, почему падает тест `OrderCreationTest.shouldShowCreatedOrder`.
Не меняй код сразу.

Сначала:
- открой страницу;
- воспроизведи сценарий;
- посмотри доступные элементы;
- объясни, почему текущий локатор не срабатывает.

Потом предложи минимальное изменение в Page Object.
Не трогай другие тесты и компоненты.

Если проект на Java и UI-тесты написаны на Selenide, подход тот же: браузерный инструмент помогает понять страницу, а изменения нужно вносить в стиле текущего фреймворка.

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

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

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

Порядок работы простой:

• сначала зафиксировать версию библиотеки в проекте;
• искать ответ в официальной документации или через инструмент, который на нее ссылается;
• просить модель указывать источник и версию;
• проверять предложенный код компиляцией и тестами;
• не обновлять зависимости «заодно», если задача была только в тесте.

AI ускоряет поиск, но не становится источником правды сам по себе.

Один хороший промпт помогает один раз. Постоянные правила работают каждый день.

Если команда регулярно использует AI для автотестов, правила стоит вынести в отдельные файлы: steering rules, skills, project instructions, AGENTS.md, CLAUDE.md, .cursor/rules или другой механизм, который поддерживает ваш инструмент. В Kiro, например, есть спецификации для больших задач, hooks и steering files. В таких файлах удобно хранить проектные договоренности, чтобы не повторять их в каждом запросе.

Для QA Automation в таких правилах стоит описать:

• структуру пакетов;
• формат Page Object;
• подход к API-клиентам;
• правило arrange-act-assert;
• как создавать тестовые данные;
• как работать с токенами и ролями;
• какие проверки обязательны для API-ответа;
• где лежат моки и как их обновлять;
• какие файлы нельзя менять без отдельного согласования;
• какие операции запрещены для базы данных;
• как именовать тесты и методы.

Пример фрагмента правил:

Правила для API-тестов:

- каждый тест должен явно разделять arrange, act и assert;
- request/response описываются моделями, сырой JSON строками запрещен;
- API-клиент возвращает промежуточный ответ, чтобы тест мог проверить status code, headers и body;
- авторизация параметризуется: valid token, invalid token, missing token;
- негативные сценарии не должны зависеть от порядка выполнения тестов;
- новые helper-классы добавляются только если есть минимум два места использования;
- перед изменением общей инфраструктуры сначала покажи план.

Так модель подстраивается под конкретный проект, а не пишет «как обычно делают в интернете».

Тесты, написанные с помощью AI, не требуют отдельного пайплайна. Их нужно прогонять теми же проверками, что и обычный код:

• форматирование;
• статический анализ;
• сборка;
• unit-тесты;
• API- и UI-тесты;
• проверка моков;
• ревью человеком.

AI можно добавить как рекомендательную проверку: попросить его отметить рискованные места в merge request, найти дублирование, проверить соответствие внутренним правилам. На старте такая проверка должна советовать, а не блокировать релиз.

Полностью автоматизировать code review и merge опасно. Модель может видеть только diff, не знать исторический контекст проекта и предложить решение, которое красиво выглядит в одном файле, но ухудшает поддержку системы. Право остановить или принять изменение должно оставаться у команды.

Если в проекте есть внешние зависимости, платежные сервисы, уведомления или сторонние API, их обычно изолируют через моки. Для HTTP-зависимостей в Java-проектах часто используют WireMock. AI может помочь написать заготовку стаба, но контракт и критичные сценарии нужно сверять с реальной интеграцией.

Есть задачи, где возможная экономия времени не перекрывает риск.

Не стоит отдавать AI:

• production-доступы;
• секреты, токены, SSH-ключи и пароли;
• сырые пользовательские данные;
• дампы рабочей базы;
• право изменять данные без отдельного подтверждения;
• право самостоятельно мержить код;
• финальное решение по архитектуре тестового фреймворка;
• проверку требований без доступа к людям, которые знают предметную область.

Отдельная проблема — старые файлы и легаси-договоренности. Модель может найти в репозитории устаревший пример и начать копировать его как актуальный. Поэтому в правилах нужно прямо указывать, какие директории являются источником правды, какие файлы deprecated и какие решения больше не используются.

Начинать лучше не с большого «внедрим AI во все тестирование», а с одного узкого сценария. Например: генерация API-тестов по OpenAPI, разбор требований или помощь с flaky UI-тестами.

Рабочий план:

• Выбрать один повторяемый сценарий, где команда тратит много времени.
• Подготовить источники: спецификацию, примеры тестов, правила проекта, тестовые данные.
• Описать ограничения: какие файлы можно менять, какие операции запрещены, какие проверки обязательны.
• Настроить доступы: локальная среда, read-only база, отдельная папка, безопасные MCP-инструменты.
• Попросить AI сначала писать план, а не сразу менять код.
• Проверять результат обычными инженерными способами: ревью, запуск тестов, линтеры, пайплайн.
• Сравнивать эффект по наблюдаемым метрикам: время на задачу, число правок на ревью, количество flaky-падений, покрытие критичных API.

Так команда увидит, где AI экономит время, а где только добавляет работу на проверку.

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

Качественные автотесты появляются не из одного удачного промпта. Нужны архитектура, правила проекта, безопасные доступы, человеческое ревью и дисциплина проверки. Тогда AI работает как управляемый инструмент в QA-процессе.