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.
Uma versão consiste em uma correção de uma linha: uma suposição de tempo, uma dependência na ordem dos testes, uma omissãoawait. 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. Eles estão 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 a 5 na primeira semana e a 13 na terceira. A solução não está em um número mais preciso; está em 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.”
Pergunta principal: “Alguém já executou isso localmente com a semente fixada?”
QA: “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 50, 1 em 5, a cada duas vezes?
- Quando começou a apresentar falhas? Em qual commit?
- O teste está errado ou está detectando algo real?
- Alguém está desativando isso, enquanto isso, 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 possa ser resolvida com uma média. É uma incógnita que precisa ser investigada. Um teste rápido e limitado resolve a questão; 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 “Estimativa de um bug sem reprodução” para o mesmo caso e “Erros comuns no Planning Poker ao 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.