Flakiness em testes automatizados: razões e como reduzir

Segundo pesquisas do Google, 84% das falhas que parecem regressões de código em sistemas de CI são, na verdade, causadas por testes instáveis, não por bugs reais. A Atlassian estima que sua organização de engenharia perde mais de 150.000 horas de desenvolvimento por ano investigando falhas geradas por flakiness.

Neste guia, você vai entender o que são flaky tests, quais são as causas mais comuns, como detectá-los na sua suíte e, principalmente, como eliminá-los de forma definitiva: com boas práticas, design de testes mais sólido e o papel crescente da inteligência artificial nesse processo.

O que é um Flaky Test? Definição precisa

Um flaky test (ou teste instável) é um teste automatizado que produz resultados inconsistentes: passa em uma execução e falha em outra, sem que haja qualquer mudança no código da aplicação ou no ambiente de teste. É um comportamento não determinístico, onde os mesmos inputs não garantem os mesmos outputs.

Parece simples, mas a confusão com outras categorias de falha é frequente. Vale diferenciar:

Tipo de falha	Comportamento	O que indica
Flaky test	Falha intermitente, sem padrão	Fragilidade no teste ou no ambiente
Teste quebrado	Falha sempre, de forma consistente	Bug real ou configuração errada
Bug real	Falha reproduzível com passos definidos	Problema na aplicação

Um flaky test não é necessariamente um sintoma de bug na aplicação. É, quase sempre, um sintoma de fragilidade no próprio teste ou no ambiente onde ele é executado.

Ferramentas como Cypress e Selenium, por dependerem de seletores rígidos e scripts estáticos, são particularmente vulneráveis a flakiness quando o layout da aplicação muda. O TestBooster.ai resolve esse problema na raiz: sua IA orientada por intenção interpreta o que o teste quer fazer (não onde clicar no HTML), e se adapta automaticamente a mudanças de UI sem retrabalho.

Por que os flaky tests são tão perigosos?

À primeira vista, um teste que “às vezes falha” parece uma inconveniência menor. Na prática, o impacto é muito maior e se agrava com o tempo.

O custo da instabilidade

Os números da indústria são diretos. Com uma taxa de flakiness de apenas 1,5% em uma suíte de 1.000 testes, você tem aproximadamente 15 testes falhando a cada ciclo de release. Cada falha exige investigação: é um bug real ou apenas ruído? A 30 ou 90 minutos por investigação, isso representa entre 7 e 22 horas de desenvolvimento perdidas por release, perseguindo fantasmas.

Em escala maior: a Atlassian documentou que, no repositório do Jira Frontend, testes instáveis eram responsáveis por até 21% das falhas no build principal. No Slack, antes da implementação de um sistema automatizado de detecção e supressão de flaky tests, apenas 20% dos builds passavam; dos builds com falha, 57% eram causados por testes instáveis, não por erros de compilação ou problemas reais. Após a automação do processo, esse índice caiu para menos de 5%.

Entre 2022 e 2025, a proporção de times que sofrem com flaky tests cresceu de 10% para 26%, um aumento de 160% em três anos, segundo análise da Bitrise sobre mais de 10 milhões de builds mobile.

O efeito “alarme do lobo”

Há um fenômeno bem documentado na medicina chamado alarm fatigue: quando profissionais de saúde são expostos a um volume excessivo de alertas, muitos dos quais são falsos positivos, começam a ignorá-los por reflexo. O resultado pode ser fatal.

Com testes, o mecanismo é o mesmo. Quando a suíte falha com frequência sem motivo real, os desenvolvedores param de tratar as falhas como sinais confiáveis. Quem lida com testes instáveis com mais frequência é significativamente mais propenso a ignorar falhas que poderiam ser bugs genuínos.

Flakiness bloqueia o CI/CD

Pipelines de integração contínua dependem de sinais confiáveis para liberar ou bloquear deploys. Quando os sinais são ruidosos, duas coisas acontecem: ou os times bloqueiam releases desnecessariamente (investigando falhas que não são bugs), ou aprendem a ignorar as falhas e liberam código sem confiança real na qualidade. Nenhum dos dois cenários é aceitável.

As 7 principais causas de flaky tests

Entender a causa raiz é o primeiro passo para resolver o problema. A maioria dos casos de flakiness se encaixa em uma dessas sete categorias.

1. Problemas de sincronização e timing assíncrono

É a causa mais comum. Pesquisa acadêmica sobre 201 correções de flaky tests em projetos Apache identificou que 45% dos casos estão relacionados a problemas de sincronização assíncrona.

O que acontece na prática: o teste tenta interagir com um elemento (um botão, um modal, um campo de formulário) antes que ele esteja disponível na interface. A solução mais usada, porém errada, é adicionar um sleep() fixo: “espera 2 segundos e segue”. Funciona na máquina local, onde o ambiente é rápido. Falha na CI, onde os recursos são disputados e a resposta pode levar mais tempo.

A solução correta é usar esperas dinâmicas: ao invés de esperar um tempo fixo, o teste verifica periodicamente se o elemento está disponível antes de prosseguir. Sem tempo fixo, sem dependência das condições do ambiente.

2. Race conditions e concorrência

Quando múltiplos processos ou testes disputam o mesmo recurso compartilhado, o resultado depende de qual processo chega primeiro. Isso é uma race condition.

Exemplo clássico: Test_CreateUser cria um usuário com ID=123. Test_DeleteUser apaga o usuário com ID=123. Se os dois rodam em paralelo e a deleção acontece antes da criação, o teste falha, embora nenhum dos dois tenha um bug. A ordem de execução determina o resultado, tornando-o não determinístico.

A solução passa por isolamento: cada teste opera sobre seus próprios dados, sem depender do estado criado por outros.

3. Seletores Frágeis (Brittle Selectors)

Esta é a causa mais relevante para times que utilizam ferramentas tradicionais como Selenium, Cypress ou Playwright. Seletores como #btn-checkout-v2, .product-list-item:first-child ou textos dinâmicos vinculados ao layout quebram a cada atualização de interface: um redesign, uma mudança de componente, um teste A/B.

O desenvolvedor não mudou a lógica de negócio. Mudou o HTML. E toda a suíte de testes vai abaixo.

É aqui que o TestBooster.ai se diferencia de forma fundamental. Enquanto ferramentas tradicionais dependem de seletores que precisam ser mantidos manualmente a cada mudança, de layout, o TestBooster usa IA orientada por intenção: os testes são escritos em linguagem natural (“clique no botão de adicionar ao carrinho”, “preencha o campo de e-mail com o usuário de teste”) e a IA interpreta a intenção, não o seletor. Quando a UI muda, o teste continua funcionando, sem retrabalho, sem investigação, sem pipeline quebrada.

4. Dependências externas instáveis

Testes que dependem de APIs de terceiros, bancos de dados compartilhados ou serviços externos são inerentemente mais frágeis. A estabilidade do teste fica vinculada a fatores fora do seu controle: lentidão de rede, rate limiting, indisponibilidade momentânea de um serviço.

A mitigação mais eficaz é o uso de mocks: simular o comportamento do serviço externo dentro do ambiente de teste, garantindo que o teste valide a lógica da aplicação, não a disponibilidade de terceiros. Containerização (Docker, por exemplo) ajuda a criar ambientes reproduzíveis e isolados.

5. Estado compartilhado entre testes (test order dependency)

Quando um teste depende de dados criados por outro teste anterior, a ordem de execução passa a importar. Isso viola um princípio básico de automação: testes devem ser independentes entre si.

O problema se manifesta de forma sutil. Os testes passam quando executados na ordem padrão. Falham ao serem rodados em ordem aleatória ou em paralelo. O diagnóstico é simples (rodar em ordem randomizada) e a correção também: cada teste deve realizar seu próprio setup e teardown, garantindo um estado limpo e previsível.

6. Inconsistências de ambiente

“Passa na minha máquina” é uma das frases mais famosas, e mais frustrantes, do desenvolvimento de software. Quando o ambiente de teste do desenvolvedor difere do ambiente de CI em versão de browser, sistema operacional, versão de biblioteca ou configuração de rede, os resultados divergem.

A solução estrutural é a padronização do ambiente: containerização com Docker garante que o teste rode nas mesmas condições em qualquer lugar. Para testes de UI em múltiplos browsers, ferramentas com suporte à execução padronizada são indispensáveis.

7. Design ruim dos testes

Nem toda flakiness vem do ambiente. Parte vem do próprio teste, mal escrito ou mal estruturado. Testes que validam mais de uma coisa ao mesmo tempo, que usam localizadores baseados em textos dinâmicos ou que não têm assertions claras são naturalmente mais instáveis.

O princípio de responsabilidade única se aplica aqui: cada teste deve validar uma única coisa. Assertions devem ser explícitas e determinísticas. Lógica de espera deve ser clara. Quanto mais simples e focado o teste, menos superfície de falha ele expõe.

8 estratégias práticas para reduzir flakiness

Diagnosticado o problema, é hora de agir. Estas são as abordagens com maior impacto, em ordem de aplicabilidade:

1. Adote esperas dinâmicas: nunca use sleep() fixo. Implemente polling inteligente que verifica a disponibilidade do elemento antes de interagir. Isso elimina a dependência das condições momentâneas do ambiente.
2. Isole seus testes completamente: cada teste deve ser autossuficiente, com seu próprio setup e teardown. Nenhum teste deve depender do estado deixado por outro.
3. Use mocks para dependências externas: simule APIs, bancos de dados e serviços de terceiros dentro do ambiente de teste. Isso remove da equação todos os fatores fora do seu controle.
4. Containerize seus ambientes: Docker garante paridade entre ambiente local e CI. O teste roda nas mesmas condições sempre, independentemente de onde é executado.
5. Elimine seletores frágeis: prefira seletores semânticos, atributos data-testid ou, melhor ainda, ferramentas que não dependem de seletores. IA orientada por intenção elimina esse problema na raiz.
6. Implemente quarentena de testes: testes instáveis identificados devem ser isolados imediatamente, antes de investigar a causa. Não deixe que poluam o pipeline principal.
7. Monitore historicamente a taxa de flakiness: defina métricas claras (ex: “nenhum teste pode falhar mais de 5% das vezes sem mudança de código”) e monitore continuamente. O que não se mede não se melhora.
8. Invista em self-healing com IA: ferramentas que se adaptam automaticamente a mudanças de UI eliminam na raiz a principal fonte de flakiness em testes de interface. 

Ferramentas Tradicionais vs. Abordagem com IA

Ferramenta	Depende de seletores	Resiliente a mudanças de UI	Self-healing	Risco de flakiness por layout
Selenium	Sim (XPath/CSS)	Não	Não	Alto
Cypress	Sim (CSS/data-attr)	Parcial	Não	Alto
Playwright	Sim (locators)	Parcial	Não	Médio
TestBooster	Não (linguagem natural)	Sim	Sim	Muito baixo

Perguntas frequentes sobre flaky tests

O que é um flaky test? 

Um flaky test é um teste automatizado que produz resultados inconsistentes: passa em uma execução e falha em outra sem que haja qualquer mudança no código ou no ambiente. É um comportamento não determinístico que compromete a confiabilidade da suíte de automação e do pipeline de CI/CD.

Qual é a principal causa de flaky tests? 

A causa mais comum é problema de sincronização e timing assíncrono, responsável por cerca de 45% dos casos em projetos Java. Em testes de UI e E2E, seletores frágeis que quebram quando o layout muda são igualmente prevalentes e, muitas vezes, a fonte de instabilidade mais recorrente no dia a dia dos times.

Flaky tests são piores do que não ter testes? 

Em muitos cenários, sim. Um teste que passa 70% das vezes gera falsos negativos que drenam o time. Mais grave: com múltiplos testes instáveis, a suíte como um todo começa a falhar na maioria das execuções, gerando o efeito “alarme do lobo”. Desenvolvedores aprendem a ignorar falhas e bugs reais chegam à produção sem resistência. O fenômeno é detalhado na revisão multivocal publicada no ScienceDirect, que analisou 200 artigos sobre flakiness em pesquisa e prática.

Devo usar retries para resolver flaky tests? 

Retries são um paliativo temporário, aceitável enquanto a causa raiz é investigada. Usá-los como política permanente é contraproducente: mascaram bugs reais, normalizam falhas, aumentam o tempo de CI e degradam a qualidade do sinal de automação ao longo do tempo.

Como a IA ajuda a reduzir flaky tests? 

Ferramentas com IA eliminam a principal causa de flakiness em testes de UI: a dependência de seletores técnicos que quebram a cada mudança de layout. Ao usar IA orientada por intenção, os testes executam com base no que o usuário quer fazer, não em onde está o elemento no HTML. Isso torna a suíte fundamentalmente mais resiliente a evoluções do produto.

Qual a diferença entre flaky test e teste quebrado? 

Um teste quebrado falha sempre, de forma consistente: indica um bug real ou configuração errada, e é relativamente simples de diagnosticar. Um flaky test falha intermitentemente, sem padrão claro, tornando difícil determinar se a falha é ruído ou sinal. Essa ambiguidade é precisamente o que torna a flakiness tão custosa.

O TestBooster elimina flakiness completamente? 

O TestBooster elimina a principal fonte de flakiness em testes de UI e E2E: mudanças de layout. A IA orientada por intenção se adapta automaticamente à interface, sem necessidade de atualizar seletores ou scripts. Para outras causas (timing, dependências externas), a ferramenta fornece relatórios detalhados com capturas de tela e insights acionáveis para que o time identifique e corrija a raiz do problema com eficiência.

Acesse nosso site e veja o TestBooster em ação → testbooster.ai