Passou ou falhou não basta: como 14 veredictos são decididos

Um teste vermelho deveria significar que a aplicação está quebrada. Quando vermelho também pode significar que o DNS falhou, que o site exibiu um CAPTCHA ou que o navegador morreu, a equipe aprende a reexecutar os vermelhos em vez de lê-los, e o defeito real se esconde no ruído. O Nexus Studio dá a cada execução um entre 14 veredictos, em vez de dois. Esta página explica como o motor escolhe um deles, na ordem em que decide, e onde o método tem limites.

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

Quais são os 14 verdicts?

Os 14 verdicts são SECURE, CHAOS_RESILIENT, AUTO_RECOVER, FLAKY, PERFORMANCE_DEGRADED, A11Y_VIOLATION, SECURITY_VIOLATION, BREACHED, BREACHED_FLAKY, CHAOS_BREACHED, TIMEOUT, UNREACHABLE, BLOCKED e CRASHED. Eles se dividem em quatro grupos: passou, passou com ressalva, a aplicação quebrou, e nenhum verdict sobre a aplicação porque o ambiente ou o harness é o culpado.

Como o engine decide um verdict?

O engine faz três perguntas, nesta ordem:

1. O teste chegou a produzir um resultado?
2. Se passou, passou de forma limpa?
3. Se falhou, de quem é a culpa: do harness, do ambiente ou da aplicação?

Só uma resposta é um relatório de bug: uma falha que pertence à aplicação. Todas as outras respostas são informação sobre outra coisa, e recebem um nome que deixa isso claro.

Quando um teste não recebe nenhum verdict?

Três estados não fazem parte dos 14, porque nenhum deles diz algo sobre a sua aplicação: SKIPPED (o teste nunca foi executado), INTERRUPTED (Ctrl+C, um limite de --max-failures ou um timeout global o interrompeu) e CONFIG_ERROR (o harness não conseguiu iniciá-lo). Nenhum deles cria uma pasta de evidências nem uma linha no History.

O INTERRUPTED existe por um motivo concreto. Sem ele, um teste interrompido caía no ramo de pass e era registrado como SECURE: um veredicto verde para um teste que nunca terminou.

Como uma aprovação é avaliada?

• SECURE: passou na primeira tentativa, e nada foi reparado.
• AUTO_RECOVER: passou, mas o self-healing precisou substituir um seletor neste teste. O locator que o autor escreveu está morto, e a próxima mudança na página quebra a suíte de verdade, por isso um pass corrigido nunca é reportado como limpo. Corrija o seletor original.
• FLAKY: falhou, depois um retry passou, e nada foi corrigido. Algo está instável, na aplicação ou no teste, e nada foi consertado.

Uma exceção: quando a primeira tentativa falhou apenas por esgotar o tempo e o retry passou, o veredicto é SECURE. Esse pass mostra latência, não instabilidade.

Como uma falha recebe um verdict?

Quando um teste falha, o motor lê a mensagem de erro e o log de rede da execução e os compara com grupos de padrões em uma ordem fixa. O primeiro grupo que corresponde decide o veredicto, então a ordem faz parte do design.

1. CONFIG_ERROR primeiro: Cannot find module, um ReferenceError ou SyntaxError, uma variável de ambiente ausente, uma fixture que falhou no setup. Se o harness nunca iniciou, qualquer sintoma posterior é consequência disso. Os padrões são deliberadamente restritos, limitados a erros que só o código de teste ou o seu ambiente podem produzir: um CONFIG_ERROR a mais culparia o harness por um bug real na sua aplicação.
2. CRASHED: Target closed, Page crashed, um erro do protocolo DevTools, SessionNotCreatedError, um invalid session id. O navegador ou o driver morreu. É infraestrutura: olhe a máquina e o driver.
3. BLOCKED: um 403 ou um 429 no erro ou no log de rede, um CAPTCHA, uma página de acesso negado ou um desafio anti-bot que o motor reconheceu na tela. O site se defendeu, e a requisição nunca chegou ao seu produto.
4. UNREACHABLE: a rede disse não antes de qualquer página ser observada: o nome não foi resolvido (net::ERR_NAME_NOT_RESOLVED no Chromium, NS_ERROR_UNKNOWN_HOST no Firefox, Could not resolve hostname no WebKit), a conexão foi recusada ou a máquina estava offline. Um erro de certificado não entra aqui: ele é um achado.
5. TIMEOUT: o Timeout 30000ms exceeded do Playwright, o Wait timed out after do Selenium, um TimeoutError ou um teste que o Playwright marcou como esgotado. Uma navegação que esgotou o tempo é um TIMEOUT, não UNREACHABLE: ela começou, e a página estava lenta.
6. BREACHED_FLAKY: nada acima explica a falha, e o teste já havia sido repetido. Ele falhou, e a própria falha é inconsistente. Compare as tentativas antes de abrir um bug.
7. BREACHED: nada acima explica a falha, em uma única tentativa. Uma asserção falhou, e nenhum padrão de ambiente ou de harness justifica o erro. Este é o relatório de bug.

Cada grupo cobre a redação tanto do Playwright quanto do Selenium WebDriver. Antes de os padrões do Selenium existirem, um TimeoutError do WebDriver e um SessionNotCreatedError de um chromedriver desatualizado eram reportados como BREACHED, como se a aplicação tivesse um defeito.

Um celular Android real que não consegue assumir a execução, porque entrou em repouso ou está bloqueado, também é BLOCKED: um pré-requisito não atendido, não uma falha do produto. A regra nasceu de um caso medido. Um celular entrou em repouso no meio de uma campanha, e um teste de login que tinha passado quatro vezes seguidas apareceu como um vermelho crítico.

Como as execuções de caos são julgadas?

Quando a execução injeta falhas do Chaos Lab, o veredicto responde a outra pergunta: a aplicação aguentou? Um pass, SECURE ou AUTO_RECOVER, vira CHAOS_RESILIENT. Qualquer outro resultado vira CHAOS_BREACHED, incluindo um pass FLAKY e um TIMEOUT, porque sob uma falha injetada isso é o impacto. SKIPPED, INTERRUPTED e CONFIG_ERROR permanecem como estão: um teste que não rodou não diz nada sobre resiliência.

Quais verificações rígidas podem alterar uma aprovação?

Três verificações rodam ao lado das suas asserções: cabeçalhos de segurança, acessibilidade com axe-core e orçamentos de desempenho para Web Vitals e lazy loading. Elas registram o que encontram a cada execução. Só mudam o veredicto quando você as torna estritas em Settings. Em uma aplicação existente, qualquer uma delas deixaria a suíte inteira vermelha no primeiro dia, e uma suíte sempre vermelha é uma suíte que ninguém lê.

Quando estão estritas, elas se aplicam apenas a um teste que passou, nesta ordem: SECURITY_VIOLATION, A11Y_VIOLATION, PERFORMANCE_DEGRADED. A segurança vem primeiro porque, das três, é a que pode terminar em um incidente e não em uma reclamação. Um teste que falhou nunca é escalonado: BREACHED já diz algo mais grave, e um aviso por cima esconderia o achado.

O que o CI enxerga?

Os sete veredictos de pass saem com código 0: SECURE, AUTO_RECOVER, FLAKY, CHAOS_RESILIENT, PERFORMANCE_DEGRADED, A11Y_VIOLATION e SECURITY_VIOLATION. Uma ressalva aparece no relatório e no History, não como um build quebrado. Os outros sete saem com código 1. Os runners de pytest e Selenium saem com código 2 quando a execução não pôde começar, por exemplo sem Python ou com um navegador para o qual o motor não tem driver.

Quais são os limites do método?

• A classificação lê o texto do erro. Uma mensagem escrita por você que contenha 403, Forbidden ou Access Denied é lida como BLOCKED, e um erro que contenha is not a function é lido como CONFIG_ERROR. Mantenha as mensagens de asserção personalizadas específicas e abra o metadata.json quando um veredicto o surpreender.
• Um TIMEOUT não é prova de que a aplicação funciona. Ele diz que a execução não consegue concluir. Um teste que dá timeout em toda execução merece atenção.
• Os retries são o que separa FLAKY de SECURE e BREACHED_FLAKY de BREACHED. Com os retries desativados, uma falha intermitente é um BREACHED.
• Os testes de API têm sete veredictos próprios, decididos por outras regras: veja testes de API.

Onde posso ver um verdict em uma falha real?

A página Evidence acompanha um teste que falhou e lista cada arquivo que cada veredicto deixa no seu disco: report.md, metadata.json, raw-data.json, uma captura de tela e, para uma falha real, o vídeo. O teste de 30 dias executa o mesmo motor nos seus próprios testes.