ResumoLivroBaseConhecimentoTesteSoftware
37 pág.

ResumoLivroBaseConhecimentoTesteSoftware


DisciplinaTestes de Software701 materiais7.134 seguidores
Pré-visualização9 páginas
podem decorrer da falta de entendimento do requisito ou simplesmente da falta de 
definição do requisito.
 
1.8.1. Tipos de Defeito
\u2022 Defeito de interface com o usuário;
\u2022Defeitos de funcionalidade quando o sistema não faz algo que o usuário espera que o faça\uf0e0
\u2022Defeitos de usabilidade dificuldades de navegação\uf0e0
\u2022Defeitos de desempenho não atende com rapidez necessária as solicitações do usuário\uf0e0
\u2022Defeitos de saída o resultado apresentado pelo software não corresponde ao que foi definido pelo\uf0e0 
usuário nas especificações ou foram mal projetadas 
 \u2022 Defeitos introduzidos no tratamento de defeitos;
\u2022Prevenção dos defeitos o programa não se protege de entradas de dados imprevistas\uf0e0
\u2022Detecção dos defeitos o programa não trata, ou trata inadequadamente, as indicações de defeitos\uf0e0 
esultantes de suas ações
\u2022Recuperação dos defeitos mesmo detectando o defeito, o programa falha porque não trata\uf0e0 
adequadamente a situação
\u2022 Defeitos de limite não consegue tratar ou trata inadequadamente valores extremos\uf0e0
\u2022 Defeitos de cálculo efetua cálculo e produz resultado errado\uf0e0
\u2022 Defeitos de inicialização ou fechamento ausência de inicialização ou fechamento de rotinas, arquivos, etc.\uf0e0
\u2022 Defeitos de controle de fluxo declaração de variável erroneamente\uf0e0
\u2022 Defeitos de manuseio ou de interpretação de dados ocorre quando um programa tem que passar um grupo \uf0e0
de dados para outro programa
\u2022 Defeitos de condição de disputa ocorre quando o programa espera uma resposta dos eventos A e B, sendo \uf0e0
presumido que A sempre termina primeiro, mas B terminou primeiro
\u2022 Defeitos de carga o programa não suporta um pico de serviço num determinado momento (estresse) ou uma\uf0e0 
carga alta de serviço por um tempo muito prolongado
\u2022 Defeito de hardware e software incompatibilidades entre o programa e o ambiente onde é processado\uf0e0
\u2022 Defeitos de controle de versão falha no processo de gestão de configuração\uf0e0
 
1.9. Processo de Gestão de Defeitos
Os elementos-chave do processo de gestão de defeitos são:
 
\u2022 Prevenção de defeitos;
\u2022Identificar os riscos críticos; 
\u2022Estimar os impactos esperados; 
\u2022Minimizar os impactos;
 \u2022 Linha-de-base (baseline) a ser entregue; 
\u2022 Identificação dos defeitos;
\u2022Encontrar defeito; 
\u2022Relatar defeito; 
\u2022Reconhecer defeito;
 \u2022 Solução do defeito;
\u2022Priorizar a correção; 
\u2022Programar a correção; 
\u2022Corrigir o defeito; 
\u2022Relatar a solução;
\u2022 Melhoria do processo;
\u2022 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:
 
\u2022 Identificar os riscos críticos;
\u2022 Estimar os impactos esperados;
\u2022 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 à:
 
\u2022 Freqüência com que o defeito ocorre;
\u2022 Custo da correção do defeito;
\u2022 Custo da instalação;
\u2022 Conseqüência.
 
 1.9.1.3. Minimizar os impactos esperados
 Minimizar os impactos esperados envolve a combinação das seguintes estratégias:
 
\u2022 Eliminar o risco; (às vezes não é possível)
\u2022 Reduzir a probabilidade de o risco se tornar um problema; (Mitigar os riscos)
\u2022 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:
 
\u2022 Garantia da Qualidade \uf0e0 área de GQA
\u2022 Treinamento e educação \uf0e0 voltado para desenvolvimento, teste e usuários
\u2022 Metodologias e padrões \uf0e0 processos bem definidos, metodologias adequadas e padrões consistentes
\u2022 Desenho defensivo;
\u2022 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:
 
\u2022 Encontrar defeito;
\u2022 Relatar defeito;
\u2022 Reconhecer defeito;
 
 1.9.3.1. Encontrar defeito
Esta etapa utiliza de técnicas como:
 
\u2022 Técnicas estáticas \uf0e0 Revisões, walkthrough e inspeções
\u2022 Técnicas dinâmicas \uf0e0 realização de Testes
\u2022 Técnicas operacionais \uf0e0defeito 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:
 
\u2022 Resumo;
\u2022 Precisão;
\u2022 Neutralidade;
\u2022 Isolamento;
\u2022 Generalização;
\u2022 Reprodução;
\u2022 Impacto;
\u2022 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:
 
\u2022 Arbitragem pelo usuário;
\u2022 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:
 
\u2022 Priorizar a correção;
\u2022 Programar a correção;
\u2022 Corrigir o defeito;
\u2022 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:
 
\u2022 Crítico sério impacto no negócio\uf0e0 
\u2022 Grave \uf0e0 erro grave ou pára de funcionar
\u2022 Menor \uf0e0 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:
 
\u2022 Avaliação do processo que originou o defeito e a compreensão do que o causou;
\u2022 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:
 
\u2022 Pelo ponto de vista do produtor o defeito é causado por um desvio em relação às especificações;\uf0e0 
\u2022 Pela ótica do cliente defeito é qualquer coisa que cause insatisfação, constando ou não nos requisitos. É \uf0e0
chamada de visão \u201cajustada para uso\u201d.
 
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:
 
\u2022 Definição do defeito;
\u2022 Fase do ciclo de desenvolvimento ou atividade que o defeito ocorreu;
\u2022 Categoria do defeito. (ausente, impreciso, incompleto inconsistente)
Capítulo 11 - Estimativas
1. Análise de pontos de Teste \u2013 (APT)
Toda técnica de medição e estimativa