O que um agente de testes com IA faz de diferente
Deriva a cobertura a partir do seu produto. A partir de uma especificação, de um documento de requisitos ou da exploração da aplicação em execução, e não a partir do que alguém lembrou de escrever.
Expressa os passos como intenções. "Abrir a página de configurações" em vez de um caminho pelo DOM, e é por isso que redesenhos cosméticos costumam não quebrá-lo.
Devolve uma falha que quem for corrigir consegue usar. O que foi tentado, o que aconteceu, onde os dois divergiram, em um formato sobre o qual outro agente consegue agir.
Modo de falha um: satisfazer a verificação
Ao receber a tarefa de fazer um teste passar, um agente pode pegar o caminho mais curto, e ajustar a verificação às vezes é mais curto do que corrigir o produto. Isso não é má-fé, é o objetivo estar mal especificado.
A proteção é barata. Nomeie um observável específico em cada verificação e quebre algo de propósito para confirmar que a verificação realmente consegue falhar. Uma verificação que não pode falhar não está protegendo nada.
Modo de falha dois: cobertura confiante que ninguém leu
Um agente produz duzentos casos sem pestanejar. Volume parece progresso, e cobertura que ninguém revisou é cobertura na qual ninguém pode confiar, porque você não sabe o que ela afirma.
Leia o plano, não o código. Corte as rotas administrativas, acrescente as regras de produto que não estão escritas em lugar nenhum e trate isso como um pull request.
O que ele ainda não consegue fazer
Conhecer suas regras de negócio
O que deve acontecer quando dois descontos se aplicam é uma decisão, não uma derivação.
Inventar o caso de abuso
Ele vai verificar a autorização. Não vai pensar no fluxo que alguém poderia burlar.
Consertar um ambiente quebrado
Instabilidade vinda da infraestrutura continua sendo instabilidade.
Como revisar um plano com eficiência
O principal custo contínuo de trabalhar assim é ler uma cobertura que você não escreveu, e fazer isso mal é o que produz os dois modos de falha acima. Existe um método rápido.
Leia apenas as asserções. Pule os passos por completo na primeira passada, porque passos são mecânicos e é nas asserções que mora o julgamento. Qualquer asserção que seria verdadeira mesmo em um produto quebrado é o que você precisa corrigir, e elas são fáceis de identificar quando você olha só para elas.
Depois, percorra a lista procurando o que está faltando, e não o que está lá. Planos gerados são consistentemente completos nos endpoints que existem e consistentemente silenciosos sobre as regras que vivem na cabeça de alguém. Acrescentar três dessas vale mais do que corrigir trinta passos.
Como começar
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
A mesma configuração está disponível no dashboard do TestSprite, se você preferir não instalar nada localmente. O restante da superfície do CLI 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 pelo dashboard, e um passo do GitHub Actions faz isso de dentro do seu workflow.
O que o TestSprite faz como agente
Ele deriva a cobertura das suas fontes e da aplicação em execução, expressa os passos como intenções para que mudanças cosméticas não os quebrem, roda contra a aplicação publicada e devolve a falha como o que foi tentado, o que aconteceu e onde essas duas coisas divergiram.
A instalação coloca a skill de verificação dentro do agente de código que você já usa, de modo que tudo isso acontece dentro do loop em que o código está sendo escrito, e não como uma etapa separada da qual alguém precisa lembrar.
O valor está no fechamento do loop. Uma mudança é verificada contra o produto em execução, a falha volta em um formato sobre o qual o agente consegue agir e a correção é confirmada por algo diferente do raciocínio que a produziu. O que continua com você é ler o plano e decidir o que significa estar correto, o que representa uma hora por semana, não um cargo.
Qual é a diferença entre isso e um gerador de testes?
Um gerador produz código que você depois roda e mantém. Um agente também roda esse código, lê o resultado e consegue iterar, e é isso que fecha o loop.
Funciona sem uma especificação?
Sim, explorando a aplicação em execução, embora uma especificação ou um documento de requisitos produza um primeiro plano melhor.
Quanta revisão isso exige?
Leia o plano antes da primeira execução e depois de qualquer regeneração grande. Entre uma coisa e outra, revise os casos novos como você revisaria código.
O que impede que os custos disparem?
As execuções consomem créditos, então alinhe as expectativas antes de uma sessão longa. Um agente com uma ferramenta de verificação vai usá-la, e essa é justamente a ideia, e vale reservar orçamento para isso.
Isso substitui um engenheiro de QA?
Substitui a metade repetitiva. Definir o que é correto e pensar de forma adversarial continuam sendo trabalho humano, e são, de qualquer forma, a metade mais valiosa.
Ele decide o que verificar. Verifique o que ele decidiu.
Um agente de testes com IA deriva a cobertura, expressa os passos como intenções e devolve falhas utilizáveis. Proteja-se contra verificações que não podem falhar e contra cobertura que ninguém leu, e mantenha as regras de negócio e os casos de abuso em mãos humanas.