Como distinguir um bug real de um teste instável?

Execute o teste várias vezes com retries desativados e conte. Um bug real falha do mesmo jeito em todas as execuções, e um teste instável passa em algumas execuções e falha em outras sem que nada tenha mudado. O exemplo abaixo faz exatamente isso em qualquer máquina com Playwright e depois mostra o que o Nexus Studio faz com cada resultado.

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

Como distingui-los em um minuto?

Execute o teste várias vezes seguidas com retries desativados. O Playwright faz isso com duas flags: --retries=0, para que uma nova tentativa não esconda uma falha, e --repeat-each=6, que executa cada teste seis vezes. Depois, conte os resultados de cada teste.

• Falhou todas as vezes: trate como um bug até conseguir provar o contrário. Uma falha em todas as execuções ainda pode vir do ambiente, como uma requisição bloqueada ou um host inacessível, então leia o erro primeiro.
• Passou em algumas execuções e falhou em outras: é instável. O código e o teste não mudaram entre essas execuções, então há algo instável envolvido, na aplicação ou no teste.
• Passou todas as vezes: ainda não há nada a investigar. Um defeito que aparece uma vez a cada cinquenta execuções exige mais execuções ou uma olhada no History do teste.

Posso testar em um exemplo executável?

Salve isto como bug-or-flaky.spec.js. O primeiro teste simula uma instabilidade: falha em uma de cada três execuções. O segundo teste é um bug real: a página diz "Welcome" e o teste espera "Welcome back", então nenhuma execução consegue passar.

import { test, expect } from '@playwright/test';

// Fails on its first attempt of every third run, passes otherwise: a simulated flake.
test('flaky: a slow load now and then', async ({ page }, info) => {
    await page.setContent('<h1>Welcome</h1>');
    expect((info.repeatEachIndex + info.retry) % 3, 'simulated slow load').not.toBe(0);
});

// Fails the same way every time: the heading says "Welcome", the test expects "Welcome back".
test('real bug: wrong heading', async ({ page }) => {
    await page.setContent('<h1>Welcome</h1>');
    await expect(page.locator('h1')).toHaveText('Welcome back', { timeout: 300 });
});

Execute seis vezes com retries desativados:

npx playwright test --retries=0 --repeat-each=6

O Playwright termina com 8 falhas e 4 aprovações. A contagem por teste é o que responde à pergunta, e é o que o list reporter exibiu, linha por linha:

flaky: a slow load now and then    4 passed, 2 failed
real bug: wrong heading            0 passed, 6 failed

Agora execute uma vez com dois retries:

npx playwright test --retries=2

O Playwright termina com um teste em cada grupo. O teste instável falhou na primeira tentativa e passou na nova tentativa nº 1. O bug real falhou nas três tentativas.

1 failed
  bug-or-flaky.spec.js:10:1 › real bug: wrong heading
1 flaky
  bug-or-flaky.spec.js:4:1 › flaky: a slow load now and then

Uma nova tentativa aprovada significa que a aplicação está bem?

Não. Uma nova tentativa que passa só indica que as tentativas divergiram, nada mais. Se a execução fica verde e ninguém olha, um defeito intermitente na aplicação, como uma condição de corrida, dados compartilhados ou uma dependência lenta, fica invisível, e esses estão entre os defeitos mais caros de encontrar. Leia um resultado flaky como uma descoberta, não como um pass a ser ignorado, e não presuma que a falha está no teste.

O que o Nexus Studio faz com cada resultado?

O Nexus Studio registra cada tentativa e dá ao resultado um veredito próprio, de modo que um retry nunca transforma um defeito em uma execução verde comum.

• FLAKY: o teste falhou, depois um retry o aprovou, e nada foi corrigido. Ele sai com código 0, então o build não quebra, e o relatório e o History mostram a ressalva.
• BREACHED: o teste falhou em uma única tentativa, e nenhum padrão de ambiente ou de harness explica o erro. Ele sai com código 1.
• BREACHED_FLAKY: o teste falhou na última tentativa depois de um retry anterior, e nenhum padrão de ambiente o explica. Ele sai com código 1. Compare as tentativas antes de abrir um bug.

O History guarda uma linha por execução de cada teste, de modo que um teste que fica verde, vermelho e verde de novo aparece como uma tendência, em vez de desaparecer em reexecuções. O guia de testes flaky lista os arquivos que cada veredito deixa.

Quais são os limites?

• O flake do exemplo é simulado com aritmética para que se repita. A instabilidade real tem uma causa, e encontrá-la ainda é trabalho para uma pessoa.
• Seis execuções são uma triagem rápida, não estatística. Uma falha que ocorre uma vez em cinquenta execuções pode passar seis vezes.
• Uma falha em toda execução nem sempre é um bug na sua aplicação: uma rede lenta, uma página de bloqueio ou um navegador morto também fazem testes falharem. O guia de falsas falhas mostra como diferenciar.
• Com os retries desligados, uma falha intermitente no Nexus Studio vira um BREACHED, porque só um retry consegue distinguir FLAKY de uma falha comum. A classificação lê o texto do erro, então abra o metadata.json quando um veredito te surpreender.

Onde posso ver isso?

O guia de vereditos explica em que ordem o mecanismo decide os 14 vereditos, e a página Evidence acompanha um teste que falhou por todos os arquivos que ele deixa. O teste gratuito de 30 dias executa o mesmo mecanismo nos seus próprios testes.