Equipe da Dokumenterra encarrega Claude de escrever testes automatizados em cinco horas

Depois que uma funcionalidade é lançada, é preciso descrever novamente seu comportamento para quem vai testá-la e, em seguida, converter os cenários em testes automatizados. A Dokumenterra experimentou usar a documentação do produto para isso: Claude a lê, elabora casos de teste e escreve os testes. Um exemplo de redefinição de senha mostra o que o processo produz e em quais pontos uma pessoa precisa verificar as suposições do modelo.

Segundo o diretor de tecnologia da empresa, preparar os prompts para uma funcionalidade leva uma hora; depois, Claude trabalha por mais cinco horas. Essa estimativa vem do relato da equipe. O artigo não apresenta uma comparação com o desenvolvimento manual de testes, os custos das execuções nem estatísticas de erros, portanto ainda não é possível calcular os ganhos.

Das instruções a dois testes

No exemplo, o agente recebe instruções de redefinição de senha: abrir a página de login, acessar o link de recuperação, inserir o nome de usuário ou o e-mail e solicitar uma mensagem. Ele lê a documentação via MCP, uma conexão que permite acessar ferramentas de busca e leitura de páginas.

Claude transforma as instruções em dois cenários. O primeiro verifica se o link da página de login abre o formulário de recuperação. O segundo verifica se um nome de usuário vazio provoca um erro de validação e mantém o usuário na mesma página. Em seguida, gera testes automatizados que verificam a URL da página, a visibilidade dos campos e a mensagem de erro.

O segundo cenário tem um detalhe importante: as instruções originais não dizem nada sobre um campo vazio. O próprio modelo propôs o comportamento esperado. É um ponto de partida útil para quem testa, mas precisa ser conferido com os requisitos do produto. Uma suposição plausível não se torna uma regra só porque o agente a transformou em um teste.

O código apresentado também depende de fixtures existentes e do objeto de página ForgotPasswordPage. Portanto, o exemplo não demonstra a criação de toda a infraestrutura de testes do zero. Além disso, essas duas verificações não cobrem todo o fluxo de redefinição de senha: receber o e-mail, acessar o link e definir uma nova senha.

Duas revisões continuam nas mãos das pessoas

A equipe descreve duas etapas manuais obrigatórias. Primeiro, uma pessoa revisa a documentação e, depois, os casos de teste elaborados pelo modelo. Em seguida, supervisiona a criação dos testes automatizados.

A primeira revisão protege contra requisitos desatualizados. Se as instruções descrevem um comportamento que já mudou no produto, o agente pode reproduzir fielmente o erro nos cenários. Nesse caso, uma execução com todos os testes passando demonstrará conformidade com uma expectativa incorreta.

A segunda revisão serve para verificar a cobertura. Um especialista que conheça os usuários pode identificar condições, papéis ou exceções que ficaram de fora. No exemplo de redefinição de senha, também vale perguntar quais cenários são necessários para um link expirado e uma nova solicitação de e-mail. São possíveis acréscimos ao plano de testes; o artigo não mostra que a equipe os tenha implementado.

O próprio autor ressalta que o servidor MCP começou a ser usado recentemente e os resultados são preliminares. O uso de informações presentes em capturas de tela também não foi verificado. O servidor retorna Markdown com links para imagens, mas a equipe ainda não determinou se o agente extrai delas as informações necessárias.

O que sua equipe pode adotar

O valor prático do caso está na organização do processo. O agente recebe a descrição de uma funcionalidade, uma tarefa, um PR e os casos de teste existentes, busca a documentação por conta própria e depois propõe um plano de testes. Assim, quem testa passa a ter material concreto para revisar.

Restrições precisas são especialmente úteis nesse processo. Uma afirmação de que há suporte ao envio de arquivos pouco define os resultados esperados. Especificar o tamanho máximo e um erro concreto já permite elaborar testes de valores-limite. Se uma regra admite várias interpretações, primeiro é preciso chegar a um acordo sobre o comportamento e depois registrá-lo em um teste.

Neste caso, o MCP dá acesso às páginas atuais, incluindo materiais restritos quando há as permissões necessárias. O relato, porém, não demonstra que a abordagem seja impossível sem essa conexão: em um pequeno experimento, é possível fornecer ao agente um trecho selecionado da documentação. A própria conexão também não garante que o texto esteja atualizado e correto.

É possível começar com uma única funcionalidade: revisar sua descrição, obter cenários, chegar a um acordo sobre os resultados esperados e só então gerar o código. Para avaliar os benefícios, vale medir o tempo de preparação e revisão, o número de correções e a estabilidade dos testes diante de mudanças posteriores. O caso da Dokumenterra oferece um modelo reproduzível para esse experimento, mas ainda não comprova economia para qualquer equipe.