Claude Code e 11 Agentes: Como um time de QA automatizou até 80% da rotina de testes

Uma equipe de QA demonstrou que agentes de IA já podem assumir a maior parte do trabalho rotineiro de testes: desde a leitura de requisitos e design de cenários de testes até o upload de casos de teste no TMS e criação de Merge Requests com autotestes prontos. Em vez de expandir o quadro com mais dois testadores, a equipe construiu um "exoesqueleto" de 11 agentes especializados baseado em Claude Code e afirma que cobre até 80% do trabalho operacional de um engenheiro de QA. Partiram de um problema típico de equipes de produtos: o desenvolvimento lança novas features mais rápido do que os testes conseguem transformar requisitos em cenários, dados e automação.

De acordo com avaliação interna, cerca de 20% do tempo de QA vai para análise de requisitos e design de testes, outros 15% para criação de casos no TMS, 10% para preparação de dados, 25% para automação, e depois vêm as verificações em si, regressão e relatórios. No total, até 80% da carga de trabalho pode ser descrita por regras e decomposta em estágios repetíveis. Daí a ideia: não substituir o engenheiro, mas transformá-lo em um operador de pipeline que define a tarefa, controla artefatos e intervém apenas onde o sistema carece de contexto ou precisa tomar uma decisão ambígua.

A arquitetura é construída como uma cadeia modular de 11 skills e um orquestrador separado. Um agente puxa a tarefa do Jira e materiais relacionados do Confluence, outro decompõe requisitos em User Stories e tarefas, um terceiro gera cenários de teste de acordo com regras ISTQB, os próximos lidam com dados faltantes, discrepâncias, seletores DOM, autotestes de API e UI, comparando cenários com código, uploadando casos para Zephyr Scale e criando Merge Requests no GitLab. Cenários JSON com rastreabilidade completa até requisitos e critérios de aceitação servem como única fonte de verdade, enquanto uma matriz de cobertura RTM é construída em paralelo.

Para a parte de frontend, o sistema também acessa Figma através de MCP e extrai não apenas screenshots, mas a estrutura da interface, estados dos elementos e restrições. Ênfase especial foi colocada em qualidade e proteção contra fraquezas típicas de LLM. Após geração de cenários, o orquestrador executa pontos de controle de qualidade: verifica schema JSON, completude de passos, prioridades, ausência de duplicatas e cobertura de requisitos.

Após geração de autotestes, o controle fica ainda mais rigoroso: código Python, fixtures e execução real dos testes são validados. Um esquema de debugging em dois estágios é usado. Primeiro, o sistema executa cada teste separadamente e diferencia problemas de código de teste de defeitos reais do produto.

Depois, testes de mutação entram em ação: em um teste já aprovado, o assert é invertido, e se mesmo assim permanecer verde, tal teste é considerado vazio e requer refinamento. Outra camada importante é o protocolo de conflitos entre Jira, Figma, texto de requisitos e comportamento real da interface. Conflitos óbvios são resolvidos automaticamente por hierarquia de prioridade de fontes, enquanto casos disputados são escalados para o engenheiro.

Na prática, o piloto ao longo de um mês e meio entregou números que tipicamente justificam lançar tais experimentos. O número de casos de teste de regressão cresceu de aproximadamente 50 para 400, a detalhabilidade de cenários se tornou completa, e a cobertura de regressão por automação se aproximou de 100%. O próprio tempo de regressão foi reduzido de aproximadamente um dia para dezenas de minutos, o caminho de conclusão do desenvolvimento para aprovação de QA de vários dias para várias horas, e a integração de testes em um novo projeto agora leva cerca de quatro horas de configuração em vez de meses para contratação e adaptação.

Adicionalmente, o sistema começou a encontrar mais contradições de requisitos ocultos e bugs do que o processo manual. Enquanto isso, a versão piloto funciona em uma assinatura Claude Pro por $100 por mês e, conforme afirmado, é capaz de atender 2–3 projetos com mais de 100 testes por mês para cada. A principal conclusão deste caso é que o papel de QA está começando a mudar da execução manual para gerenciamento de contexto, regras e qualidade das decisões que a IA toma.

Mas a história funciona apenas sob certas condições: requisitos devem ser suficientemente completos, o projeto deve ter uma fonte apropriada de contexto como contratos de API e dados de teste, e o pipeline em si não deve ser uma "caixa preta". O valor aqui não está em geração mágica de testes, mas em uma cadeia transparente de etapas que pode ser re-executada, verificada e gradualmente fortalecida. Se essa abordagem delanchar além dos pilotos, o mercado de testes pode ganhar não uma substituição para engenheiros, mas um formato muito mais produtivo e escalável para seu trabalho.