Por que meus testes falham quando a aplicação está bem?

Um teste de ponta a ponta fica vermelho quando a rede está lenta, o DNS falha, o site responde com 403 ou 429 ou exibe um desafio anti-bot, ou o navegador morre, e nada disso é um defeito da sua aplicação. O Nexus Studio, da Verdict System LLC, dá a essas falhas vereditos próprios: TIMEOUT, UNREACHABLE, BLOCKED e CRASHED. Nenhum deles é reportado como bug na aplicação.

Pela equipe do Nexus Studio, Verdict System LLC. 7 de outubro de 2026.

O que faz um teste falhar sem que haja um bug?

Um teste apenas informa que algo não aconteceu. A causa pode estar em quatro lugares que não têm relação nenhuma com o seu código:

a página estava lenta e o teste esgotou o tempo;
não foi possível alcançar o host, por exemplo porque o nome não foi resolvido;
o site se defendeu com um 403, um 429, um CAPTCHA ou um desafio anti-bot, e a requisição nunca chegou ao seu produto;
o navegador ou o processo morreu.

Quando todos esses casos aparecem como um simples vermelho, a equipe os registra como bugs ou aprende a reexecutar os vermelhos em vez de lê-los. Nos dois casos, o defeito real se esconde no ruído.

Como o Nexus Studio diferencia uma falha falsa de um bug?

Quando um teste falha, o motor lê a mensagem de erro e o log de rede da execução e os confronta com grupos de padrões em uma ordem fixa. O primeiro grupo que corresponder define o veredito. A ordem é CONFIG_ERROR, depois CRASHED, BLOCKED, UNREACHABLE e TIMEOUT, e só então BREACHED_FLAKY ou BREACHED. Assim, BREACHED, o veredito que significa um relatório de bug, fica reservado para uma falha que nenhum padrão de ambiente ou de harness explica. Os padrões cobrem tanto a redação do Playwright quanto a do Selenium WebDriver.

O que significam TIMEOUT, UNREACHABLE, BLOCKED e CRASHED?

TIMEOUT: o teste não recebeu resposta a tempo. Isso não prova que a aplicação está quebrada, nem que funciona: a execução não tem como saber. Uma navegação que esgotou o tempo é um TIMEOUT, porque começou e a página estava lenta.
UNREACHABLE: não foi possível alcançar o host. O DNS ou a conexão falhou antes de qualquer página ser observada, como no caso de um nome que não foi resolvido, uma conexão recusada ou uma máquina offline. Um erro de certificado não entra aqui: ele é um achado.
BLOCKED: o site se defendeu com um 403, um 429, uma página de bloqueio ou um desafio anti-bot. Quando havia uma defesa na tela, o metadata.json a identifica. Um celular Android real que adormeceu ou está bloqueado também é BLOCKED, como um pré-requisito não atendido.
CRASHED: o navegador ou o processo morreu, por exemplo uma página fechada, um erro do protocolo DevTools ou uma sessão do WebDriver encerrada. É infraestrutura: verifique a máquina e o driver.

O guia de vereditos lista os padrões de erro exatos por trás de cada um.

O que o meu pipeline de CI enxerga?

Sete dos 14 vereditos encerram com código 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION e SECURITY_VIOLATION. Os outros sete encerram com código 1, e TIMEOUT, UNREACHABLE, BLOCKED e CRASHED estão entre eles. Portanto, o build continua falhando, porque o teste não passou, mas o relatório e o History indicam qual foi a causa. Os runners de pytest e Selenium encerram com código 2 quando a execução nem chegou a iniciar.

Que evidências cada falha falsa mantém?

Cada um dos quatro mantém report.md, metadata.json, raw-data.json e uma captura de tela do último quadro. O vídeo é diferente:

TIMEOUT e BLOCKED: o vídeo vem desativado por padrão. Ative-o em Settings, em Keep failure video for.
UNREACHABLE: nenhum vídeo é oferecido, porque nenhuma página carregou e a gravação ficaria em branco.
CRASHED: nenhum vídeo é oferecido, porque a gravação de um navegador que morreu sai corrompida.

Apenas as execuções Playwright web e mobile emulado gravam vídeo. Um celular Android real, uma execução Selenium e um teste de API não gravam.

Com o Jira ativado, um TIMEOUT abre um ticket, e um bloqueio, uma falha de navegador e um site inacessível nunca abrem.

Quais são os limites?

A classificação lê o texto do erro. Uma mensagem escrita por você que contenha 403, Forbidden ou Access Denied é interpretada como BLOCKED. Mantenha as mensagens de asserção personalizadas específicas e abra o metadata.json quando um veredito surpreender você.
Um TIMEOUT não prova que a aplicação funciona. Um teste que dá timeout em todas as execuções merece atenção.
Um timeout maior não esconde um elemento quebrado: a falha apenas acontece mais tarde.
Esses vereditos indicam a causa de uma execução que falhou. Eles não eliminam a causa: um site bloqueado continua bloqueado até você mudar a forma como o acessa.

Onde posso ver isso?

A página Evidence acompanha um teste que falhou e lista todos os arquivos que cada veredito deixa no seu disco. O guia de vereditos explica em que ordem o motor decide os 14. O teste gratuito de 30 dias executa o mesmo motor nos seus próprios testes.