quanto testar
Publicado: 18/04/2009 Filed under: principal 6 comentáriosAdverência: esse post não responde de forma objetiva ao seu título. É mais subjetivo, para provocar reflexão.
Observem o seguinte gráfico:
Ele mostra a relação entre o esforço gasto com desenvolvimento em si (novas funcionalidades), com testes e com correções de bugs. É claro que a separação entre funcionalidades e testes é muito difícil, quiçá impossível, de ser estabelecida. Mas façamos um pequeno esforço mental para entender essa separação.
Os pontos A e C são extrapolações, não existem no mundo real. No A, não há qualquer teste. Seria o caso do desenvolver simplesmente escrever o código, compilar, não realizar o obscuro “teste do desenvolvedor” e entregar para o cliente. No C, todo o esforço é gasto com testes (“Testar o quê, se nenhuma funcionalidade foi produzida?”). Existe o lance das provas formais, que não conheço direito, mas até onde sei é algo impraticável em 999.999.999 de cada bilhão de softwares.
Por observação, boa parte das equipes se encontra entre A e B. Uma pena, já que isso se mostra uma tremenda estupidez. Na verdade, estupidez não é nem estar entre A e B; é não querer sair de lá. Por quê? Simples: o ponto B é o de maior produtividade. Ou seja: teste um pouco mais e será mais produtivo. Não é nem uma questão de fazer tão bem feito, com poucos bugs. É uma questão simples de produtividade. O curioso é que qualquer equipe deveria no mínimo se posicionar em B. E por que muitas não se posicionam? Assunto para outro post. Lembrei de uma frase que a mamãe costumava repetir: “O preguiçoso trabalha mais que o trabalhador.”
Sendo assim, os menos atentos diriam: “O ideal então é se posicionar em B, que é o ponto de maior produtividade.” Não é bem assim. Pergunto: seria certo se posicionar em B uma equipe que está produzindo um software embarcado que guia um míssil ao seu alvo? Claro que não! É preciso observar o nível de bugs no ponto B. Um erro nesse software poderia ser catastrófico. Ou seja, esse software deve ser virtualmente perfeito, sem bugs. Essa equipe deve se posicionar o mais próximo possível de C.
“Resolvido, então. Devemos sempre nos posicionar o mais próximo possível de C, correto?” Também não. Depende da natureza do software. A tolerância a erros de um software de um míssil é totalmente diferente da tolerância de um software gratuito para comunidades virtuais, por exemplo. Um erro neste nunca seria catastrófico. “Mas mesmo não sendo catastrófico, não seria melhor não ter erro nesse software?” Seria. Mas devemos observar outro fator: produtividade (funcionalidades). A partir de B, à medida que nos aproximamos de C a produtividade cai, já que o investimento em testes aumenta. Na prática, a grande maioria dos softwares não comporta um posicionamento próximo de C devido à baixa produtividade.
Um aparte: a curva dos defeitos em relação aos testes é logarítmica. Isso é apenas minha opinião, apesar de achar fortemente que estou certo – minha experiência e intuição me gritam. Se souberem de alguma pesquisa ou estudo científico que mostre essa relação, ficaria muito grato se me indicassem.
“Onde se posicionar, então?” Infelizmente ainda não descobrimos resposta objetiva para isso. O que vale aqui é a experiência e o bom senso da equipe, além do próprio processo empírico. Algumas heurísticas também podem ajudar.
Uma última análise: de modo bem simplista, podemos dizer que o basicão do TDD (100% de cobertura) está no ponto G, em que o esforço de testes é igual ao esforço de funcionalidades. Nessa minha simulação, de B para G, há uma queda de 22% na produtividade e de 63% nos defeitos. Coisas como essa explicam por que os agilistas (especialmente os XPeiros) somos tão vidrados em testes.
P.S.: para efeito deste post, em “testes” incluem-se coisas como programação em par e inspeção.
P.P.S.: “defeitos” referem-se ao esforço que a equipe fez para corrigir erros depois de realizados os testes, depois do deploy. Ex.: num período de um ano de um projeto, a equipe gastou 10% do esforço para corrigir bugs encontrados em produção.
Clavius Tales 
Tales, o que não concordo com suas observações é o fato de diminuir 22% de produtividade a partir de B. Há algo aí que não se encaixa.
Considerando que a cobertura dos testes captura um número significativo de bugs que impedem um retorno daquelas funcionalidades para conserto, a produtividade do projeto só deveria aumentar a partir de B e ter uma queda significativa sim entre A e B [por causa de costume, aprendizado,etc] e não a suave estabilização entre A e B como apresenta.
Claro que aqui considerando produtividade o tempo gasto no ciclo de vida do projeto e não apenas de uma tarefa.
Durante a iterações vamos apresentar um retorno de funcionalidades para conserto bem menor com testes seja TDD ou não, diferente de de um processo que não inclua testes pelo menos no fim de cada iteração, dessa forma segundo minhas observações esse número de diminuição de produtividade é absurdo de alto, já que teremos tempo ganho suficiente para produzir artefatos relativos a todo o arcabouço de teste sem comprometer a agilidade na construção do software e finalização das tarefas.
Oi, Milfont.
A produtividade a que me referi está bem simplificada. É o simples esforço de desenvolvimento direto de novas funcionalidades. Não estou nem considerando questões como manutenibilidade, para facilitar a argumentação.
Além do mais, o número de 22% é fruto de uma mera simulação. O número exato vai depender de quão acentuada é a curva logarítmica, e isso pode inclusive variar por projeto. Se a curva for menos acentuada, esse número cai. Cheguei a fazer essa simulação, de curva menos acentuada, só que cheguei também a um percentual de defeitos que considerei irreal, muito alto. Ex.: no caso em que o ponto G (que chamei de TDD basicão) é também o de maior produtividade, a taxa de defeitos fica em 33%. Se quiser posso te mandar a planilha. Está meio ruim porque algumas coisas precisam ser feitas na base da tentativa e erro, devido ao meu enferrujamento matemático. Mas dá para brincar um pouquinho.
Se assim fosse, testaríamos até a exaustão. E isso não acontece na prática. Há um ponto específico em que a produtividade atinge seu ápice. Se você não concordar com essa afirmação, não vai conseguir entender o que quis dizer.
“Suave estabilização entre A e B”? O gráfico mostra justamente o contrário. É exatamente quando há uma maior variação da produtividade.
Sem dúvida. Não disse nada diferente. A zona entre A e B mostra isso peremptoriamente.
Como já disse, esse número depende de quão acentuada é a curva logarítmica dos defeitos. E de aceitar que essa curva é logarítmica. Numa lista de discussão, você deve ter visto que o MT confirmou essa curva através da experiência em sua empresa.
[…] dia desses na Fortes com o Clavius Tales sobre o seu post de mesmo preocupação, ele me explicava porque encontrou uma função logarítmica e eu tive o mesmo sentimento em dois […]
[…] dia desses na Fortes com o Clavius Tales sobre o seu post de mesmo preocupação, ele me explicava porque encontrou uma função logarítmica e eu tive o mesmo sentimento em dois […]
[…] quanto testar « Clavius Tales. […]
Olá, Clavius Tales.
Parabéns pelo post. Achei interessante a discussão proposta e coloquei uma referência em meu blog apontando para o seu post. Segue o endereço.
http://brunotg.wordpress.com/
Abraços
Bruno Guimarães