Teste verde sem evidência não é verde: uma imagem por verificação

“Passou” é uma afirmação. Num relatório de testes automatizados, ela costuma vir sem nenhuma prova de o que exatamente foi verificado naquele instante. No QAOS, toda verificação deixa um registro visual, e um teste sem ele não pode ser dado como aprovado.

O print final não prova nada

A versão anterior tirava um print no fim do teste de tela, em regime de “melhor esforço”: se existisse, ótimo; se não, ninguém cobrava. Havia três falhas nisso:

• o print final duplicava a última verificação e ignorava as anteriores;
• o teste sem tela (de API, por exemplo) não tinha imagem nenhuma;
• nada impedia que a imagem simplesmente faltasse.

Uma imagem por verificação

Agora cada verificação (cada assert) gera uma imagem no instante em que é avaliada. No teste de tela, é o print da página aberta. No teste sem tela, é uma imagem gerada a partir da requisição e da resposta. Nos testes Java (JUnit), um PNG por teste, gerado no servidor a partir do relatório.

Quando um teste falha, a imagem do ponto de falha substitui o print final, com o passo e o erro anotados ao lado. Falha fora de uma verificação também gera imagem. Há um teto de 50 imagens por teste, mas a última e a de falha são sempre gravadas, e o que passar do teto é declarado, nunca silenciado.

Nem toda imagem sustenta um bug

O nome do arquivo carrega o tipo da evidência:

1. TelaPrint da página no instante da verificação.
2. RequisiçãoImagem gerada com a requisição e a resposta do alvo.
3. Sem saída do alvoTeste unitário, JUnit ou verificação sem requisição.

As três contam como “existe imagem”. Mas só as duas primeiras podem sustentar a classificação bug_provavel_do_alvo. Um teste unitário com imagem prova que foi avaliado, não que o produto está quebrado.

Redigir antes de desenhar

Imagens de teste podem acabar mostrando senha, token ou dado pessoal. Segredo que virou pixel não se remove depois: OCR ou borrão no servidor só pegariam o que já está visível. Por isso o texto é redigido antes de ser desenhado. No contêiner, a lista do que redigir vem de um arquivo; se ele não existir, o sistema falha fechado e não desenha nenhuma imagem gerada.

Sem imagem, sem aprovação

Uma guarda em código, e não uma recomendação no prompt, confere o resultado. Se uma linha marcada como aprovada ou reprovada não tem a imagem de alguma verificação, ela é rebaixada para indeterminado e recebe a etiqueta sem-imagem, com o motivo escrito.

Há uma exceção declarada: quando o teste nem chegou a rodar por erro de configuração (falha no setup), o caso fica isento e o resumo diz isso.

O que foi descartado

• Pedir a imagem ao script gerado. A imagem pertence ao harness, não ao script, que é código gerado por IA e não pode ser a fonte da própria prova.
• Redação por OCR no servidor. Pelo motivo acima: depois que o segredo virou pixel, é tarde.
• Assertivas “moles” (expect.soft). Uma que falha não interrompe o teste, e a imagem daquela verificação diria “aprovado”. Scripts que usam isso são removidos e o fato é declarado.

Um limite que o projeto registra: o nome do arquivo não prova quem o escreveu, porque harness e script gravam na mesma pasta. O fechamento disso, com assinatura do harness, está no backlog. Medida de custo numa execução real: cerca de 381 KB em 258 arquivos, sem necessidade de reajustar os tetos.