terça-feira, 4 de agosto de 2009

Relatório Parcial de Execução de Teste

Quando estamos participando de uma execução de teste não basta executar, executar, executar, encontrar defeitos, encontrar mais defeitos e mais. Precisamos saber repassar/compartilhar para os Stakeholders (Partes interessadas no projeto) todo o trabalho que foi feito em forma de números e riscos. A idéia deste post é compartilhar com vocês um exemplo simples e fácil de reportar o status de uma execução de teste.

Um Analista de Teste precisa reportar os defeitos encontrados na execução de testes, juntamente com informações úteis para as partes interessadas no projeto. Na maioria das vezes, esses relatórios não usam nenhum padrão ou modelo nem são comuns para a organização e, o que é pior, não é possível saber se a execução está atrasada ou quais defeitos o time de desenvolvimento deverá dar prioridade.

O relatório parcial de execução deve ser resumido e objetivo, basicamente com as informações abaixo:

  • Informação do Plano Master;
  • Gráfico Curva-S Esforço;
  • Distribuição Gráfica de Defeitos;
  • Lista de Requisição de Mudanças;
  • Riscos;
  • Contatos;

1. Informação do Plano Master
A seção informação do plano master deve conter a quantidade de testes planejados, executados, passados, falhados e bloqueados até o momento. Ao verificar essa seção, o usuário deve ser capaz de obter as seguintes informações que são divididas em três partes:

Informações Gerais

  • Plano Master: nome do plano master;
  • # de Ciclos: número de ciclos executados até o momento;
  • Data de Início: data de início da execução;
  • Data de Término: data de término da execução;
  • Release Atual: versão do release usado na execução;

Dados de execução do(s) ciclo(s)

  • Ciclo: número do ciclo;
  • Total Planejado: número total de testes planejados;
  • Total Executado: número total de testes executados;
  • Total Passado: número total de testes passados;
  • Total Falhado: número total de testes falhados;
  • Total Bloqueado: número total de testes bloqueados;

Dados de execução do plano master

  • Total Planejado: número total de testes planejados;
  • Total Executado: número total de testes executados;
  • Total Passado: número total de testes passados;
  • Total Falhado: número total de testes falhados;
  • Total Bloqueado: número total de testes bloqueados;
Como um plano master pode conter vários ciclos, ou seja, um caso de teste pode ser executado em mais de um ciclo e o resultado da execução desse teste pode ser diferente em todos os ciclos, o valor reportado no plano master deve ser o resultado mais novo/atual reportado. Abaixo segue um exemplo para ilustrar as informações acima:

Informações Gerais
  • Plano Master: Portal Web de Notícias
  • # de Ciclos: 02
  • Data de Início: 01/08/2009
  • Data de Término: 12/08/2009
  • Release Atual: 01.00.01
Dados de execução do(s) ciclo(s)
  • Ciclo: 01 (data 05/08/2009)
  • Total Planejado: 100
  • Total Executado: 100 100%
  • Total Passado: 90 90%
  • Total Falhado: 05 05%
  • Total Bloqueado: 05 05%
  • Ciclo: 02 (data 12/08/2008)
  • Total Planejado: 10 (5 casos de teste falhados e 5 bloqueados)
  • Total Executado: 10 100%
  • Total Passado: 09 09%
  • Total Falhado: 01 01%
  • Total Bloqueado: 00 00%
Dados de execução do plano master
  • Total Planejado: 100;
  • Total Executado: 100 100%
  • Total Passado: 99 99%
  • Total Falhado: 01 01%
  • Total Bloqueado: 00 00%
2. Gráfico Curva-S Esforço
A seção gráfico curva-s esforço deve informar a quantidade de testes planejados, executados, passados, falhados e bloqueados até o momento, só que de forma gráfica, onde o usuário poderá comparar o esforço planejado X atual. Para gerar esse gráfico, o Analista de Teste deve ter uma tabela onde os valores são atualizados diariamente de acordo com o progresso. Segue abaixo um exemplo:


Tabela 1 – Tabela Gráfico Curva-S Esforço



Figura 1 – Gráfico Curva-S Esforço

3. Distribuição Gráfica de Defeitos
A seção distribuição gráfica de defeitos deve conter a quantidade de defeitos encontrados de forma gráfica. Ao verificar essa seção, o usuário deve ser capaz de saber quais são os defeitos que impactam um número maior de casos de teste e, dessa maneira, o Gerente de Projeto ou o próprio time de desenvolvimento poderá dar prioridade para os defeitos que mais impactam o resultado final da execução. Vale lembrar que nem sempre devemos olhar somente para o número de casos de teste que o defeito impacta, mas também analisar a severidade e prioridade do mesmo. Segue abaixo um exemplo:



Figura 2 – Gráfico de Defeitos Encontrados

4. Lista de Requisição de Mudanças
A seção lista de requisição de mudanças deve conter os defeitos encontrados com o ID do defeito, descrição, status, severidade, data de abertura, data de fechamento e duração (em dias).


  • ID do Defeito: identificador do defeito;
  • Descrição: descrição do defeito (deve ser uma descrição resumida);
  • Status: status do defeito (pode ser aberto, fechado, análise, assinalado, etc.);
  • Severidade: severidade do defeito;
  • Data de Abertura: data da abertura do defeito;
  • Data de Fechamento: data do fechamento do defeito;
  • Duração: quantidade de dias que o defeito levou para chegar ao status fechado;

Ao verificar essa seção, o usuário deve ser capaz de identificar quais são os defeitos que ainda continuam abertos e qual a sua gravidade, pois dessa maneira, o Gerente de Projeto ou o próprio time de desenvolvimento poderá dar prioridade para os defeitos que tem maior severidade e impactam no resultado final da execução. Segue abaixo um exemplo:



Tabela 2 – Defeitos Encontrados

5. Riscos
A seção Riscos deve conter os riscos identificados na fase de execução ou até mesmo os que estão em fases anteriores e, que de alguma forma, impactam o progresso de execução. Ao verificar essa seção, o usuário deve ser capaz de encontrar os riscos levantados até o momento de forma resumida, com uma descrição do risco e seu possível impacto não sendo necessário listar todos os dados dos riscos encontrados na fase de identificação dos riscos do produto. Segue abaixo um exemplo completo de como reportar um risco e, neste caso, fica a critério de cada Projeto e Equipe de Teste reportar os campos necessários:

Como faço para documentar os riscos?
Para documentar e fazer o acompanhamento dos riscos é necessário ter uma Matriz de Análise de Riscos. Nessa matriz temos alguns campos, por exemplo:

  • ID do Risco: campo utilizado para identificar o risco;
  • ID do Requisito: campo utilizado para identificar qual requisito está associado com o risco, se aplicável;
  • Projeto: campo utilizado para identificar o projeto associado ao risco;
  • Item de Risco: campo utilizado para documentar qual é o item de risco;
  • Status: campo utilizado para saber qual é o status do risco, por exemplo, aberto, fechado ou parado;
  • Impacto: campo utilizado para saber qual é o impacto do risco, por exemplo, alto, médio ou baixo;
  • Plano de Mitigação e Contingência: campo utilizado para documentar o plano de mitigação e contingência;
  • Pessoa Responsável: campo utilizado para identificar a pessoa responsável para ajudar, acompanhar ou resolver o risco;
  • Acompanhamento / Comentários: campo utilizado para documentar o acompanhamento e comentários em geral;
  • Data de Abertura: campo utilizado para indicar a data de abertura do risco;
  • Data de Fechamento: campo utilizado para indicar a data de fechamento do risco;
  • Duração (dias): campo utilizado para indicar a quantidade de dias que o risco ficou aberto.

6. Contatos
A seção Contatos deve conter informações dos participantes do projeto de teste, principalmente na fase de execução. Será por meio desta seção que o usuário deverá ser capaz de encontrar as pessoas em caso de dúvidas com os resultados reportados ou ter acesso a qualquer outra informação. Segue abaixo um exemplo:

Líder de Teste:

  • Email:
  • Telefone:

Analista de Teste:

  • Email:
  • Telefone:

Testador:

  • Email:
  • Telefone:

Para finalizar, segue o modelo do relatório:

Agora, se na sua empresa não tem um modelo de relatório parcial de execução de teste, você poderá conversar com o seu gerente imediato e propor o exemplo mostrado neste post ;-).

Caso ele não goste da idéia, não vai falar que viu isso no meu blog, hein?!?!?! :-D

Para obter mais detalhes sobre execução e relatório de teste, basta acessar o post Relatório e Execução de Teste.


Até+,
Quezada

4 comentários:

  1. Olá Gustavo!

    O trabalho que deve ter dado pra fazer o post, com certeza valeu a pena, o resultado ficou muito bom! :)

    Sò tenho uma consideração a fazer:

    Existe sim um relatório padrão que pode ser usado como base para o "Relatório Parcial de Execução de Teste", o "Relatório de Resumo de Teste" (Test Summary Report), definido pelo IEEE 829. E embora, na maioria das vezes, esse relatório seja usado como o relatório final, nada impede dele ser adaptado e enviado a cada iteração (sprint), por exemplo.

    Aliás, o objetivo desses dois relatórios é o mesmo - resumir os resultados das atividades de testes e prover avaliações baseadas nesses resultados. Além da estrutura dos relatórios terem tópicos em comum. ;)

    Mais um belo post, e que traz exemplos bem úteis!

    Abraços! E sucesso!

    Fabrício Ferrari de Campos

    ResponderExcluir
  2. Olá Fabrício,

    Valeu pelo feedback ;-) !!
    Eu não acrescentei dados da norma IEEE 829-1998 pois aqui eu queria mostrar um relatório mais "simples" e com escopo resumido para os stakeholders. Irei escrever um outro post relacionado com Execução de Teste que já comecei. Segue o início dele em primeira mão ;-)

    "Sempre que é encontrado um incidente de teste na fase de execução é necessário relatar esse incidente. Para isso, deve-se definir os relatórios necessários para acompanhar o progresso do(s) projeto(s) de teste segundo a norma IEEE 829-1998 [3]. Os relatórios de teste que a IEEE sugere são os seguintes:
    - Relatório de Log de Teste;
    - Relatório de incidentes de Teste;
    - Relatório de Sumário de Teste."

    Novamente, muito obrigado pelo feedback ;-) !!

    Até+,
    Quezada

    ResponderExcluir
  3. Muito bom!!!
    Sou um leitor assíduo desde o post 'Perguntas e Respostas'...bacana demais! Esclareceu e esclarece muitas dúvidas minhas!

    Sucesso!!!!
    Abração

    ResponderExcluir
  4. Opa Ricardo,

    Muito bom saber que o blog está ajudando no esclarecimento de dúvidas!! :-) Essa é a idéia !!

    Até+,
    Quezada

    ResponderExcluir