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

Статья подготовлена по мотивам вебинара Spectr «Искусственный интеллект в автотестировании: опыт QA Automation Tech Lead». Вебинар провёл Олег Казаков, технический директор Spectr, в формате живого разговора с приглашённым гостем — Олегом Пендрак, Tech Lead QA Automation в СберЗдоровье и лидером сообщества ThreadQA. Олег Пендрак делился практикой: как AI помогает работать с документацией, писать API-тесты, чинить локаторы, разбирать JSON, составлять SQL-запросы и искать причины падений.

• Запись вебинара Spectr — смотреть на ThreadQA
• Оригинал статьи на сайте Spectr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В автотестах часто нужно проверить состояние данных после действия в системе: появилась запись, изменился статус, связались сущности, событие ушло в нужный контур. С 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 модель взаимодействует со страницами через структурированные accessibility-снимки. Агент может открыть тестовый стенд, найти элемент, посмотреть доступные роли и текст, воспроизвести сценарий и предложить более устойчивый локатор.

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

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

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

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

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

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

• ▸Зафиксировать версию библиотеки в проекте
• ▸Искать ответ в официальной документации или через инструмент, который на неё ссылается
• ▸Просить модель указывать источник и версию
• ▸Проверять предложенный код компиляцией и тестами
• ▸Не обновлять зависимости «заодно», если задача была только в тесте

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

Для 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, не знать исторический контекст проекта и предложить решение, которое красиво выглядит в одном файле, но ухудшает поддержку системы. Право остановить или принять изменение должно оставаться у команды.

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

• ▸Production-доступы
• ▸Секреты, токены, SSH-ключи и пароли
• ▸Сырые пользовательские данные
• ▸Дампы рабочей базы
• ▸Право изменять данные без отдельного подтверждения
• ▸Право самостоятельно мержить код
• ▸Финальное решение по архитектуре тестового фреймворка
• ▸Проверку требований без доступа к людям, которые знают предметную область

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

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

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

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

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

• Оригинал статьи: «AI в автотестировании: сценарии, инструменты и правила безопасной работы» — digital-spectr.ru
• Вебинар Spectr «Искусственный интеллект в автотестировании: опыт QA Automation Tech Lead» — запись на ThreadQA

На курсах ThreadQA по Java и Python QA Automation мы учим работать с современными инструментами, включая AI-ассистентов для написания тестов. Актуальный стек 2026, практика на реальных проектах, поддержка ментора. Первые уроки бесплатно.