Quanto custa um defeito?

Quando se fala em métricas de Qualidade de Software, um dos primeiros pontos de que lembramos é o número de defeitos (ou bugs). Podemos falar em densidade de defeitos, em razão de defeitos, em pontos de falha, e há, realmente, uma série de métricas importantes que podem ser obtidas a partir de sua excelência, o defeito.

Mas algo de que pouco se trata é: quanto custa um defeito? Podemos, além de diminuir o número de defeitos de um projeto, diminuir também o custo dos defeitos?

Para falar sobre custo de defeitos, é importante falarmos sobre retrabalho. Retrabalho é um indicador a que se presta pouca atenção, infelizmente. O custo acumulado de retrabalho pode ser enorme em projetos e organizações, mas, ainda assim, permanecer invisível.

Eu gosto de classificar o retrabalho de acordo com a etapa do processo de software em que ele foi identificado. Neste caso, para simplificar, poderíamos propor a seguinte classificação:

• Retrabalho de primeira ordem: basicamente defeitos ou bugs.

• Retrabalho de segunda ordem: defeitos ou bugs que “voltam” porque não foram adequadamente corrigidos.

Para termos ideia do custo de um defeito, vamos observar o custo de retrabalho de primeira ordem.

Supondo, para fins didáticos, que as fases de um defeito são detecção (d), registro (r), priorização (p), solução (s) e teste de confirmação (t), e supondo, ainda, unidades de tempo que possam ser utilizadas como medida dessas fases, proponho a distribuição de tempo abaixo:

\(CUSTO(1) = d+r+p+s+t\)

Onde Custo(1) é o custo de retrabalho de primeira ordem, ou seja, o custo de um defeito.

Para tornar mais concreto o exemplo acima, vamos atribuir alguns valores (em horas) aos tempos acima:

d = 1h
r = 0.25h
p = 1h
s = 4h
t = 1h

Portanto, neste exemplo, Custo(1) = 7.25h.

Agora, imaginemos que o defeito “voltou", ou seja, passou por uma fase de correção mas, na verdade, ao ser retestado, ainda permanecia. Neste caso, estamos falando de retrabalho de segunda ordem. Para tanto, podemos assumir que todas as fases acima se repetem, com exceção da fase de detecção, que acaba sendo a fase de teste de confirmação do defeito de primeira ordem:

\(Custo(2) = Custo(1) + r + p + s + t\)

Assim, usando os mesmos valores para r, p, s e t, chegamos a Custo(2) = 13.5h.

Estabelecemos aqui que, neste exemplo hipotético, cada defeito custa 7.5h e, cada defeito que “volta", 13.5h.

Para tornar ainda mais concreto o exemplo, suponhamos que cada hora do projeto custe R$100,00. Isso significa que os bugs custam R$750,00 cada um, e que os retrabalhos de segunda ordem custam R$1.350,00 cada um. Para ficarmos apenas nos bugs (retrabalhos de primeira ordem), isso significa que cada defeito “rouba” praticamente o equivalente a um dia de trabalho no projeto.

Obviamente, esses valores são arbitrários, mas já é possível ter uma ideia de como o custo de um bug impacta o custo de um projeto, sem falar nos atrasos decorrentes.

Temos então a dupla consequência dos defeitos: não apenas representam, inerentemente, uma diminuição da percepção de Qualidade de um projeto, como também causam impacto significativo em custos e prazos.

E como minimizar esses impactos? Bons engenheiros de Qualidade de Software têm uma caixinha de ferramentas que pode ser bastante útil!