Quanto testar?

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.

Typically chemist’s shop can sale to you with discreet treatments for various health problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a so complicated matter. Matters, like “coupons for viagra“, are coupled numerous types of health problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an hard-on. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

7 thoughts on “Quanto testar?

  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. 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. Pingback: Quanto testar? « Templário da Tecnologia

  4. Pingback: quanto testar « Clavius Tales « Investimentos em TI

  5. 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á.

  6. Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting

Comments are closed.