Execução e Relatório de Teste

Para continuar com o assunto “Relatório de Execução de Teste”, hoje vamos mostrar um pouco mais sobre Execução de Teste. A idéia deste post é auxiliar você com as atividades de planejamento, execução e relatórios de teste.

Execução dos casos de teste

Após a fase de Análise e Design de Teste ser concluída, chega à hora de entrar na fase de Execução de Teste. A primeira coisa que deve ser feita antes de começar a execução efetivamente é planejar e/ou rever o planejamento dessa fase. Para ajudar nesse planejamento uma boa prática é utilizar um Gráfico para mostrar o planejado versus o atual e, neste caso, nada melhor do que o Gráfico Curva-S. Abaixo temos a Tabela 1 – Gráfico Curva-S, a qual é utilizada para fazer o planejamento da execução dos casos de teste.

Tabela 1 – Gráfico Curva-S

Para facilitar o entendimento da tabela acima, segue abaixo a descrição de cada coluna:

• Data: data de execução planejada;
• Total Planejado: número total de casos de teste planejado para execução;
• Total Planejado Acumulativo: número total de casos de teste planejado acumulativo;
• Total Passado Planejado: número total de casos de teste passados no dia;
• Total Passado: número total de casos de teste passados acumulados;
• Total Falhado Planejado: número total de casos de teste falhados no dia;
• Total Falhado: número total de casos de teste falhados acumulados;
• Total Bloqueado Planejado: número total de casos de teste bloqueados no dia;
• Total Bloqueado: número total de casos de teste bloqueados acumulados;
• Total Atingido: número total de casos de teste executados até o momento somando, total passado, total falhado, total bloqueado;
• Comentário Execução: comentários gerais do planejamento.

Após a criação da tabela acima, basta gerar gráfico incluindo os campos Data, Total Planejado Acumulativo, Total Passado, Total Falhado, Total Bloqueado, Total Atingido, como mostrado abaixo na Figura 1 – Gráfico Curva-S.

Figura 1 – Gráfico Curva-S

Após a criação do Gráfico Curva-s, obtém-se o número total de casos de teste que foram planejados para execução incluindo os novos casos de teste, porcentagem de casos passados, falhados e bloqueados e casos de teste de regressão. Com isso é possível verificar se o planejamento feito anteriormente está de acordo com o atual, caso seja necessário, um novo re-planejamento deve ser feito e as partes interessadas informadas. Vale lembrar que a criação dos ciclos de teste deve ser planejada de acordo com o progresso da execução, estabilidade do software e critério de saída. Quando o planejamento está concluído, chega a hora da execução dos testes.
Os casos de teste são executados usando os procedimentos documentados e/ou automáticos do script de teste. Para que a fase de execução de teste seja executada com sucesso deve-se:

• Executar os casos de teste usando o documento de procedimentos de teste e/ou scripts de teste;
• Registrar o resultado atual;
• Comparar o resultado atual com o resultado esperado;
• Se necessário, repetir a execução de um caso de teste quando um incidente é encontrado, ou seja, devemos fazer o teste de confirmação;
• Executar testes de regressão como planejado.

Devido ao alto risco de mudança do código entre a execução de um ciclo e outro, deve-se ter uma política de re-teste bem definida.
Em alguns casos, testes podem ser executados “informalmente” sem usar procedimentos de teste detalhado, como por exemplo: teste exploratório.

Relatórios de Teste
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. 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.

Para ajudar no entendimento de como chegamos aos relatórios acima, segue abaixo a Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829.

Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829 -1998

Relatório de Log de Teste
Tudo o que for relevante durante a fase de execução de teste deve ser reportada no relatório de log de teste.
Segundo a norma IEEE 829 o relatório de log de teste deve ter as seguintes informações:

• Identificador: identificador único e específico para o relatório, por exemplo, o nome do sistema com número do release mais data e hora do teste;
• Descrição: identificar o que foi testado e o ambiente em que o teste foi executado incluindo hardware, quantidade de memória utilizada, etc;
• Atividades e eventos: para cada evento, identificar data/hora, tempo utilizado e responsável;
• Descrição da execução: descrever o que foi feito e identificar os responsáveis pela atividade incluindo testadores, observadores e operadores;
• Resultados dos procedimentos: para cada execução, descrever os resultados encontrados podendo ser sucesso ou não;
• Informações sobre ambiente de teste: informar qualquer condição específica do ambiente de teste, caso seja necessário;
• Eventos imprevistos: descrever detalhadamente o que aconteceu antes e depois de uma atividade ou evento inesperado.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

Relatório de Incidentes de Teste
Toda e qualquer discrepância entre o resultado esperado e o encontrado na execução dos casos de teste devem ser reportados para o time de desenvolvimento com o máximo de detalhes possíveis. Nesse caso, é utilizado o relatório de incidentes de teste o qual é registrado todos os defeitos encontrados durante a fase de execução de teste.
Segundo a norma IEEE 829 o relatório de incidente de teste deve ter as seguintes informações:

• Identificador do relatório: identificador único e específico para o relatório, por exemplo, release testado mais o identificador de um caso de teste ;
• Sumário da ocorrência: uma breve descrição do incidente; identificar os itens de teste envolvidos indicando sua versão, caso seja necessário; adicionar referência para a especificação do caso de teste, assim o desenvolvedor que for corrigir o defeito terá uma base de documento de teste além do documento de requisitos e adicionar também o relatório de log de teste, se necessário;
• Descrição do incidente: prover uma descrição do incidente incluindo os seguintes itens:
• ==>Entradas;
• ==>Resultados esperados;
• ==>Resultados encontrados;
• ==>Problemas;
• ==>Data e hora do incidente;
• ==>Procedimentos para reproduzir o problema;
• ==>Ambiente;
• ==>Tentativas para repetir o problema;
• ==>Testadores;
• ==>Observadores.
  

Vale lembrar que outras informações podem ser incluídas sempre que necessário e nem sempre todos os campos acima serão necessários.

• Impacto: indicar qual o impacto que o incidente terá no plano de teste de execução podendo falhar, bloquear o(s) testes(s) ou até mesmo uma possível mudança no caso de teste ou requisitos. Se possível, informar a prioridade e severidade do incidente.
  Os incidentes de teste devem ser armazenados em um repositório e, caso necessário, revisar o relatório de incidentes de teste com as partes interessadas.

Relatório de Sumário de Teste
Fornecer um sumário das atividades de teste incluindo os resultados, como o próprio nome do relatório já diz, relatório de sumário de teste. A idéia é resumir as atividades realizadas na execução dos testes.
Segundo a norma IEEE 829 o relatório de sumário de teste deve ter as seguintes informações:

• Identificador: identificador único e específico para o relatório, por exemplo, release e/ou projeto testado;
• Sumário: sumarizar a evolução das atividades de teste identificando os itens testados e o ambiente utilizado para execução dos testes;
• Variações: informar qualquer procedimento diferente do que estava especificado no plano de teste e procedimentos de teste; especificar o motivo da utilização do procedimento alternativo;
• Avaliações do processo: avaliação resumida do processo adotado contra o especificado no plano de teste; identificar as funcionalidades ou combinações de teste que não foram exercitadas explicando a razão; qualquer ocorrência que possa impactar na qualidade do software/produto deve ser considerada;
• Sumário dos resultados: sumarizar os resultados de teste identificando o número de casos de teste executados, número de defeitos encontrados, número de defeitos fechados e abertos, etc;
• Avaliação do(s) teste(s): proporcionar uma avaliação global de cada item, incluindo suas limitações. Essa avaliação deve ser baseada nos resultados dos casos de teste e nos critérios de aprovação/reprovação;
• Sumário de atividades: resumir os recursos envolvidos no projeto de teste, número total de horas utilizadas no projeto, tempo total utilizado para cada atividade principal, etc;
• Aprovações: listar o nome e títulos das pessoas responsáveis pela aprovação do projeto de teste incluindo os relatórios.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

No post Relatório Parcial de Execução de Teste você pode encontrar informações adicionais sobre relatório de teste.

Até+,
Quezada

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:

Relatório Parcial de Execução de Teste - Exemplo

Veja mais apresentações de Gustavo Quezada.

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