TCS monta agentes para testes em bancos: 100 cenários em 24 horas em vez de 200

A automação de testes há tempos acelera a execução, mas quase não toca em todo o resto. Os cenários continuam sendo criados por pessoas, os scripts são reescritos após cada alteração de user story e o teste que falha é analisado manualmente. Foi exatamente essa parte da cadeia que a TCS decidiu automatizar para clientes de bancos, serviços financeiros e seguros (BFSI). A empresa falou sobre isso junto com a AWS.

Um prompt não basta: é preciso um pipeline

A empresa formulou quatro requisitos. Cada teste deve se basear no contexto de um projeto específico. O sistema deve cobrir tanto APIs quanto a UI do navegador. Os dados de cada cliente devem ser isolados. O caminho do requisito ao relatório deve se repetir de um release para outro.

Uma única chamada de LLM não oferece esse controle. Por isso, a TCS dividiu o trabalho entre agentes, cada um com suas próprias ferramentas, regras de validação e contexto. O roteamento não é feito por um modelo, mas por um supervisor determinístico. Os agentes foram escritos com o Strands Agents SDK e rodam no Amazon Bedrock AgentCore Runtime.

Estes são os papéis:

• o agente gerador cria cenários, converte-os para Gherkin e escreve testes automatizados em Java ou Python;
• o agente de chat distingue uma pergunta de um pedido para alterar um artefato e, conforme o caso, responde ou edita;
• o agente de tarefas transforma um BRD em user stories com critérios de aceitação;
• o agente incremental complementa os testes ao longo de uma cadeia de tarefas relacionadas do Jira, em vez de começar do zero;
• o agente de execução roda os testes, classifica as falhas e salva o resultado.

O contexto é obtido do Amazon Bedrock Knowledge Bases: Jira, BRD, Swagger, código, localizadores e dados de teste. A recuperação é filtrada por cliente, projeto e sessão, de modo que o conhecimento de um cliente não vai parar nos testes de outro. Para a UI, um serviço separado em Puppeteer recebe uma URL e um objetivo em texto e gera a descrição do cenário e localizadores XPath.

Como funcionam a execução e a autocorreção

O agente de execução determina sozinho o tipo de teste pelo código. Os testes de API rodam no ECS com Fargate. Os testes Selenium rodam no ECS sobre EC2, onde o Chrome trabalha com uma tela virtual e a gravação via FFmpeg é transmitida para o S3 e o CloudFront.

O ciclo de correção de erros é descrito como um grafo do LangGraph com ordem estrita de etapas: obter, executar, corrigir, salvar. O número de tentativas é limitado. Se a falha for classificada como erro de código, um agente separado recebe um contexto reduzido e propõe uma correção pontual. Verificações de proteção rejeitam arquivos vazios, arquivos novos inesperados e saltos bruscos de tamanho. Erros de ambiente, como falhas de rede ou de autorização, simplesmente não são admitidos para correção de código. Essa é a resposta ao principal receio: o agente não deve "consertar" um teste apenas para que ele passe.

Isolamento de clientes e resultado

A plataforma é multi-inquilino. A camada de controle compartilhada inclui EKS, um registro e um portal administrativo. Cada cliente tem seu próprio namespace do Kubernetes, pool do Cognito, chave KMS, bucket S3, tabelas DynamoDB e base de conhecimento. O onboarding passa por EventBridge e CodeBuild com AWS CDK, portanto a implantação de um novo cliente é repetível. Os segredos do Jira e do GitLab ficam no Secrets Manager, com WAF, NetworkPolicy e ResourceQuota por cima, e o OpenTelemetry coleta o rastreamento dos agentes.

Em uma carga representativa de cerca de 100 cenários, o processo manual levava aproximadamente duas horas por cenário, ou seja, 200 horas. Com o orquestrador, são cerca de 14 minutos por cenário, ou 24 horas. Isso representa uma redução de 88% no esforço.

Limitações e o que levar daqui

O número vem do benchmark interno da própria TCS, e os prazos dependem da complexidade da aplicação e da equipe. Trata-se de uma publicação conjunta com a AWS, que também vende a solução pelo Marketplace. Não há verificação independente, nem dados sobre a fatia de testes que os engenheiros ainda assim reescrevem.

A conclusão prática vai além do QA bancário. Para processos regulados, funciona um esquema em que o modelo não conduz o processo, mas executa etapas estreitas. O roteamento é determinístico, o número de tentativas é limitado, erros de ambiente são separados de erros de código e o isolamento de dados é parte da infraestrutura. Se você está construindo agentes para um processo de ponta a ponta, comece por esses limites e só depois escolha o modelo.