1. Como utilizar indicadores de qualidade no desenvolvimento de
software
Vanessa Campos
Publicado na iMasters em 11/09/2012
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).
O primeiro mito que pode ser vencido é o de que a taxa de cobertura de testes não é um
número significativo. Realmente, se analisarmos somente a taxa de cobertura, isoladamente,
ela não significa muito. Porém, quando são usados vários mecanismos de teste e se define
muito bem o escopo da taxa de cobertura usando-se os plugins maven-cobertura-plugin e
maven-surefire-plugin, é possível ter tranquilidade em afirmar que a cobertura de testes está
alta ou baixa. Isso quando se considera na taxa de cobertura somente o código que trata do
negócio do sistema.
À primeira vista, o número pode não parecer muito significativo. Porém, ao longo do projeto,
refatoramentos do código são necessários. Nesse ponto é que a equipe percebe a
importância da taxa de cobertura estar alta e bem medida, pois o a essa altura o software já
estará bem testado, e é possível garantir que todo o impacto causado pela mudança foi
tratado.Passada a primeira barreira, é importante decidir ir um pouco além e adicionar mais
métricas de qualidade. Dessa vez, pode-se optar por usar o CCN (Cyclomatic Complexity
Number) e o número de bugs de código, usando-se a ferramenta Findbugs.O CCN é uma
métrica de código desenvolvida por Thomas J. McCabe para indicar a complexidade do
código. Segundo McCabe, um trecho de código deve ser avaliado sempre que o CCN
exceder 10. Todo método cujo CCN excede 10 é candidato a refatoramento. E, com isso,
pode-se quebrar outro mito do projeto: durante o desenvolvimento, não há tempo para
melhorar o código. Lembre-se: é importante testar muito bem, medir a cobertura de testes
constantemente e reavaliar esses números o tempo todo. Mas somente a lista de métodos
candidatos não é suficiente. Por isso, deve-se criar um indicador para medir a qualidade do
software.
Isso pode ser feito comparando-se o número de métodos com CCN maior que dez com o

2. 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.
Seguindo nessa linha de melhoria contínua, é interessante adotar também o Findbugs e criar
um indicador para ele, comparando o número de bugs com o número de linhas de código. O
Findbugs proporciona uma análise diferente, pois encontra falhas, e não defeitos no sistema.
Ou seja, nos indica potenciais futuros bugs da aplicação, além de mostrar à equipe melhores
maneiras de desenvolver software, criando uma oportunidade de aprendizado dentro do
projeto.Com esse mix de ferramentas e indicadores sendo avaliados constantemente, pode-
se focar nos pontos críticos do sistema, introduzir uma cultura de avaliação e melhoria
contínua do software, além de proporcionar a toda a equipe momentos de avaliação do
código e uso de boas práticas de desenvolvimento.
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.
Leia o artigo na iMasters e deixe seu comentário:
http://imasters.com.br/desenvolvimento/como-utilizar-indicadores-de-qualidade-no-desenvolvimento-de-software/
Entre em contato com a autora do artigo:
Vanessa Campos
fb.com/camposvoc
@vanessaocampos