Fundamentos em Teste de Software

Módulo 2 – Planejando os Testes

Érika Hmeljevski – 2010

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.

 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.

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.

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
 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 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 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
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 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.

Dimensões 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 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.
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 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.
Riscos
 Entendendo melhor o conceito de
risco
O que é 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
 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.
 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>.
 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)

 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?
 Onde estão os maiores riscos de
defeitos?
 Funções muito complexas;

 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.

 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).
 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
 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
 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 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

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.
 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..
 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 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 5 0,3
no local da palestra,etc..
 Riscos desta palestra não ser realizada
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 5 0,3 0,15
no local da palestra,etc..
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

 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

 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”
 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
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

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.
 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
Plano de Teste
 Plano de Testes

Levantamento Plano de
dos requisitos
Teste Teste de aceitação

Especificação Teste de sistema

Arquitetura Teste de integração

Construção Teste de unidade

Codificação
 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.
 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.
 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)
 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 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
 Correspondência entre os Padrões
Planos do Plano Itens do Plano de Teste do Modelo de Teste IEEE 829 Itens do Plano de Teste do
Global do Projeto modelo QAI
Escopo Identificação do Plano de Testes Escopo do Teste
Referências Objetivos de Teste
Introdução Premissas
Funcionalidades a serem testadas Estrutura do 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
Custo Métricas Métricas
Tempo Cronograma
Recursos e Cronograma de
Testes
Qualidade Abordagem (estratégia) dos testes Gerência de Dados de Teste
Gerência de Dados de Teste
Critérios de conclusão dos testes
Critérios para interrupção e retomada dos testes
Integração Ambiente de Teste Ambiente de Teste
Recursos Pessoal (equipe, treinamento, local, etc.) Funções e responsabilidades
Humanos Responsabilidades
Comunicação Entregas (Plano de Teste, Casos de Teste, etc.) Comunicação
Riscos Riscos do processo de Testes Análise de Riscos
Plano de Riscos e contingências
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
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

Dúvidas