Os últimos dias que antecedem a uma entrega, com frequência, são repletos de correria, stress, pressão e claro bugs e mais bugs, que parecem intermináveis.

O que pode nos levar a pensar, que estamos cometendo os mesmos erros. Pensamos, refletimos, avaliamos e discutimos durante reuniões de Sprint Retrospective, que as vezes parecem intermináveis, o porquê de, mais uma vez, termos feito diversas horas extras nos últimos dias que antecederam a entrega.

Abaixo, listamos alguns dos fatores, que podem contribuir para esse número de bugs elevado, os quais podemos combater e assim, pelo menos, reduzir sua probabilidade de ocorrência.

Ausência de testes durante a sprint
Um dos problemas mais comuns que econtramos está relacionado a ausência de testes intermediários durante a sprint, sobrecarregando os testes de sistema realizados nos últimos dias e consequentemente proporcionando um número maior de CRs graves nos últimos dias.

Testes mal priorizados
Durante a execução do ciclo de testes de sistema, a priorização da ordem de execução também tem se mostrado um elemento fundamental para permitir que a maior parte dos defeitos graves sejam encontrados nos primeiros dias de execução.

Prazos irreais para testes
Sistemas gigantescos, com diversos requisitos de hardware, contando apenas com alguns dias para testes. Mais um grande motivo, para que o planejamento seja mal feito, a execução corrida e, desse modo, defeitos graves acabem não sendo antecipados ou até mesmo escapando.

Prazos irreais para correção
Desenvolvedores pressionados pelo “dia da entrega” implementando soluções, que nem sempre são a “melhor” solução, podendo, também, gerar novos bugs no sistema.

Especificação Deficiente
Estórias ou requisitos mal descritos, ausência de Product Owner ou Engenheiro de Requisitos, proporcionam dificuldades para desenvolvedores e testadores, o que acaba significando um maior número de defeitos.

Testes mal realizados
Diversos pontos da estratégia de testes podem precisar de uma boa revisão, é comum a ausência dos testes estáticos na documentação, a precariedade dos testes unitários, e a falta dos de componente. Criando, dessa forma, um enorme gargalo nos testes de sistema ou de regressão.

Porém, ledo engano nosso, achar que ao identificar e corrigir todos os possíveis problemas, nenhum bug grave será encontrado nos últimos dias. Na verdade, isso apenas minimiza o problema (o que é fundamental) e, hoje, não temos como garantir, que iremos conseguir antecipar todos os defeitos graves.

Enquanto houver tempo para testar, e o time possuir qualidade e disposição, devem haver bugs, inclusive graves…
E se adiarmos a entrega por mais alguns dias… continuaremos a encontrar bugs…

E você o que acha? Que outras medidas podem ser tomadas?

Acompanhe as novidades do BdB pelo Facebook, acesse e curta nossa página.