TCS собрала агентов для тестов в банках: 100 сценариев за 24 часа вместо 200

Автоматизация тестов давно ускоряет прогон, но почти не трогает всё остальное. Сценарии всё равно придумывают люди, скрипты переписывают после каждой правки user story, а упавший тест разбирают вручную. Именно эту часть цепочки TCS и решила автоматизировать для банков, финансовых и страховых клиентов (BFSI). Они рассказали об этом вместе с AWS.

Один промпт не годится, нужен конвейер

Компания сформулировала четыре требования. Каждый тест должен опираться на контекст конкретного проекта. Система должна покрывать и API, и браузерный UI. Данные каждого клиента должны быть изолированы. Путь от требования до отчёта должен повторяться из релиза в релиз.

Один вызов LLM такого контроля не даёт. Поэтому TCS разделила работу между агентами, у каждого из которых свои инструменты, правила валидации и контекст. Маршрутизацией занимается не модель, а детерминированный супервизор. Агенты написаны на Strands Agents SDK и работают в Amazon Bedrock AgentCore Runtime.

Вот как распределены роли:

• генерирующий агент строит сценарии, переводит их в Gherkin и пишет автотесты на Java или Python;
• чат-агент отличает вопрос от просьбы изменить артефакт и либо отвечает, либо правит;
• агент задач превращает BRD в user story с критериями приёмки;
• инкрементальный агент достраивает тесты по цепочке связанных задач Jira, а не начинает с нуля;
• агент исполнения запускает тесты, классифицирует падения и сохраняет результат.

Контекст подтягивается из Amazon Bedrock Knowledge Bases: Jira, BRD, Swagger, код, локаторы и тестовые данные. Выдача фильтруется по клиенту, проекту и сессии, поэтому знания одного заказчика не попадают в тесты другого. Для UI отдельный сервис на Puppeteer по URL и текстовой цели строит описание сценария и XPath-локаторы.

Как устроены запуск и самолечение

Агент исполнения сам определяет тип теста по коду. API-тесты идут в ECS на Fargate. Selenium-тесты идут на ECS поверх EC2, где Chrome работает с виртуальным дисплеем, а запись через FFmpeg стримится в S3 и CloudFront.

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

Изоляция клиентов и результат

Платформа многоарендная. Общий управляющий слой включает EKS, реестр и административный портал. У каждого клиента свои namespace Kubernetes, пул Cognito, ключ KMS, бакет S3, таблицы DynamoDB и база знаний. Онбординг идёт через EventBridge и CodeBuild с AWS CDK, поэтому развёртывание нового клиента повторяемо. Секреты Jira и GitLab лежат в Secrets Manager, поверх работают WAF, NetworkPolicy и ResourceQuota, а трассировку агентов собирает OpenTelemetry.

На представительной нагрузке из примерно 100 сценариев ручной процесс занимал около двух часов на сценарий, то есть 200 часов. С оркестратором выходит около 14 минут на сценарий, или 24 часа. Это минус 88% трудозатрат.

Ограничения и что взять на заметку

Цифра получена на внутреннем бенчмарке самой TCS, и сроки зависят от сложности приложения и команды. Это совместная публикация с AWS, она же продаёт решение через Marketplace. Независимой проверки нет, как и данных о доле тестов, которые инженеры всё равно переписывают.

Практический вывод шире банковского QA. Для регулируемых процессов работает схема, где модель не управляет процессом, а выполняет узкие шаги. Маршрутизация детерминирована, число повторов ограничено, ошибки окружения отделены от ошибок кода, а изоляция данных заложена в инфраструктуру. Если вы строите агентов для сквозного процесса, начните с этих рамок, а уже потом подбирайте модель.