Métricas de teste

As informações sobre defeitos encontrados e corrigidos produzidas durante a atividade de testes são normalmente utilizadas pela gerência de desenvolvimento para avaliar a maturidade do produto. Essa e outras métricas geradas pela atividade de testes dão subsídios ao gerente de testes para o gerenciamento das suas equipes. Paakki [56] cita algumas métricas de defeitos e métricas de casos de teste úteis para o gerenciamento de projetos de teste:

• Número de defeitos por área funcional: esta métrica indica que áreas do

software possuem maior número de defeitos e, conseqüentemente, maior instabilidade e maior risco. O gerente de testes pode concentrar os esforços nas áreas que apresentarem um maior número de defeitos ao invés de dividir os esforços de forma igualitária entre todas as áreas do software, aumentando a efetividade do seu grupo de testes.

• Curva S: esta métrica compara o número de testes planejados e os executados ao longo do tempo e é uma boa ferramenta para acompanhar o progresso da execução de casos de teste. Através dessa métrica o gerente de testes tem a informação se a sua equipe está executando os testes dentro do prazo ou se aconteceu algum atraso ou antecipação do cronograma planejado.

Hutcheson [44] vai mais além na questão das métricas de teste argumentando que os objetos de teste têm múltiplas propriedades que muitas vezes só fazem sentido quando combinadas. Por exemplo, o número de defeitos encontrados só faz sentido se combinado com outras informações como a severidade, o tipo de defeito encontrado, número de defeitos corrigidos e outros. Hutcheson cita as métricas consideradas fundamentais para a atividade de testes de software:

• Tempo requerido para execução de um teste: geralmente estimado em

minutos ou horas por testes. Esta métrica é fundamental para estimar o esforço necessário para execução dos testes planejados. A execução de um

teste é normalmente dividida em atividades de setup, a execução

propriamente dita e atividades de cleanup. As atividades de setup, onde o testador prepara o sistema para o teste, e de cleanup, onde o testador ajusta o estado do sistema após a realização do teste, se necessário, também devem ser consideradas nesta métrica.

• Tempo disponível para o esforço de teste: é, normalmente, a métrica mais

rígida e mais divulgada e corresponde ao prazo para finalização das atividades de teste.

• Custo de teste: inclui, normalmente, o custo de remuneração dos testadores,

equipamentos e softwares, podendo ser quantificada em termos de custos para executar um teste ou uma suíte de testes. Embora o custo de realização de testes possa ser calculado facilmente, calcular os custos de não realização dos testes, o que fortemente justifica os investimentos em teste, não é uma tarefa fácil.

• Número de defeitos encontrados: é importante medir tanto os defeitos encontrados antes do lançamento do produto quanto os encontrados após o seu lançamento.

• Taxa de descoberta de defeitos: o número de defeitos descobertos por hora

dá uma boa indicação da estabilidade do sistema testado e também é útil para medir o custo de testes.

• Densidade de defeitos por área funcional: esta métrica permite identificar

as áreas onde ocorre maior concentração de defeitos e deve ser monitorada durante o esforço de teste. Útil para auxiliar os gerentes na decisão de onde concentrar os esforços de desenvolvimento e de teste, conforme mostra a Figura 7. O nível de severidade também influência nesta decisão.

0 2 4 6 8 10 12 14 16

App 1 App 2 App3 App 4

Severity 1 Severity 2 Severity 3 Severity 4

Figura 7 – Densidade de Defeitos por Área Funcional [44]

• Taxa de correção de defeitos: estudos realizados entre 1988 e 2000

demonstraram que a taxa de correção de defeitos encontrados em diversas aplicações comerciais era de 80 a 85 por cento. Pressões para o lançamento do produto, a baixa severidade de defeitos ou a dificuldade para reprodução de erros encontrados podem levar a gerência a decidir por não realizar a correção destes defeitos antes do lançamento do produto.

• Cobertura de testes: dado um conjunto de itens a serem testados, a cobertura de testes é a porção do que foi realmente testado e é normalmente representado em termos percentuais (cobertura = (testes conduzidos / total de testes) * 100). Uma cobertura de código de 100 por cento, por exemplo, significa que todos os comandos do programa foram testados. Como, na maioria das vezes, não é possível testar 100 por cento do código, a cobertura de código é, normalmente, calculada tomando como base a quantidade de testes planejados. A efetividade desta cobertura dependerá do quão bom for este conjunto de testes.

• Efetividade de testes: um conjunto efetivo de testes irá maximizar o número

de defeitos encontrados durante a realização dos testes. A efetividade de testes é a medida da habilidade de um conjunto de testes para descobrir defeitos e é a relação entre o número de defeitos encontrados na fase de teste sobre o número total de defeitos encontrados. Esta medida é usada para determinar a efetividade de uma determinada fase do processo de testes. A Figura 8, por exemplo, demonstra que a maioria dos defeitos está sendo descoberta na fase de testes de sistema, indicando uma cobertura pobre dos testes unitários e de integração.

Unit Test 19% Integration Test 15% System Test 57% Acceptance test 9%

Além destas, muitas outras métricas, tais como, número de testes realizados e número de testes com sucesso ou falhas podem auxiliar no gerenciamento do esforço de testes e nas decisões relativas à qualidade do produto. Uma questão fundamental no estabelecimento do conjunto de métricas a ser adotado é ter em mente que cada métrica deve ser simples, objetiva e fácil de ser coletada. Além disso, determinar quando e por quem serão coletadas e, principalmente, quem serão seus usuários evitará a criação indiscriminada de métricas que podem levar a um aumento do esforço dos envolvidos no processo de teste para coleta de dados que podem não ser úteis para a organização.