Привет! На связи команда QA Automation СВОЙ Тех. Сегодня мы хотим поднять тему, которая за последний год превратилась из хайпового «вайб-кодинга» в суровую инженерную реальность. Мы поговорим об агентной разработке (AI Agents) в автоматизации тестирования.
Когда речь заходит об ИИ в QA, многие представляют себе банальный чат-интерфейс, куда копируют логи падающего теста в надежде получить готовое решение. Но это вчерашний день. Настоящая эффективность начинается тогда, когда ИИ превращается из умного собеседника в автономного агента, интегрированного во фреймворк, систему контроля версий, таск-трекер и CI/CD.
Технологии ИИ летят вперед со скоростью экспресса. Тот функционал, который вы освоили вчера, сегодня уже может стать легаси. Тем не менее подходы, которые мы внедрили и обкатали в нашей команде автоматизации, прямо сейчас приносят ощутимую пользу в рабочих процессах. И мы готовы поделиться этой практической концепцией, которую вы сможете применить на своем проекте.
Архитектурный базис: выбор инструментов и интерфейсов
Когда мы проектировали наше решение и оценивали доступные инструменты основными критериями были автономность, гибкость и глубина интеграции. Мы остановились на Codex (в качестве базового ИИ-агента для написания кода на основе моделей OpenAI) и позже, по инициативе компании и здравого смысла, добавили полноценную поддержку Claude.
По своей сути это два максимально близких по возможностям инструмента. Мы изначально выстраивали архитектуру так, чтобы они оставались взаимозаменяемыми. Эффективность LLM постоянно колеблется от релиза к релизу. Если в какой-то момент новая версия Codex лучше справляется с рефакторингом или у вас банально закончились токены в одном из сервисов, вы можете бесшовно «свайпнуть» агента прямо в процессе выполнения задачи и продолжить работу.
Что касается интерфейсов взаимодействия, то для реальной разработки доступны три варианта:
-
Веб-интерфейсы (ChatGPT / Claude Web)
Полезны для быстрых вопросов, анализа локальных проблем. В вебе нет специализированного мода агента, там вы общаетесь со стандартным чатом. -
Desktop-версии
Вариант разработки с менее удобным форматом работы с агентом чем CLI (терминал) – слишком много ручной работы. -
CLI (терминал) и плагины для IDE – наш выбор
Самый производительный и удобный вариант – плагин для IDE, работающий под капотом на базе терминального CLI (claude-code для Claude и соответствующий интерфейс для Codex). Агент получает прямой санкционированный доступ к файловой системе проекта.
Как устроен наш тестовый проект: анатомия папок и навыков
Чтобы автономный агент мог эффективно «понимать» контекст и фреймворк автоматизации, сам проект должен соответствовать жестким структурным требованиям. В нашем репозитории для разработки автоматизированных текстов мы выделили подсистемы для управления агентами.
В корне проекта под каждого агента заведена своя точка входа и конфигурация. Например, для Claude структура выглядит следующим образом:
-
claude.md– файлы памяти агента, основная деклоративная точка входа для ИИ. -
Пакет
.claude/– пакет, в котором хранятся сопутствующие системные промпты и так называемые скиллы (skills).Пакет ai/это общая библиотека, которая шарится между всеми агентами:-
task-additional-files/– рабочие артефакты под текущую задачу, специфические файлы для изолированных задач; -
task-history/– логи жизненного цикла и слепки контекста; любую задачу можно возобновить, перечитав файл из этого пакета;
-
Анатомия скилла
Вся наша концепция автоматизации построена вокруг скиллов. Скилл – это атомарный навык агента, имеющий строгую структуру.
Каждый скилл состоит из двух ключевых элементов:
-
Диктующий файл спецификации (
<skill_name>.md): cодержит строго зафиксированные мета-поля, по которым агент понимает: что это за навык, когда и в каких границах его можно активировать, а также входные/выходные параметры. -
Тело скилла (Body / Workflow) и сопутствующий пакет: cюда входят конкретные инструкции, шаблоны (templates) и скрипты, описывающие пошаговый алгоритм выполнения.
Декомпозиция работы автоматизатора: 5 типов задач и 12 актов
Перед тем как писать промпты, мы сели и проанализировали: а чем вообще занимается автоматизатор в течение спринта? Всю рутину команды автоматизации нам удалось уложить в 5 базовых типов задач.
-
Создание нового теста (New Test): сбор требований, проектирование сценария, написание кода, локальный прогон, деплой.
-
Обновление тестов (Update Test): актуализация упавших или временно отключенных тестов под изменившийся продукт.
-
Расследование падений (Investigate Failures): анализ логов, дифференциация багов продукта от проблем инфраструктуры и флакающих (flaky) тестов.
-
Технические задачи (Tech Tasks): развитие самого фреймворка, рефакторинг, закрытие техдолга.
-
Специфические задачи (Other): проверка безумных гипотез, прототипирование. Логика здесь размыта, поэтому автоматизировать их сложнее всего.
Первые три карточки — наш главный приоритет. Именно они отнимают 80% времени.
Если взять процесс создания нового теста и детально его дефрагментировать, мы получим линейную последовательность из 12 обязательных актов.
Каждая задача проходит через эти стадии: от сбора требований, планирования, имплементации кода, покрытия юнит-тестами фреймворка до селф-ревью, создания Pull Request, кросс-ревью коллегами, мерджа, сборки версии и финальной ретроспективы. Внутри этих актов крутятся цикличные действия: коммиты, фиксы, доработки и перепрогоны.
Карта автоматизации: оркестрация скиллами и моделями
А теперь объединим структуру задач и концепцию скиллов. Наша цель – покрыть цепочку из 12 актов специализированными навыками агента. Вот как выглядит глобальная карта автоматизации нашего проекта (в каком-то роде похожа на концепцию, которую предлагает плагин Superpowers):
Разбор поведения агентов на ключевых этапах воркфлоу
Давайте посмотрим на живом примере, как выстраивается цепочка вызовов (Skill Chain). В основу этого примера лег реальный лог (history file) задачи по миграции наших конфигураций автоматизации с Codex на Claude.
1.Вход (Entry Point)
Мы пишем агенту в консоли кодовую фразу: new task: Migrate configs to Claude. Включается скилл верхнего уровня – Task Definition.
2.МониторингTask Definition параллельно запускает скилл Task Monitoring. Он создает в папке task_history/ файл истории, фиксирует создание ветки от master и начинает собирать весь контекст выполнения.
3.Менеджмент задач в Jira
Автоматически триггерится Jira Task Manager (работающий по MCP). Он проверяет существование задачи в Jira. Если ее нет – создает по всем корпоративным стандартам, если есть – линкует контекст, чтобы потом автоматически проставлять номера задач в коммитах.
4.Оценка (Estimate)
Включается скилл Task Estimation. На удивление, он довольно точно эстимирует крупные задачи (на мелких атомарных операциях может слегка ошибаться). Эстимейт записывается в файл истории (Task Monitoring) и улетает в соответствующее поле Jira-таски через Jira Task Manager.
Дальнейшее выполнение задачи происходит по аналогичному принципу: система последовательно активирует профильные скиллы в зависимости от текущей фазы воркфлоу.
Прелесть подхода в том, что разные типы задач используют на 85% одинаковые цепочки. Например, разница между созданием нового теста (Create Test) и обновлением старого (Update Test) заключается лишь в замене одного скилла: вместо генерации сценария с нуля вызывается скилл его обновления. А если нам нужна свободная работа без жесткого воркфлоу, мы можем вызывать скиллы поодиночке в ручном режиме (Run tests, Create PR).
Оптимизация контекста и выбор LLM
Одной из важных практик стала грамотная маршрутизация задач между моделями. Нет смысла использовать Claude 3 Opus или Thinking-модели для формирования коммитов, запуска типовых скриптов или других рутинных операций. Это приводит к лишним затратам токенов и более быстрому исчерпанию лимитов. Мы стараемся подбирать модель под задачу: простую работу отдавать легким моделям, а самые мощные использовать только там, где действительно требуется глубокий анализ и сложные рассуждения.
Интеграция через Model Context Protocol (MCP)
Чтобы ИИ-агент работал через строго определённый API и не расходовал токены на адаптацию к особенностям используемых инструментов, мы активно внедряем MCP (Model Context Protocol). Часть наших скиллов реализована через MCP-серверы. Мы разворачиваем их локально в Docker либо используем готовые внешние сервисы, предоставляя агентам стандартизированный доступ к Jira, GitHub и другим корпоративным инструментам.
Эффект маховика: самоанализ и непрерывное улучшение
Один из важнейших артефактов нашей системы – файл истории от Task Monitoring. Мы собираем не просто код, а историю его создания: какие ошибки совершал агент, какие компиляционные баги правил.
Имея этот слепок контекста, мы можем реализовывать концепцию Self-Healing / Self-Analysis.
Пример из практики: Агент пытается создать Pull Request через терминал, обходя MCP-сервер GitHub. Первая попытка – неудача, неправильно подобраны флаги CLI. Вторая попытка – конфликт веток. На пятый раз он подобрал верную комбинацию и выполнил задачу.
Мы берем этот лог, скармливаем агенту в рамках ретроспективы и просим: «Проанализируй, почему ты ошибся 4 раза. Обнови системный промпт или конфигурацию скилла
GitHub Workflow, чтобы зафиксировать это правило».
Происходит циклическое улучшение фреймворка. Каждая успешно или неуспешно решенная задача делает инструмент умнее к следующему запуску.
Заключение
Описанный подход стал частью ежедневной работы нашей команды автоматизации. Мы развиваем скиллы, тюним промпты и постепенно передаем ИИ все больше рутинных операций. В масштабах отдельной задачи выигрыш может быть небольшим, но в масштабах команды это превращается в ощутимую экономию времени, которую можно направить на более сложные и интересные инженерные задачи.
ссылка на оригинал статьи https://habr.com/ru/articles/1048146/