Guia aprofundado
Simulador de gargalo entre QA e sprint: quando os desenvolvedores superam a capacidade de testes
Análise executiva do setor
Uma equipe de software é um fluxo, e um fluxo não entrega mais depressa do que a sua etapa mais lenta. Quando os desenvolvedores terminam mais funcionalidades do que os testadores conseguem verificar, o trabalho excedente não desaparece; entra em uma fila. Os gestores veem desenvolvedores ocupados e um quadro de sprint cheio e concluem que a equipe é produtiva. Mas uma funcionalidade construída e não testada não rendeu nada, e a cada semana de espera perde valor. Acrescentar desenvolvedores nessa situação eleva a folha e o tamanho da fila juntos e deixa a produção entregue exatamente onde estava.
A estrutura do problema é a diferença entre duas taxas. A produção dos desenvolvedores é o número de desenvolvedores vezes as funcionalidades que cada um conclui. A capacidade do QA é o número de testadores vezes as funcionalidades que cada um consegue verificar. As funcionalidades entregues são a menor das duas, e a diferença entre elas é a taxa em que a fila cresce. Como a fila se acumula mês após mês, o seu custo não permanece constante; ele aumenta. Uma equipe um pouco acima da capacidade parece bem no primeiro sprint e claramente quebrada no sexto, e é por isso que o problema é fácil de ignorar até ficar grande.
O efeito dominó mostra a sequência. Uma produção alta dos desenvolvedores eleva a parcela da capacidade do QA demandada acima de cem por cento. Essa carga faz a fila crescer, o que atrasa cada funcionalidade que está atrás dela. A espera custa valor diretamente e também puxa os desenvolvedores de volta ao trabalho antigo, por correções de defeitos e dúvidas, de modo que o tempo deles se perde em trocas de contexto. Testadores sobrecarregados correm, e mais defeitos escapam. Cada etapa alimenta a seguinte, de modo que uma pequena sobrecarga na segunda caixa pode deixar a última no vermelho em poucos sprints.
O iceberg separa a folha de pagamento do custo do gargalo. Acima da linha d'água estão os salários dos desenvolvedores e do QA, que todos veem. Abaixo dela ficam quatro custos que raramente têm uma linha: o valor perdido enquanto as funcionalidades esperam, o custo dos defeitos que chegam aos clientes porque os testes foram apressados, o tempo dos desenvolvedores perdido com troca de contexto e as horas extras que os testadores fazem sob sobrecarga. Juntos, podem superar o custo do testador extra que os teria eliminado. Use o simulador para achar a proporção entre desenvolvedores e QA em que o seu fluxo deixa de se pagar e depois compare com a contratação de um testador.
Fórmulas e metodologia
O modelo trabalha por mês em regime estável. A produção dos desenvolvedores é o número de desenvolvedores vezes as funcionalidades de cada um. A capacidade do QA é o número de testadores vezes as funcionalidades de cada um. As funcionalidades entregues são a menor das duas. A fila cresce pela diferença a cada mês, e a fila média numa janela de seis meses é metade de seis vezes esse crescimento. O custo do atraso é a fila média vezes o custo do atraso. Os desenvolvedores perdem 1% do tempo com troca de contexto para cada funcionalidade na fila, com teto de 20%. Os defeitos que escapam aumentam com a sobrecarga.
- Produção dos desenvolvedores
- P = desenvolvedores × funcionalidades por desenvolvedor
- Funcionalidades concluídas e entregues ao QA a cada mês.
- Funcionalidades entregues
- S = mín(P, testadores × funcionalidades por testador)
- O fluxo só consegue liberar o que os testes verificam.
- Fila
- Q = máx(0, P − capacidade) × 3
- Número médio de funcionalidades à espera numa janela de seis meses, já que a fila cresce de forma linear.
- Custo dos defeitos que escapam
- E = S × (3% + 15% × sobrecarga) × 4.000
- Defeitos que chegam aos clientes aumentam quando o QA está sobrecarregado, a um custo de 4.000 cada.
- Resultado do fluxo
- Líquido = S × valor − folha − Q × custo do atraso − E − custo de contexto − horas extras do QA
- Resultado mensal. A carga de equilíbrio é aquela em que ele chega a zero.
Elasticidade em cascata
A diferença entre a produção dos desenvolvedores e a capacidade do QA é o fator mais elástico, porque move ao mesmo tempo a fila, o atraso, a troca de contexto e os defeitos que escapam. O valor por funcionalidade multiplica diretamente a produção entregue. A folha é linear e age como um limiar, e é por isso que acrescentar um testador muitas vezes se paga muitas vezes o seu custo.
Três estudos de caso reais
Início com recursos próprios
Uma equipe de produto de três pessoas
Três desenvolvedores e um testador trabalham em um produto pequeno. Os desenvolvedores concluem seis funcionalidades por mês e o testador consegue verificar sete, então nada fica na fila. Carregue o caso para ver uma equipe pequena equilibrada, em que entregar é igual a construir e não há gargalo a corrigir.
Médio porte em expansão
Uma organização equilibrada de vinte e quatro desenvolvedores
Uma grande organização mantém sete testadores para vinte e quatro desenvolvedores e investe em automação, de modo que o QA supera levemente a produção dos desenvolvedores. As filas são mínimas e o valor entregue é alto. Carregue o caso para ver por que uma proporção saudável mantém uma equipe grande lucrativa.
Crise de cisne negro
Dez desenvolvedores e dois testadores sobrecarregados
Dez desenvolvedores rápidos concluem trinta funcionalidades por mês, mas dois testadores conseguem verificar apenas dez. A fila cresce vinte funcionalidades por mês, defeitos escapam e os desenvolvedores voltam sempre ao código antigo. Carregue o caso para ver como um problema de proporção transforma uma folha grande em prejuízo.
Matriz de referências do setor
| Métrica | Zona de perigo | Média do setor | Elite dos 10% melhores |
|---|---|---|---|
| Desenvolvedores por testador | Acima de 8:1 | 3–5:1 | Cerca de 2–3:1 com automação |
| Carga do QA (produção dos desenvolvedores em relação à capacidade) | Acima de 130% | 90–105% | Abaixo de 90% |
| Fila média aguardando teste | Acima de 10 funcionalidades | 2–4 funcionalidades | Menos de 2 |
| Defeitos que escapam para produção por liberação | Acima de 10% | 3–6% | Abaixo de 2% |
| Tempo de ciclo do concluído até o liberado | Acima de 4 semanas | 1–2 semanas | Menos de 3 dias |
Variáveis e alavancas
Desenvolvedores
Engenheiros que constroem funcionalidades. Mais desenvolvedores elevam a produção, mas não a velocidade dos testes.
Alavanca: Não acrescente desenvolvedores antes de a capacidade de testes crescer; limite o trabalho em andamento para que a equipe termine menos, mas entregue mais.
Funcionalidades concluídas por desenvolvedor por mês
Funcionalidades que um desenvolvedor conclui e entrega ao QA em um mês.
Alavanca: Limite as funcionalidades iniciadas por sprint ao que o QA consegue verificar, porque trabalho concluído e não testado não rende nada.
Testadores de QA
Pessoas que verificam as funcionalidades antes da liberação.
Alavanca: Acrescente testadores ou incorpore engenheiros de teste à equipe, pois cada testador libera um bloco de funcionalidades que hoje espera.
Funcionalidades verificadas por testador por mês
Quantas funcionalidades um testador consegue testar por completo, retestar e aprovar em um mês.
Alavanca: Automatize os testes de regressão e escreva critérios de aceitação antecipadamente, para que os testadores verifiquem trabalho novo em vez de repetir verificações antigas.
Valor de uma funcionalidade entregue
Receita, retenção ou economia que uma funcionalidade traz quando chega aos usuários.
Alavanca: Priorize as funcionalidades por valor e descarte as de baixo valor, já que a capacidade de testes é gasta com tudo o que entra na fila.
Custo do atraso por funcionalidade por mês
O que cada funcionalidade perde por mês em que espera na fila, em receita perdida ou confiança dos clientes.
Alavanca: Libere incrementos menores com mais frequência, o que encurta a espera de cada funcionalidade e reduz o custo do atraso.
Como usar este simulador
- 1Informe o número de desenvolvedores e as funcionalidades que cada um conclui em um mês.
- 2Defina o número de testadores e quantas funcionalidades cada um consegue verificar.
- 3Estime o valor de uma funcionalidade entregue e o custo do atraso por funcionalidade por mês.
- 4Leia os cinco dominós e observe quando a carga do QA passa de cem por cento.
- 5Compare com o plano do testador extra na aba Universo paralelo e compartilhe o link.
Erros a evitar
- Medir os desenvolvedores pelas funcionalidades concluídas. Trabalho esperando teste é estoque, não produção.
- Tirar a média de um período longo. Uma fila que cresce a cada mês parece pequena no início e grande depois.
- Tratar os testadores como um custo a cortar. Em um gargalo, a capacidade de um testador é a capacidade mais valiosa do fluxo.
- Contar apenas o custo do atraso. Defeitos que escapam e troca de contexto muitas vezes o superam.
Perguntas frequentes
Por que acrescentar desenvolvedores não aumenta a produção entregue?
Porque a entrega é limitada pela etapa mais lenta. Desenvolvedores extras aumentam a fila diante do QA, o que eleva o custo sem elevar a taxa de liberação.
A proporção entre desenvolvedores e testadores basta para planejar?
É um começo, mas a comparação útil é a produção contra a capacidade. A automação, a qualidade dos requisitos e o tipo de produto podem mudar bastante a proporção.
Como o custo do atraso é estimado?
Como uma perda mensal por funcionalidade em espera, em receita, retenção ou confiança perdidas. É uma premissa, então teste um valor baixo e um alto e veja qual predomina.
Por que os defeitos aumentam sob sobrecarga?
Testadores apressados pulam casos e revisam menos. O modelo acrescenta defeitos que escapam em proporção ao quanto a demanda excede a capacidade.
O que o cenário do testador extra mostra?
Mostra o retorno de mais um testador e de uma regressão automatizada, que eleva a capacidade do QA e normalmente esvazia a fila. A aba de 24 meses mostra quando isso se paga.
Qual é a precisão desta simulação?
É um modelo educacional de planejamento, com as premissas apresentadas, e não aconselhamento de engenharia ou financeiro. Substitua as entradas pelos seus próprios dados de vazão e de custo.
Este é um modelo educacional de planejamento, com premissas declaradas. Não constitui aconselhamento financeiro, tributário ou jurídico. Substitua os dados pelos seus próprios números e confirme decisões importantes com um profissional qualificado.