Processo de Teste 2

Processo de Teste 2

1. Como Projetar os Testes?

   • Especificação dos Requisitos
   • Intuição e Experiência
   • Código-Fonte.
   • Falhas.
   • Uso do Sistema.
   • Natureza da Aplicação.

2. Testes Scripted

   • Os testes são escritos em uma fase anterior à execução (design de testes).
   • Atividade geralmente realizada por arquitetos ou analistas de teste.
   • Os testes são conjuntos de passos predefinidos e com os resultados esperados.
   • Normalmente estão relacionados à confirmação dos requisitos do software.
   • São repetitivos.

3. Divisão das Tarefas

   • Projetista de Teste
     • Como Projetar os Testes?
       • Intuição e Experiência.
         • Teste Ad Hoc.
           • Realizado sem planejamento, são derivados do conhecimento e intuição com programas similares
           • Deficiências do Teste Ad hoc
             • • Pessoas possuem diferentes níveis de experiência e conhecimento.  • Dificuldade em repetir um suíte de testes.  • Dificuldade em planejar os testes.
         • Teste Exploratório.
           • "Testes exploratórios é o processo interativo de concorrentemente explorar o produto, projetar os testes e executar os testes"
           • Quando utilizar testes exploratórios?
             • • Quando existe pouca ou nenhuma especificação de requisitos.  • Quando você possui pouco ou nenhum conhecimento do domínio que será testado.  • Quando não há tempo para especificar scripts detalhados de teste e executá-los.  • Quando precisa sondar se existem áreas de fraqueza no sistema.

4. Processo de Testes Exploratórios

   • 1.Pesquisa e Planejamento
     • Gerente de testes/testador agrupa informações para definir o que será testado.
     • Abordagens para o Planejamento
       • Baseada nos Modelos
         • –Diagramas de Entidade-Relacionamento;  –Diagramas de Arquitetura;  –Modelos de Negócio;  –Casos de Uso.
       • Baseada nos Requisitos
         • –Funcionais;  –Não-funcionais;  –Cuidado com a duplicidade com os casos de teste scripted.
       • Baseado numa Avaliação Simples
         • – Navegar, passo a passo, pelas funcionalidades do software.  – Fazer entradas simples. – Observar os fluxos de controle, as telas e as mensagens.  – Excelente abordagem para aprender sobre o software.
   • 2.Design
     • Seleciona um escopo e decompõe em subescopos que devem ser testados entre 1 e 2 horas.
   • 3.Sessão
     • O objetivo principal é achar o maior número de Bugs válidos  – Conhecer o software.  – Avaliar a estabilidade.  – Depurar uma falha encontrada.
     • 3.1Avaliação ( Debrief
       • • Conversa rápida entre o testador e o gerente sobre a sessão e os resultados encontrados.  • Utilizado para verificar se o que estava dentro dos planos foi realmente testado.  • Planejar novas sessões.  • Gerar novas ideias para criação de novos charters e sessões.
   • Bug Tracking
     • • Verificar se o bug já foi relatado na ferramenta.  • Após a abertura do bug , o testador deve fazer o acompanhamento até que o mesmo chegue em um estado final.  • Se possível, validar se o bug foi realmente corrigido.

Imágenes y archivos del mapa