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

O bug estava lá. Claro, documentado, com print, com passo a passo. O QA reabriu o chamado pela segunda vez. O dev olhou, testou no ambiente dele, não reproduziu. Os dois têm certeza de que estão certos, e nenhum dos dois está completamente errado. Essa cena acontece em praticamente todo time de software. O problema

Tem uma situação que se repete em muitos times de QA: os dashboards estão cheios de números, os relatórios saem toda semana, e mesmo assim ninguém consegue responder com clareza se os testes estão funcionando bem. Os dados existem, o problema é que ninguém sabe muito bem o que fazer com eles. Métricas de QA

Tem um cenário que se repete em muitos times de QA: a suíte de testes cresceu ao longo do tempo, chegou a centenas (às vezes milhares) de casos, e de repente o pipeline começa a demorar horas para rodar. Falhas aparecem, mas quando você investiga, boa parte delas repete exatamente o mesmo problema em testes

Toda equipe de desenvolvimento testa software. A questão é se ela faz isso de forma estratégica, sabendo exatamente qual tipo de teste aplicar em cada momento. Existem dezenas de tipos de teste, e escolher o errado no momento errado tem custo, seja tempo de desenvolvimento perdido, retrabalho caro ou, no pior cenário, falhas em produção