GESTÃO DE DEFEITOS

GARANTIR QUALIDADE

Minimizar os riscos e entregar o sistema ao cliente com o mínimo de defeitos.

Visão geral – Finalidade

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.

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.

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.

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.

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.

Conceito de defeito – Visão geral

O objetivo desse tópico é apresentar o gerenciamento de defeitos no processo de teste de

software.

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.

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.

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.

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.

Podemos classificar os defeitos por Alguns Tópicos normalmente são os mais comuns

Controle do código fonte

Não controlar adequadamente o código fonte do sistema

Erros de inicialização

Estados iniciais e finais de variáveis errados.

Testes

Não ter uma política de teste, um planejamento e execução adequada, não definir o escopo

Documentação

Não manter a documentação atualizada.

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.

Processo de Gestã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.

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.

Prevenção de defeitos

È 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.

Baseline a ser entregue

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.

Identificar 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.

Resolução do defeito

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.

Melhoria do Processo

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.

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.

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.

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.

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.

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

Sumário

Código que identifica o relatório de sumário de teste

Identificador

Descreve resumidamente o trabalho de teste executado

Variações Listar qualquer procedimento adotado

que seja diferente do que foi inicialmente planejado.

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.

Avaliação do teste

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.

O sumário de atividades deve listar as pessoas envolvidas no projeto de teste

Sumário de atividades

Aprovações

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

FIM