Gestão de defeitos.

Apresentação em tema: "Gestão de defeitos."— Transcrição da apresentação:

1 Gestão de defeitos

2 GARANTIR QUALIDADE Visão geral – Finalidade
Minimizar os riscos e entregar o sistema ao cliente com o mínimo de defeitos.

3 Visão geral – Conceitos básicos
Erro: resultado de uma falha humana. Defeitos: resultado de um erro existente em um código ou em um documento. A partir dessa simples explicação, podemos entender que os defeitos são resultados de erros de software desenvolvidos por pessoas.

4 Visão geral – Princípios
Evitar erros Todas as novas técnicas de testes de software estão sendo criadas com a intenção de iniciar os testes desde o início do projeto de desenvolvimento de software. Ao realizar os testes nos requisitos, com certeza estaremos tentando evitar defeitos em estágios posteriores.

5 Visão geral – Princípios
Minimizar os riscos Para que os defeitos sejam evitados. Os riscos devem ser minimizados nos projetos de desenvolvimento, e também, nos projetos de testes.

6 Visão geral – Princípios
Uso de ferramentas de automação e integração dos testadores e desenvolvedores É importante que exista uma integração entre testadores e desenvolvedores, para que seja possível que ambas as equipes atuem em conjunto e harmonia. Ambos os projetos deve ser paralelos.

7 Visão geral – Princípios
Coletar dados para realizar uma melhoria contínua É necessário que o material coletado pela gestão de defeitos seja utilizado pelos testadores e desenvolvedores com o objetivo de aperfeiçoar seus trabalhos.

8 Conceito de defeito – Visão geral
O objetivo desse tópico é apresentar o gerenciamento de defeitos no processo de teste de software.

9 Conceito de defeitos – O que é defeito
É definido em uma falha no processo onde retorna uma informação inesperada. Ex: Programador faz um código no projeto, e o Retorno desse código não é o esperado pelo Programador.

10 Conceito de defeito – Defeitos mais comuns
Os defeitos são ocasionados por vários motivos no processo do dia a dia, como usuários especificam os requisitos errados, analistas interpretam erradamente os requisitos, especificações funcionais e técnicas elaboradas erroneamente, codificação errada do projeto, Dados de entrada e saída errados, Correções erradas de defeitos encontrados.

11 Reportando Defeitos Sempre que um defeito for identificado devemos reportá-los a área responsável onde esse erro ocorreu. Com algumas informações Básica     Categoria do defeito (validação, algoritmo)     Grau de exigência (Alta, Média ou Baixa)     Prioridade do Defeito (Alta Media ou Baixa) Descrição do defeito ou do comportamento do resultado ou a própria mensagem de erro.

12 Podemos classificar os defeitos por Alguns Tópicos normalmente são os mais comuns
Tratamento de erros Não antecipar-se as falhas ou não evitar travamentos ou comportamentos anormais no programa. Erros de cálculos Falhas decorrentes de cálculos computacionais, tais como divisão por zero, estouro de campos, algoritmos errados.

13 Erros de inicialização Estados iniciais e finais de variáveis errados.
Controle do código fonte Não controlar adequadamente o código fonte do sistema

14 Documentação Testes Não manter a documentação atualizada.
Não ter uma política de teste, um planejamento e execução adequada, não definir o escopo

15 Processo de Gestão de Defeitos
Os elementos-chave do processo de gestão de defeitos são: prevenção de defeitos; linha-de-base (baseline)a ser entregue; Identificação do defeito; solução do defeito; melhoria do processo; relatório de gestão.

16 Prevenção de defeitos As técnicas de testes buscam cada vez mais diminuir o número de defeitos, ou, como forma de evitar retrabalhos e assim reduzir os custos e prazos, encontrar os defeitos o quanto antes. Isso significa que a equipe de testes está diretamente ligada com a equipe de desenvolvimento na verificação da documentação de software. Os testes devem estar presentes nos estágios iniciais do desenvolvimento de software, que é a maneira mais elementar de se prevenir defeitos.

17 Prevenção de defeitos Os principais passos para prevenção de defeitos são: Identificar os riscos críticos; estimar os impactos esperados; minimizar os impactos esperados.

18 Baseline a ser entregue
È considerado baseline, quando um produto atinge seu marco pré-definido pela equipe de desenvolvimento. Atingido esse marco, é transferido o produto de um estágio do processo de desenvolvimento para o próximo estágio.

19 Identificar defeito Um defeito é considerado identificado quando reconhecido como válido pela equipe de desenvolvimento. Isso significa que a equipe de testes encontra os defeitos, relata-os mas deve ser reconhecido pela equipe de desenvolvimento como válido. As etapas envolvidas na identificação de defeitos são: Encontrar defeitos; Relatar defeitos; Reconhecer defeitos.

20 Resolução do defeito Após reconhecido o defeito, ou seja, declarado como válido, o desenvolvimento inicia o processo de resolução. Os passos são: Priorizar a correção; Programar a correção; Corrigir o defeito; Relatar a solução.

21 Melhoria do Processo Embora seja talvez a atividade mais ignorada pelas organizações, é uma das que oferecem as melhores taxas de retorno. A ocorrência de defeitos, independentemente de sua importância, pode oferecer a oportunidade de avaliar o processo que os originou, de estudar como melhorá-lo e prevenir possíveis falhas graves.

22 Relatório de Log de Teste - Propósito
Tem um proposito básico de detalhar todas as atividades que foram realizadas durante o projeto de testes. Pode ser considerado um diário das atividades do projeto de teste.

23 Relatório de Log de Teste - Conteúdo
Identificação – Identificação única do relatório. Descrição – Descrever o que foi testado e o ambiente. Atividades e eventos – Informar data e hora e o tempo consumido para cada evento. Descrição da execução – Identificar os responsáveis e descrever o que foi realizado. Resultados – Descrever o resultado de cada atividade. Informação sobre o ambiente de teste – Informar o ambiente onde o teste foi realizado, apenas se necessário. Eventos imprevistos – Descrever os eventos imprevistos que podem acontecer durante algum teste.

24 Relatório de Incidentes de Teste - Propósito
Tem um proposito básico de detalhar toda e qualquer ocorrência no projeto de teste que necessita de investigação, ou seja, é o relatório utilizado para relatar os defeitos ocorridos durante os testes do sistema para que seja passado para a equipe de desenvolvedores, para seja realizadas as devidas correções.

25 Relatório de Incidentes de Teste - Conteúdo
Identificador do relatório – Identificador único em todo o projeto Sumário da ocorrência – Descrever em detalhes o que estava sendo realizando quando o incidente aconteceu. Descrição do incidente – O IEEE aconselha que a descrição do incidente contenha: Entradas Resultados esperados Resultados encontrados Data e hora da ocorrência Sugestões de procedimentos a serem tomados Ambiente Tentativas de contornar o problema Testadores envolvidos Observadores Impacto – Descrever o impacto que foi causado pela ocorrência do incidente.

26 Relatório de Sumário de Teste
Propósito Fornecer um sumário das atividades de teste realizadas durante um determinado projeto e mostra de forma resumidamente as ocorrências durante todas elas, é um relatório que costuma fechar o projeto de teste.

27 O relatório de sumário de teste deve ter os seguintes conteúdos básicos:
Identificador Sumário Variações Avaliação do processo Sumário dos resultados Avaliação de teste Sumário de atividades Aprovações

28 Identificador Sumário Variações
Código que identifica o relatório de sumário de teste Sumário Descreve resumidamente o trabalho de teste executado Variações Listar qualquer procedimento adotado que seja diferente do que foi inicialmente planejado.

29 Sumário dos resultados
Avaliação de processo Pode ser que algum tipo de teste tenha sido interrompido por pressões decorrentes de falta de prazo. Sumário dos resultados São todos os parâmetros que possam quantificar o projeto de teste que está se encerrando.

30 Avaliação do teste Sumário de atividades
O projeto de teste identifica, por exemplo, alguns riscos não agravados que podem causar problemas no momento em que o software entra em produção. Sumário de atividades O sumário de atividades deve listar as pessoas envolvidas no projeto de teste

31 Aprovações Nome das pessoas responsáveis pela aprovação do projeto de teste.

32 FIM