Analyzing and Reporting Test Results

405 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
405
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Analyzing and Reporting Test Results

  1. 1. PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELETRÔNICA E COMPUTAÇÃO PG/EEC-I – 2º SEMESTRE 2010 – ITA CE - 237 Teste de Software - Semana 7 Eng. Thiago Tadeu de Carvalho Ferreira Passo 5 – Analisar e relatar os resultados dos Testes Cap 11 (Perry,2007)
  2. 2. Passo 5: Analisar e Relatar os Resultados do Teste <ul><li>A equipe de teste é responsável não apenas pela execução do teste, mas também consolidar os dados num formato que facilite a tomada de decisão da gerência. </li></ul><ul><li>Ao longo do capítulo 11, é explicado que a função da equipe de teste não é somente relatar os erros encontrados no Software; mas também escrever relatórios sobre gastos, recursos, status do cronograma (que seria o papel do Engenheiro da Qualidade de Software em outros livros) </li></ul>07.2b.
  3. 3. Preocupações <ul><li>Times de desenvolvimento tendem a ter uma visão otimista sobre o status do projeto. </li></ul><ul><li>Enquanto que o time de teste pode apresentar uma visão independente do mesmo. </li></ul><ul><li>Porém, o time deve estar atento a: </li></ul><ul><ul><li>Disponibilizar os relatórios sempre que necessário; </li></ul></ul><ul><ul><li>Com informações adequadas; </li></ul></ul><ul><ul><li>Ter certeza que as pessoas certas irão receber os relatórios corretos. </li></ul></ul>07.2b.
  4. 4. Bancada: Visão Geral 07.2b.
  5. 5. Bancada: Detalhamento <ul><li>Entradas: </li></ul><ul><ul><li>Plano de Teste e também Plano do Projeto, pois será contra esses dois planos que os testadores reportarão o status do projeto </li></ul></ul><ul><ul><li>Saber os resultados esperados (requisitos claros) </li></ul></ul><ul><ul><li>Dados coletados durante o teste!!! </li></ul></ul>07.2b.
  6. 6. Dados coletados durante o teste <ul><li>Não se limita somente aos defeitos encontrados durante os testes </li></ul><ul><li>Mas também os resultados de revisões e inspeções feitos em documentos (exemplo: documento de requisitos) </li></ul><ul><li>E também validar que os objetivos do negócio foram encontrados. </li></ul><ul><li>Armazenar todos os dados num banco de dados especifico </li></ul>07.2b.
  7. 7. Tarefas <ul><li>1 Reportar o status do projeto </li></ul><ul><li>2 Reportar resultados provisórios do teste </li></ul><ul><li>3 Reportar o resultados finais do teste </li></ul>07.2b.
  8. 8. Tarefa 1: Reportar o status do projeto <ul><li>Essa tarefa oferece uma abordagem para reportar o status do projeto </li></ul><ul><li>Dois relatórios devem ser gerados: </li></ul><ul><ul><li>Resumido: Visão geral de todos os projetos. Usado para mostrar quais projetos necessitam de atenção imediata da gerência </li></ul></ul><ul><ul><li>Relatório do Status do Projeto: Informação detalhada sobre cronograma, recursos, orçamentos </li></ul></ul>07.2b.
  9. 9. Tarefa 1: Reportar o status do projeto <ul><li>Porém, um processo deve ser estabelecido para que os dados dos relatórios sejam confiáveis. Logo, seis sub-tarefas foram estabelecidas </li></ul><ul><li>Estabelecer uma equipe de medição </li></ul><ul><li>Criar um inventário para as medições existentes (seguindo um planejamento </li></ul><ul><li>Criar um conjunto de métricas </li></ul><ul><li>Definir os requisitos para esse processo de medições (relatórios desejados, ferramentas utilizadas etc.) </li></ul><ul><li>Desenvolver e Implementar o Processo </li></ul><ul><li>Monitorar o Processo </li></ul>07.2b.
  10. 10. Exemplo de Relatórios <ul><li>Relatório Resumido: </li></ul>07.2b.
  11. 11. Exemplo de Relatórios <ul><li>Relatório Completo: </li></ul>07.2b.
  12. 12. Tarefa 2: Reportar resultados provisórios <ul><li>São apresentados 10 exemplo de relatórios provisórios </li></ul><ul><li>O autor recomenda que todos sejam preparados para serem incorporados depois no Relatório Final </li></ul>07.2b.
  13. 13. Relatório 1: Matriz Função/Teste <ul><li>Apresenta quais testes devem ser feitos para validar as funções do software, e em qual sequência isso deverá ser feito </li></ul><ul><li>Para fazer essa matriz, é necessário antes preencher o Work-Paper 11-1 </li></ul><ul><li>Esse Work Paper deverá ser preenchido toda vez que um defeito por descoberto </li></ul>07.2b.
  14. 14. Work Paper 11-1 07.2b.
  15. 15. Relatório 1: Matriz Função/Teste <ul><li>Com base nesse work paper, uma matriz função/teste deve ser feita, onde a intersecção do teste e da função pode ser codificada com um número que indique: </li></ul><ul><li>1 = Teste necessário, mas não foi feito </li></ul><ul><li>2 = Teste sendo feito </li></ul><ul><li>3 = Defeito com baixa criticidade </li></ul><ul><li>4 = Defeto com alta criticidade </li></ul><ul><li>5= Teste completo, e a função não possui error(para os critérios desse teste) </li></ul>07.2b.
  16. 16. Relatório 1: Matriz Função/Teste 07.2b. O que entendi da Matriz seria Porém o livro exemplifica com 'X' (???)
  17. 17. Relatório 2: Status Funcional dos Testes CE-237 Prof. VDias & Prof. Cunha - Semana 6 07.2b. O propósito desse relatório e mostrar a porcentagem de funções: que foram totalmente testadas, não testada ou ainda que não foram corrigidas.
  18. 18. Relatório 3: Cronograma para Funcionamento das Funções (Functions Working Timeline Report) 07.2b. <ul><li>Esse relatório mostra o status do teste e a probabilidade que o SW estará pronto na data estimada. </li></ul>
  19. 19. Relatório 4: Esperado vs Atual ( defeitos encontrados ) 07.2b. <ul><li>O propósito desse relatório é mostrar se o número de defeitos é maior ou menor do que o esperado. Isso mostra que a organização possui uma série histórica para poder planejar a quantidade de defeitos, e que também o processo de desenvolvimento é suficientemente estável para que a média dos defeitos encontrados sejam relativamente consistente. </li></ul>
  20. 20. Relatório 4: Esperado vs Atual ( defeitos encontrados ) 07.2b.
  21. 21. Relatório 5: Defeitos vs Correções 07.2b. <ul><li>O propósito desse relatório é listar os defeitos que ainda não foram corrigidos. É necessário armazenar os defeitos assim que encontrados, e depois quando forem corrigidos </li></ul><ul><li>Plotando o gráfico para ambos, será fácil de identificar quantos defeitos ainda estão por corrigir. </li></ul>
  22. 22. Relatório 5: Defeitos vs Correções 07.2b.
  23. 23. Relatório 6: Idade Média dos Defeitos 07.2b. <ul><li>Esse relatório mostra, dividido por severidade (menor, maior e crítica), um média da idade (em dias) dos defeitos ainda não corrigidos </li></ul>
  24. 24. Relatório 7:Distribuição dos Defeitos 07.2b. <ul><li>O propósito desse relatório é distribuir os defeitos entre os módulos/unidades que compõem o projeto de SW </li></ul>
  25. 25. Relatório 8: Distribuição dos Defeitos Normalizada 07.2b. <ul><li>Tem o mesmo objetivo do relatório anterior, porém o número de defeitos é normalizado, por exemplo: defeitos por 100 pontos de função ou por 1000 linhas de código. </li></ul>
  26. 26. Relatório 9: Ação do teste 07.2b. <ul><li>Esse é um resumo que contém informações coletadas nos relatórios anteriores. </li></ul><ul><li>Endereçado ao Gerente do Desenvolvimento ou Gerente da equipe de Teste => para que ambos possam tomar as ações necessárias </li></ul><ul><li>É composto por 4 informações: 1) Testes em atraso, 2) Defeitos críticos não corrigidos, 3) Principais Defeitos de idade igual a 5 dias não corrigidos e 4) e o número total de defeitos ainda não corrigidos. </li></ul>
  27. 27. Relatório 9: Ação do teste 07.2b.
  28. 28. Relatório 10: Provisório CE-237 Prof. VDias & Prof. Cunha - Semana 6 07.2b. <ul><li>Esse relatório deve mostrar os resultados dos testes até então, o que funciona e o que não funciona e recomendações </li></ul><ul><li>Importante ressaltar no relatório o escopo do teste, do contrário o leitor poderá erroneamente assumir que um teste exaustivo foi realizado, o que não é possível! (questões práticas e econômicas) </li></ul><ul><li>Logo, o escopo deve explicar claramente o que o testadores fizeram </li></ul>
  29. 29. Relatório 10: Provisório 07.2b.
  30. 30. Relembrando as tarefas!! 07.2b.
  31. 31. Tarefa 3: Resultados Finais do Teste 07.2b. <ul><li>Um relatório final deve ser feito para documentar os resultados do testes, se estes estão de acordo com o Planejamento dos Testes </li></ul><ul><li>O cliente pode determinar se o sistema está pronto para a produção </li></ul><ul><li>Ele deve resumir o conteúdo dos seguintes testes: </li></ul><ul><ul><li>Relatório Individual de cada Testador (igual ao provisório) </li></ul></ul><ul><ul><li>Teste de Integração </li></ul></ul><ul><ul><li>Teste de Sistema (capítulo 8) </li></ul></ul><ul><ul><li>Teste de Aceitação </li></ul></ul>
  32. 32. Monitorar o trabalho: WP 11-2 07.2b. <ul><li>Para monitorar se o processo de reportar os resultados do teste foi feito corretamente, o autor propõe a utilização do Work-Paper 11-2 </li></ul><ul><li>É um questionário dividido em 3 partes. Controle da Qualidade para: </li></ul><ul><ul><li>Escrever o relatório de status; </li></ul></ul><ul><ul><li>Desenvolver o relatório provisório. </li></ul></ul><ul><ul><li>Escrever o relatório final. </li></ul></ul>
  33. 33. Monitorar o processo: WP 11-2 e 11-3 07.2b. <ul><li>Para monitorar se o processo de reportar os resultados do teste foi feito corretamente, o autor propõe a utilização do Work-Paper 11-2 </li></ul><ul><li>O primeiro é um questionário dividido em 3 partes, enquanto que o segundo que ajudará os testadores escreverem relatórios eficazes. </li></ul>
  34. 34. Monitorar o processo: WP 11-2 07.2b.
  35. 35. Monitorar o processo: WP 11-3 07.2b.
  36. 36. Considerações finais 07.2b. <ul><li>A empresa deve adaptar o processo aqui apresentado: quais relatórios devem ser feitos? </li></ul><ul><li>Uma vez que um conjunto de relatórios foi escolhido, eles devem formar uma linha base ( baseline ) para que os projetos possam ser comparados entre si, identificando quais projetos estão abaixo da média da empresa </li></ul>

×