Teste e qualidade são duas máximas apresentadas com frequência em artigos, sala de aula, planejamento de projeto e ao longo do desenvolvimento de um software. E sempre levam a perguntas do tipo: quais os custos, as dificuldades de implementação e benefícios dos testes? Desenvolvimento ágil com qualidade e custo factível é possível?
A experiência de desenvolvimento ágil fortemente baseado em SCRUM tem ajudado a transpor várias barreiras e a quebrar muitos dos diversos mitos referentes às métricas de qualidade. Os pontos de avaliação do processo e da equipe e a melhoria contínua que a metodologia ágil proporciona são pontos essenciais do processo utilizado para desenvolver software. Apresentaremos neste artigo algumas das soluções e mitos sobre a adoção dessa prática.
Testar software é caro! Sim, testar é caro. Mas não testar é muito mais caro! E não, teste não é custo adicional do desenvolvimento. E de maneira alguma teste é algo que possa ser cortado ou reduzido. Quando todos entendem que teste faz parte do desenvolvimento, a própria equipe se reorganiza e garante que o teste não será negligenciado. É possível fazer isso usando-se um mix de TDD (Test-driven Design) e BDD (Behavior-driven Design) e vários níveis de testes ao longo do projeto (de teste unitário a teste de aceitação).
Isso pode ser feito comparando-se o número de métodos com CCN maior que dez com o número total de métodos do projeto. Após coletar e avaliar esse indicador duas ou três vezes, é possível chegar a um valor médio que faz sentido para o projeto e trabalhar para que o indicador fique dentro da meta estabelecida.
Usando essas métricas, fica mais seguro produzir o software de qualidade. A cobertura de testes traz essa segurança, aliada ao número de bugs do Findbugs sempre baixo, próximo de zero.
O número de métodos refatorados devido ao CCN alto diminui ao longo do projeto e se começa a criar novos métodos já observando sua complexidade. O código se torna mais simples de ler, pois os métodos se tornam menos complexos. O Findbugs traz novo conhecimento, principalmente referente a boas práticas de desenvolvimento, movimentando o conhecimento dentro da equipe e motivando ao estudo mais saprofundado das ferramentas utilizadas no desenvolvimento.
Para o cliente, todo esse movimento representa um número extremamente reduzido de defeitos nos testes de aceitação e a garantia de que a implementação de novos requisitos não trará impacto nos requisitos já entregues. Quem trabalha com entrega contínua de software sabe muito bem o quanto isso é importante.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?