TCS monta un equipo de agentes para pruebas en bancos: 100 escenarios en 24 horas en lugar de 200

La automatización de pruebas lleva tiempo acelerando la ejecución, pero apenas toca todo lo demás. Los escenarios los siguen ideando personas, los scripts se reescriben tras cada cambio en una user story y las pruebas fallidas se analizan a mano. Esta es la parte de la cadena que TCS decidió automatizar para sus clientes de banca, servicios financieros y seguros (BFSI). La compañía lo contó junto con AWS.

Un solo prompt no basta: hace falta un pipeline

La compañía formuló cuatro requisitos. Cada prueba debe apoyarse en el contexto de un proyecto concreto. El sistema debe cubrir tanto las API como la interfaz del navegador. Los datos de cada cliente deben estar aislados. El camino del requisito al informe debe repetirse de una versión a otra.

Una única llamada a un LLM no ofrece ese control. Por eso TCS repartió el trabajo entre agentes, cada uno con sus propias herramientas, reglas de validación y contexto. El enrutamiento no lo hace un modelo, sino un supervisor determinista. Los agentes están escritos con Strands Agents SDK y se ejecutan en Amazon Bedrock AgentCore Runtime.

Así se reparten los roles:

• el agente generador construye escenarios, los convierte a Gherkin y escribe pruebas automatizadas en Java o Python;
• el agente de chat distingue una pregunta de una petición de modificar un artefacto y, según el caso, responde o edita;
• el agente de tareas convierte un BRD en user stories con criterios de aceptación;
• el agente incremental completa las pruebas siguiendo una cadena de tareas de Jira vinculadas, en lugar de empezar de cero;
• el agente de ejecución lanza las pruebas, clasifica los fallos y guarda el resultado.

El contexto se obtiene de Amazon Bedrock Knowledge Bases: Jira, BRD, Swagger, código, localizadores y datos de prueba. Los resultados se filtran por cliente, proyecto y sesión, de modo que el conocimiento de un cliente no acaba en las pruebas de otro. Para la UI, un servicio aparte basado en Puppeteer toma una URL y un objetivo en texto y genera la descripción del escenario y localizadores XPath.

Cómo funcionan la ejecución y la autorreparación

El agente de ejecución determina por sí mismo el tipo de prueba a partir del código. Las pruebas de API se ejecutan en ECS con Fargate. Las pruebas Selenium se ejecutan en ECS sobre EC2, donde Chrome trabaja con una pantalla virtual y la grabación con FFmpeg se transmite a S3 y CloudFront.

El circuito de corrección de errores se describe como un grafo de LangGraph con un orden estricto de pasos: obtener, ejecutar, corregir, guardar. El número de reintentos está limitado. Si un fallo se clasifica como error de código, un agente aparte recibe un contexto reducido y propone una corrección puntual. Las comprobaciones de seguridad rechazan archivos vacíos, archivos nuevos inesperados y saltos bruscos de tamaño. Los errores de entorno, como fallos de red o de autorización, directamente no pueden desencadenar correcciones de código. Es la respuesta al principal temor: que el agente "arregle" una prueba solo para que empiece a pasar.

Aislamiento de clientes y resultado

La plataforma es multiinquilino. La capa de control común incluye EKS, un registro y un portal de administración. Cada cliente tiene su propio namespace de Kubernetes, pool de Cognito, clave KMS, bucket de S3, tablas de DynamoDB y base de conocimiento. El onboarding se realiza mediante EventBridge y CodeBuild con AWS CDK, por lo que el despliegue de un nuevo cliente es repetible. Los secretos de Jira y GitLab están en Secrets Manager, con WAF, NetworkPolicy y ResourceQuota por encima, y OpenTelemetry recoge la trazabilidad de los agentes.

Con una carga representativa de unos 100 escenarios, el proceso manual requería unas dos horas por escenario, es decir, 200 horas. Con el orquestador salen unos 14 minutos por escenario, o 24 horas. Es una reducción del 88 % del esfuerzo.

Limitaciones y qué conviene retener

La cifra procede del benchmark interno de la propia TCS, y los plazos dependen de la complejidad de la aplicación y del equipo. Es una publicación conjunta con AWS, que además vende la solución a través de Marketplace. No hay verificación independiente ni datos sobre la proporción de pruebas que los ingenieros acaban reescribiendo igualmente.

La conclusión práctica va más allá del QA bancario. Para procesos regulados funciona un esquema en el que el modelo no gestiona el proceso, sino que ejecuta pasos acotados. El enrutamiento es determinista, los reintentos están limitados, los errores de entorno se separan de los de código y el aislamiento de datos está integrado en la infraestructura. Si construyes agentes para un proceso de extremo a extremo, empieza por estos límites y solo después elige el modelo.