segunda-feira, 23 de agosto de 2010

Resumo livro BCTS: Capítulo 8 – Gestão de Defeitos

Capítulo 8 – Gestão de Defeitos


 
Erro: resultado de uma falha humana.
Defeito: resultado de um erro existente num código ou num documento.

 
O processo de gestão de defeitos se baseia nos seguintes princípios:
 
• O objetivo primordial é evitar defeitos;
• Um dos princípios básicos para evitar defeitos é minimizar riscos, não só do projeto de desenvolvimento, mas também do projeto de teste;
• Integração entre desenvolvedores e testadores através de uma ferramenta de gestão de defeitos;
• Automação da gestão de defeitos é um fator muito importante para o sucesso;
• Melhoria contínua e
• Utilizar práticas de modelos de processo (Ex: CMMI).


 1.8. Conceito de defeito 
O Defeito ocorre em função de algum desvio em relação ao requisito:
 
Defeitos decorrentes de falta de concordância com a especificação do produto  As especificações dizem uma coisa e o software faz outra.
Defeitos decorrentes de situações inesperadas, mas não definidas nas especificações do produto O gestor ou usuário não definiu nada nas especificações, porém o software age de maneira inesperada em determinadas situações.
 
No entanto, defeitos podem decorrer da falta de entendimento do requisito ou simplesmente da falta de definição do requisito.

 
1.8.1. Tipos de Defeito
Defeito de interface com o usuário;
  • Defeitos de funcionalidade  quando o sistema não faz algo que o usuário espera que o faça
  • Defeitos de usabilidade dificuldades de navegação
  • Defeitos de desempenho não atende com rapidez necessária as solicitações do usuário
  • Defeitos de saída o resultado apresentado pelo software não corresponde ao que foi definido pelo usuário nas especificações ou foram mal projetadas 
 • Defeitos introduzidos no tratamento de defeitos;
  • Prevenção dos defeitos  o programa não se protege de entradas de dados imprevistas
  • Detecção dos defeitos  o programa não trata, ou trata inadequadamente, as indicações de defeitos esultantes de suas ações
  • Recuperação dos defeitos  mesmo detectando o defeito, o programa falha porque não trata adequadamente a situação
Defeitos de limite  não consegue tratar ou trata inadequadamente valores extremos
Defeitos de cálculo  efetua cálculo e produz resultado errado
Defeitos de inicialização ou fechamento  ausência de inicialização ou fechamento de rotinas, arquivos, etc.
Defeitos de controle de fluxo declaração de variável erroneamente
Defeitos de manuseio ou de interpretação de dados  ocorre quando um programa tem que passar um grupo de dados para outro programa
Defeitos de condição de disputa  ocorre quando o programa espera uma resposta dos eventos A e B, sendo presumido que A sempre termina primeiro, mas B terminou primeiro
Defeitos de carga  o programa não suporta um pico de serviço num determinado momento (estresse) ou uma carga alta de serviço por um tempo muito prolongado
Defeito de hardware e software  incompatibilidades entre o programa e o ambiente onde é processado
Defeitos de controle de versão  falha no processo de gestão de configuração

  
1.9. Processo de Gestão de Defeitos
Os elementos-chave do processo de gestão de defeitos são:

 
• Prevenção de defeitos;
  • Identificar os riscos críticos; 
  • Estimar os impactos esperados; 
  • Minimizar os impactos;

 • Linha-de-base (baseline) a ser entregue; 
• Identificação dos defeitos;
  • Encontrar defeito; 
  • Relatar defeito; 
  • Reconhecer defeito;
 • Solução do defeito;
  • Priorizar a correção; 
  • Programar a correção; 
  • Corrigir o defeito; 
  • Relatar a solução;
• Melhoria do processo;
• Relatório de gestão.

  
1.9.1. Prevenção de Defeitos

 A maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do software.

 
Passos para prevenção de defeitos:

 
• Identificar os riscos críticos;
• Estimar os impactos esperados;
• Minimizar os impactos;

 

 1.9.1.1. Identificar os Riscos Críticos

 A melhor maneira de fazer isso é identificar os tipos de defeitos que representam as maiores ameaças, ou seja, defeitos que podem colocar em risco o sucesso da construção, entrega e/ou operação do software.
 
A ênfase desse passo não é identificar todos os riscos, e sim identificar os riscos críticos que podem prejudicar o sucesso do projeto e que merecem atenção especial.

 
1.9.1.2. Estimar os impactos esperados

 Segundo Beizer, a importância do defeito está diretamente ligada à:

 
• Freqüência com que o defeito ocorre;
• Custo da correção do defeito;
• Custo da instalação;
• Conseqüência.

 

 1.9.1.3. Minimizar os impactos esperados

 Minimizar os impactos esperados envolve a combinação das seguintes estratégias:

 
• Eliminar o risco; (às vezes não é possível)
• Reduzir a probabilidade de o risco se tornar um problema; (Mitigar os riscos)
• Reduzir o impacto se houver problema. (contigenciar o risco)

Algumas técnicas podem se utilizadas para reduzir o impacto esperado. Entre essas técnicas temos:

 
Garantia da Qualidade  área de GQA
Treinamento e educação  voltado para desenvolvimento, teste e usuários
Metodologias e padrões  processos bem definidos, metodologias adequadas e padrões consistentes
Desenho defensivo;
Código defensivo.

 

 1.9.2. Linha-de-base (Baseline) a ser entregue

 Um produto a ser entregue é considerado baseline quando alcança um marco pré-definido em seu desenvolvimento.
 
Depois de o produto se tornar baseline, recomenda-se que este seja colocado sob gerenciamento de configuração. Um defeito é caracterizado quando um componente de um produto baseline não satisfaz seu conjunto de requisitos.

  
1.9.3. Identificação do defeito

O defeito é considerado identificado quando reconhecido formalmente pelos desenvolvedores como defeito válido.

 
As etapas envolvidas na identificação dos defeitos são:

 
• Encontrar defeito;
• Relatar defeito;
• Reconhecer defeito;

 

 1.9.3.1. Encontrar defeito

Esta etapa utiliza de técnicas como:

 
Técnicas estáticas  Revisões, walkthrough e inspeções
Técnicas dinâmicas  realização de Testes
Técnicas operacionais defeito descoberto como resultado de uma falha na operação do sistema

  
1.9.3.2. Relatar defeito

Ao relatar um defeito, devemos dar atenção aos seguintes detalhes:

 
• Resumo;
• Precisão;
• Neutralidade;
• Isolamento;
• Generalização;
• Reprodução;
• Impacto;
• Provas.

 
Ao relatar um defeito, devemos indicar, entre outras coisas, o impacto que ele representa tato para o sistema quanto para os negócios.

 
1.9.3.3. Reconhecer defeito

Depois de detectado o defeito, o desenvolvedor deve decidir se ele é válido ou não.
 
Quando um grupo achar que é defeito (os usuário, por exemplo) e outro grupo achar que não é, as abordagens mais eficazes são:
 
• Arbitragem pelo usuário;
• Arbitragem pelo gerente de desenvolvimento.

  
1.9.4. Solução do defeito

Tendo defeitos validados pelos desenvolvedores, se dá início ao processo de correção. Para isso são realizados os seguintes passos:

 
• Priorizar a correção;
• Programar a correção;
• Corrigir o defeito;
• Relatar a solução;

 

 1.9.4.1. Priorizar a correção

Um método sugerido para priorização é classificar o defeito conforme os critérios a seguir:

 
Crítico  sério impacto no negócio 
Grave  erro grave ou pára de funcionar
Menor  algo errado, mas não afeta os usuários

 

 1.9.4.2. Programar a correção

Refere-se ao processo de alocação de recursos para a correção do defeito.

 
1.9.4.3. Corrigir o defeito

Envolve a verificação de um ou mais produtos necessários para a remoção do defeito (p.e.: programas, documentos) e a execução da correção.

 
1.9.4.4. Relatar a solução

Notificar todos os envolvidos a correção, natureza da correção e como a correção será liberada.

 
1.9.5. Melhoria do processo

A ocorrência de defeitos, independente de sua importância, pode oferecer a oportunidade de avaliar o processo que os originou, de estudar como melhorá-los e prevenir possíveis falhas.

 
Essa atividade deve abranger:

 
• Avaliação do processo que originou o defeito e a compreensão do que o causou;
• Se pertinente, propostas de mudanças processuais capazes de minimizar ou eliminar a causa do defeito.

 

 1.9.6. Relatórios de gestão

O propósito dessa atividade é criar um registro completo dos desvios identificados durante o processo de teste para que sirvam de base a várias utilizações no decorrer do projeto, o que inclui as medições de qualidade.
 
O defeito pode ser definido por duas óticas:
 
Pelo ponto de vista do produtor  o defeito é causado por um desvio em relação às especificações; 
Pela ótica do cliente  defeito é qualquer coisa que cause insatisfação, constando ou não nos requisitos. É chamada de visão “ajustada para uso”.

  
1.9.7. Qualificação do defeito

É importante que os defeitos sejam qualificados no início do processo de gestão de defeitos.

 
É recomendada a seguinte estrutura de qualificação:

 
• Definição do defeito;
• Fase do ciclo de desenvolvimento ou atividade que o defeito ocorreu;
• Categoria do defeito. (ausente, impreciso, incompleto inconsistente)

 
 

Um comentário:

  1. Ueslei.
    Pode me passar a Bibliografia do livro BCTS que voce postou os resumos?

    ResponderExcluir