Привет, Хабр. Меня зовут Егор, я QA Fullstack Java в SENSE на проекте российского банка.

Год назад я был уверен, что ИИ-агент в QA — это либо маркетинг, либо повод искать новую профессию. Сегодня он у меня в проекте разбирает упавшие тесты, актуализирует локаторы и пишет шаблонные кейсы по спецификациям. Расскажу, как мы прошли путь от «он не справляется с добавлением поля в класс» до 1600 рабочих тестов за сутки на хакатоне. А еще расскажу, что в итоге агент так и не научился делать.

Первые шаги и первые разочарования

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

Ключевые требования к агенту были такие:

• соответствие строгим требованиям безопасности энтерпрайз-разработки;

• способность изучать проект и обучаться на его основе;

• разумное потребление ресурсов (серверы у нас не резиновые особенно РОСА).

Первые версии разочаровали. Агент не справлялся с элементарным. Например, не мог корректно добавить поле в класс. На этом этапе мой скепсис только укрепился: я не верил, что инструмент может оказаться полезным хоть для чего-то. 

Поворотный момент: работа «коллективным разумом»

Разработчики понимали, что они не погружены во все нюансы «QA-кухни». Поэтому нам, тестировщикам из фокус-группы, дали возможность самим настраивать агент: добавлять промты, корректировать существующие, подгружать документацию.

В следующие месяцы мы постепенно «обучали» агента, загружая релевантную для наших повседневных задач документацию:

• по Selenium (автоматизация веб‑тестов);

• по PlaywrightCLI для анализа DOM-дерева;

• документацию по  Gradle (да, да, у нас GRADLE);

• внутренние гайды и стандарты тестирования, принятые в банке.

Параллельно дописывали функционал: агент стал подключаться к проекту через консоль и анализировать код напрямую — то есть наконец увидел реальную структуру, а не работал в отрыве от контекста. 

Готовый промпт по анализу Allure отчётов оставил здесь. Надеюсь, будет полезно.

Тут вылезла новая проблема — нехватка ресурсов. Агент тормозил, терял соединение с сервером и кричал нам: «Эй, ребята, мне нужно больше памяти, или я сейчас усну!».

Команда уменьшила размер контекста, ограничила глубину анализа и добавила кэширование промежуточных результатов. После этого агент перестал «засыпать» и начал отвечать стабильно.

Первый успех: хакатон по вайб-кодингу

Перелом случился на хакатоне по вайб-кодингу в апреле 2026 года. За сутки нужно было с нуля собрать полноценное клиент-серверное приложение и добиться покрытия кода тестами не менее 80%.

Агент работал в режиме нон-стоп и по мере появления кода:

• анализировал коммиты и сразу строил тестовые сценарии;

• писал готовые юнит-тесты (JUnit), интеграционные проверки и тесты API, которые сразу можно было добавить в пайплайн;

• мониторил покрытие кода (с использованием JaCoCo для Java) и показывал непокрытые участки;

• запускал тесты локально и сразу отдавал отчёт где упал тест или покрытие было недостаточным;

• отлаживал упавшие тесты и актуализировал существующие под изменённую логику.

В итоге, за 24 часа мы получили:

• полноценное приложение с фронтендом, бэкенд и API;

• около 1600 тестов, включая модульные тесты для бэкенда (JUnit/TestNG), UI-тесты для фронтенда (Selenium), интеграционные сценарии (проверка взаимодействия микросервисов);

• покрытие кода более 85% и перевыполненный план.

Тогда я впервые подумал: «А может не все так плохо с ИИ-агентами?» Особенно, когда все написанные им тесты успешно выполнялись. 

Внедрение в боевой проект автотестов

Хакатон — это зелёное поле. С существующим проектом автотестов, который развивается несколько лет, всё сложнее. Я начал погружать агента постепенно. Этапы внедрения:

Разбор упавших тестов. Агент анализировал логи и предлагал правки, например, корректировал устаревшие локаторы в Selenide.

Генерация тестов по спецификациям. Я давал агенту спеку новой функциональности, а он описывал тест‑кейсы в формате Gherkin (для Cucumber) или готовил структуру для JUnit.

Анализ отчётов. Агент разбирал Allure-отчёты, находил повторяющиеся паттерны падений и предлагал решения — например, добавлял retry-логику для нестабильных тестов.

Архитектурные задачи. Я попробовал дать более сложные задачи:

• настроить Retry и Rerun для падающих тестов в Cucumber;

• оптимизировать запросы Hibernate, настроить ленивую загрузку и кэширование.

Здесь агент показал свои ограничения — с подобными задачами он не справился. До тестировщика уровня senior агенту пока далеко.

Что в итоге

Плюсы

Агент уверенно закрывает рутину. Есть три категории задач, на которых он реально окупается:

• Написание шаблонных тест-кейсов. Неважно, тестируете вы монолитную систему или крошечный микросервис, — он одинаково бодро генерирует базовые сценарии.

• Актуализация тестов при изменениях в UI (например, обновление Page Object Model). Работает не только для интегрированных систем, но и для небольших веб-приложений, мобильных клиентов или даже десктопных утилит. Для использования нужна утилита PlaywrightCLI.

• Анализ результатов прогона (сбор метрик, генерация отчётов). 10 тестов у вас или 10 000 — обработает всё с одинаковой невозмутимостью.

Когда у вас 2000+ интеграционных тестов и тестовые данные меняются ежедневно(глубоко интегрированная система) из-за работы соседних команд, это критично.

Он экономит время и на простых сценариях:

• генерирует кейсы на основе спек — даже для небольшого внутреннего инструмента, который вы пишете для коллег;

• отлаживает тесты до рабочего состояния — например, правит пару assert-ов в юнит-тесте;

• анализирует DOM-дерево и автоматически обновляет локаторы — хоть для большого банковского портала, хоть для маленького лендинга.

Минусы

Сложные задачи не вытягивает — оптимизация фреймворка, распараллеливание тестов, рефакторинг архитектуры остаются за человеком. 

Требует контроля. Может «решить», что класс стоит переименовать, — и тогда падает половина проекта. Может починить один баг и принести два новых.

Привносит риск не узнать свой код, если дать агенту слишком много свободы...

Отсутствие креатива. Тестирование —это поиск неочевидных багов. Агент пишет кейсы по шаблонам, но пропускает уникальные сценарии (например, edge cases при высокой нагрузке или странные комбинации действий пользователя). Он не догадается проверить, что будет, если нажать на все кнопки одновременно или ввести в поле «возраст» строку «мне 999 лет».

Не несёт ответственности. ИИ не пойдёт к тимлиду с фразой «я тут накосячил, давайте исправим». За результат всё равно отвечает человек.

Вывод

Через полгода работы с агентом моя позиция выглядит так: ИИ-агент не заменяет QA, но снимает с него рутину и освобождает время на более сложные задачи. Вы перестаёте быть «человеком‑тестировщиком» и становитесь «человеком‑стратегом», который использует ИИ как инструмент, точно так же Java, Junit, Selenide и другие.

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