EN·ES·PT
Automação de testes · protocolo anti-flake

Uma suíte instável é pior que nenhuma suíte.

Quando um run vermelho é só ruído, os engenheiros param de olhar para ele — e na única vez em que o vermelho significa uma regressão real, ela passa direto para produção. A instabilidade não é um incômodo; é a falha do portão inteiro. Este é o protocolo que uso para levar uma suíte de vermelho-como-ruído para vermelho-como-sinal: diagnosticar as fontes, colocar em quarentena e definir uma política de retry, corrigir o isolamento — e manter os testes que você já escreveu.

Prova: 37/37, 0 flakes, 15,3s ↗ Este site roda seu próprio QA ↗ Serviço: Automação de testes & CI ↗
Assista · automação de testes & CI em ~45s
10% → <1%
Taxa de flake da HighStrike, fluxos de trading ao vivo
500+
testes estabilizados em fluxos reais de mercado
37 / 37
specs verdes · 0 flakes · 15,3s (suíte pública)
4h → 75min
Regressão Home Depot, 2.300+ lojas

Cada número aqui vem de trabalho real. Os números públicos apontam para o comprovante — a suíte Playwright está no GitHub e o próprio QA deste site roda ao vivo em eval.html; os números da HighStrike & Home Depot vêm de cargos full-time anteriores e são auto-reportados. Sem números de demo arredondados para cima.

O custo real · por que um comprador deveria se importar

Ruído não só desperdiça tempo. Ele esconde a única falha que importava.

O colapso da confiança

Uma taxa de flake de 10% em uma suíte de 500 testes significa dezenas de falsos vermelhos por run. Os engenheiros aprendem a clicar em "re-executar" por reflexo — e o hábito que limpa o ruído também limpa a única regressão real escondida nele.

O imposto de velocidade

Cada vermelho instável é uma troca de contexto: investigar, descartar, re-executar, esperar. Multiplique isso por uma equipe e por um dia, e a suíte que você construiu para ir mais rápido acaba sendo o que desacelera cada merge.

O portão que não é portão

Um portão de CI só protege você se o vermelho tiver credibilidade. Assim que ele vira ruído, o portão é decorativo — você entrega na base da esperança, com um painel todo verde que passa uma falsa confiança.

A virada · o que o protocolo muda

De vermelho-como-ruído para vermelho-como-sinal.

O objetivo não é uma suíte que está sempre verde. É uma suíte onde um run vermelho significa algo — para que a equipe o leia, confie nele e pare quando ele dispara.

Pipeline instável versus pipeline estável Um pipeline instável emite runs vermelhos aleatórios que são tratados como ruído e re-executados. O protocolo anti-flake — diagnosticar, colocar em quarentena, definir política de retry, corrigir isolamento — o transforma em um pipeline estável onde um run vermelho é um sinal confiável que bloqueia a entrega. ANTES — VERMELHO É RUÍDO Vermelhos aleatórios → "é só re-executar" → regressão real passa PROTOCOLO ANTI-FLAKE 1 · Diagnosticar fontes 2 · Quarentena + retry 3 · Corrigir isolamento DEPOIS — VERMELHO É SINAL bug real PORTÃO DE CI vermelho = bloqueado, acreditado ENTREGAR O verde é confiável. A suíte que você manteve ainda roda. BLOQUEADO A regressão real é pega.
run que passa run que falha o portão
O protocolo não apaga seus testes — ele torna o veredito deles confiável de novo.
O diagnóstico · fonte do flake → correção

A maior parte da instabilidade vem de quatro lugares.

A instabilidade raramente é aleatória — é um sintoma com uma fonte. O protocolo começa nomeando qual delas você tem, porque a correção é diferente para cada uma. É o mapa que eu uso como base.

Fonte do flake → sinal → correção
FonteComo apareceA correção
Timing & corridas Passa localmente, falha no CI; falha sob carga; "resolvido" adicionando um sleep(). Substitua esperas fixas por esperas baseadas em estado (web-first assertions, poll-until-condition). Nunca espere pelo relógio — espere pela aplicação.
Estado compartilhado Só falha quando executado junto com outros testes; um registro "envenenado" deixado por um teste anterior acaba vazando. Isole cada teste: fixtures novas, dados únicos por run, teardown que realmente limpa. Nenhum teste deve depender de outro ter rodado.
Dependência de ordem Verde em uma ordem, vermelho quando o runner embaralha ou paraleliza. Torne os testes independentes de ordem e seguros para paralelismo: sem dependência da sequência de execução, sem singletons globais mutados entre specs.
Ambiente & dados Depende de um terceiro ao vivo, de um registro pré-populado, da hora do dia ou das condições da rede. Controle a fronteira: seeds determinísticos, serviços externos mockados ou testados por contrato, relógios congelados onde o comportamento é sensível ao tempo.

Este é o mesmo diagnóstico que levou a suíte da HighStrike de uma taxa de flake de 10% para menos de 1% — em 500+ testes rodando contra fluxos de trading ao vivo, onde um falso vermelho é caro e um vermelho real ignorado é pior.

O protocolo · como o trabalho corre

Quarentena primeiro. Correção depois. Nunca apagar a suíte.

1 · Faixa de quarentena
  • Specs sabidamente instáveis vão para uma faixa separada e não bloqueante — o CI fica verde-confiável imediatamente
  • Nada é apagado; cada teste em quarentena é uma dívida rastreada com um responsável
  • A suíte bloqueante contém apenas testes em que você pode acreditar hoje
2 · Política de retry
  • Um retry limitado e medido — não um retry indiscriminado que esconde falhas reais
  • Os retries são contados: uma spec que só passa no retry é sinalizada, não celebrada
  • A taxa de flake vira uma métrica no dashboard, para que não possa voltar silenciosamente
3 · Correções de isolamento
  • Reduza a faixa de quarentena, fonte por fonte, usando a matriz acima
  • Cada spec corrigida volta à ativa na suíte bloqueante, comprovadamente estável
  • Você termina com a mesma cobertura com que começou — agora confiável
▸ como eu construo automação de testes & CI Certificado ISTQB CT-AI + Test Automation Engineer
A prova · não uma alegação, um link

Uma suíte pública que roda verde, rápida e livre de flakes.

A suíte pública de regressão

Uma suíte SDET aberta em Playwright que você pode ler e rodar: 37 de 37 specs passando, 0 flakes, run completo em 15,3 segundos. Web-first assertions, fixtures isoladas, seguras para paralelismo — o protocolo desta página, em código que você pode inspecionar.

37/37 specs0 flakes15,3sPlaywright
Este site faz o QA de si mesmo

O site que você está lendo roda seu próprio QA — 100+ verificações, acessibilidade axe-clean — e hospeda uma demo de eval ao vivo. Prova acima de alegações é toda a tese, então a prova está a um clique de distância, não em um PDF de estudo de caso.

100+ verificaçõesaxe-cleandemo ao vivo
▸ a suíte pública Playwright no GitHub ▸ experimente a demo de eval ao vivo
Relacionado · mais sobre testar IA
Contrate um Engenheiro de QA de IA →Consultor de Avaliação de LLM →Avaliação de RAG →Teste de Agentes de IA →

Tem uma suíte em que a equipe deixou de confiar?

Agende uma call e vamos diagnosticar as fontes de flake na sua suíte real — depois colocar em quarentena, corrigir e devolvê-la como um portão em que o vermelho significa algo de novo.

Agende uma call → Serviço de automação de testes & CI →
perguntas frequentes

Perguntas, respondidas.

O que realmente causa testes instáveis?
Quase sempre estado compartilhado, timing e condições de corrida, ou dependências de ordem de execução dos testes — não falta de sorte. Eu diagnostico a fonte em vez de aplicar retry indiscriminadamente.
Você só adiciona retries?
Retries são um paliativo que esconde o sinal. Eu instalo uma faixa de quarentena e uma política de retry enquanto corrijo a causa raiz — isolamento, esperas, fixtures.
Vocês vão reconstruir toda a nossa suíte?
Raramente. Manter sua suíte existente e torná-la confiável é mais rápido e mais barato; uma reconstrução é o último recurso, não o primeiro passo.
Que resultado posso esperar?
Uma suíte rápida e estável onde vermelho significa vermelho. Em um cargo full-time anterior, reduzi a taxa de flake de uma suíte em produção de ~10% para menos de 1% e o tempo de execução de 45 para 8 minutos (auto-reportado).
Como você mede nossa taxa real de flake antes de começar?
Eu re-executo sua suíte em várias rodadas de CI sobre o mesmo código, sem alterações, e conto os testes que alternam entre passar e falhar. Isso dá uma taxa real de flake e uma lista ranqueada dos piores culpados antes de eu tocar em qualquer coisa.
Qual é a política de quarentena — testes instáveis são desabilitados?
Testes instáveis vão para uma faixa de quarentena, não para o lixo. Eles continuam rodando e reportando, mas param de bloquear o pipeline principal enquanto corrijo a causa raiz, e depois voltam à ativa quando se mostram estáveis.
Quanto tempo leva para ficar abaixo de um por cento?
Depende do tamanho da suíte e de quão profundas são as fontes de flake. Eu coloco em quarentena cedo para que seu pipeline se torne confiável rápido, e depois trabalho as correções de causa raiz em ordem de prioridade.
Isso funciona com nossa suíte existente ou exige uma reescrita?
Funciona com sua suíte existente. Seja com Playwright, Pytest ou outro framework, eu estabilizo o que você já tem em vez de começar do zero — uma reconstrução é o último recurso.
Como você encontra a causa raiz de um teste instável?
Eu isolo o teste que falha, executo na ordem e fora dela e inspeciono estado compartilhado, timing e fixtures até a falha se reproduzir sob demanda. Um flake que você consegue reproduzir é um bug que você consegue corrigir.
O que ficamos ao final que impede o flake de voltar?
Uma suíte estabilizada mais as proteções que a mantêm assim — uma faixa de quarentena, uma política de retry e padrões de isolamento que sua equipe aplica a novos testes. O sinal permanece confiável depois que eu saio.