Flaky Tests: O Problema Não São os Testes, É a Confiança

VictorOliveira — Wed, 19 Aug 2026 18:09:33 +0000

Flaky Tests: O Problema Não São os Testes, É a Confiança

Um desenvolvedor aperta "merge". O pipeline fica vermelho. Ele clica em "re-run". Passa verde. Merge feito. Ninguém investiga.

Esse cenário se repete milhões de vezes por dia em empresas ao redor do mundo. E é exatamente aí que mora o problema: não são os testes que estão quebrados — é a confiança no pipeline que se destruiu.

Os Números Que Ninguém Quer Ver

Google: 1,5 milhão de reruns de testes flaky por dia no pico
Atlassian: 21% das falhas no master branch são causadas por flaky tests — totalizando 150.000 horas de desenvolvedores desperdiçadas por ano
SAP HANA: Análise de 559 reports de flakiness mostrou que 23% são causados por problemas de concorrência
Exact: Uma empresa com 2.000 funcionários e 25.000 testes diários tinha taxa de sucesso de pipeline de apenas 27% antes de atacar flakiness

Flaky tests não são uma inconveniência técnica. São um problema de economia de entrega. E ele se compõe.

O Ciclo da Desconfiança

O ciclo é previsível e acontece em 6-8 semanas:

Semana 1-2: Flaky tests começam a aparecer. Desenvolvedos culpam seu próprio código.

Semana 3: Eles percebem o padrão — mesmos testes, mesmas falhas, nada a ver com suas mudanças.

Semana 6: Mentalmente, desistiram. Toda a suíte se torna suspeita, inclusive os testes que funcionam perfeitamente.

Semana 8: O pipeline perde toda credibilidade. O que antes era uma barreira de qualidade vira um obstáculo irritante.

O indicador-chave? Taxa de re-run. Quando desenvolvedores clicam "retry" em mais de 30% dos seus PRs, eles não estão testando — estão apostando. Abaixo de 30%, eles confiam que a falha é deles. Acima de 30%, confiam que a falha é da infraestrutura.

As 5 Causas Raiz (Nenhuma É "Azar")

Flakiness quase nunca é aleatório. Há padrões identificáveis:

1. Corridas de Tempo (Timing Races)

A causa mais comum. Um sleep(5000) hardcoded que funciona 99% do tempo, mas falha quando o CI está sob carga. Ou uma.assert que verifica o estado antes da UI terminar de renderizar.

// RUIM — depende de timing fixo
await page.waitForTimeout(2000);
expect(await page.textContent('.result')).toBe('Sucesso');

// BOM — espera pela condição real
await expect(page.locator('.result')).toHaveText('Sucesso');

Playwright resolve isso com auto-wait nativo. Cypress tem retry automático de comandos. Mas a regra universal é: nunca asserte em um timer, sempre no estado estabelecido.

2. Estado Compartilhado (Test Interdependence)

O teste A cria um registro no banco. O teste B depende desse registro. O teste C deleta algo que o teste D precisa. Resultado: a ordem de execução determina se o build passa ou falha.

# RUIM — fixture global compartilhada
@pytest.fixture(scope="session")
def db_connection():
    return create_connection()

# BOM — isolamento por teste
@pytest.fixture
def db_connection():
    conn = create_connection()
    yield conn
    conn.rollback()  # Limpa tudo após o teste

Teste de sanidade: Se você embaralhar a ordem dos testes e o suite quebrar, existe acoplamento oculto que retries esconderiam pra sempre.

3. Ambiente Instável (Environment Flakiness)

APIs externas com latência variável, containers que demoram para subir, dados de teste compartilhados entre pipelines. Um estudo do Docker descobriu que após um ano tentando consertar testes individualmente, a estabilidade não melhorou — até que investiram na infraestrutura do ambiente de teste.

4. Dependências de Rede

Chamadas HTTP reais em testes E2E. Timeouts que variam dependendo da carga do servidor. Webhooks que chegam antes ou depois do esperado.

5. Animações e Transições

Elementos que estão em transição CSS quando o teste tenta interagir. Modais que estão animando abrindo. Toasts que somem após 3 segundos.

Por Que Retries São o Pior Remédio

A indústria tratou flaky tests como um problema de agendamento. Retry 3 vezes, se passar, tá verde. Mas retries não consertam — escondem.

Dimensão	Retries às cegas	Quarantine + fix
Sinal de falha	Oculto, descartado	Preservado e classificado
Tempo/custo de CI	Cresce silenciosamente	Diminui com o tempo
Confiança no deploy	Verde falso, bugs passam	Verde confiável
Causas raiz	Se acumulam	Caminham a zero
Confiança do dev	Erosiona	Se restaura

O pior cenário: um teste que falha 20% do tempo passa quase sempre com política de 3 retries. Parece estável, mas não é. Quando finalmente deixa passar uma regressão real no retry "sortudo", vocêshipa o bug confiando no checkmark verde.

Um pipeline com taxa de retry de 15% e pass rate de 98% não é um pipeline saudável. É um pipeline com um problema de confiança escondido.

A Estratégia de Quarantine

A alternativa aos retries é o quarantine — isolar testes flaky sem deletá-los, mantendo visibilidade enquanto resolve a causa raiz.

Como Implementar

1. Detectar automaticamente

Registre resultados por teste, por commit SHA. Um teste que passa E falha no mesmo SHA é flaky por definição.

# Exemplo de detecção via histórico
def is_flaky(test_name, sha, results):
    statuses = [r.status for r in results if r.test == test_name and r.sha == sha]
    return 'pass' in statuses and 'fail' in statuses

2. Separar em duas suítes

Blocking suite: testes estáveis. Falha aqui bloqueia o merge.
Quarantine suite: testes flaky conhecidos. Executam, mas não bloqueiam.

3. Dono e prazo

Cada teste em quarantine tem um dono e um ticket. Prazo máximo: 30 dias. Depois disso: consertar ou deletar com justificativa.

4. Monitorar

Tamanho do quarantine ao longo do tempo (crescendo = problema)
Dias em quarantine por teste (máximo 30)
Taxa de entrada/saída (fluido = saudável)

Resultado Real

A Exact aplicou essas intervenções e elevou a taxa de sucesso do pipeline de 27% para 96%. O segredo não foi consertar todos os testes — foi classificar, isolar e atacar as causas raiz: tarefas de banco redundantes (40% das falhas) e dados de teste poluídos (22%).

Métricas Que Importam

Esqueça pass rate. Essas métricas contam a verdadeira história:

Métrica	Como calcular	Meta
Flake rate	Testes com pass/fail misto no mesmo commit / total	< 2%
Taxa de retry	Jobs que passam só no retry / total de jobs	< 2%
Quarantine %	Testes em quarantine / total de testes	< 5%
Custo de retry	Minutos de retry / minutos totais de CI	< 10%
Tempo para confiança	Tempo até o dev confiar que o merge é seguro	< 10 min

O Que a Pesquisa Diz Sobre IA e Flakiness

Um dado que pega desprevenido: testes gerados por IA aumentam a taxa de flakiness. LLMs são competentes em gerar scaffolding de testes, mas frequentemente criam asserts frágeis — dependência de timing, assumptions hardcoded sobre o ambiente, e mocks excessivamente específicos.

Antes de jogar um Copilot na suíte de testes, modernize a infraestrutura de teste primeiro. Caso contrário, você vai aumentar a taxa de flakiness com confiança.

Aprender com Google, Atlassian e SAP

Google descobriu que 84% das transições de pass para fail vêm de flakiness, não de bugs reais. Isso significa que quase toda falha que seu time investiga é fantasma.

Atlassian quantificou o custo: 150.000 horas/ano desperdiçadas. Quando flaky tests causam 21% das falhas no master, o problema não é mais técnico — é financeiro.

SAP HANA analisou 559 reports de flakiness usando LLMs como anotadores. Concorrência (23%), timeouts (18%), e fragilidade de oráculos (11%) foram as principais causas. Cada tipo de teste enfrenta desafios diferentes.

Conclusão: Trust Over Green

Um build verde que ninguém acredita é pior que nenhum build. Porque ele fornece confiança falsa no exato momento em que você precisa de confiança real: enviando para produção.

A regra é simples:

Pare de medir pass rate. Meça taxa de retry.
Pare de consertar cada flaky test. Quarantine os piores 5%.
Pare de celebrar builds verdes. Celebre pipelines confiáveis.
Nunca faça retry de vermelho para verde. Isso é mentira.

Confiança não é binária. Não se perde gradualmente — despenha de um penhasco. E recuperá-la é muito mais difícil do que perdê-la.

Seu pipeline mente? A resposta define se você pode confiar na sua automação ou se está apenas apertando botões.

Baseado em pesquisas do Google, Atlassian, SAP, Exact, Docker, e artigos de DevOps.com, SD Times, e ContextQA (2026).

Design Patterns para Automação de Testes: Guia Prático com Playwright e Cypress

VictorOliveira — Wed, 19 Aug 2026 17:48:06 +0000

Design Patterns para Automação de Testes: Guia Prático

Se você já escreveu automação de testes, provavelmente já enfrentou aquele momento em que os testes ficam tão acoplados que qualquer mudança quebram dezenas de scripts. É aí que os Design Patterns entram.

Neste artigo, vamos ver os padrões mais usados na indústria, com exemplos práticos em Playwright e Cypress.

1. Page Object Model (POM)

O mais clássico e amplamente adotado. Separa a lógica de localização dos elementos da lógica dos testes.

// Playwright - Page Object
class LoginPage {
  constructor(private page: Page) {}

  private emailInput = () => this.page.locator('#email');
  private passwordInput = () => this.page.locator('#password');
  private submitButton = () => this.page.locator('button[type=submit]');

  async login(email: string, password: string) {
    await this.emailInput().fill(email);
    await this.passwordInput().fill(password);
    await this.submitButton().click();
  }
}

Vantagens: Manutenção centralizada, reutilizabilidade, código limpo nos testes.

2. Screenplay Pattern

Mais avançado, modela testes como atores realizando ações em um cenário. Excelente para testes complexos com múltiplos usuários.

3. Data-Driven Testing

Separa os dados dos testes da lógica. Ideal para validar múltiplas entradas no mesmo fluxo.

const testCases = [
  { user: 'admin', expected: 'Dashboard' },
  { user: 'viewer', expected: 'Read Only' },
];

for (const tc of testCases) {
  test(`Login as ${tc.user}`, async ({ page }) => {
    await loginAs(page, tc.user);
    await expect(page).toHaveTitle(tc.expected);
  });
}

4. Fixture Pattern (Cypress)

No Cypress, fixtures são nativos e permitem setup/teardown elegante:

test.use({
  storageState: 'auth.json',
});

 test('access dashboard', async ({ page }) => {
  await page.goto('/dashboard');
  await expect(page.locator('.stats')).toBeVisible();
});

Conclusão

Não existe um pattern perfeito para todos os casos. O ideal é combinar POM com Data-Driven e ajustar conforme a complexidade do projeto.

Quer aprender mais? Visite QA Overflow para tutoriais completos.

Artigo por Victor Oliveira - QA Senior com 13+ anos de experiência

DEV Community: VictorOliveira

Flaky Tests: O Problema Não São os Testes, É a Confiança

Flaky Tests: O Problema Não São os Testes, É a Confiança

Os Números Que Ninguém Quer Ver

O Ciclo da Desconfiança

As 5 Causas Raiz (Nenhuma É "Azar")

1. Corridas de Tempo (Timing Races)

2. Estado Compartilhado (Test Interdependence)

3. Ambiente Instável (Environment Flakiness)

4. Dependências de Rede

5. Animações e Transições

Por Que Retries São o Pior Remédio

A Estratégia de Quarantine

Como Implementar

Resultado Real

Métricas Que Importam

O Que a Pesquisa Diz Sobre IA e Flakiness

Aprender com Google, Atlassian e SAP

Conclusão: Trust Over Green

Design Patterns para Automação de Testes: Guia Prático com Playwright e Cypress

Design Patterns para Automação de Testes: Guia Prático

1. Page Object Model (POM)

2. Screenplay Pattern

3. Data-Driven Testing

4. Fixture Pattern (Cypress)

Conclusão