Com IA escrevendo testes, a pirâmide de testes e os seus custos mudam?

Na “T02.03 — Explore: Pirâmide de Testes, TDD, Cultura de Qualidade e Blueprints” do QA Transform, surgiu uma pergunta que provavelmente já apareceu em muitas equipes desde que ferramentas de inteligência artificial começaram a entrar no desenvolvimento de software:

Se a IA ajuda a escrever testes, a pirâmide de testes muda? O custo muda? A lógica continua fazendo sentido?

A resposta curta é: a pirâmide não muda.

Mas a dificuldade de construir uma pirâmide saudável pode diminuir bastante.

Essa diferença é importante. A IA pode ajudar o time a criar testes unitários, sugerir cenários, acelerar casos de regressão e apoiar a cobertura de código legado. Mas ela não transforma testes lentos em rápidos, não torna fluxos de ponta a ponta menos frágeis por mágica e não substitui uma estratégia de qualidade.

Em outras palavras: a IA não muda a física do sistema. Ela muda a fricção para trabalharmos melhor dentro dela.

Quando o problema volta, a pirâmide está tentando dizer algo

Um problema recorrente em produção raramente volta por acaso. Às vezes ele volta porque a correção foi feita sem teste de regressão. Às vezes porque a regra de negócio só foi validada no fluxo completo do usuário. Às vezes porque existe um grande bloco de código legado sem proteção, onde qualquer ajuste vira uma aposta.

A pirâmide de testes ajuda justamente a pensar onde cada tipo de validação deve viver.

Na base estão os testes unitários: rápidos, baratos e focados em regras pequenas. Eles validam uma regra de desconto, uma condição de CPF inválido, uma exceção para usuário inativo. Não dependem de banco, rede ou ambiente. Por isso podem ser numerosos e rodar o tempo todo.

Acima vêm os testes de integração, que verificam conexões entre partes internas do sistema, como serviço e repositório. Depois, testes de componente, que exercitam um pedaço maior da aplicação com dependências externas simuladas. Mais acima estão os testes E2E, sigla para end-to-end, ou ponta a ponta: fluxos completos do usuário em ambiente real ou próximo do real. Eles são úteis, mas mais lentos, caros e sensíveis a mudanças de interface.

Por fim, existem testes exploratórios: investigação estruturada, não clique aleatório. Uma sessão exploratória com missão, tempo definido e anotações pode descobrir comportamentos que nenhum script antecipou.

Uma pirâmide saudável tem muitos testes rápidos na base e poucos testes amplos no topo. Uma pirâmide invertida acontece quando quase tudo depende de testes E2E ou validação manual. O resultado é conhecido: feedback lento, instabilidade, filas de validação e medo de mexer no sistema.

De onde veio essa ideia

A pirâmide de testes foi proposta por Mike Cohn no contexto das práticas ágeis e depois popularizada por autores como Martin Fowler. Ela nasceu como uma resposta a um problema prático: equipes automatizavam testes, mas concentravam esforço em validações lentas, caras e frágeis demais para dar feedback rápido.

A mensagem não era “E2E é ruim”. Era outra: cada tipo de teste tem um custo, uma velocidade e uma capacidade diferente de localizar defeitos. Quanto mais alto na pirâmide, mais próximo da experiência real do usuário, mas também maior o custo de manutenção e investigação.

O TDD, ou Test-Driven Development, desenvolvimento orientado por testes, também vem desse movimento de buscar feedback mais cedo. Popularizado por Kent Beck nas práticas de Extreme Programming, ele propõe o ciclo Red, Green, Refactor: escrever um teste que falha, fazer a implementação mínima passar e então refatorar.

TDD não é sinônimo de teste unitário. Também não é apenas “ter muitos testes”. É uma prática de design: pensar no comportamento esperado antes de escrever a solução.

IA ajuda mais onde a base costuma estar vazia

Muitas organizações sabem que precisam de mais testes unitários, mas não conseguem chegar lá. Falta tempo, hábito, clareza nos requisitos, domínio do legado ou confiança para mexer em partes antigas.

É aqui que a IA pode ajudar de forma concreta.

Ela pode sugerir casos para uma função existente, gerar estruturas de Arrange, Act, Assert (preparar, executar e verificar, respectivamente), identificar caminhos condicionais, propor nomes de testes mais descritivos e acelerar a criação de testes de regressão depois de um defeito.

Imagine um bug em um cupom de desconto: o cliente aplica um cupom válido, remove um item do carrinho e o valor final fica incorreto. Corrigir o código é apenas uma parte da resposta. A pergunta de qualidade é: qual teste teria capturado esse erro antes do cliente?

Provavelmente não precisamos começar por um E2E longo abrindo navegador, preenchendo carrinho, aplicando cupom e finalizando compra. Antes disso, podemos criar testes unitários para regras de desconto, testes de integração para a comunicação entre carrinho e serviço de cupom e um teste de componente para o checkout com gateway simulado. O E2E fica reservado ao fluxo crítico principal.

A IA pode acelerar a escrita desses testes. Mas a decisão sobre onde testar continua sendo humana e estratégica.

O que empresas grandes mostram na prática

Essa lógica aparece em organizações que operam software em grande escala. O Google, por exemplo, já recomendou como ponto de partida uma distribuição próxima de 70% de testes unitários, 20% de integração e 10% de ponta a ponta. O número exato varia por contexto, mas a forma continua sendo a mensagem: muitos testes rápidos na base e poucos testes amplos no topo.

A Meta também publicou um estudo sobre geração automática de testes unitários a partir de observações de execução. A iniciativa buscou transformar sinais capturados em testes menores, capazes de rodar continuamente e detectar problemas antes que se tornassem bloqueios maiores. Ou seja: em ambientes com altíssima escala, a atenção à pirâmide é imprescindível.

Gerar teste não é o mesmo que gerar confiança

Existe um risco importante: pedir para a IA escrever testes apenas olhando a implementação atual pode gerar testes que confirmam o que o código faz, não o que deveria fazer.

Isso é perigoso quando o próprio código contém o defeito.

Um teste ruim pode aumentar cobertura sem aumentar confiança. Ele passa, aparece no relatório, melhora um número bonito e não protege o comportamento que importa. Cobertura de testes não equivale automaticamente a qualidade. Ela é um sinal, não uma garantia.

Por isso, o critério de aceite continua essencial. Se o Product Owner escreve “o sistema deve tratar erros adequadamente”, a IA também terá dificuldade de saber o que validar. Se o critério diz “Dado que o CPF tem 10 dígitos, quando o usuário clicar em salvar, então deve exibir CPF inválido abaixo do campo sem limpar os outros campos”, o teste passa a ter uma direção.

IA funciona melhor quando a equipe já sabe o comportamento esperado.

O impacto não é só técnico

Quando um problema volta, a organização paga mais de uma vez pelo mesmo risco.

Considere um cenário ilustrativo: um defeito recorrente no checkout mobiliza uma pessoa de suporte, uma de produto, duas de desenvolvimento, uma de QA e uma de operações por três horas. São 18 horas desviadas, sem contar clientes afetados, receita atrasada, comunicação emergencial e interrupção de prioridades.

Se o defeito reaparece porque nunca ganhou um teste na camada certa, não estamos diante apenas de uma falha técnica. Estamos diante de uma falha de aprendizado.

Em uma fintech, isso pode significar cobrança incorreta. Em um SaaS, permissões quebradas para clientes importantes. Em um sistema de saúde, dados exibidos fora do contexto adequado. Em operações internas, retrabalho manual toda vez que o mesmo comportamento falha.

Uma pirâmide de testes saudável reduz esse custo porque aproxima o feedback do ponto onde o defeito nasce.

IA como alavanca, não como terceirização da qualidade

A cultura de qualidade não melhora porque uma ferramenta escreve testes. Melhora quando o time usa a ferramenta para reforçar práticas certas.

Produto contribui com critérios testáveis. Desenvolvimento escreve e revisa testes como parte da entrega. QA orienta estratégia, riscos e lacunas. Sustentação adiciona characterization tests antes de alterar código legado. CS, ou Client Service, transforma tickets recorrentes em sinais de qualidade. Liderança protege tempo para que essas práticas não sejam cortadas sempre que o prazo aperta.

A IA pode ajudar a sair de uma pirâmide invertida, especialmente quando a base unitária está vazia. Pode tornar mais barato começar. Pode reduzir a resistência inicial. Pode sugerir caminhos que o time revisa, adapta e incorpora.

Mas a pergunta continua sendo a mesma: esse teste captura um comportamento relevante? Ele está na camada certa? Ele falharia se o defeito voltasse?

Se a resposta for não, a IA apenas gerou mais código.

No fim, a pirâmide não muda porque continua existindo a lógica de custo, velocidade e confiança. O que muda é que ferramentas como IA podem tornar muito mais simples fortalecer a base da pirâmide. É como ganhar uma boa caixa de ferramentas novas: a estrutura da casa continua a mesma, mas construir e reforçar os alicerces passa a exigir menos esforço e menos tempo.

O problema que volta está sempre contando uma história. A pirâmide ajuda a descobrir em qual camada deveríamos ter ouvido esse sinal antes.

---

Interessante, não? A IA pode ajudar a escrever mais testes, a pirâmide pode ficar mais saudável e aquele defeito recorrente pode finalmente ganhar uma proteção permanente.

Mas isso ainda olha para uma parte da história: a execução dos testes.

E antes disso?

Como evitar que a regra chegue ambígua? Como impedir que o defeito nasça no requisito, no design, na decisão de produto ou na pressa do desenvolvimento? Como antecipar a qualidade antes da fase formal de testes?

Para isso, temos um post no qual falamos sobre Shift-Left, Built-in Quality e TDD como formas de trazer qualidade para mais perto da origem do problema… Antes que alguém “encontre” o defeito no final.