Agente de IA com GPT-5.5 analisou 2600 autotestes da TravelLine em duas semanas

O testador da TravelLine Ilsur Mingazov conduziu, em duas semanas, uma auditoria dos autotestes da plataforma para hotéis com a ajuda de um agente de IA. A análise de conteúdo cobriu cerca de 2600 testes de uma base de 6500 cenários E2E, e as estatísticas de execução foram coletadas para a base inteira. O motivo foi a migração planejada dos testes de Java para .NET. A equipe concluiu que um port "como está" levaria para a nova stack também a dívida técnica acumulada ao longo de 15 anos. No fim, cerca de 450 testes obsoletos foram removidos da seção de testes de screenshot, e várias outras seções ganharam tarefas para a criação de testes de integração.

Ambiente do agente: código, MCP e escolha do modelo

Só a lista de nomes de cenários do TMS não bastava para esse trabalho, então o agente recebeu o contexto completo. O ambiente de trabalho ficou assim:

• OpenCode — o ambiente em que o agente trabalha.
• Repositórios locais — clones do produto e do projeto de autotestes. O agente percorre as pastas por conta própria, procura métodos e classes e relaciona as chamadas, sem que nada precise ser copiado manualmente para o contexto.
• TestIT via MCP — a equipe começou com requisições diretas à API e depois passou para um servidor MCP. O agente chama ferramentas prontas, e o servidor busca entidades, metadados e execuções.
• GPT-5.5 — o modelo escolhido no catálogo do OpenCode. As versões leves Flash foram descartadas de cara: ao relacionar arquitetura e lógica complexa, perdiam detalhes. O GPT-5.5 manteve um prompt longo com as regras da pirâmide de testes, chamou as ferramentas MCP com precisão e não inventou ligações entre testes e código.
• Prompt de sistema e contrato de resposta — critérios para dividir entre E2E e integration, mais um formato rígido de relatório em markdown, sem enrolação.

O primeiro teste foi do próprio agente. O pedido para analisar uma seção devolveu uma lista incompleta. Os logs de raciocínio mostraram que ele se apoiava nos conjuntos de testes (suites), enquanto o testador esperava a árvore de seções e subseções. O que resolveu foi um screenshot da árvore e uma explicação detalhada de onde buscar os testes. Depois disso, a ordem de trabalho foi registrada nas instruções do agente.

Primeira iteração: migrar, mover para baixo ou não mexer

No skill.md, cada teste precisava receber um de três rótulos:

• MIGRATE_TO_NET — cenário atual, migrado para o framework .NET sem alterações;
• SHIFT_TO_INTEGRATION — lógica de negócio ou API que vale entregar aos desenvolvedores de back-end para virar teste de integração;
• OBSOLETE_OR_BROKEN — a funcionalidade foi removida ou alterada, o teste está quebrado, duplica outro ou é redundante como verificação de UI; não é migrado.

O agente classificava como E2E o happy path crítico, os fluxos completos do usuário, a integração entre subsistemas, a navegação e a exibição. Como integration, ficavam os cálculos, a validação de combinações de dados, o salvamento de configurações e os limites, ou seja, tudo em que o navegador só deixa a execução mais lenta.

Um exemplo claro é a seção Transfers. Dos 18 testes E2E, o agente relacionou os cenários com os testes de integração existentes e descobriu que 15 deles duplicam verificações do nível inferior, mas com custo maior e mais risco de falhas instáveis. Resultado: 3 testes em MIGRATE_TO_NET, 0 em SHIFT_TO_INTEGRATION e 15 em OBSOLETE_OR_BROKEN. A migração direta teria levado 15 cenários desnecessários para o .NET: mais tempo de execução, mais falhas para analisar e mais código para manter.

Segunda iteração: P85 de falhas e duração

O código não mostra com que frequência um teste falha nem quanto tempo ele leva na prática. Por isso, para cada um dos ~6500 testes, a equipe pediu ao TestIT até 100 resultados recentes e os agrupou por seção. Dois indicadores foram calculados:

• fail rate — a proporção de resultados Failed sobre o total, por exemplo 10 em 100 dá 10%;
• P85 de duração — calculado sobre as execuções com status Passed; as que falharam ficaram de fora para que timeouts não distorcessem o quadro.

Dentro de cada seção, foram calculados os limites de P85 para os dois indicadores, o que gerou quatro grupos: só falhas frequentes, só testes longos, a interseção e os demais. A interseção foi analisada primeiro. Um teste longo nem sempre é ruim, e as falhas frequentes podem ter origem no produto ou no ambiente. A estatística montou a fila de análise, mas não emitiu veredito.

Na seção reports, o agente contou 245 testes, 24 051 execuções e 1598 falhas, ou seja, um fail rate de 6,6%. Só pelas falhas, 29 testes caíram na zona problemática; só pela duração, 28; pelos dois critérios, 9. Para esses nove, o agente preparou um relatório em DOCX e Markdown (passed / failed / P85 passed em segundos):

• alteração de parâmetros do pedido — 87 / 11 / 131,0;
• cancelamento de operação com recálculo parcial — 86 / 11 / 102,0;
• filtragem de dados por parâmetros — 88 / 10 / 308,0;
• verificação de fuso horário nos relatórios — 78 / 10 / 170,9;
• verificação de periodicidade nas exportações — 75 / 11 / 162,0;
• confirmação do status da entidade — 74 / 11 / 144,1;
• finalização do pedido — 75 / 9 / 169,8;
• envio de notificações transacionais — 70 / 19 / 240,1;
• processamento de pagamento e execução de reembolso — 63 / 33 / 253,7.

O que outras equipes podem aproveitar

O papel do humano no processo continuou o mesmo: definir os critérios, verificar as conclusões do agente e discutir os casos difíceis com os desenvolvedores. O agente assumiu a busca de arquivos, a leitura do código, o cruzamento das verificações e a coleta de estatísticas. O resultado final foi um conjunto de tarefas, e não um relatório. As duplicatas foram eliminadas, cerca de 450 testes de screenshot foram removidos, foram criadas tarefas para testes de integração e para a migração dos cenários validados, e as demais seções entraram na fila de discussão.

Para equipes com uma base de testes grande, a lição é prática. O agente precisa de acesso ao código e ao sistema de gestão de testes via MCP, e não de uma exportação de nomes. Rótulos de decisão rendem mais do que descrições, e a verificação inicial do agente deve entrar no planejamento. Faz sentido analisar primeiro os testes que são ao mesmo tempo longos e instáveis. Um agente configurado com regras de análise continua na equipe e pode investigar falhas, buscar a cobertura existente e avaliar novos cenários sem remontar o contexto.