Você está na página 1de 55

Fundamentos em Teste de Software

Módulo 2 Planejando os Testes

Érika Hmeljevski 2010

Fundamentos em Teste de Software Módulo 2 – Planejando os Testes Érika Hmeljevski – 2010

Onde estamos?

Onde estamos?
Onde estamos?

Planejamento de testes

Atividades:

  • Analisar os riscos do Projeto

  • Definir a Estratégia de Teste

  • Adaptar processo de teste para o Projeto

  • Escrever o Plano de Teste

  • Detalhar planejamento das atividades de Teste

  • Definir necessidades de comunicação do projeto

  • Definir citérios de aceitação

  • Definir cronograma; etc.

Planejamento de testes Atividades:  Analisar os riscos do Projeto  Definir a Estratégia de Teste

Vale a pena investir em Planejamento?

  • Ajuda a garantir que o produto final irá atender aos usuários

  • Ajuda a evitar problemas e a minimizar o re-trabalho

  • Garante que você está na direção certa antes de iniciar os trabalhos

  • Garante que você vai conseguir o comprometimento das gerências envolvidas para o seu plano

  • Diminui o tempo total do projeto

  • Considerações:

    • Nunca comece um projeto sem um documento de compromisso (project charter)

    • Identifique claramente as necessidades do usuário

    • Crie o plano de projeto junto com a sua equipe.

Livro: Getting Started in Project Management Paula Martin e Karem Tate.

Vale a pena investir em Planejamento?  Ajuda a garantir que o produto final irá atender

Estratégias de Teste

Estratégias de Teste

Estratégia de Testes

Atividades:

  • Avaliar requisitos do sistema;

  • Identificar e Analisar riscos para o negócio;

  • Analisar as possibilidades de testes para minimizar os riscos;

  • Estabelecer os tipos e técnicas de teste a serem realizados;

  • Definir prioridades para os testes;

  • Estabelecer que produtos serão inspecionados.

Estratégia de Testes Atividades:  Avaliar requisitos do sistema;  Identificar e Analisar riscos para o

Definindo a estratégia de testes baseando-se nas dimensões dos testes

Definindo a estratégia de testes baseando-se nas dimensões dos testes
Definindo a estratégia de testes baseando-se nas dimensões dos testes

Estágios ou Níveis de Teste

  • Testes Unitários

  • Testes de Iteração ou Integração

  • Teste de Sistema

  • Teste de Aceitação

Estágios ou Níveis de Teste  Testes Unitários  Testes de Iteração ou Integração  Teste

Testes Unitários

  • Testes realizados a nível de uma unidade

independente do produto;

  • Estágio mais baixo da escala de teste;

  • Aplicado nos menores componentes de código criados, visando garantir que estes atendem às especificações funcionais e de arquitetura;

  • Geralmente realizado pelo desenvolvedor que construiu a unidade.

Testes Unitários  Testes realizados a nível de uma unidade independente do produto;  Estágio mais

Testes de Iteração ou Integração

  • Quando? Teste do sistema ao término de cada iteração

  • Onde? Dentro de um ambiente operacional controlado

  • Finalidade ? Para validar a exatidão e perfeição na execução de suas funções, referentes aos casos de uso da iteração.

  • Responsável ? Normalmente feito pelo analista de sistemas para um módulo ou conjunto de programas.

Normalmente os seguintes métodos de integração são seguidos:

  • Abordagem de integração Top-down

  • Abordagem de integração Bottom-up

Testes de Iteração ou Integração  Quando? Teste do sistema ao término de cada iteração 

Testes de Sistema

Série de diferentes testes cujo principal objetivo é exercitar a

operação do sistema de forma completa.

  • Como? Execução do sistema como um todo

  • Onde? Dentro de um ambiente operacional controlado

  • Finalidade? Para validar a exatidão e perfeição na execução de suas funções, acompanhando cenários sistêmicos elaborados pelo profissional de requisitos do projeto

  • Responsável? Normalmente feito pelo analista de testes (casos de testes) em Ambiente de testes

Testes de Sistema Série de diferentes testes cujo principal objetivo é exercitar a operação do sistema

Testes de Sistema

Os seguintes testes podem ser categorizados

como Testes de Sistema:

  • Testes de Recuperação

  • Testes Funcionais

  • Testes de Segurança

  • Testes de Estresse

  • Testes de Desempenho (Performance)

Testes de Sistema Os seguintes testes podem ser categorizados como Testes de Sistema:  Testes de

Testes de Aceitação

Realizados pelos usuários ou por pessoas por eles delegadas visando verificar se o sistema tem condições de ser colocado em produção, com base nos seus critérios de aceitação.

  • É a última ação de teste antes da implantação do software, sendo de responsabilidade do cliente.

  • O objetivo deste teste é verificar se o software está pronto e pode ser usado por usuários finais para executar as funções e tarefas para as quais foi construído.

  • Normalmente feito pelo usuário em ambiente de homologação.

Testes de Aceitação Realizados pelos usuários ou por pessoas por eles delegadas visando verificar se o

Dimensões de Teste

Dimensões de Teste
Dimensões de Teste

Tipos de Teste

Tipos de Teste
Tipos de Teste

Tipos de Teste

Teste Funcional: Teste que foca a validação das funções do elemento a ser testado.

Teste de Regressão: Teste no qual se verifica se as partes do software não afetadas por uma alteração continuam funcionando normalmente.

Teste de Segurança: Teste para garantir que os dados (ou sistemas) possam ser acessados apenas por autorizados.

Teste de Interface : Teste que verifica a utilização dos padrões de interface da organização, textos, apresentação dos itens da interface como um todo.

Teste de usabilidade: Teste que verifica a navegação do sistema, avaliando fatores como facilidade do uso, estática, ajuda, consistência na interface do usuário, etc.

Teste de integridade (robustez): Teste que verifica a resistência a falhas e a compatibilidade técnica em relação a linguagem, sintaxe e utilização de recursos.

Teste de estrutura: Em geral, é realizado em aplicativos Web, garantindo que todos os links estejam conectados, que o conteúdo apropriado

seja exibido e que não haja conteúdo órfão.

Tipos de Teste Teste Funcional: Teste que foca a validação das funções do elemento a ser

Tipos de Teste

Teste de estresse: Teste para avaliar como o sistema responde em condições anormais. Podem ser cargas de trabalho extremas, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados.

Smoke Test: Exercita o sistema em uma única passagem, normalmente utilizando script de execução automática.

Teste de performance: Teste em que o perfil de andamento do item de teste é monitorado (fluxo de execução, acesso a dados e chamadas de função, a fim de identificar e lidar com gargalos de desempenho e processos ineficientes).

Teste de configuração: Teste para garantir que o item de teste funcione conforme o esperado em diferentes configurações de hardware e/ou software.

Teste de instalação: Teste destinado a garantir que o item de teste seja instalado conforme o esperado em diferentes configurações de hardware e/ou software e sob diferentes condições.

Testes Alfa: Testes conduzidos no sistema de desenvolvimento e pelos usuários com ambiente controlado.

Testes Beta :Testes conduzidos em um ou mais sistemas de clientes, e realizados por usuários finais do sistema.

Tipos de Teste Teste de estresse: Teste para avaliar como o sistema responde em condições anormais.

Dimensões de Testes

Dimensões de Testes
Dimensões de Testes

Técnica de Teste Estrutural

O Objetivo é garantir que o produto desenvolvido está estruturado e se funciona corretamente.

Pretende determinar se a tecnologia utilizada foi apropriada e se os componentes montados funcionam como uma unidade coesa.

Técnica de Teste Estrutural  O Objetivo é garantir que o produto desenvolvido está estruturado e

Técnica de Testes Funcional

O Objetivo é verificar se os requisitos do sistema e as especificações foram atendidos.

Funcionalidades são as tarefas que o sistema é desenvolvido para atender.

Envolve a criação de cenários de testes para uso na avaliação das funcionalidades da aplicação, validando se o que foi especificado foi implementado corretamente.

O Teste Funcional não está preocupado como o processo ocorre e sim com os resultados do processo.

Técnica de Testes Funcional O Objetivo é verificar se os requisitos do sistema e as especificações

Riscos

Riscos

Entendendo melhor o conceito de

O que é risco?

risco

  • Se alguma coisa com certeza vai acontecer, então isso deixa de ser um risco e passa a ser um problema

  • Risco é algum evento no futuro cuja ocorrência poderá causar algum tipo de problema, no caso, ao projeto de teste de software.

Um risco pode ser dividido da seguinte forma:

  • Fonte (indício)

  • Sintoma

  • Conseqüência

Entendendo melhor o conceito de O que é risco ? risco  Se alguma coisa com

Exemplo

Suponhamos que tempo de resposta é um requisito do negócio, para validarmos este requisito vamos necessitar de uma ferramenta, suponhamos ainda que a instituição não possui ferramenta e terá

que adquirir uma, a partir de agora a aquisição da ferramenta torna

se um risco para o negócio, pois sem esta os testes de performance podem não ser executados.

Exemplo Suponhamos que tempo de resposta é um requisito do negócio, para validarmos este requisito vamos

Resumo

Devido a uma <fonte>, o <sintoma> está ocorrendo, podendo causar <conseqüências>

No nosso exemplo podemos afirmar:

Devido a um <atraso no processo de aquisição do software de teste de carga>, a <execução inadequada dos testes de carga> está ocorrendo, podendo causar <a liberação do software sem a adequada performance exigida nos seus requisitos>.

Resumo Devido a uma <fonte>, o <sintoma> está ocorrendo, podendo causar <conseqüências> No nosso exemplo podemos

Alguns Riscos do Projeto de Teste

  • Ausência de um cronograma detalhado

  • Prazo final de entrega dependente dos testes

  • Dados de teste não estão disponíveis na data programada

  • Dados de testes ruins

  • Falta de uma métrica para medição do sistema em PF (e dos testes em PT)

  • Disponibilidade da equipe de testes

  • Disponibilidade do ambiente de testes

  • Falta de uma gerência de configuração (teste e desenvolvimento)

  • Abordagens de desenvolvimento ou teste não usuais pela organização (ex. RUP)

Alguns Riscos do Projeto de Teste  Ausência de um cronograma detalhado  Prazo final de

Riscos devido ao processo de Teste

1

- Existe uma gerência de teste na organização?

  • - O gerente de teste tem experiência neste tipo de atividade?

2

  • - Existe um processo de teste perfeitamente definido?

  • - Este processo de teste é seguido por todos os profissionais de teste?

3

  • - Existe apoio da gerencia para a atividade de teste?

  • - É comum a execução de inspeções nos produtos de teste ou isso só ocorre nos produtos de desenvolvimento?

4

- São usadas ferramentas de automação de teste para gestão e/ou execução dos

testes?

  • - As ferramentas são integradas entre si?

  • - A equipe está familiarizada com essas ferramentas?

5

- São usados documentos padronizados?

6

  • - Existe uma regra de priorização da correção dos defeitos ou um grupo que defina essas prioridades?

7

  • - Existe algum tipo de problema envolvendo o ambiente de teste?

8

- O ambiente de teste é equivalente ao ambiente de produção?

9

  • - Existe uma metodologia de teste associada ao ciclo de vida do processo de teste?

10 -Existe uma métrica para medir os testes?

Riscos devido ao processo de Teste 1 - Existe uma gerência de teste na organização? -

Onde estão os maiores riscos de

  • Funções muito complexas;

defeitos?

  • Funções completamente novas;

  • Funções freqüentemente alteradas;

  • Funções onde uma determinada ferramenta foi usada pela primeira vez no seu desenvolvimento;

  • Funções que foram transferidas de um desenvolvedor para outro durante o desenvolvimento do software;

  • Funções que foram construídas sob pressão;

  • Funções que sofreram muita otimização - mais do que a média;

  • Funções onde muitos defeitos já foram encontrados em revisões ou versões anteriores;

  • Funções com muitas interfaces.

Martim Pol, Software Testing.

Onde estão os maiores riscos de  Funções muito complexas; defeitos?  Funções completamente novas; 

Gerenciando os riscos dos projetos PMI

Project Management Institute

Segundo o PMBok, um risco é "um evento ou condição incerta que, se ocorrer, provocará um efeito positivo ou negativo nos objetivos do projeto

(glossário, pg.376).

Gerenciando os riscos dos projetos PMI Project Management Institute Segundo o PMBok, um risco é "

Planos de Projeto - PMI

  • Plano Global do Projeto

  • Plano de Gerenciamento de Escopo

  • Plano de Gerenciamento de Tempo

  • Plano de Gerenciamento de Custos

  • Plano de Gerenciamento de Qualidade

  • Plano de Gerenciamento de RH

  • Plano de Gerenciamento de Comunicações

  • Plano de Gerenciamento de Riscos

  • Plano de Gerenciamento de Contratos

Planos de Projeto - PMI  Plano Global do Projeto  Plano de Gerenciamento de Escopo

Plano de Gerenciamento de Riscos

  • Título do projeto

  • Descrição do projeto

  • Responsável pelo projeto

  • Responsável pelo plano de riscos

  • Riscos identificados

  • Qualificação dos riscos

  • Quantificação dos riscos

  • Resposta planejada aos riscos

  • Planos de mitigação

  • Planos de contingência

  • Responsáveis pelos riscos e pelos planos de mitigação e de contingência

  • Forma de avaliação do plano de riscos

  • Outras informações

Plano de Gerenciamento de Riscos  Título do projeto  Descrição do projeto  Responsável pelo

Gerenciando os riscos dos Projetos CMMI/SW

Níveis de Maturidade Áreas de Processo 2- Gerenciado Gerência de Requisitos Planejamento de Projeto Controle e
Níveis de Maturidade
Áreas de Processo
2- Gerenciado
Gerência de Requisitos
Planejamento de Projeto
Controle e Monitoração de projeto
Medições e Análise
Garantia de Qualidade de Produto e Processo
Gerência de Configuração
3 - Definido
Desenvolvimento de Requisitos
Solução Técnica
Integração de Produto
Verificação
Validação
Foco no Processo Organizacional
Definição do Processo Organizacional
Treinamento Organizacional
Gerência Integrada de Projeto
Gerência de Risco
Integração de Equipe
Gerencia Integrada de Fornecedores
Resolução e Análise de Decisão
Ambiente Organizacional para Integração
4- Quantitativamente Gerenciado
Desempenho do Processo Organizacional
Gerência Quantitativa de Projeto
5- Otimizado
Inovação e Implantação na Organização
Análise e Resolução de Causa

Exemplo Análise de Riscos Qualitativa

Exemplo Análise de Riscos Qualitativa Análise de riscos pode ser um exercício de intuição Considerando-se que

Análise de riscos pode ser um exercício de intuição

Considerando-se que um palestrante

tivesse que realizar o trajeto ao lado

para chegar ao local de sua palestra que deve ter início as 9 h.

Identifique alguns riscos para que esta palestra não ocorresse.

Exemplo Análise de Riscos Qualitativa Análise de riscos pode ser um exercício de intuição Considerando-se que

Identificando os Riscos

O despertador não tocar no horário desejado

Sujar a roupa ao tomar café

O ônibus atrasar

Haver engarrafamento entre a casa do palestrante e a estação do Catamarã

O catamarã atrasar

O catamarã pifar no meio da baía

O elevador do edifício onde será a palestra escangalhar

O arquivo power point não funcionar (corrompido,etc.)

Haver divergências entre as versões do arquivo criado e o software usado no local da palestra,etc ..

Identificando os Riscos O despertador não tocar no horário desejado Sujar a roupa ao tomar café

Classificando os riscos

Por probabilidade de ocorrência: entre 0,1 e 0,9 Por gravidade ou criticidade (dano ao negócio): entre 1 e 5

Riscos Cr Pr O despertador não tocar no horário desejado 4 0,3 Sujar a roupa ao
Riscos
Cr
Pr
O despertador não tocar no horário desejado
4
0,3
Sujar a roupa ao tomar café
2
0,1
O ônibus atrasar
5
0,7
Haver engarrafamento entre a casa do palestrante e a estação do catamarã
5
0,4
O catamarã atrasar
5
0,5
O catamarã pifar no meio da baía
5
0,1
O elevador do edifício onde será a palestra escangalhar
2
0,1
O arquivo power point não funcionar (corrompido,etc.)
5
0,5
Haver divergências entre as versões do arquivo criado e o software usado
no local da palestra,etc ..
5
0,3

Riscos desta palestra não ser realizada

Risco = Chance de falhar x Prejuízo causado pela falha Riscos Cr Pr Total O despertador
Risco = Chance de falhar x Prejuízo causado pela falha
Riscos
Cr
Pr
Total
O despertador não tocar no horário desejado
4
0,3
0,12
Sujar a roupa ao tomar café
2
0,1
0,02
O ônibus atrasar
5
0,7
0,35
Haver engarrafamento entre a casa do palestrante e a estação do
5
0,4
0,20
catamarã
O catamarã atrasar
5
0,5
0,25
O catamarã pifar no meio da baía
5
0,1
0,05
O elevador do edifício onde será a palestra escangalhar
2
0,1
0,02
O arquivo power point não funcionar (corrompido,etc.)
5
0,5
0,25
Haver divergências entre as versões do arquivo criado e o software usado
no local da palestra,etc ..
5
0,3
0,15

Estimativas

Estimativas

Estimativa do projeto de Testes

Estimativa de testes é difícil pois:

  • Existem poucos dados históricos

  • Os requisitos estão incompletos , ambíguos, etc.

  • A qualidade dos dados para testes é desconhecido

  • Um grande número de fatores influenciam nos testes

  • Incerteza e falta de informação

  • As pessoas são otimistas

Estimativa do projeto de Testes Estimativa de testes é difícil pois:  Existem poucos dados históricos

Regras para o Processo de Estimativas de Testes

Deve ser sempre baseado nos requisitos

Deve ser baseado no julgamento de pessoas experientes

Deve ser baseado em projetos anteriores

Deve ser baseado em métricas

Deve ser registrado

Deve ser apoiado por ferramentas

Deve ser sempre validado

Regras para o Processo de Estimativas de Testes  Deve ser sempre baseado nos requisitos 

Métodos de Estimativa

Intuição ( ou chute )

Deixa rolar erros de até 100% das estimativas

Experiência prévia

Baseados em fórmulas (+ “Top-Down”)

Pontos de Testes “Thumb Rules”

Detalhamento das atividades de testes

“Brain-Storm”

“Bottom-up”

Métodos de Estimativa  Intuição ( ou chute )  Deixa rolar – erros de até

Análise de Pontos de Teste

Usando a Análise de Pontos de Função (APF ou PF) como base, Martin Pol, Ruud Tennissen e Erik van Veenendaal desenvolveram uma unidade de mensuração da atividade de teste chamada

Análise de Pontos de Teste (APT)

(livro “Software Testing, A Guide to Tmap Approach”)

APF => APT

Análise de Pontos de Teste Usando a Análise de Pontos de Função (APF ou PF) como

Análise de Pontos de Teste

Introdução:

  • A análise de ponto de teste (APT) é hoje uma das métricas de teste mais utilizadas no mercado mundial.

  • Ela utiliza como base o tamanho da funcionalidade do software já medida em pontos de função.

  • Embora a medição do sistema em pontos de função inclua os testes unitários e de integração, ela não cobre os testes de alto nível.

Ao fazermos estimativas usando Pontos de Teste devemos considerar

principalmente três elementos importantes:

  • O tamanho do sistema a ser testado

  • A estratégia de testes a ser usada (componentes, características de qualidade e cobertura do teste conforme acordado com o usuário)

  • O nível de produtividade da equipe

Análise de Pontos de Teste Introdução:  A análise de ponto de teste (APT) é hoje

Gráfico geral do processo de medição:

Gráfico geral do processo de medição:
Gráfico geral do processo de medição:

Análise de Pontos de Teste

Para aqueles que querem um número mágico para estimativas rápidas sugerimos um valor entre 1 e 2 horas de teste por

ponto de função.

No entanto cabe lembrar que são valores médios de mercado e nem sempre correspondem a um projeto de teste específico.

Análise de Pontos de Teste Para aqueles que querem um número mágico para estimativas rápidas sugerimos

Estimativas baseada em UC

O esforço de teste é medido combinando-se a complexidade e o tamanho do caso de uso

Esse valor em horas (complexidade/tamanho) deve ser dividido pelas diferentes fases do ciclo do teste (elaboração, execução,

reteste, etc).

  • Planejamento + projeto de teste = 35% do tempo total

  • Execução do teste = 60%

  • 5% restante deve ser destinado para o reteste e a conclusão do teste

Estimativas baseada em UC O esforço de teste é medido combinando-se a complexidade e o tamanho

Plano de Teste

Plano de Teste

Plano de Testes

Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção
Plano de
Levantamento
dos requisitos
Teste
Especificação
Arquitetura
Construção
Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste
Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste

Teste de aceitação

Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste
Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste

Teste de sistema

Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste
Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste

Teste de integração

Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste

Teste de unidade

Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste

Codificação

Plano de Testes Plano de Levantamento dos requisitos Teste Especificação Arquitetura Construção Teste de aceitação Teste

O que é Plano de Teste

  • Instrumento básico para a gerência de projetos de

teste gerenciar e controlar os projetos de teste de software

  • O Plano de Teste é o documento que apresenta o

nível de cobertura onde os elementos mais críticos do

software serão testados com prioridade e com um nível

de cobertura mais amplo. Descreve o que? Quando? e

Como? será testado cada elemento do software.

O que é Plano de Teste  Instrumento básico para a gerência de projetos de teste

Padrões de Plano de Teste

PMI

Este padrão é aplicado a qualquer tipo de projeto. Considerando-se que o teste de software também é

um projeto, o Plano de Teste deveria poder ser criado

segundo as regras do PMI.

IEEE 829 e QAI

Adaptações do padrão PMI ao ambiente de teste.

Padrões de Plano de Teste PMI Este padrão é aplicado a qualquer tipo de projeto. Considerando-se

Projetos - Padrão PMI

Áreas de conhecimento da Gerência de Projetos

conforme o PMBoK:

  • Gerência da integração do projeto

  • Gerência do escopo do projeto

  • Gerência de tempo do projeto

  • Gerência de custo do projeto

  • Gerência de qualidade do projeto

  • Gerência de recursos humanos do projeto

  • Gerência de comunicações do projeto

  • Gerência de riscos do projeto

  • Gerência de aquisições do projeto (suprimentos)

Projetos - Padrão PMI Áreas de conhecimento da Gerência de Projetos conforme o PMBoK:  Gerência

Plano de Teste Padrão IEEE 829

Identificação do Plano de Testes Referências Introdução Funcionalidades a serem testadas Riscos do processo de teste Funções a serem testadas do ponto de vista do usuário Funções que não serão testadas do ponto de vista do usuário Abordagem (estratégia) dos testes Critérios de conclusão dos testes Critérios para interrupção e retomada dos testes Entregas (Plano de Teste, Casos de Teste, etc.) Ambiente de teste Pessoal (equipe, treinamento, local, etc.) Responsabilidades Cronograma Plano de Riscos e contingências Aprovação dos testes Métricas

Plano de Teste – Padrão IEEE 829  Identificação do Plano de Testes  Referências 

Plano de Teste Padrão QAI

  • Escopo de Teste

  • Objetivos de Teste

  • Premissas

  • Análise de Risco

  • Estrutura do Teste

  • Funções e responsabilidades

  • Recursos e Cronograma de Testes

  • Gerência de Dados de Teste

  • Ambiente de Teste

  • Comunicação

  • Ferramentas de Teste

  • Métricas

Plano de Teste – Padrão QAI  Escopo de Teste  Objetivos de Teste  Premissas

Correspondência entre os Padrões

Planos do Plano Global do Projeto Itens do Plano de Teste do Modelo de Teste IEEE
Planos do Plano
Global do Projeto
Itens do Plano de Teste do Modelo de Teste IEEE 829
Itens do Plano de Teste do
modelo QAI
Escopo
Identificação do Plano de Testes
Referências
Introdução
Funcionalidades a serem testadas
Funções a serem testadas do ponto de vista do usuário
Funções que não serão testadas do ponto de vista do usuário
Escopo do Teste
Objetivos de Teste
Premissas
Estrutura do Teste
Custo
Métricas
Métricas
Tempo
Cronograma
Qualidade
Abordagem (estratégia) dos testes
Gerência de Dados de Teste
Critérios de conclusão dos testes
Critérios para interrupção e retomada dos testes
Ambiente de Teste
Pessoal (equipe, treinamento, local, etc.)
Responsabilidades
Entregas (Plano de Teste, Casos de Teste, etc.)
Riscos do processo de Testes
Plano de Riscos e contingências
Recursos e Cronograma de
Testes
Gerência de Dados de Teste
Integração
Recursos
Ambiente de Teste
Funções e responsabilidades
Humanos
Comunicação
Riscos
Comunicação
Análise de Riscos
Suprimentos
Ferramentas de Teste

Dificuldades no cumprimento do

Plano de Teste

1 - Falta de envolvimento dos usuários e dos clientes

2 - Falta de treinamento

3 - Desenvolvedores vs. Testadores

4 - Falta de ferramentas de teste

5 - Falta de apoio da gerência

6 - Falta de tempo para testar

Dificuldades no cumprimento do Plano de Teste 1 - Falta de envolvimento dos usuários e dos

Dificuldades no cumprimento do

Plano de Teste

7 - Quem testa é a equipe de testes

8 - Alterações rápidas

9 - Os testadores são sempre os culpados

10 - Testadores precisam aprender a dizer não

Dificuldades no cumprimento do Plano de Teste 7 - Quem testa é a equipe de testes

Dúvidas

Dúvidas
Dúvidas