Claude Code y 11 Agentes: Cómo un equipo de QA automatizó hasta el 80% de la rutina de pruebas

Команда QA показала, что ИИ-агенты уже могут забирать на себя большую часть тестовой рутины: от чтения требований и проектирования сценариев до загрузки тест-кейсов в TMS и открытия Merge Request с готовыми автотестами. Вместо расширения штата еще на двух тестировщиков команда собрала на базе Claude Code «экзоскелет» из 11 специализированных агентов и заявляет, что он закрывает до 80% операционной работы QA-инженера. Отталкивались от типичной проблемы продуктовых команд: разработка выпускает новые фичи быстрее, чем тестирование успевает превращать требования в сценарии, данные и автоматизацию.

По внутренней оценке, около 20% времени QA уходит на анализ требований и тест-дизайн, еще 15% — на создание кейсов в TMS, 10% — на подготовку данных, 25% — на автоматизацию, а дальше идут сами проверки, регресс и отчеты. В сумме получается, что до 80% нагрузки можно описать правилами и разложить на повторяемые этапы. Отсюда и идея: не заменять инженера, а превратить его в оператора пайплайна, который ставит задачу, контролирует артефакты и вмешивается только там, где системе не хватает контекста или нужно принять неоднозначное решение.

Архитектура построена как модульная цепочка из 11 скиллов и отдельного оркестратора. Один агент вытягивает задачу из Jira и связанные материалы из Confluence, другой декомпозирует требования в User Stories и задачи, третий генерирует тестовые сценарии по правилам ISTQB, следующие занимаются недостающими данными, расхождениями, DOM-селекторами, API- и UI-автотестами, сравнением сценариев с кодом, загрузкой кейсов в Zephyr Scale и созданием Merge Request в GitLab. В качестве единого источника правды используются JSON-сценарии с полной трассируемостью до требований и критериев приемки, а параллельно строится матрица покрытия RTM.

Для фронтенд-части система дополнительно ходит в Figma через MCP и извлекает не просто скриншоты, а структуру интерфейса, состояния и ограничения элементов. Отдельный акцент сделан на качестве и защите от типичных слабых мест LLM. После генерации сценариев оркестратор прогоняет контрольные точки качества: проверяет JSON-схему, полноту шагов, приоритеты, отсутствие дублей и покрытие требований.

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

Затем включается мутационное тестирование: у уже прошедшего теста инвертируют assert, и если он все равно остается зеленым, такой тест считается пустым и требует доработки. Еще один важный слой — протокол расхождений между Jira, Figma, текстом требований и реальным поведением интерфейса. Очевидные конфликты закрываются автоматически по иерархии приоритетов источников, а спорные случаи поднимаются до инженера.

На практике пилот за полтора месяца дал цифры, ради которых обычно и запускают такие эксперименты. Число регрессионных тест-кейсов выросло примерно с 50 до 400, детализация сценариев стала полной, а покрытие регресса автоматизацией приблизилось к 100%. Время самого регресса сократилось с примерно одного дня до десятков минут, путь от завершения разработки до QA-апрува — с нескольких дней до нескольких часов, а подключение тестирования на новый проект теперь занимает около четырех часов настройки вместо месяцев на найм и адаптацию.

Дополнительно система начала находить больше скрытых противоречий в требованиях и багов, чем ручной процесс. При этом пилотная версия работает на подписке Claude Pro за 100 долларов в месяц и, как утверждается, способна обслуживать 2–3 проекта с объемом более 100 тестов в месяц на каждый. Главный вывод из этого кейса в том, что роль QA действительно начинает смещаться от ручного исполнения к управлению контекстом, правилами и качеством решений, которые принимает ИИ.

Но история работает только при нескольких условиях: требования должны быть достаточно полными, проект обязан иметь нормальный источник контекста вроде API-контрактов и тестовых данных, а сам пайплайн не должен быть «черным ящиком». Здесь ценность не в магической генерации тестов, а в прозрачной цепочке шагов, которую можно перезапускать, проверять и постепенно усиливать. Если такой подход взлетит за пределами пилотов, рынок тестирования может получить не замену инженеров, а гораздо более продуктивный и масштабируемый формат их работы.