Your SlideShare is downloading. ×

Qualidade

881

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
881
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×