Pirâmide de testes como ferramenta para decompor tarefas de agentes de IA no QA Assist

Quando um modelo de linguagem assume o papel de designer de testes, a teoria clássica de QA ganha, de forma inesperada, uma nova dimensão. Esse é o tema do terceiro artigo da série de Mikhail Fedorov sobre o sistema QA Assist, publicado no Habr. Desta vez, o autor explica por que a pirâmide de testes, criada muito antes da era das redes neurais, se mostra crucial para agentes de IA com janela de contexto limitada.

O QA Assist é um sistema com 11 agentes de IA especializados na automação de testes de software. No primeiro artigo da série, Fedorov descreveu a arquitetura: como as responsabilidades são divididas entre os agentes, como eles interagem e o que sabem fazer. No segundo, mostrou com franqueza a realidade da implantação: uma tarefa que no papel parece levar quatro horas vira, no ambiente corporativo, uma semana de aprovações, reuniões com a equipe de segurança e ajustes na configuração de infraestrutura.

O terceiro artigo sobe um nível e trata de como formular tarefas para a IA de modo a obter resultados de qualidade e reproduzíveis. A pirâmide de testes é um dos princípios básicos do desenvolvimento. Na base ficam os testes unitários, rápidos e baratos, que verificam funções e métodos de forma isolada.

No meio estão os testes de integração, que checam a interação entre componentes. No topo, os testes end-to-end, lentos e caros, que simulam um cenário real de uso. A proporção clássica é: muitos testes unitários, menos testes de integração e o mínimo de E2E.

Essa estrutura economiza tempo de execução e facilita a depuração: quando um teste unitário falha, fica claro na hora o que quebrou. O problema surge quando quem projeta os testes deixa de ser um engenheiro e passa a ser um modelo de linguagem. Um LLM trabalha dentro de uma janela de contexto, ou seja, um volume fixo de tokens que o modelo consegue manter em uma única sessão de geração.

Em tarefas pequenas, isso não é crítico. Mas, se você pedir à rede neural que escreva toda a suíte de testes de uma aplicação grande em uma única requisição, o resultado é previsível: ou parte da lógica de negócio fica de fora do contexto, ou o modelo entrega cenários superficiais, sem se aprofundar nas dependências reais e nos casos de borda. É aqui que a pirâmide de testes deixa de ser teoria de livro didático e se torna uma ferramenta prática de decomposição.

A metáfora do autor, dar o elefante à rede neural em pedaços, descreve com precisão a essência da abordagem. A tarefa grande é dividida em camadas, seguindo a pirâmide: primeiro os agentes geram testes unitários no nível das funções, depois passam aos cenários de integração e, só no final, aos E2E. Cada camada cabe na janela de contexto do modelo e é processada de forma isolada, sem perda de qualidade por estouro de contexto.

Essa abordagem traz algumas vantagens concretas. Cada requisição ao modelo fica focada: o agente recebe um escopo claro, um contrato de entrada definido e um artefato específico de saída. Os erros ficam localizados: se um teste unitário foi escrito de forma incorreta, isso aparece imediatamente, e não várias iterações depois, quando um cenário de integração já está sendo construído em cima dele.

Por fim, a pirâmide estabelece uma ordem natural de dependências: os testes E2E são construídos sobre uma base já verificada, e não em paralelo a ela. Fedorov não tem a pretensão de reinventar a roda. O próprio autor reconhece que se trata da aplicação de um princípio de engenharia conhecido há muito tempo a um novo contexto.

E essa é justamente a ideia central: a IA não elimina os princípios básicos do desenvolvimento; ela os torna ainda mais importantes. Entender a pirâmide de testes agora é necessário não só para o engenheiro de QA, mas também para quem projeta a arquitetura de requisições a modelos de linguagem. Para equipes que avaliam ferramentas de IA para automação de testes, fica uma lição prática: primeiro projete a decomposição da tarefa e só depois a confie ao modelo.

O elefante se come aos pedaços, e isso não é uma limitação da tecnologia, mas a única arquitetura que funciona.