Agente de testes: as três coisas que tornam um agente útil

Um agente de testes vale o que valem suas falhas

Uma linha vermelha com uma captura de tela pressupõe que um humano vai interpretá-la. Uma falha utilizável diz o que foi tentado, o que a aplicação fez e onde as duas coisas divergiram, em um formato sobre o qual quem vai corrigir consegue agir sem reconstruir a história.

Isso pesa em dobro quando quem corrige é um agente de código, que não consegue olhar uma captura de tela e inferir a intenção. Peça para ver uma falha real, não uma execução que passou.

Dois: se a verificação pode falhar

Quebre algo de propósito durante a avaliação. Um salvamento que deixa de persistir, um filtro que silenciosamente retorna tudo. Se a verificação continuar verde, ela nunca esteve ligada ao seu produto.

Há dois jeitos de isso dar errado. Uma verificação vaga demais para ter um resultado, e uma execução que estoura o tempo limite antes de chegar às asserções e é reportada como aprovada. O segundo é pior, porque parece cobertura.

Três: se ele roda sem que ninguém peça

• Apenas sob demanda. Útil durante uma sessão, invisível depois.

• A cada mudança. Disparado por um pull request ou por um deploy. É esse que protege você.

• Por agendamento. Pega desvios de ambiente e mudanças em dependências externas.

Um agente de testes que só age quando alguém fala com ele é um testador manual melhor, o que tem algum valor e não é o que você estava comprando.

O que observar na primeira semana

Além das três propriedades, dois comportamentos na primeira semana indicam se isso vai dar certo.

A cobertura que ele cria reflete o seu produto ou o formato da sua especificação. Um agente que parte de um documento de API vai cobrir fielmente todos os endpoints, inclusive os que ninguém usa, e deixar passar a única regra que mora em um comentário. Ler o primeiro plano mostra qual dos dois você tem, e corrigir cedo é muito mais barato do que corrigir com duzentos casos.

E se alguém lê as falhas. Um agente de testes produz mais sinal do que um processo manual, e sinal que ninguém consome é só custo. Se depois de uma semana as falhas estão sendo reconhecidas em vez de investigadas, o problema costuma ser o formato da falha, não o time, e vale levantar isso antes que o hábito se firme.

A avaliação em meio dia

Descreva três fluxos. Quebre uma coisa. Faça um merge. Se ele pegar a quebra, reportar de um jeito útil e perceber o merge sem que ninguém peça, está fazendo o trabalho. Se qualquer um dos três falhar, nenhuma lista de funcionalidades compensa.

Se você preferir não instalar nada, o painel faz a mesma coisa. Todo o resto que a linha de comando faz está no repositório do CLI.

O gatilho importa mais do que o mecanismo. Apontá-lo para o seu evento de deploy significa que toda mudança é verificada sem que ninguém precise decidir por isso; o GitHub App faz isso a partir do painel, e um passo do GitHub Actions faz isso de dentro do seu workflow.

Como a TestSprite responde aos três

Uma falha volta como o que foi tentado, o que a aplicação fez e onde as duas coisas divergiram, em um formato sobre o qual um agente de código consegue agir sem que alguém precise interpretar antes. As verificações fazem asserções sobre algo específico, e uma execução que nunca chegou às suas asserções não é reportada como aprovada. E ele roda a cada mudança: conecte um repositório e as execuções começam a partir do deploy que o seu pipeline já produz.

A cobertura é gerada a partir do seu produto e refinada em linguagem comum, e a instalação coloca a skill de verificação dentro do agente de código que você já usa, então criar e rodar uma verificação acontece dentro do trabalho, e não ao lado dele.

O que você ganha é a avaliação de meio dia sendo aprovada: ele pega a quebra, reporta de um jeito útil e percebe o merge sem que ninguém peça.