Gestão de defeitos - Sistema de Informação

Visão geral – Finalidade
GARANTIR
QUALIDADE
Minimizar os riscos e entregar o
sistema ao cliente com o mínimo de
defeitos.
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.
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.
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
Documentação
Não manter a documentação
atualizada.
Testes
Não ter uma política de teste,
um planejamento e execução
adequada, não definir o escopo
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.
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.
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.
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.
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.
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.
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.
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
Identificador

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.
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.
Sumário de atividades

O sumário de atividades deve listar as
pessoas envolvidas no projeto de teste
Aprovações

Nome das pessoas responsáveis pela
aprovação do projeto de teste.
FIM