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.
• 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
Os elementos-chave do processo de gestão de defeitos são:
- 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;
- Priorizar a correção;
- Programar a correção;
- Corrigir o defeito;
- Relatar a solução;
• Relatório de gestão.
A maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do software.
• 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.
Segundo Beizer, a importância do defeito está diretamente ligada à:
• 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:
• 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:
• 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.
O defeito é considerado identificado quando reconhecido formalmente pelos desenvolvedores como defeito válido.
• Relatar defeito;
• Reconhecer defeito;
1.9.3.1. Encontrar defeito
Esta etapa utiliza de técnicas como:
• Técnicas dinâmicas realização de Testes
• Técnicas operacionais defeito descoberto como resultado de uma falha na operação do sistema
Ao relatar um defeito, devemos dar atenção aos seguintes detalhes:
• Precisão;
• Neutralidade;
• Isolamento;
• Generalização;
• Reprodução;
• Impacto;
• Provas.
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 gerente de desenvolvimento.
Tendo defeitos validados pelos desenvolvedores, se dá início ao processo de correção. Para isso são realizados os seguintes passos:
• 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.
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.
Notificar todos os envolvidos a correção, natureza da correção e como a correção será liberada.
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.
• 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”.
É importante que os defeitos sejam qualificados no início do processo de gestão de defeitos.
• Fase do ciclo de desenvolvimento ou atividade que o defeito ocorreu;
• Categoria do defeito. (ausente, impreciso, incompleto inconsistente)
Ueslei.
ResponderExcluirPode me passar a Bibliografia do livro BCTS que voce postou os resumos?