A suíte de testes que engoliu a entrega: quando aumentar o tempo limite esconde a causa

Numa sexta-feira às 19h05, a versão nova do site institucional não saiu: o build estava havia 99 minutos rodando, de um limite de 100, e no minuto 100 o sistema o cortou.

O build é o pipeline de entrega: compila, roda a suíte de testes automatizados e deixa a versão pronta. Nenhum teste falhou. Eles simplesmente não terminaram a tempo, e a cadeia de entrega fez o que tinha de fazer: parar. A versão trazia uma mudança de texto e uma correção no formulário de contato, e o marketing precisava dela naquele dia: na segunda-feira começava uma campanha.

No canal da equipe, alguém escreveu o que todos pensavam: «E se subirmos para 120?».

A pergunta que importa é outra: quantas vezes a equipe aumentou um tempo limite este ano, e em quantas delas alguém perguntou por que era necessário?

Um esclarecimento antes de começar: este é um cenário hipotético e ilustrativo. A equipe, o site e os números são inventados e não descrevem nenhum cliente da Hábil. O padrão aparece em muitas equipes e costuma começar do mesmo jeito: um defeito de projeto encoberto por um remendo que parece razoável. O que vem de fontes publicadas leva o número de referência; quando algo é leitura nossa, dizemos.

Em 1 minuto

• O risco: tratar a duração dos testes como um problema de configuração: cada vez que a entrega se aproxima do limite, alguém aumenta o limite e a causa continua crescendo.
• O caso: em cinco semanas, o limite do build passou de 30 para 100 minutos. A causa estava lá desde o primeiro dia: cada arquivo de teste reconstruía o site inteiro antes de verificar a própria parte. Nenhum remendo tocou nela.
• O custo de não agir: uma entrega parada no dia em que o negócio precisava dela, uma campanha sem página e uma equipe que deixa de confiar nos próprios alarmes. Para a validação que roda a cada mudança, Fowler cita uma diretriz de cerca de dez minutos [1] e a DORA, um limite de cerca de 10 minutos para os testes [2]; nessa equipe, a etapa de testes terminou em cerca de 58 minutos e o limite, em cem.
• O que decidir na segunda-feira: que a duração dos testes tenha orçamento e seja comparada versão contra versão, e que nenhum remendo seja aceito se não explicar a causa, quer o proponha uma pessoa, quer um assistente de inteligência artificial.

Neste artigo

1. O que aconteceu na sexta-feira em que a entrega não saiu?
2. Como se chegou a cem minutos em cinco semanas?
3. Qual era a causa real?
4. Por que nenhum remendo resolveu o problema?
5. O que diz a prática do setor sobre quanto uma entrega deve demorar?
6. Que três regras mudam a história?
7. Que papel teve a inteligência artificial?
8. Como é a versão chata desta história?
9. Para levar
10. O que a Hábil faz?
11. Perguntas frequentes

O que aconteceu na sexta-feira em que a entrega não saiu?

A entrega não parou por um erro no código: parou porque os testes demoraram mais do que o tempo que lhes era permitido.

Convém separar dois relógios desde o início, porque nesta história eles se confundem com facilidade:

O limite é uma permissão. A duração é um fato. Aumentar a permissão não muda o fato; só muda o momento em que se fica sabendo dele.

O site era o institucional de uma empresa média: algumas páginas em espanhol e inglês, um formulário e uma seção de notícias. Nada de missão crítica. Por isso o caso é útil: o mesmo padrão pode afetar sistemas mais críticos, com um impacto que depende da arquitetura, da capacidade disponível e do desenho dos testes de cada um.

Na semana 5, a etapa de testes girava em torno de 58 minutos em condições normais; o restante do build completo se somava a esse número. Naquela sexta-feira, além disso, outro pipeline ocupava a mesma máquina de integração: o build completo, com todas as etapas e a espera por recursos, chegou aos 100 minutos do limite e parou. A máquina compartilhada foi o empurrão, não a causa: uma suíte saudável teria demorado mais, mas longe do limite. Esta já vivia tão perto do limite que qualquer carga extra bastava para ultrapassá-lo.

Como se chegou a cem minutos em cinco semanas?

Com cinco decisões que, uma a uma, faziam sentido, e nenhuma das quais perguntou por que demorava o que demorava.

A equipe usava assistentes de inteligência artificial para gerar boa parte do código e dos testes, e cada funcionalidade nova chegava com o respectivo teste. Aquilo parecia disciplina. Cada linha da tabela teve uma explicação que soava bem: «a suíte cresceu», «os arquivos grandes são lentos», «a máquina está sufocada». E ninguém fez a única pergunta que importava: por que demora o que demora?

Qual era a causa real?

Cada arquivo de teste reconstruía o site inteiro antes de verificar a própria parte: um custo que devia ser pago uma vez era pago duzentas e trinta.

A pista esteve na tabela o tempo todo. Observe a semana 5: quase os mesmos testes, cerca de 18 minutos a mais. Como o escopo dos testes mudou pouco, a hipótese razoável era que esses minutos vinham de como eles eram executados, não do que se testava. Uma hipótese se confirma medindo: separando o tempo de preparação, o de teste e a espera por recursos. No cenário, essa medição mostra que quase tudo era preparação.

Para comprovar que um botão dizia «Send» na versão em inglês, o arquivo de teste fazia tudo isto: compilar o site, gerar todas as páginas nos dois idiomas, colocá-lo para funcionar e, só então, olhar o botão. O arquivo seguinte, o do mesmo botão em espanhol, repetia tudo do zero. E o seguinte. Cerca de duzentas e trinta vezes.

É como construir o prédio de novo antes de revisar cada lâmpada.

Com 60 arquivos, esse custo repetido não doía, e como ninguém media quanto ia para preparar e quanto para testar, ninguém o viu. A cada arquivo novo, ele crescia na mesma proporção. Esse é o defeito de nascença: não era um problema da semana 5; era um desenho que, desde a semana 1, embutia um custo repetido, que cresceria a cada arquivo novo.

Com isso em mãos, cada remendo se lê de outro jeito:

• Dividir 4 arquivos em 13 transformou 4 reconstruções do site em 13.
• Reduzir o paralelismo fez essas reconstruções rodarem mais em fila e menos ao mesmo tempo.
• Aumentar o limite deu mais corda a tudo o que veio antes.

As falhas «sem razão» da semana 3 também têm outra leitura. No cenário, eram compatíveis com uma máquina saturada. O Google documentou em 2016 que, entre várias causas possíveis dos testes que às vezes passam e às vezes falham com o mesmo código, estão a concorrência (vários testes que disputam o mesmo recurso ao mesmo tempo) e os problemas de infraestrutura [3]; confirmar isso num caso concreto exige métricas e registros de execução. Dar a eles mais tempo sem medir não os curou: tirou deles a voz.

Por que nenhum remendo resolveu o problema?

Porque todos atacavam o sintoma (o relógio) e nenhum o trabalho que se repetia.

Nenhum remendo era incorreto em si; a todos faltou medir antes de decidir.

Um tempo limite funciona como um detector de fumaça. Se for aumentado cada vez que dispara, não há menos fogo: há menos aviso.

O Google descreve isso com números da própria operação: cerca de 1,5% de todas as execuções de testes reportava um resultado instável, e quase 16% dos testes tinha algum grau de instabilidade [3]. O mais relevante para a direção é a consequência que apontam: com tantos falsos positivos, é comum que falhas legítimas sejam ignoradas [3]. E advertem que afastar automaticamente os testes instáveis pode mascarar com facilidade um erro real do código [3]. Tolerar um alarme tem um preço, ainda que não apareça em nenhuma fatura.

Por isso a moral desta história não é «a suíte cresceu até quebrar». É mais incômoda: nasceu com o defeito, e cada remendo que não mediu a causa a deixou mais lenta.

O que diz a prática do setor sobre quanto uma entrega deve demorar?

Que a validação que roda a cada mudança deve girar em torno de dez minutos, e que, quando começa a crescer, se age de imediato, não quando já não cabe.

Martin Fowler, no artigo sobre integração contínua, retoma a diretriz da programação extrema (XP) de um build de dez minutos e diz que, para a maioria dos projetos, ela é perfeitamente razoável [1]. E pede que se vigiem os tempos do build e que se aja assim que eles começarem a superar a regra dos dez minutos [1]. Também observa que, pelo menos em aplicações empresariais, o gargalo habitual são os testes [1].

A DORA descreve a integração contínua em termos parecidos: os testes devem rodar em poucos minutos, com um limite superior de cerca de 10 minutos [2]. E fixa uma disciplina de equipe: se os testes automatizados falham, a equipe para o que está fazendo para corrigi-los de imediato; se o build não puder ser corrigido em poucos minutos, identifica-se e reverte-se a mudança que o quebrou [2]. A DORA pede ainda que os testes sejam confiáveis e rápidos, para dar retorno o quanto antes, e propõe tirar os testes mais longos para um build à parte [2]. Atenção à diferença: decidir quais testes rodam a cada mudança e quais em outro momento é uma decisão de desenho tomada de antemão; tirá-los porque já não cabem é mais um limite que se aumenta.

Lado a lado com o cenário:

Leitura nossa: dez minutos não é um número mágico, mas a prática deixa claro que a duração se vigia e se defende como uma propriedade do sistema, não como uma casinha que se ajusta quando atrapalha.

Que três regras mudam a história?

Nenhuma é uma linha de configuração: as três são critério, e cabem numa política de engenharia de uma página.

Regra 1. O que é caro se prepara uma vez e se reutiliza até onde for seguro

Se os testes precisam do site construído, de um banco de dados com dados de exemplo ou de um serviço no ar, identifique o que pode ser preparado uma vez e compartilhado sem romper o isolamento entre testes.

O que não muda, como um site já construído, é usado por todos os testes; o que muda, como um banco de dados, é isolado ou reiniciado de forma controlada. Ninguém reconstrói o mundo para olhar um botão.

Não é uma ideia nova. Os frameworks de teste modernos trazem um lugar para a preparação global: uma função executada uma vez antes de todos os testes [4][5], ou recursos cujo escopo é a sessão de testes completa, e não cada teste individual [6]. A documentação de um deles aponta que os recursos que exigem acesso à rede costumam ser caros de criar [6]. O mecanismo muda de uma ferramenta para outra: outro desses frameworks recomenda declarar a preparação como um projeto do qual os demais dependem, em vez da função global que ele oferece, porque se integra melhor ao executor de testes da ferramenta [4].

E o que foi preparado não fica necessariamente disponível da mesma forma para cada teste: um desses frameworks esclarece que as variáveis globais definidas na preparação global não podem ser lidas a partir dos testes [5]. A equipe deve confirmar isso antes de dar a correção por feita.

Regra 2. A suíte tem orçamento, e se compara versão contra versão

Assim como um projeto tem orçamento de dinheiro, a etapa de testes tem orçamento de duração, e ele é vigiado a cada versão.

Não basta que «caiba no limite». A pergunta é se demora o mesmo que a versão anterior e, se demora mais, se alguém esperava por isso. Para isso, a cadeia de entrega leva um portão: uma regra automática que detém a entrega quando a duração ultrapassa a variação permitida. Por exemplo, se a etapa levava 12 minutos e a versão nova leva 16 sem que ninguém tivesse previsto, isso fica visível e se explica antes de seguir.

É um portão, não uma estatística que alguém revisa quando se lembra. Com ele, essa equipe poderia ter detectado o desvio na semana 2, e não na 5, quando custou uma campanha. É a instrução de Fowler de agir assim que o build começar a passar do tempo [1], convertida em controle automático.

Regra 3. Aumentar o limite ou dividir testes não conta como correção

Quando a suíte esbarra no orçamento, a primeira pergunta não é «quanto tempo a mais damos?», e sim «o que está se repetindo que não deveria?».

Aumentar o limite pode ser uma medida temporária válida para uma entrega urgente, mas se registra como o que é, dívida com data e com dono, e a investigação da causa é aberta no mesmo dia. Se o limite sobe e ninguém abre a investigação, não foi uma decisão técnica: foi varrer para debaixo do tapete.

Que papel teve a inteligência artificial?

Nenhum que a torne culpada ou inocente: as propostas atendiam à pergunta que a equipe fazia, e ninguém fez a pergunta sobre a causa.

Culpar a ferramenta ou absolvê-la não serve à direção. A pergunta que a equipe fazia era «como faço isto passar?», e as propostas que obteve atendiam a isso: mais tempo, mais pedaços, menos processos. Respostas plausíveis para a pergunta errada.

O problema foi outro: a equipe aceitou cada remendo sem perguntar por quê. Quando uma pessoa com pouca experiência propõe aumentar um tempo limite, alguém com mais ofício costuma perguntar «e por que demora?». Quando a proposta chega na hora e redigida com segurança, essa pergunta é pulada com mais facilidade.

A velocidade dos assistentes não elimina a necessidade de critério: aumenta-a, porque agora os erros também se produzem mais rápido. A regra que esta história deixa é simples de escrever e exigente de cumprir: um remendo que não explica a causa não é aceito, venha de uma pessoa ou de uma ferramenta. A revisão de mudanças exige evidência da causa, do impacto esperado e da medição posterior, seja qual for a origem da proposta.

Como é a versão chata desta história?

É a mesma semana 2, com um portão que dispara o alarme a tempo e alguém que pergunta por quê.

Nessa versão, na terça-feira da semana 2, o portão aponta que a etapa passou de 12 para 16 minutos sem explicação. A versão fica parada por algumas horas. Uma pessoa da equipe mede para onde vai o tempo e descobre que quase tudo é preparação: cada arquivo constrói o site do zero.

Naquela tarde, o site passa a ser construído uma vez no início e todos os testes o usam; o banco de dados de exemplo é reiniciado de forma controlada entre os testes. Depois de validada a mudança, a etapa pode voltar ao orçamento combinado e o limite fica onde estava.

Três semanas depois, na sexta-feira da campanha, outro pipeline ocupa a mesma máquina e o build demora um pouco mais. Com margem suficiente diante dessa carga extra, o risco de a suíte deter a entrega é muito menor.

Essa é a versão chata. E numa cadeia de entrega, chato é a meta.

Para levar

Quatro perguntas para o próximo comitê de tecnologia:

1. Quanto leva hoje a etapa de testes dos nossos sistemas principais, quanto levava há três meses e quem vigia essa diferença?
2. Quantas vezes aumentamos um tempo limite este ano, e em quantas dessas vezes se abriu uma investigação da causa com data e dono?
3. Sabemos que parte da duração dos nossos testes é preparação e que parte é teste?
4. Quando um assistente de inteligência artificial propõe um remendo, nosso processo de revisão exige que ele explique a causa, ou só que a entrega passe?

O que a Hábil faz?

A Hábil ajuda a tornar a cadeia de entrega rápida e confiável, para que liberar uma mudança deixe de ser uma aposta.

Uma suíte de testes com duração crescente pode atrasar entregas e gerar custos operacionais que ninguém vê chegar. Trabalhamos com a equipe em quatro frentes:

• Testes que medem o que importa. Que cada teste comprove algo do negócio e que o que é caro se prepare uma vez, não duzentas e trinta.
• Orçamento de duração vigiado. A duração dos testes é controlada como qualquer outro orçamento, com um portão que a compara versão contra versão.
• Cada alarme com dono e causa. Os testes intermitentes e os tempos limite são tratados como avisos que se investigam, não como ruído que se silencia.
• Assistentes de IA sem perder o critério. A equipe aproveita a velocidade dos assistentes com uma revisão que exige que cada mudança explique o porquê.

Integramos os testes e a segurança ao caminho de entrega. Veja Nuvem e DevSecOps.

Se a etapa de testes vem crescendo há semanas e o limite já foi aumentado mais de uma vez, comecemos por aí. Vamos conversar sobre o seu caso. A primeira conversa é sem custo.

Perguntas frequentes

Aumentar o tempo limite do build é errado?

Não necessariamente. Pode ser uma medida temporária válida para tirar uma entrega urgente. O problema aparece quando é usado como correção: se o limite sobe e ninguém mede para onde vai o tempo, a causa continua crescendo. Por isso cada aumento se registra como dívida com data e dono.

Como saber se a minha equipe tem esse mesmo defeito?

Um sinal claro é o da semana 5: a duração sobe muito mais do que o número de testes. Outro, que dividir arquivos lentos não melhore o tempo total. A verificação de fundo é medir, por arquivo, quanto vai para preparar o ambiente e quanto para testar. Se a preparação domina e se repete em cada arquivo, é aí que está o custo.

Fontes consultadas em 6 de novembro de 2026. As citações de documentos em inglês estão traduzidas.

Dorian Chávez conta uma versão narrada deste padrão, em espanhol, no Substack «En construcción»: https://enconstruccionmx.substack.com/p/la-suite-que-se-comio-la-entrega