quinta-feira, 13 de agosto de 2009

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.

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

Nenhum comentário:

Postar um comentário