Qualidade

1.060 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.060
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Qualidade

  1. 1. Garantia de Qualidade(QualityAssurance)<br />
  2. 2. O que é Qualidade?<br />“Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos” <br />NBR ISO 9000:2005<br />
  3. 3. Software QualityAssurance (SQA)<br />Software QualityAssurance(SQA) compõe o conjunto de “atividades sistemáticas fornecendo evidências para o uso pretendido para o produto total de software". (LEWIS, 2004, p. 18)<br />Esse tipo de ação é orientada a prevenção.<br />
  4. 4. Porquê prevenção?<br />Defeito encontrado nos requisitos:<br />Se uma falha nos requisitos do sofware é encontrada e corrigida, sua correção é relativamente simples: atualizar a especificação de requisitos.<br />
  5. 5. Porquê prevenção?<br />Se o mesmo erro é encontrado fase de implantação, as correções tardias envolvem:<br />Report de erros pelo cliente;<br />Avaliação do erro pela equipe de desenvolvimento;<br />Correção do erro<br />Re-envio do pacote de desenvolvimento ao cliente;<br />Nova validação pelo cliente; <br />E correções em ciclos se mais erros relacionados forem encontrados.<br />
  6. 6. Software QualityAssurance (SQA)<br />Envolve todo o processo de desenvolvimento de software<br />Realizando as devidas monitorações e melhorias de processos pertinentes<br />Assegurando que os padrões, procedimentos acordados estejam sendo seguidos <br />Garantindo que problemas sejam encontrados e ações corretivas sejam tomadas. <br />Teste de software é umas das atividades de QualityAssurance (Garantia de Qualidade).<br />
  7. 7. Testes de Software<br />Ajudam a medir a qualidade do software baseando-se nos defeitos(bugs) encontrados.<br />Reduzem o nível de risco* de um sistema como um todo<br />*Risco: um fator que pode resultar em futuras consequências negativas; usualmente expressado como impacto e probabilidade de ocorrer.<br />Contribuem para o cumprimento de itens contratuais ou requisitos legais acordados com o cliente<br />Como? <br />Encontrando e corrigindo defeitos ANTES do sistema ser implantado em ambiente operacional.<br />
  8. 8. Processo de Testes<br />*satifaz requisitos para entrega?<br />
  9. 9. Planejamento e Controle<br />Nesta etapa é especificada qual estratégia de testes será adotada:<br />Identificar objetivos do teste<br />Definir quais atividades e teste serão realizadas<br />Definir quais técnicas serão aplicadas<br />Determinar qual o critério de saída: quando as atividades de teste devem ser encerradas?<br />
  10. 10. Análise e Design<br />Testes são projetados utilizando-se as técnicas selecionadas.<br />Revisar os documentos e artefatos recebidos<br />Levantar dados para teste<br />Projetar test-cases, definir checklists e/ou qualquer outro artefato* <br />*Com a finalidade de descobrir e eliminar problemas antes da etapa de desenvolvimento do software<br />
  11. 11. Execução<br />Execução dos testes de acordo com a seqüência planejada<br />Comparação de resultados planejados (ou especificados) com resultados esperados<br />Report de incidentes <br />Bugs e/ou falhas encontradas<br />Gerar logs de saída da execução dos testes<br /><ul><li>Repetição de testes para checagem da correção</li></li></ul><li>Avaliação de Critério de Saída<br />A execução dos testes é dada por completo quando os objetivos do teste é atingido<br />Avaliar se mais testes são necessários<br />Realizar tarefas de fechamento:<br />Checar se todos os incidentes foram encerrados<br />Checar que as atividades planejadas foram entregues<br />Analisar Lições Aprendidas para releases e projetos futuros e para a melhoria do processo.<br />
  12. 12. Os 7 Princípios-chave <br />Os testes mostram a presença de defeitos, não sua ausência<br />Testes exaustivos são impossíveis<br />Teste o mais cedo quanto possível<br />Defect Clustering<br />The pesticide paradox<br />Test is Context Dependent<br />Absence of Errors Fallacy<br />
  13. 13. 1. Os testes mostram a presença de defeitos, não sua ausência<br />Nós testamos para encontrar falhas/defeitos<br />Quando encontramos defeitos hoje, a probabilidades de encontrarmos defeitos futuros não descobertos no sistema diminui<br />A probabilidade de existência de mais erros em uma seção de um programa é proporcional ao número de erros já encontrados naquele programa<br />Um bom teste tem uma alta probabilidade de detectar erros ainda não descobertos<br />
  14. 14. 2. Testes exaustivos não são possível<br />É absolutamente inviável testar tudo*<br />*Ou testar todas as combinações de entrada e saída, incluindo as pré-condições<br />Isto exigiram um número astronômico de test cases, ou simulações<br />Geralmente os testes são priorizados de acordo com uma abordagem baseada em riscos ou prioridades<br />
  15. 15. 3. Os testes devem começar tão cedo quanto possível<br />As atividades de teste devem ser iniciadas quanto mais cedo possível no ciclo de desenvolvimento<br />As atividades devem ser focadas em objetivos definidos dentro de uma estratégia de testes<br />
  16. 16. 4. Defeitos tendem a se agrupar<br />Os defeitos não são distribuídos uniformemente no sistema, geralmente se encontram agrupados<br />Em outras palavras, a maioria dos defeitos encontrados durante os testes são geralmente confinados a uma pequena parte do sistema<br />Estes dados servem de base para a priorização dos testes: Por Criticidade<br />
  17. 17. 5. O paradoxo do pesticida<br />Se os mesmos testes são repetidos continuamente, eles tendem a perder sua eficácia<br />Para evitar, novos Test Cases devem ser desenvolvidos usando novas combinações de dados e novas técnicas que capturem outros defeitos<br />
  18. 18. 6. Testes são dependentes de contexto<br />Testes são feitos de forma diferente em diferentes contextos<br />Os testes devem ser aplicados baseando-se nos riscos inerentes ao uso e no ambiente da aplicação<br />Todo software deve ter critérios de saída que devem ser decididos individualmente<br />Exemplo:<br />Sistemas de segurança requerem testes diferentes de sistemas de e-commerce<br />
  19. 19. 7. O fato de falhas não existirem, não significa um sistema utilizável (usefull)<br />Encontrar falhas e reparar não garante que os sistema como um todo garanta as expectativas do usuário e suas necessidades<br />O envolvimento mais cedo do usuário no processo de desenvolvimento e o uso de protótipos são métodos preventivos<br />
  20. 20. ISTQB – International Standards TestingQualityBoard<br />www.testexpert.com.br<br />QAI – QualityAssurance Global Institute<br />Livro: Software Testing Foundations: A Study Guide for the Certified Tester Exam, 2nd Edition<br />Andreas Spillner; Tilo Linz; Hans Schaefer<br />Fonte:<br />

×