Qualidade de SW

Qualidade de SW

1. Conceitos

   • Grandes atividades principais
     • Garantia da qualidade
       • Estabelecimento de um framework com PROCEDIMENTOS e PADRÕES que conduzem a um software de qualidade
       • É orientada a PROCESSO
     • Planejamento da qualidade
       • Seleção de PROCEDIMENTOS e PADRÕES para aplicação em um projeto de software específico
     • Controle da qualidade
       • Definição e aprovação de processos que assegurem que a equipe de desenvolvimento siga os PROCEDIMENTOS e os PADRÕES
       • É orientado ao PRODUTO
   • Tipos de inconformidades
     • Defeito/Falta
       • Ato inconsistente cometido por um indivíduo ao tentar entender uma informação, resolver um problema ou utilizar um método ou uma ferramenta
       • PODE ocasionar a manifestação de erros no produto
     • Erro
       • Manifestação concreta de um defeito
       • Discrepância entre resultado ESPERADO e resultado OBTIDO
     • Falha
       • Comportamento operacional do software diferente do esperado pelo usuário
       • PODE ser causado por um ou mais erros
   • Verificação x Validação
     • Verificação
       • Pergunta: "Estamos construindo o produto corretamente?"
       • Depende da ESPECIFICAÇÃO
       • Ocorre em ambiente de DESENVOLVIMENTO
       • Tipos
         • Estática
           • Também chamada de INSPEÇÃO, ocorre sem a necessidade de EXECUTAR o software
         • Dinâmica
           • Também chamada de TESTE, envolve EXECUTAR o software
     • Validação
       • Pergunta: "Estamos produzindo o produto correto?"
       • Depende dos USUÁRIOS
       • Ocorre em ambiente de PRODUÇÃO
   • Artefatos
     • Plano de testes
       • Inclui ABRANGÊNCIA, ABORDAGEM, RECURSOS e CRONOGRAMA das atividades de teste
       • Identifica os itens e as funcionalidades a serem testados, as tarefas realizadas e os riscos associados com a atividade de teste
       • É de responsabilidade do GERENTE DE TESTES
     • Casos se teste
       • Possui um conjunto de condições/entradas usadas para testar um software
       • Descreve o passo-a-passo da execução do teste
       • É de responsabilidade do ANALISTA DE TESTES

2. Características da qualidade

   • Interoperabilidade
     • Capacidade do software de interagir com um ou mais sistemas especificados
   • Conformidade
     • Capacidade do software estar de acordo com:
       • Normas
       • Convenções ou regulamentações previstas em lei
       • Prescrições relacionadas à funcionalidade
     • Pode ser compreendida como o "atendimento às especificações do produto ou processo"
   • Tolerância à falhas
     • Manutenção do nível de desempenho especificado no caso de defeito no produto ou na violação de sua interface
     • Pode ser compreendida como "capacidade do produto de satisfazer seus requisitos apesar de suas falhas"
   • Usabilidade
     • Capacidade do produto de ser COMPREENDIDO, APRENDIDO, OPERADO e ATRAENTE ao usuário

3. Teste de SW

   • Objetivos
     • Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos especificados
     • Descobrir falhas ou defeitos no software
   • Classificações de teste
     • Teste de validação
       • Atesta o correto funcionamento do sistema
       • É bem-sucedido quando o sistema funciona conforme o esperado
     • Teste de defeitos
       • Busca expor defeitos do sistema
       • É bem-sucedido quando expõe um comportamento incorreto do sistema
   • Princípios
     • Um teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. Ele reduz a probabilidade de que os defeitos permaneçam, mas mesmo se nenhum defeito for encontrado não quer dizer que ele não os tenha
     • Testar todas as condições de entradas e pré-condições é inviável, exceto para casos triviais. Em vez de realizar testes exaustivos, os riscos e prioridades são levados em consideração para dar foco aos esforços de teste
     • Os defeitos encontrados nas fases iniciais do processo de desenvolvimento de software são mais baratos de serem corrigidos do que aquele encontrados já na fase de produção. Há, inclusive, técnicas de teste antes mesmo da implementação
     • Seguindo o princípio de Pareto, 80% dos defeitos são causados por 20% do código. Ao identificar essas áreas sensíveis, os testes podem priorizá-las, de forma a ter alta probabilidade de encontrar defeitos
     • Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis, ou seja, não conseguem encontrar um novo defeito. Por isso, os testes precisam ser revistos com frequência
     • Os testes devem ser elaborados de acordo com o contexto de utilização do software. Um sistema bancário deve ser testado de maneira diferente de uma rede social, assim como testes de aplicação Web tem foco diferente de uma aplicação desktop
   • Características que levam a um software testável (segundo Pressman)
     • Operabilidade
       • Quanto melhor o software funciona, mais eficientemente pode ser testado
     • Observabilidade
       • O que você vê é o que você testa
     • Controlabilidade
       • Quanto mais você pode controlar o software, mais o teste pode ser automatizado e otimizado
     • Decomponibilidade
       • Controlando o escopo, podemos isolar problemas mais rapidamente e realizar testes mais inteligentes
     • Simplicidade
       • Quanto menos houver o que testar, mais rapidamente poderemos testá-lo
     • Estabilidade
       • Quanto menos modificações, menos interrupções no teste
     • Compreensibilidade
       • Quanto mais informações temos, mais inteligentemente iremos testar
   • Formas de teste
     • Teste de unidade
       • Foca a menor unidade de projeto de software (componente ou módulo)
       • A interface do módulo é testada para assegurar que as informações fluam corretamente para dentro e para fora do componente
       • Pode ser realizado ANTES que o componente seja implementado
       • Geralmente é realizado pelos próprios desenvolvedores
     • Teste de integração
       • Foca na INTEGRAÇÃO entre os componentes do software
       • Objetiva identificar erros na comunicação entre os componentes
     • Teste de aceitação
       • Também conhecido como teste de VALIDAÇÃO
       • Foca nas AÇÕES E SAÍDAS VISÍVEIS ao usuário
       • O teste é bem-sucedido quando o software se comporta da maneira esperada pelo usuário
       • Estratégias
         • Teste de aceitação formal
           • Geralmente é uma extensão do Teste do Sistema, sendo planejado e projetado com o mesmo nível de detalhe
           • Geralmente é IMPRATICÁVEL se o software possui muitos usuários diferentes
         • Teste de aceitação informal (testes alfa)
           • São identificadas e documentadas funções de negócio, mas não são exigidos casos de teste
           • O testador determina como se dará o teste
           • Ocorrem em AMBIENTE CONTROLADO
         • Testes beta
           • São os menos controlados das 3 estratégias
           • A quantidade de detalhes, os dados e a abordagem são inteiramente de responsabilidade do testador
           • Ocorrem em AMBIENTE NÃO-CONTROLADO
     • Teste de sistema
       • Abarcam não só o software em sim, mas também o ambiente no qual ele está inserido
       • É realizado por ENGENHEIROS DE SOFTWARE
       • Busca exercitar totalmente o sistema

4. Ciclo de vida de testes

   • Planejamento
     • Elabora-se o PLANO DE TESTES
     • Realiza-se a ANÁLISE DE RISCOS dos projetos de teste
   • Preparação
     • Organiza-se o AMBIENTE DE TESTES
   • Especificação
     • Elabora-se e revisa-se os CASOS DE TESTE e os ROTEIROS DE TESTE
   • Execução
     • Prepara-se os dados de teste
     • Executa-se os casos de teste
     • Elabora-se o relatório final
   • Entrega
     • Avalia-se e arquiva-se a documentação
     • Gera-se um relatório de conformidades e não-conformidades

5. Técnicas de teste

   • Caixa-preta
     • Foca nas entradas e saídas especificadas nos requisitos funcionais
     • Deriva casos de teste a partir dos REQUISITOS, ignorando detalhes de implementação
     • Principais técnicas
       • Baseado em grafos
         • Permite identificar os objetos e gera grafos para representá-los, testando-os e seus relacionamentos com o intuito de descobrir erros
       • Partição de equivalência
         • Permite agrupar os valores de entrada em categorias de dados para evitar redundância e aumentar a cobertura de testes do sistema
       • Análise de valor limite
         • Permite exercitar os limites do domínio de entrada,a tendo em vista que a maioria dos erros se encontram nas extremidades da entrada
   • Caixa-Branca
     • Foca nas estruturas internas dos procedimentos do sistema
     • Principais técnicas
       • Caminho básico
         • Permite derivar uma medida de complexidade lógica de um procedimento e a utiliza para definir um conjunto de caminhos de execução
       • Estruturas de controle
         • Permite validar estruturas de controle como estruturas de condição, estruturas de fluxo de dados ou estruturas de laço
       • Complexidade ciclomática
         • Permite medir quantitativamente a complexidade lógica de um código por meio do número de caminhos independentes
   • Caixa-cinza
     • Fica tanto em estruturas internas quanto nas entradas e saídas

6. Tipos de teste

   • Teste de carga/estresse/volume
     • Busca demonstrar o funcionamento do software em situações ANORMAIS, com grandes demandas de recursos
     • Geralmente são feitos durante os TESTES DE SISTEMA
   • Teste de desempenho/performance
     • Busca demonstrar que o software atende aos níveis de desempenho e tempo de resposta exigidos nos requisitos
     • É realizado com base numa carga que reflita a CONDIÇÃO NORMAL de operação do software
   • Teste de usabilidade
     • Busca demonstrar falhas na facilidade de uso do software pelos usuários
     • Inclui documentação de usuário e treinamento
   • Tese de cenários
     • Utilizam cenários (estórias hipotéticas) para testar o sistema
     • As estórias abrangem vários casos de teste
   • Teste de regressão
     • Consiste na aplicação de testes de versões anteriores visando garantir que novos defeitos não surjam
   • Teste back-to-back ou comparação
     • Testa-se diferentes versões do sistema e compara-se os resultados
     • Geralmente são realizados em sistemas críticos
   • Testes de recuperação
     • Valida a capacidade e qualidade da recuperação do software após crashes, falhas de hardware ou outros eventos catastróficos
   • Testes de compatibilidade
     • Validam a capacidade do software ser executado em um ambiente particular (software, hardware, SO, rede, etc)
   • Testes estáticos e dinâmicos
     • Testes estáticos: O código é examinado à procura de defeitos
     • Testes dinâmicos: O código é executado à procura de defeitos
   • Teste de vulnerabilidade
     • Busca encontrar vulnerabilidades no sistema através de tentativas de penetração na arquitetura do software ou do ambiente
   • Teste de segurança
     • Verifica se os mecanismos de proteção do sistema são capazes de protegê-lo no caso de invasão indevida

Bilder und Dateien der Mindmap