AS DUAS GRANDES ARMADILHAS DA COBERTURA DE CÓDIGO

Medir a cobertura do código geralmente recebe muito foco na avaliação das práticas de teste de unidade porque fornece informações importantes sobre o estado dos testes. O código precisa de uma cobertura significativa, que indique que o software foi testado adequadamente.

A cobertura de código pode ser um bom número para avaliar a qualidade do software, mas é importante lembrar que é um meio, e não um fim. É um fator importante porque deve indicar que um bom trabalho foi feito testando o software. Se os testes em si não forem significativos, realizar um número maior de testes certamente não indicará se um software é melhor. O principal objetivo é garantir que a lógica do código seja testada funcionalmente, não apenas que as linhas de código sejam executadas. Uma alta cobertura por si só não significa necessariamente uma alta qualidade do código.

Armadilhas

1- “Não conhecemos nossa cobertura”

Não conhecer a cobertura do código parece irracional nos dias de hoje, porque as ferramentas de cobertura são baratas e abundantes. Em alguns casos, as organizações sabem que seu número de cobertura não é bom, mas seus desenvolvedores e testadores relutam em expor a baixa cobertura para suas chefias.

Outra forma dessa armadilha acontece com as organizações que desenvolvem muitos testes, mas não conseguem determinar um número de cobertura real porque não encontraram uma maneira adequada de consolidar os números de diferentes práticas de teste.

A cobertura de várias práticas de teste deve ser medida e combinada de maneira que façam sentido. Uma ferramenta para executar relatórios e análises como o Parasoft DTP fornece uma visão abrangente e agregada da cobertura de código. Os monitores de aplicativos da Parasoft coletam dados de cobertura do aplicativo diretamente enquanto ele está sendo testado e enviam essas informações para o Parasoft DTP, que agrega dados de cobertura em todas as práticas de teste, bem como entre equipes de teste e execuções de testes. Um painel interativo permite que as equipes naveguem pelos dados de cobertura e tomem decisões sobre onde concentrar os esforços de teste. Se vários testes cobrirem o mesmo código, eles não serão contados em duplicidade, enquanto as partes não testadas do código serão rápidas e fáceis de identificar, mostrando quais partes do aplicativo foram bem testadas e quais não foram.

Application Coverage: Visualize os dados de cobertura agregados em todas as práticas de teste.

2 – “A cobertura é tudo!”

É comum que organizações ou gestores pensem erroneamente que a cobertura é tudo. Uma vez que a cobertura está sendo medida, não é difícil encontrar gestores que desejam aumentar o percentual de cobertura. É outra forma de pensamento errado que leva a acreditar que o próprio número pode se tornar mais importante do que os testes.

A cobertura precisa refletir o uso real e significativo do código, caso contrário, é apenas ruído. O custo aumenta à medida que a cobertura aumenta. Lembre-se de que os testes não precisam apenas ser criados, mas devem ser mantidos no futuro. Se a equipe não planeja executar e manter um teste, provavelmente não deve perder tempo criando-o em primeiro lugar. Além disso, se os testes forem mal projetados, a quantidade de ruído que eles produzem aumenta significativamente. Testes mal projetados criam mais ruído do que bons testes porque podem falhar mesmo quando o comportamento do aplicativo não mudou. Em outras palavras, eles não são muito sustentáveis.

A maneira de escapar dessa armadilha é primeiro entender que a porcentagem de cobertura em si não é o objetivo. O objetivo real é criar testes úteis e significativos.

A ferramenta de teste de desenvolvimento Java Parasoft Jtest contém tecnologia para resolver isso. Os testes de unidade são gerados com stubs e mocks configurados adequadamente para cobrir o código em questão. Seu “Unit Test Assistant” ajuda os desenvolvedores a assumir as tarefas tediosas de configurar mocks e stubs corretamente. A solução também pode expandir os testes existentes de forma útil para aumentar a cobertura. O Parasoft Jtest ajuda as equipes a criar bons testes de unidade do zero, além de fazer recomendações para melhorar a cobertura e a qualidade dos testes existentes.

UMA MANEIRA SIMPLES DE AUMENTAR O ROI DOS TESTES DE UNIDADE JAVA

Apresentamos a seguir algumas estatísticas preocupantes, que se aplicam tanto a desenvolvedores que usam Scrum e ferramentas de software mais recentes quanto a qualquer outro tipo de desenvolvimento de software.

Taxas de sucesso em testes atuais

Segundo a Parasoft, os desenvolvedores de software estão gastando aproximadamente metade de seu orçamento de desenvolvimento para encontrar e corrigir bugs e os métodos tradicionais de teste ainda estão deixando dois terços dos bugs no software. Veja alguns números interessantes:

• Mesmo usando os métodos de desenvolvimento de software mais recentes, a taxa de remoção de defeitos é de aproximadamente 85% nos melhores projetos. Isso significa que 15% dos defeitos ainda não foram encontrados e chegam ao produto final.
• Cerca de 6% dos casos de teste têm bugs nos próprios casos de teste.
• Em grandes projetos, até 20% dos testes de regressão são duplicados, o que aumenta os custos dos testes, mas não aumenta a qualidade do produto.
• Cerca de 7% das correções de bugs incluem novos bugs. Assim, enquanto os bugs são resolvidos, novos bugs estão sendo introduzidos.

O verdadeiro ROI da qualidade melhorada

Há mais retorno sobre o investimento quando aumentamos a qualidade, em comparação com o custo para corrigir um defeito. Corrigir um bug no início do ciclo de vida economiza recursos financeiros e econômicos. Embora essa seja uma boa métrica e por si só seja suficiente para justificar o investimento em um processo de melhor qualidade, na verdade ela vai além da análise de ROI.

Uma das principais causas de atrasos no projeto são os defeitos não percebidos e as vulnerabilidades de segurança que chegam aos estágios finais de um ciclo de desenvolvimento de um produto.

Usando apenas a métrica de custo por defeito e a abordagem tradicional para calcular o ROI, considere um exemplo que envolve uma equipe de 20 pessoas trabalhando em um projeto com um custo de mão de obra de R$ 300 por hora. Essa equipe, usando novas ferramentas de automação de testes descobre 20 defeitos a mais do que nos sprints anteriores. Encontrar e corrigir esses bugs antecipadamente exige três horas por defeito, totalizando R$ 18.000. Encontrar e corrigir esses bugs posteriormente na integração ou no teste do sistema pode triplicar o esforço, levando custo a R$ 54.000.

De forma simplista, para este sprint, o ROI é de R$ 36.000. Parece ótimo, certo? No entanto, isso não leva em consideração os dois dias de economia de tempo de desenvolvimento para o sprint, com uma economia adicional de R$ 96.000 e aumento de produtividade.

Olhando para o quadro geral, podemos ver que o tempo de desenvolvimento de todo o lançamento tem impacto maior para a economia de recursos do que definir o custo por defeito. A recompensa real por realizar os testes no início do ciclo de vida do produto é atingir ou superar os cronogramas e metas do projeto. Considere o exemplo acima novamente. Desta vez, olhe para o ROI em termos de toda a equipe de desenvolvimento terminando o lançamento antes de 12 dias. Para esta equipe, são 12 dias de 20 pessoas, o que equivale a R$ 576.000! Embora este exemplo simples pareça óbvio, ele aponta que o ROI das ferramentas é realizado no nível da equipe, quando os produtos são entregues ao mercado mais rapidamente sem sacrificar a qualidade.

Como aumentar o ROI de testes de unidade: execução de teste de unidade

Seguindo com o exemplo acima, vamos supor que a equipe de desenvolvimento crie cada vez mais testes de unidade, desde testes de unidade solitary (isolados), que levam segundos para serem executados, até testes de unidade sociable (envolvendo integração) que levam muito mais tempo para serem executados.

O tempo de execução completo do conjunto de testes de unidade eventualmente aumenta para duas horas, o que é muito tempo para uma equipe de desenvolvimento de software esperar antes de obter feedback sobre as alterações de código. Se equipe segue uma metodologia Agile, então eles rodam o projeto várias vezes ao dia para fornecer feedback frequente, mas devido ao tempo de execução de duas horas do teste de unidade, eles podem executar apenas três compilações por dia, correspondendo a seis horas totais para execução diária de testes de unidade. Isso pode resultar em ineficiência no processo de desenvolvimento, pois outros membros da equipe podem começar a depender das alterações de código antes que o feedback dos testes automatizados esteja disponível.

Para reduzir o tempo de feedback do teste, a equipe pode otimizar a execução do teste de unidade com o Parasoft Jtest, que reduz o tempo necessário para executar testes de unidade com automação de teste baseada em IA, executando um conjunto otimizado de testes de unidade com base no código que foi alterado, em vez de executar o conjunto completo de testes.

Essa otimização acontece no ambiente de desenvolvimento integrado (IDE) do desenvolvedor antes da entrada do código, bem como durante as compilações de CI (Continuous Integration), enquanto o conjunto de testes completo continua sendo executado todas as noites. Ao reduzir o número de testes executados apenas para aqueles necessários para validar as alterações, o tempo geral de compilação é drasticamente reduzido e permite um feedback mais rápido para a equipe de software. Com isso, a equipe pode obter mais compilações por dia, o que otimiza sua produtividade durante a parte ativa do dia, resultando em um tempo de entrega mais rápido.

A keeggo e a Parasoft traz uma parceria de sucesso de alavanca o valor da ação dos nossos clientes, recentemente fizemos o Tech Talk: Velocidade na esteira DevOps com IA onde falamos mais sobre a aplicação cotidiana do tema.

Nossa equipe técnica está pronta para tirar suas dúvidas e te mostrar mais potencial das suas ações.

Venha conversar com a keeggo!