Resumo livro BCTS: Capítulo 8 – Gestão de Defeitos
Autor: Ueslei Silva | Publicado: 2010-08-23T14:39:00-07:00

Capítulo 8 – Gestão de Defeitos


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

&nbsp;O processo de gestão de defeitos se baseia nos seguintes princípios:&nbsp;• 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).

&nbsp;1.8. Conceito de defeito&nbsp;O Defeito ocorre em função de algum desvio em relação ao requisito:&nbsp;• 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.&nbsp;No entanto, defeitos podem decorrer da falta de entendimento do requisito ou simplesmente da falta de definição do requisito.
&nbsp;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&nbsp;
&nbsp;• 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
&nbsp;&nbsp;1.9. Processo de Gestão de Defeitos
Os elementos-chave do processo de gestão de defeitos são:

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

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

&nbsp;&nbsp;1.9.1. Prevenção de Defeitos

&nbsp;A maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do software.
&nbsp;Passos para prevenção de defeitos:

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

&nbsp;
&nbsp;1.9.1.1. Identificar os Riscos Críticos
&nbsp;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.&nbsp;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.
&nbsp;1.9.1.2. Estimar os impactos esperados

&nbsp;Segundo Beizer, a importância do defeito está diretamente ligada à:
&nbsp;• Freqüência com que o defeito ocorre;
• Custo da correção do defeito;
• Custo da instalação;
• Conseqüência.

&nbsp;
&nbsp;1.9.1.3. Minimizar os impactos esperados
&nbsp;Minimizar os impactos esperados envolve a combinação das seguintes estratégias:
&nbsp;• 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:

&nbsp;• 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.

&nbsp;
&nbsp;1.9.2. Linha-de-base (Baseline) a ser entregue
&nbsp;Um produto a ser entregue é considerado baseline quando alcança um marco pré-definido em seu desenvolvimento. &nbsp;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.
&nbsp;&nbsp;1.9.3. Identificação do defeito

O defeito é considerado identificado quando reconhecido formalmente pelos desenvolvedores como defeito válido.
&nbsp;As etapas envolvidas na identificação dos defeitos são:

&nbsp;• Encontrar defeito;
• Relatar defeito;
• Reconhecer defeito;

&nbsp;
&nbsp;1.9.3.1. Encontrar defeito
Esta etapa utiliza de técnicas como:
&nbsp;• 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

&nbsp;&nbsp;1.9.3.2. Relatar defeito

Ao relatar um defeito, devemos dar atenção aos seguintes detalhes:
&nbsp;• Resumo;
• Precisão;
• Neutralidade;
• Isolamento;
• Generalização;
• Reprodução;
• Impacto;
• Provas.

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

&nbsp;1.9.3.3. Reconhecer defeito

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

&nbsp;&nbsp;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:
&nbsp;• Priorizar a correção;
• Programar a correção;
• Corrigir o defeito;
• Relatar a solução;

&nbsp;
&nbsp;1.9.4.1. Priorizar a correção
Um método sugerido para priorização é classificar o defeito conforme os critérios a seguir:
&nbsp;• Crítico  sério impacto no negócio&nbsp;• Grave  erro grave ou pára de funcionar
• Menor  algo errado, mas não afeta os usuários

&nbsp;
&nbsp;1.9.4.2. Programar a correção
Refere-se ao processo de alocação de recursos para a correção do defeito.
&nbsp;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.
&nbsp;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.
&nbsp;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.
&nbsp;Essa atividade deve abranger:

&nbsp;• 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.

&nbsp;
&nbsp;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.&nbsp;O defeito pode ser definido por duas óticas:&nbsp;• Pelo ponto de vista do produtor  o defeito é causado por um desvio em relação às especificações;&nbsp;• Pela ótica do cliente  defeito é qualquer coisa que cause insatisfação, constando ou não nos requisitos. É chamada de visão “ajustada para uso”.
&nbsp;&nbsp;1.9.7. Qualificação do defeito

É importante que os defeitos sejam qualificados no início do processo de gestão de defeitos. 
&nbsp;É recomendada a seguinte estrutura de qualificação:

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

&nbsp;&nbsp;Posts relacionados: 

Resumo Livro BCTS: Capítulo 2 – Processo de teste
Resumo Livro BCTS: Capítulo 4 – Análise de Riscos
Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes
Resumo Livro BCTS: Capítulo 7 – Execução dos testes