Um teste flaky (ou teste instável) é um teste que produz resultados diferentes — aprovação ou falha — para o mesmo código e a mesma configuração, sem nenhuma modificação no sistema testado. Ele falha hoje, passa amanhã, falha de novo na semana que vem, sem que ninguém tenha tocado no código.
Aqui vai uma opinião que pode incomodar: um teste visual flaky é pior do que nenhum teste. E não é provocação gratuita. Um teste ausente não custa nada no dia a dia. Não bloqueia seu pipeline de CI/CD. Não consome o tempo da sua equipe. Não destrói a confiança na infraestrutura de testes. Um teste flaky faz tudo isso, todos os dias, de forma insidiosa — porque cada falha falsa se parece o suficiente com uma falha real para exigir investigação.
Os dados do Google sobre seus próprios sistemas de teste são eloquentes: aproximadamente 1,5% de seus testes são flaky a qualquer momento, mas esses testes consomem uma parcela desproporcional do tempo de engenharia. Se uma empresa do tamanho e da competência técnica do Google não conseguiu eliminar o problema, não é uma questão trivial. E no domínio específico do teste visual, o problema é amplificado pela própria natureza do que está sendo comparado.
Por que os testes visuais são particularmente vulneráveis à instabilidade
O teste visual automatizado introduz uma camada de não-determinismo que testes unitários ou funcionais não possuem. Um teste unitário verifica se uma função retorna o valor correto. Um teste funcional verifica se um botão dispara a ação certa. Esses resultados são binários e determinísticos.
O teste visual verifica se a renderização da sua interface corresponde a uma imagem de referência (captura de referência). E a renderização de uma página web é o resultado de uma cadeia complexa de processos, cada um introduzindo sua própria variabilidade: análise do HTML, aplicação de CSS, execução de JavaScript, carregamento de recursos externos, cálculo de layout, rasterização e composição. Cada etapa pode variar de uma execução para outra.
As quatro causas principais dos testes visuais flaky
Timing: o problema que você não pode ignorar
A web é assíncrona por natureza. Quando você pede ao navegador para capturar um screenshot, a página está realmente pronta? A resposta é quase sempre: depende.
O carregamento de uma página não é um evento único — é uma cascata de eventos. O HTML é analisado, o CSS é aplicado, os scripts são executados, as imagens carregam, as web fonts são aplicadas, as requisições à API retornam dados. Cada etapa tem duração variável. A estratégia clássica de esperar pelo estado "pronto" — DOMContentLoaded, evento load ou network idle — não garante que a renderização visual esteja completa.
Resultado: seu screenshot às vezes captura uma página completa, às vezes uma página no meio da renderização, com elementos desalinhados ou fontes ainda não carregadas.
Animações: movimento em um meio estático
Um screenshot é uma imagem fixa. Uma animação é mudança contínua. Os dois são fundamentalmente incompatíveis para comparação automatizada. Se a sua página contém uma animação de 300ms que dispara ao carregar, o momento exato da captura em relação ao início da animação varia entre as execuções.
Animações infinitas (spinners, skeleton loaders, pulsos de loading) são ainda piores: não existe um momento "estável" para capturar o screenshot. Cada execução congela a animação em um ponto diferente, gerando uma diferença visual detectada pelo algoritmo de comparação.
Conteúdo dinâmico: tudo que muda sem você
Datas, horários, anúncios publicitários, avatares gerados aleatoriamente, notificações em tempo real, contadores de visitantes — tudo varia entre as execuções de teste. Cada variação é detectada como uma diferença visual. Cada diferença falha o teste.
Rede e infraestrutura: variáveis que você não controla
Seu teste roda em um ambiente que depende de recursos externos: servidores de API, CDN para imagens e fontes, serviços de terceiros (analytics, chat widgets, mapas). A latência varia entre execuções. Em um pipeline de CI/CD, o problema é amplificado — seu runner CI compartilha recursos com outros jobs, e a concorrência introduz ainda mais variabilidade.
O custo real dos testes flaky
O custo mais visível é o tempo de triagem. Cada falha de um teste flaky exige investigação: alguém precisa olhar os resultados, comparar manualmente, decidir se é real ou falsa, e relançar se necessário. Em uma equipe de 5 pessoas, isso pode representar horas por semana.
Mas o custo mais destrutivo é invisível: a perda de confiança. Quando uma equipe aprende que os testes visuais falham "o tempo todo" sem razão, ela desenvolve um reflexo automático de relançamento. O dia em que um teste falha devido a um bug real, o reflexo é o mesmo: relançar. E o bug chega à produção.
Esse fenômeno tem um nome: o efeito "chamar o lobo". Uma vez estabelecido, é muito difícil de reverter.
Estratégias de estabilização que funcionam
Controlar o ambiente de renderização
Use um navegador headless em um container controlado com resolução fixa, fontes pré-instaladas e configuração de rede determinística. Congele a versão do navegador, desative a renderização por GPU, configure um tamanho de viewport fixo. Quanto mais variáveis você eliminar do ambiente, mais estáveis serão os resultados.
Neutralizar as animações
Injete uma folha de estilo que force todas as animações e transições a duração zero. Isso congela instantaneamente todos os elementos animados no seu estado final, eliminando uma das maiores fontes de instabilidade. Uma única linha CSS — *, *::before, *::after { animation-duration: 0s !important; transition-duration: 0s !important; } — resolve o problema na maioria dos casos.
Estabilizar o conteúdo dinâmico
Fixe datas e horas (use data mockada), desative widgets de terceiros, mocke os dados da API, substitua avatares gerados por imagens estáticas nos fixtures de teste. O objetivo é criar um ambiente onde a única variável seja o código da sua interface — nada mais.
Esperar inteligentemente
Em vez de atrasos fixos (espere 3 segundos), use estratégias de espera baseadas no estado real da página. Espere que os elementos críticos estejam visíveis, que as imagens estejam carregadas, que as fontes estejam aplicadas, que as requisições de rede estejam concluídas. Ferramentas modernas oferecem APIs de espera inteligente que monitoram o estado da página em vez de confiar em timers arbitrários.
Adotar uma comparação que tolere ruído
A comparação pixel a pixel é a mais sensível ao não-determinismo de renderização. Algoritmos perceptuais (SSIM, pHash) são mais tolerantes. A abordagem estrutural — comparar o DOM e as propriedades CSS computadas em vez de pixels — é a mais resistente ao ruído de renderização, porque ignora nativamente as variações de sub-pixel que causam a maioria das falhas intermitentes.
O teste visual no-code como solução ao problema de manutenção
Testes visuais baseados em código (Playwright, Cypress, Selenium) exigem scripts que navegam, interagem e capturam. Esses scripts são, por si mesmos, uma fonte de instabilidade: um seletor CSS que não encontra mais o elemento, um timing de clique que erra o alvo, um gerenciamento de estado que falha.
Ferramentas no-code como o Delta-QA eliminam essa camada de fragilidade. Você não escreve scripts — configura seus testes visualmente. A ferramenta cuida do carregamento, da espera, da estabilização e da comparação. Quando um elemento muda de seletor, a ferramenta se adapta sem intervenção manual.
Quando deletar um teste flaky
Se um teste visual falha intermitentemente apesar de todas as tentativas de estabilização, a decisão mais corajosa — e frequentemente mais sábia — é deletá-lo. Um teste flaky que ninguém corrige degrada ativamente seu pipeline. Ele treina sua equipe a ignorar falhas.
Delete-o, documente o porquê e substitua-o por uma verificação mais pontual e direcionada. O objetivo não é ter o máximo de testes — é ter testes nos quais sua equipe confia.
FAQ
Qual é a diferença entre um teste flaky e um falso positivo?
Um falso positivo sinaliza um problema que não existe. Um teste flaky produz resultados inconsistentes de uma execução para outra para o mesmo código.
Como medir a taxa de flakiness dos seus testes visuais?
Execute a mesma suíte de testes visuais várias vezes sem alterar o código e conte os testes cujo resultado muda entre as execuções. Cinco execuções consecutivas bastam para identificar os testes mais instáveis.
Testes visuais no-code são menos flaky do que testes com código?
Eles eliminam uma categoria inteira de flakiness — a fragilidade dos scripts de teste (seletores quebradiços, timing de navegação, gerenciamento de estado). Mas continuam sujeitos às mesmas restrições de renderização do navegador.
Deve-se relançar automaticamente os testes visuais que falham?
Retry é um paliativo, não uma solução. Ele mascara o problema. Se precisar habilitar retries, limite a um e marque os testes que precisaram de retry para investigação posterior.
Qual é o limiar de flakiness aceitável em CI/CD?
Mire abaixo de 1% do total da sua suíte de testes. Acima de 3%, o impacto na produtividade se torna mensurável. Acima de 5%, sua equipe quase certamente desenvolve o reflexo de relançar sistematicamente os pipelines que falham.
O Delta-QA ajuda a estabilizar testes visuais?
Delta-QA reduz a flakiness na origem usando uma abordagem estrutural em vez da comparação pixel a pixel. Variações de sub-pixel rendering, antialiasing e problemas de timing que causam a maioria das falhas intermitentes são ignorados nativamente. Combinado com a abordagem no-code que elimina scripts de teste frágeis, o Delta-QA produz resultados de teste confiáveis e reprodutíveis sem configuração complexa.
Para aprofundar
- Falsos Positivos em Teste Visual: Por Que Eles Matam Seus Testes e Como Eliminá-los
- Bugs Visuais e SEO: Como o CLS Destrói o Seu Posicionamento no Google (e Como o Teste Visual o Previne)
- Por Que Seu Site Aparece Diferente em Cada Navegador (E Como Corrigir)
- LGPD e Testes Visuais: Por Que Suas Capturas Não Devem Sair do Brasil
Um teste visual só tem valor se a sua equipe confia nele. Testes flaky destroem essa confiança dia após dia. Em vez de gastar tempo estabilizando scripts frágeis e triando falsas falhas, adote uma ferramenta projetada para confiabilidade desde o início.