Estimativa de um teste instável
Como estimar um teste instável: por que são duas estimativas, e não uma, e por que definir um prazo é melhor do que discutir sobre pontos quando a resposta depende do que você descobrir.
Um teste instável consiste em duas estimativas. Você ainda não sabe qual delas.
awaitUma versão é uma correção de uma linha: uma suposição de tempo, uma dependência da ordem dos testes, uma omissão. A outra versão envolve três dias de investigação de uma condição de corrida no código de produção que o teste, por acaso, detectou. Quando as cartas variam de 2 a 13, a equipe não está em desacordo quanto ao tamanho — está em desacordo sobre que tipo de bug é esse, que é a verdadeira incógnita.
Fazer uma estimativa para descobrir o tamanho de algo, em vez de esperar até depois, é o que faz com que essa história chegue ao 5 na primeira semana e ao 13 na terceira. A solução não é um número mais preciso; é uma abordagem diferente do trabalho. Defina um prazo para a investigação e, em seguida, faça a estimativa da solução real assim que a abordagem estiver definida.
O que se fala na sala
Engenheiro A: “Se estiver apresentando falhas pelo motivo que eu imagino, isso merece nota 2.”
Engenheiro B: “Se estiver apresentando falhas pelo motivo que eu imagino, é um 13.”
Título: “Alguém já executou isso localmente com a semente fixada?”
Pergunta: “Só falha na integração contínua. Nunca em uma máquina de desenvolvimento.”
Perguntas que vale a pena fazer antes de votar
- Isso ocorre localmente ou apenas no CI?
- Com que frequência isso dá errado — 1 em cada 50, 1 em cada 5, a cada duas tentativas?
- Quando começou a apresentar falhas? Em qual commit?
- O teste está errado ou está detectando algo real?
- Alguém está desativando isso por enquanto, e a que custo?
A diferença entre o Engenheiro A e o Engenheiro B não é uma divergência sobre pontos de história que se resolva com uma média — é uma incógnita que precisa ser investigada. Um “spike” curto e limitado resolve essa diferença; uma discussão acalorada, não.
Defina um prazo, não uma solução. Meio dia para investigar e, depois, uma matéria de verdade sobre o que quer que você descubra.
Consulte como estimar um bug sem reprodução para o mesmo caso e erros comuns no Planning Poker para estimar bugs com precisão de recurso. Confira os outros exemplos práticos de estimativa ou inicie uma sessão gratuita de Planning Poker quando a investigação tiver um resultado.