• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Qualidade
 

Qualidade

on

  • 1,154 views

 

Statistics

Views

Total Views
1,154
Views on SlideShare
1,154
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Qualidade Qualidade Presentation Transcript

    • Garantia de Qualidade(QualityAssurance)
    • O que é Qualidade?
      “Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos”
      NBR ISO 9000:2005
    • 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.
    • 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.
    • 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.
    • 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).
    • 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.
    • Processo de Testes
      *satifaz requisitos para entrega?
    • 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?
    • 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
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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: