Este teste é flaky ou é um bug real?

Um teste flaky falhou e depois passou em um retry sem que ninguém corrigisse nada, e um bug real falha por um motivo que nenhum retry muda. O Nexus Studio, da Verdict System LLC, distingue os dois registrando cada retry: FLAKY para uma falha que um retry fez passar, BREACHED para um achado real e BREACHED_FLAKY para uma falha que é, ela mesma, inconsistente. Um retry nunca transforma um defeito em uma execução verde.

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

O que é um teste flaky?

Um teste flaky é aquele cujas tentativas discordam: falha uma vez e passa em outra tentativa, com o código e o teste inalterados. No Nexus Studio a palavra tem um único significado. FLAKY é um teste que falhou e depois passou em um retry, sem nada corrigido. Algo está instável, na aplicação ou no teste, e nada foi consertado.

Uma falha grave que acontece em todas as tentativas não é flaky, mesmo quando o self-healing tentou reparar um seletor e não conseguiu. Uma versão anterior do motor classificava esse caso como FLAKY. As equipes leem FLAKY como "o teste é ruim" e seguem em frente, então uma aplicação quebrada foi entregue como ruído. O motor não faz mais isso.

Os retries escondem bugs reais?

Podem, e o motivo é o número de estados. Com apenas pass e fail, um retry que passa transforma uma execução vermelha em verde, e um defeito intermitente na aplicação fica invisível. Esse é um dos tipos de bug mais caros de encontrar. Quando vermelho também pode significar uma oscilação de rede ou um navegador morto, a equipe aprende a reexecutar os vermelhos em vez de lê-los, e a suíte perde a confiança.

O Nexus Studio mantém o retry visível. Um teste que falhou e depois passou não é SECURE. Ele sai com código 0 no CI, então não quebra o build, mas aparece no relatório e no History como FLAKY, um pass com ressalva. Veja como os 14 veredictos são decididos para a ordem completa das verificações.

Qual é a diferença entre FLAKY, BREACHED e BREACHED_FLAKY?

• FLAKY: falhou, depois um retry passou, e nada foi reparado. Leia o raw-data.json da tentativa que falhou e depois a tendência no History. Sai com código 0.
• BREACHED: o teste falhou em uma única tentativa, e nenhum padrão de ambiente ou de harness explica o erro. Uma asserção falhou. Este é o relatório de bug, e sai com código 1.
• BREACHED_FLAKY: o teste falhou na última tentativa após um retry anterior, e nenhum padrão de ambiente ou de harness o explica. A própria falha é inconsistente. Compare as tentativas antes de abrir um bug. Sai com código 1.

Dois vizinhos mantêm o quadro honesto. AUTO_RECOVER é um pass em que o self-healing substituiu um seletor, então o locator do autor está morto e o teste não está limpo. Uma primeira tentativa que falhou apenas por tempo e depois passou no retry é SECURE, porque isso mostra latência, não instabilidade.

Antes que uma falha possa ser BREACHED ou BREACHED_FLAKY, o classificador descarta as outras explicações em uma ordem fixa: um erro de harness, um crash, um bloqueio, um host inacessível e um timeout. Só uma falha que nenhuma delas explica é um achado. Por isso um timeout ou um CAPTCHA não chega como relatório de bug.

Como os retries são contados?

O motor lê o número da tentativa da execução. Um teste que passa com número de retry acima de zero é FLAKY, a menos que um seletor tenha sido corrigido, caso em que é AUTO_RECOVER. Um teste que falha ou esgota o tempo com número de retry acima de zero, e sem explicação de ambiente, é BREACHED_FLAKY. Um pass limpo exige retry zero e nenhum seletor corrigido.

FLAKY significa que as tentativas discordaram, e nada além disso. Uma falha em uma única tentativa, com zero retries, nunca é rotulada como flaky. Cada linha do History também registra retry_attempt e attempts, então a contagem fica com a execução.

Que evidências cada veredicto deixa?

• FLAKY: screenshot.png, metadata.json e raw-data.json. A pasta mantém o raw-data.json da tentativa que falhou, então um retry que escondeu a falha ainda deixa o log dela. Isso segue a configuração Keep evidence of a FLAKY / AUTO_RECOVER pass, que vem ativada por padrão.
• BREACHED_FLAKY: report.md, metadata.json, raw-data.json e screenshot.png, e o vídeo da falha é mantido por padrão.
• BREACHED: os mesmos arquivos, com o vídeo mantido por padrão.

O veredito está no nome da pasta de evidências, por exemplo um nome que termina em [BREACHED]. A página Evidence acompanha um teste que falhou por todos os arquivos.

Como o History identifica um teste que oscila?

O History guarda uma linha por execução para cada teste e navegador ou dispositivo, com o veredito, a tentativa de retry e a assinatura do erro. A partir dessas linhas, ele mostra tendências por sessão, dia ou semana: Regressed, Recovered, Still broken e Slower. Um teste que fica verde, vermelho e verde de novo aparece ali, em vez de desaparecer em meio às reexecuções.

O ranking de risco, no Evidence Locker e no Patrol, ordena os testes pela frequência com que oscilam, quebram ou consomem tempo. Ele também mostra um risco previsto, calculado por uma regressão logística sobre o seu histórico, com um fallback de EWMA quando há poucos dados. Nenhum teste é considerado instável com menos de cinco execuções, porque uma ou duas execuções não são suficientes para mostrar um padrão.

Limites

• Os retries são o que separa FLAKY de SECURE e BREACHED_FLAKY de BREACHED. Com os retries desativados, uma falha intermitente é um BREACHED.
• FLAKY indica que as tentativas divergiram. Não indica o motivo. Encontrar a causa, seja na aplicação ou no teste, continua sendo trabalho de uma pessoa.
• A classificação lê o texto do erro, então uma mensagem de asserção personalizada que contenha palavras como 403 ou Forbidden pode ser interpretada como um problema de ambiente. Abra o metadata.json quando um veredito surpreender você.
• Com menos de cinco execuções, o History e o ranking de risco não classificam nada como instável.

Próximos passos

A página Evidence mostra todos os arquivos que um teste com falha deixa, e Como o Nexus Studio decide 14 vereditos de teste explica a ordem das verificações. O teste gratuito de 30 dias executa o mesmo motor nos seus próprios testes.

Para executar a verificação primeiro na sua própria máquina, Como distinguir um bug real de um teste instável? traz um exemplo executável.