Quanto testar?

{ June 7th, 2009 }


cmilfont

Autor: cmilfont

Uma métrica que sempre tenho dificuldade de aferir é o retorno sobre o investimento no aumento da quantidade de testes do sistema.

Quando falo em testes aqui eu falo no conjunto de todos os tipos de testes, como: unit√°rios, aceita√ß√£o, integra√ß√£o, carga e demais necess√°rios. A cobertura de testes √© um investimento para redu√ß√£o de bugs na f√≥rmula de ROI. Bugs s√£o como “Back Order” na ind√ļstria e com√©rcio, al√©m de lucro perdido pela n√£o-venda da mercadoria, ainda fragiliza a marca.

Um ponto crucial: EU ACREDITO EM COBERTURA DE 100%, mas n√£o existe cobertura de 100%, ent√£o como podemos conviver com esse paradoxo?

Cobertura de 100% é uma meta ambiciosa de um mundo feliz onde não nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real não é vendável, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padrão aceitável.

Sabemos por consequ√™ncia que testes aumentam a qualidade do software, eu n√£o tenho tanto problema quanto antes em vender testes de software, mesmo a empresa que n√£o tem testes autom√°ticos, sabem da import√Ęncia de se testar o software [mesmo que manual].

Meu problema atual é como conseguir vender o aumento da cobertura, mas antes disso eu mesmo preciso entender até quanto testar é suficiente para se pagar.

Power Law

Conversando 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 pontos: que o aumento de testes por mais insignificativo que seja j√° provoca uma redu√ß√£o dr√°stica de bugs e que ao passar do tempo voc√™ tem a impress√£o de que os testes j√° n√£o trazem mais retorno, como voc√™s podem ver no grafico abaixo. Vou chamar esse ponto de “Ponto de Acomoda√ß√£o”.

Funcionalidades x Testes x Defeitos

Fonte da imagem: Blog do Clavius Tales.

Comentei com o Tales que concordo que a fun√ß√£o seja mesmo logar√≠tmica, mas que tenho a impress√£o que a curva √© um pouco mais acentuada e o “Ponto de Acomoda√ß√£o Ideal” que deveria ser o “Ponto G” no mundo real √© algo entre ele e o “Ponto B” e que devemos ir mais al√©m. No gr√°fico do Tales ele mostra dois pontos de acomoda√ß√£o, o real no Ponto B [que √© um engano e as empresas devem buscar sair dessa √°rea] e o “ideal” no ponto G, aqui tratado.

Ent√£o temos dois fatores novos, a curva mais acentuada e o ponto de acomoda√ß√£o, que √© o ponto onde as pessoas sentem que n√£o adianta mais testar porque o inicio de testes j√° reduzem significativamente o n√ļmero de bugs. Esse ponto de acomoda√ß√£o pode ser explicado por Pareto que √© algo que funciona aproximado em quase tudo na vida, dizendo que 20% de alguma coisa geralmente representa 80% do todo.

Tenho ainda um terceiro sentimento provocado pela minha experiŠļĹncia com testes, quanto mais testes n√≥s fazemos, mais cedo detectamos bugs e sempre h√° pelo menos uma inconsist√™ncia que n√£o tinhamos “pensado” antes. Pode at√© ser que seja finito a quantidade de testes necess√°rios no sistema, mas esse n√ļmero √© muito grande e nunca consegui alcan√ßar na pr√°tica, sempre h√° bugs.

Considerando esses fatores somados, podemos usar os cálculos do Power Law ou cauda longa para melhorarmos o gráfico original do Tales de forma mais aproximado da redução de bugs com o aumento constante de testes no sistema.

Fonte da imagem: Wikipedia

Considero que a meta de cobertura de 100%, mesmo sendo irreal, √© algo a ser buscado sempre, for√ßando o time a se policiar e aumentar o n√ļmero de testes constantemente mesmo ap√≥s a acentuada queda de bugs [que chamei de “Ponto de Acomoda√ß√£o”] e que 100% de cobertura n√£o quer dizer livre de bugs porque a cauda sempre vai ser um n√ļmero aproximado mas nunca toca o zero na pr√°tica. Esse caso se aproxima da regra de 98%.

Considero tamb√©m que dependendo da necessidade de software em produ√ß√£o um n√ļmero aceit√°vel de bugs a partir do “Ponto de Acomoda√ß√£o” n√£o tr√°s tanto retorno de investimento a curto prazo.

Vou come√ßar a coletar informa√ß√Ķes de dois projetos atuais para verificar se a tend√™ncia desse gr√°fico satisfaz a realidade. Por enquanto preciso de mais informa√ß√Ķes para chegar a conclus√Ķes melhores.

Categories: Engenharia de Software, mercado, Metodologia, M√©todos √Āgeis, Test Driven, teste, xpce ~ ~ Trackback


Assine os coment√°rios deste artigo.


7 Responses to “Quanto testar?”

  1. 1
    Marcos Sousa

    Milfont,

    100% √© algo meio imposs√≠vel, principalmente quando envolve regras mais complexas com comunica√ß√Ķes Webservices, integra√ß√£o com outros sistemas e c√°lculos matem√°ticos mais profundos. Mas concordo contigo que √© algo que deve ser buscado sempre.

    Ultimamente venho falando sobre a import√Ęncia de se testar a exaust√£o, garantir o m√°ximo de qualidade do que foi desenvolvido. Falo com frequ√™ncia aos membros da equipe, principalmente para as pessoas que est√£o iniciando a desenvolver. E algo que estou notando √© a dificuldade que as pessoas encontram em testar.

    E por experi√™ncia pr√≥pria, sei que criar um teste consistente exige mais que desenvolver. Principalmente quando os testes s√£o para os cen√°rios que eu citei acima. Criar mocks, criar cen√°rios, fazer cargas iniciais para testes de m√≥dulos dependentes s√£o as grandes barreiras. Como exigem que o profissional pense, vejo a pregui√ßa reinar em muitos casos e os testes manuais voltam a entrar em cena. Quando me deparo com situa√ß√Ķes como estas, estou buscando fazer testes das minhas atividades mostrando a todos os benef√≠cios para incentiv√°-los a criar testes tamb√©m.

  2. 2
    Rafael Ponte

    O problema que vejo é a maioria dos desenvolvedores que tive a chance de trabalhar tendem somente a criar testes para os casos mais básicos (happy paths), e não ligam mais para os demais cenários.

    Sobre at√© quanto testar eu tamb√©m n√£o sei responder. Mas acho que os testes tem sua grande import√Ęncia durante o desenvolvimento e deveriam ser levados mais a s√©rios por todos os membros da equipe.

    Excelente post, fico no aguardo das tuas conclus√Ķes.

  3. 3
    Quanto testar? « Templ√°rio da Tecnologia

    […] an√°lise e conclus√Ķes acerca da import√Ęncia da “arte” de testar. Artigo retirado do blog Milfont e na √≠ntegra […]

  4. 4
    quanto testar ¬ę Clavius Tales « Investimentos em TI

    […] Quanto testar? – CMilfont Tech. Deixe um coment√°rio […]

  5. 5
    Bruno Guimar√£es

    Ol√°, Christiano Milfont.

    Achei interessante a discussão proposta e coloquei uma referência em meu blog apontando para o seu post e o do Clavius Tales. Segue o endereço.

    http://brunotg.wordpress.com/

    Abraços
    Bruno Guimar√£es

  6. 6
    Tales

    “Um ponto crucial: EU ACREDITO EM COBERTURA DE 100%, mas n√£o existe cobertura de 100%, ent√£o como podemos conviver com esse paradoxo?

    Cobertura de 100% √© uma meta ambiciosa de um mundo feliz onde n√£o nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real n√£o √© vend√°vel, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padr√£o aceit√°vel.”

    Não acho que seja tão utópico assim. A turma da ImproveIt por exemplo trabalha com 100% de cobertura. Aqui na Fortes, todo código novo deve ser produzido com 100% cobertura. Há casos que é realmente chato, como os Sets e Gets simples, mas aqui por exemplo se resolveu por reflexão (no caso de Java), fazendo a cobertura de forma automatizada. Já ouvi falar de ferramentas que fazem isso.

    Nossos servidores de integra√ß√£o n√£o permitem redu√ß√£o da taxa de cobertura. Se cair, a “build” quebra. Ou seja, o destino √© 100%. E por que ainda n√£o √© 100%? Infelizmente temos um legado muito grande. Mas um dia chegamos l√°.

  7. 7
    Palestra Agilidade no Mundo Real - Milfont Consulting

    […] Testes http://www.milfont.org/tech/2009/06/01/recomendacao-sobre-tdd/ http://www.milfont.org/tech/2009/06/07/quanto-testar/ […]

Leave a Reply