quinta-feira, 3 de setembro de 2009

Processo de Teste: Avaliando critérios de saída e reportando

Falamos sobre Análise e Projeto de Teste de Software:
Estudo CTAL: Processo de Teste
Falamos sobre Implementação e Execução em dois artigos:
Processo de Teste: Implementação e Execução
Processo de Teste: Implementação e Execução II

E o próximo ponto importante para o Analista de Testes é avaliar os critérios de saída e gerar relatórios para acompanhamento do gerente.

Nesse ponto do processo serão coletadas informações para o gerenciamento e medido o progresso, que consequentemente leva a detecção de desvios do plano.

Para medir a completude do teste é possível considerar informações como:

- Número de condições de teste, casos de teste, ou procedimentos de teste planejados, executados, passados, e falhados
- Número total de defeitos classificados por severidade, prioridade, status, ou outro fator relevante
- Requisições de mudanças (change requests) propostas, aceitas, testadas
- Planejado versus real: Custos, cronograma, esforço...
- Riscos de qualidade mitigados e os restantes
- Tempo de teste perdido com eventos que bloquearam testes (time de implementação não liberou a versão na data planejada, o ambiente estava fora, etc)
- Resultados dos testes de confirmação e regressão


Resumo do Test Suite

Permite fazer um tracking de algumas propriedades importantes da execução


Nesta tabela podemos avaliar:

- Progresso dos testes cases
- Taxas de testes passados e falhados
- Defeitos por test suite de acordo com prioridade/severidade (weighted failure)
- Valor agregado

No lado esquerdo, as duas primeiras colunas são o nome do test suite e o número de caso de testes dele.

Depois, sob Planning Tests Fulfilled, tem-se os testes que estão prontos, que não tem nenhum trabalho adicional a ser feito neles.

Weighted Failure é uma métrica para os bugs encontrados em casa suite. O peso de cada um é medido de acordo com a sua prioridade e severidade num cálculo simples. Bugs com severidade 1 prioridade 1 tem o ponto total (1.00) e considerando 5 niveis de prioridade e 5 niveis de severidade, o bug de menor severidade e menor prioridade vale o mínimo de 0.04. Acrescendo esse valor a cada relação severidade x prioridade, temos valores médios para cada combinação severidade x prioridade, como fica mais claro na figura abaixo:


Em Planned Tests Unfulfilled estão os testes incompletos, que ainda há algum trabalho a ser feito neles. A propósito, caso gere dúvidas, IP é In Progress.

Earned Value é um conceito de gerenciamento de projetos que diz que em um projeto, nós realizamos tarefas gastando recursos (faz sentido, não?). Então se o percentual de tarefas realizadas é mais ou menos igual ao percentual de recursos gastos, estamos no caminho certo. Se o percentual de tarefas realizadas é maior que o percentual de recursos gastos, estamos em um caminho melhor ainda :), a tendência é ficar abaixo do orçamento. Se o percentual de tarefas realizadas é menor que o percentual de recursos gastos, estamos a caminho de passar do orçamento.

Do ponto de vista de cronograma, o percentual das tarefas realizadas deveria ser aproximadamente igual a percentual de periodo decorrido do projeto (elapsed time). Então se o percentual de tarefas está acima do percentual do cronograma, ficamos felizes e satisfeitos e se está abaixo, ficamos tristes e preocupados :P.

Na execução de testes, consideramos o caso de teste ou o procedimento de teste como nossa tarefa básica. Os recursos (para testes manuais) são “pessoa-hora” para rodar os testes.

Fácil? Difícil? :)

Mais um então!


Defect Breakdown

Uma das muitas formas de olhar um defeito é analisando ele sob a perspectiva de severidade x prioridade ou uma combinação dos dois.

Na figura abaixo, temos um gráfico que, comparado a gráficos similares de projetos anteriores, pode nos dizer se estamos indo bem ou não. O ideal é que ele inicia com mais bugs de prioridade/severidade maior, isso demonstraria uma boa aplicação de risk-based testing.

 Figura do livro Advanced Software Testing

Temos nesse gráfico, 5 pontos de severidade. A definição de como aplicar o nível de severidade e prioridade deve estar bem clara para todos os envolvidos no projeto. É bastante comum descobrir, atraves da avaliação desses gráficos, erros na classificação de defeitos.

Para um projeto que esteja no início, parece um bom comportamento gráfico, entretando para um projeto que esteja que esteja próximo ao término do ciclo de execução, é um gráfico bem preocupante.


Taxa de Falha de Confirmação

Um evento que poucos (ao menos eu vi poucos) se preocupam em medir é a taxa de falha de confirmação. O testador encontra um bug, o desenvolvedor resolve, o testador re-testa para confirmar a correção e ..... ? devolve para o desenvolvedor porque o problema não foi resolvido. Esse tipo de situação, que é comum, é uma perda de tempo. E pode ser medida através de um gráfico como esse:


Nesse exemplo, vários bugs foram reabertos, uma média de 1 a cada 6 defeitos reportados.


Padrões

De acordo com o famoso padrão IEEE 829, alguns itens que devem ser incluídos em um report de testes:

- Identificador do report
- Resumo (o que foi testado, quais são as conclusões, etc)
- Variações (do plano, dos casos, dos procedimentos)
- Avaliação compreensível
- Resumo dos resultados (métricas, etc)
- Avaliação de cada item de acordo com seus critérios de falha ou sucesso
- Resumo das atividades (uso de recursos, eficiência, etc)
- Aprovações

Esses resumos podem ser entregues durante a execução do teste, não necessáriamente só no final, e usado como ferramenta de acompanhamento.


Ainda sobre o assunto, eu sugiro a leitura dos seguintes artigos:

Execução e Relatório de Teste
Relatório Parcial de Execução de Teste

E um agradecimento especial ao autor desses dois artigos, o Gustavo Quezada, por nossa conversa sobre métricas. Ajudou bastante :)

2 comentários:

  1. Oi Sarah,

    Obrigado pelo agradecimento!!! Mas vamos falar a verdade vai... eu não ajudei em nada ;-)

    Vale lembrar que devemos tomar muito cuidado no momento de avaliar os números pois algumas vezes eles podem nos enganar. Tente entender o porque daquele número, não olhe pra ele simplesmente e saia tirando as suas conclusões.

    Pergunte, questione, entenda!!

    Parabéns, Sarah!

    Até+,
    Quezada

    ResponderExcluir
  2. Bem lembrado Gustavo.

    Aquele gráfico de Defect Breakdown pode demonstrar a má aplicação de severidade/prioridade nos defeitos.

    Assim como na análise do gráfico Taxa de Falha de Confirmação, pode-se concluir que os testadores não estão sendo precisos ao reportar defeitos.

    E por ai vai... A análise dos dados, chegar ao "por que" dos resultados é essencial.

    Att,
    Sarah

    ResponderExcluir