Embed Size (px)
DESCRIPTION
Curso de estimativas e metricas para projetos de teste de software
Citation preview
Estimativas em Projetos de Testes
Agenda
Estimativas Métricas Analise de Ponto de Teste Pontos de Casos de Teste
Indicadores
Previsão e otimização podem ser complexas
Vamos lá, não podemos errar todas...
Estimativas
ESTIMATIVA DE SOFTWARE
(aplicado a Teste de Software)
4
SOFTWARE ESTIMATION:
Demystifying the Black Art
Steve McConnel, 2006
Microsoft Press
Fonte
Considere o seguinte requisito:
O acesso dos usuários aos seus dados
cadastrais deve ser feito através do
fornecimento de sigla e senha.
Quanto tempo você estima que precisaria para testar este
requisito?
Como chutar bem
Eu sou o
chutador
de
prazos
Planning PokerEstruturando o chute
Considerando-se o requisito anterior escolha
uma das seguintes estimativas para testá-lo
– 1 hora
– 2 horas
– 3 horas
– 5 horas
– 10 horas
– 20 horas
Curso de Formação Profissional
6
Resposta dada por um especialista
Quantos casos de teste seriam necessários?
– Entre 20 e 30 casos de teste
Quanto tempo seriam gasto na elaboração e
na execução de cada caso de teste?
– Elaboração – 3 minutos (45%)
– Execução – 4 minutos (55%)
Esforço total mínimo = 7x20 = 140 minutos = +- 2 horas
Esforço total máximo = 7x30 = 210 minutos = +-3 horas
Caso real – Complexidade de Caso de Uso
Curso de Formação Profissional
8
Nº UC Caso de Uso Iteração Complexidade Pontos
UC 01 - Enquadrar Ordem de Pagamento Simples 5
UC 02 - Parametrizar Dados do Cliente Médio 10
UC 03 - Enviar Fale conosco Simples 5
UC 04 - Consultar Ordem de Pagamento Complexo 15
UC 05 - Detalhar Ordem de Pagamento Simples 5
UC 06 - Realizar Download de Ordem de Pagamento Simples 5
UC 07 - Transmitir por e-mail Ordem de Pagamento Simples 5
UC 08 - Enviar e-mail Simples 5
Etc..........
Atividades e Produtos
Total do Projeto
Tamanho Esforço
Gerência 15,0% 0,0
Plano de Projeto 0,5% 0,0
Requisitos 20,0% 0,0
Documento de Visão 3,5% 0,0
Modelagem 17,0% 0,0
Modelo de Dados 5,0% 0,0
Construção 40,0% 0,0
Código 35,0% 0,0
Teste 8,0% 0,0
Plano de Teste 0,5% 0,0
Total 100,00% 3733,4
Conceitos básicos
Estimativa
Meta
Compromisso
Relação entre estimativa e planejamento
Divulgação, negociação e aceitação
Estimativa acurada e precisa
9
Conceitos básicos
O que se quer estimar?
Tamanho
Esforço
Custo
Prazo
10
Conceitos básicos
11
TAMANHO
ESFORÇO
CUSTO PRAZO
Estimativa e probabilidade
12
PR
OB
AB
ILID
AD
E
PRAZO/ CUSTO / ESFORÇO
A maioria dos
projetos de teste de
software tem uma
probabilidade do
tipo mostrado ao
lado.
100% de acerto
Um ponto simples é
uma meta mascarada
como estimativa.
Estimativa e probabilidade
13
PR
OB
AB
ILID
AD
E
PRAZO / CUSTO / ESFORÇO
PR
OB
AB
ILID
AD
E
PRAZO CUSTO / ESFORÇO
Esta seria a curva
normalmente aceita
para projetos de
teste de software
100% de acerto
Na verdade sempre
haverá um custo ou
esforço mínimo.
- +
Estimativa “boa”
O uso de dados
históricos e
métodos
estatísticos reduz
muito a dispersão
das estimativas
14
Boeing Company
-150
-50
50
150
1 2 3 4 5
CMMI Level
Err
o n
a e
sti
mati
va %
Estimativa e gerência de projeto
15
P R O J E T O
Falta equipe quando planejado
Requisitos retirados
Recursos desviados Funcionalidades
removidas
Requisitos acrescentados
Equipe menos experiente
Novos recursos acrescentados
estimativa
Equipe atendendo
outro projeto
Estimativa com “folgas”
Lei de Parkinson
Procrastinação
“Enfeitar o pavão”
16
Estimativa “apertada”
Desenvolvedores ou testadores são 20% a 30% “otimistas” em suas estimativas
Menos investimento na fase inicial
Dinâmica destrutiva:– Mais reuniões
– Mais desculpas
– “Cortes”
– Adoção de práticas de “alto risco”
17
Quando voce
estima mal o
caos vem
depois.
Estimativa apertada e com folga
18
Esforço
Custo
Prazo
Crescimento não
linear por erros de
planejamento,
práticas de alto risco Crescimento
linear devido à
lei de Parkinson
Apertada Folgada
Lei de Parkinson – Se você der 5 dias para um testador fazer o seu trabalho e se ele terminar em 4 dias, com toda certeza vai arrumar alguma coisa para fazer no dia que sobrou.
Benefícios de boas estimativas
Visibilidade do projeto
Mais qualidade
Melhor coordenação entre equipes
Melhor orçamento
Credibilidade da equipe
Identificação prematura de riscos
19
O que você prefere?
Previsão para desenvolvimento do projeto A:
1) Prazo previsto de 4 meses, podendo ser 1
mês antes ou 1 meses depois.
2) Prazo previsto de 5 meses, podendo ser
uma semana antes ou uma semana depois.
20
O que você prefere?
Lembre-se desta afirmativa: As penalidades
pela estimativa abaixo do prazo real
(underestimation) são maiores do que
aquelas acima do prazo real. Se voce tiver
que escolher, opte sempre pela estimativa
acima do prazo (overestimation).
21
Pense um pouco sobre isso
Projeto A
1) Usuário: Este projeto precisa estar pronto
em 4 meses porque o produto precisa estar
no mercado.
2) Gerente do projeto: Estimou o
desenvolvimento do projeto em 6 meses.
O que vai acontecer?
22
Origens dos erros em estimativas
Falta de informação sobre o projeto;
Falta de informação sobre a organização;
Tentativa de estimar o caos (alvo móvel);
Pressões dos usuários ou gerentes;
Processo de estimativa inadequado.
23
24
CONE DE INCERTEZA
0.1
10
TEMPO
IMP
RE
CIS
ÃO
Início
DefiniçãoRequisitos
Interface Projeto
detalhado
O cone da incerteza não irá se afunilando por si só, você precisar ir
tomando medidas corretivas para que isso aconteça. Por exemplo, voce
precisa dizer o que o projeto irá entregar ou não entregar. Caso isso
demore a acontecer a tendência é o cone não afunilar.
Cone de incertezaFontes adicionais de variação
25
CONE DE INCERTEZA
0.1
10
TEMPO
IMP
RE
CIS
ÃO
Início
DefiniçãoRequisitos
Interface Projeto
detalhado
Requisitos mal definidos
Requisitos imprevistos
Não envolvimento do cliente
Projeto ruim (gera erros futuros)
Práticas de teste inadequadas
Inexperiência
Falta de planejamento
“Prima donna”
Abandonar o processo (pressão)
Falta de controle (automatizado)
Falta de ferramentas adequadas
Requisitos funcionais esquecidos
Instalação e configuração
Conversão de dados
Adaptadores para produtos de terceiros
Help
Interfaces com outros sistemas
26
Requisitos instáveis são fontes inesgotáveis de erros de
estimativas, pois nem sempre essas mudanças implicam na
revisão da estimativa inicial.
Requisitos não-funcionais esquecidos
Acurácia e precisão
Interoperabilidade
Manutenibilidade
Desempenho
Portabilidade
Confiabilidade
27
• Reusabilidade
• Escalabilidade
• Segurança
• Recuperabilidade
• Usabilidade
Lembre-se da norma ISO 9126 cujas características podem
estar implícitas no esforço de teste.
Atividades esquecidas
• Tempo de adaptação de novos membros
• Mentoring
• Gerência e coordenação, reuniões
• Cutover / implementação
• Conversão de dados
• Instalação
• Customização
• Elicitação de requisitos
• Revisões e ajustes
• Suporte
• Manutenção de scripts / builds
• Geração / Manutenção de testes automáticos
• Revisões e reuniões técnicas
• Integração de tarefas
• Processamento de pedidos de mudanças
• Coordenação com sub-contratados
28
• Suporte técnico a antigos sistemas
• Manutenção em sistemas antigos
• Retrabalho e correção de defeitos
• Variação e ajuste de desempenho
• Aprendizagem de novas ferramentas / técnicas
• Tarefas administrativas
• Coordenação com testadores
• Coordenação com desenvolvedores
• Garantia da qualidade
• Preparação e revisão de documentação
• Demonstrações a clientes, eventos, etc.
• Demonstrações a alta gerência
• Contatos com clientes
• Revisões de planejamento, estimativas, etc.
• Revisões por pares
• Tarefas extra-profissionais
Outras atividades “esquecidas”
Férias, feriados, feriadões
Doenças e faltas
Treinamento
Eventos organizacionais, encontros,
congressos
Instalações e configurações do PC
Problemas de hardware e software
Almoços prolongados
Aniversário do chefão
Etc.29
Fatores influentes na estimativa
Otimismo e expectativas conscientes ou não
Métodos com muitos fatores de ajuste (p. ex. COCOMO II: 17 multiplicadores e 5 fatores de escala – 22 ajustes!)
Estimativas precipitadas
Desconhecimento do domínio ou tecnologia
Orçamentação prematura
Conversão de tamanho em esforço
Conversão de esforço em prazo e custo
Transmissão, divulgação e comunicação
30
Fatores que influenciam na estimativa
Quanto é 68 + 73 ?
Engenheiro: É 141.
Matemático: 68+73=73+68 porque a adição é comutativa
Contador: normalmente é 141, mas para o quê você vai usar isto?
Desenvolvedor – preciso fazer um programa
Testador – o programa para ser confiável ainda precisa ser testado.
31
Fatores que influenciam no projeto
O fator mais influente é o tamanho.
O esforço aumenta muito com o tamanho
Incrementos no tamanho refletem-se
dramaticamente nos custos, esforço e prazo
Redução de tamanho tem efeito menos
expressivo
32
Outros fatores que influenciam no projeto
33
Fatores pessoais x percentual de variação introduzido:
(fonte: Software Estimation, McConnel, 2006)
-30 -20 -10 0 10 20 30 40 50
Coesão da equipe
Experiência na plataforma
Experiência na linguagem e feramentas
Experiência no dominio
Turnover
Programador
Analista de requisitos
Infomormações extraidas de um estudo que vem sendo feito desde 1960 e que está publicado no modelo
COCOMO II – Barry Boehm.
Um analista
de
requisitos
ruim pode
trazer um
acréscimo
de até 42%
no tempo
total do
projeto
Como estimar
Fundamentação
Contar (recomendável)
Calcular (razoável)
Julgar (se não tiver outro jeito)
Geralmente uma combinação dessas técnicas
34
Estimativa por analogia
Obtenha os valores para tamanho, esforço e custo em projetos semelhantes;
Se possível, obtenha esses dados detalhados por WBS, tipo de item, etc.;
Estime o tamanho do novo projeto proporcionalmente;
Estime o esforço com base na relação de tamanhos entre os projetos;
Verifique a consistência do resultado.
35
Estimativa por analogia
36
Outras possibilidades:
-Um sistema com 500 pontos de função foi testado em um
mês, logo um sistema com 1000 pontos de função estima-se
que será testado em dois meses.
- Um sistema com 30 casos de uso foi testado em um mês,
logo um sistema com 60 casos de uso será testado em dois
meses.
- Eu gasto em média 30% do tempo de desenvolvimento
para testar
Isso é verdade?
Estimativa Delphi
Etapas:
1. O coordenador envia a especificação e o
formulário;
2. Reunião de discussão de questões;
3. Cada membro estima separadamente;
4. Coleta-se as estimativas anônimas;
5. O coordenador consolida e redistribui;
6. Reunião para discutir as variações e votação
anônima de aceitação da média;
7. Não havendo consenso volta-se à etapa 3;
8. O resultado pode ser um valor único ou um
intervalo e um valor esperado.
37
Ajuste da estimativa
O primeiro marco, previsto para 4 semanas, foi alcançado em 6 semanas, num projeto de 26 semanas. O que você faria:
1 -Manteria o prazo de 26 semanas e trataria de compensar o atraso;
2 - Reajustaria o prazo para 28 semanas;
3 - Reajustaria o prazo para 39 semanas (considerando um erro de 50%).
38
Como apresentar estimativas
39
1717FINAL
15-1816Primeira iteração
12-1814Projeto da interface
9-2013Requisitos aprovados
5-2010Definição do produto
3-4010Concepção
EstimativaEstimativaEtapa
Explicação
Quando você trabalha com faixas de
previsão não precisa ficar a todo momento
tendo que explicar aos usuários mudanças
de cronograma. Além disso tem uma
margem de segurança para fazer o
replanejamento sem precisar discutir outra
vez prazos.
MEDIDAS DE TAMANHO
Funcionalidades ou requisitos
Histórias de uso (XP)
Story points
Requisitos
Casos de uso
Casos de Teste
Pontos por função
Pontos de teste
Pontos de casos de teste
Páginas WEB
Elementos GUI (janelas, caixas, relatórios...)
Tabelas BD
Classes
Funções/subrotinas
LINHAS DE CÓDIGO
41
Caso real – Complexidade de requisitos
Curso de Formação Profissional
42
Complexidade
de Requisitos
Quantidade de horas
por requisito
Quantidade
Requisitos
Tamanho
Total Horas
Estimadas
Baixa 2 193 386
Médio 3 9 27
Alto 5 0 0
Atividades Responsável Início Término
Analisar Solicitação Gerente de Teste 05/10/2010 05/10/2010
Definir Equipe Gerente de Teste 05/10/2010 05/10/2010
Elaborar Plano de Teste Gestor de Teste 06/10/2010 18/10/2010
Definir Métricas Gestor de Teste 18/10/2010 18/10/2010
Projetar Teste Projetista de Teste 19/10/2010 05/112010
Preparar Ambiente Suporte de Infra-Estrutura 19/10/2010 21/10/2010
Gerar Scripts de Teste Projetista de Teste 08/11/2010 07/12/2010
Executar Testes Testador 08/12/2010 15/12/2010
Consolidar Resultado dos Testes Gestor de Teste 16/12/2010 20/12/2010
Encerrar Projeto de Teste Gerente de Teste 21/12/2010 21/12/2010
Estimando redução do prazo
43
-65%+30%
-50%+20%
-30%+10%
+25%-5%
+50%-10%
+100%-15%
VARIAÇÃO DO
ESFORÇO
VARIAÇÃO DO
PRAZO
Measures for Excellence (Putnam & Meyers, 1992)
Estimando alocação de esforço nas atividades do projeto
44
37%44%19%500 KLOC
29%53%18%125 KLOC
27%57%16%25 KLOC
19%70%11%1 KLOC
TesteConstruçãoArquitetura
AtividadeTamanho
Estimando a remoção de defeitos
45 85%75%60%Beta teste com mais de 1.000 sites
40%35%25%Beta teste com menos de 10 sites
55%40%25%Teste de sistema
30%25%15%Teste de regressão
40%35%25%Teste de integração
35%30%20%Teste de nova funcionalidade
50%30%15%Teste unitário
60%43%20%Revisão-leitura do código invidual
80%65%35%Modelagem ou prototipação
70%60%45%Inspeção formal de código
35%25%20%Revisão informal de código
60%55%45%Inspeção formal de projeto
40%35%25%Revisão informal de projeto
MAIORMÉDIAMENORETAPA
Fonte: Software Defect Removal Efficiency – Jones 1996
Aumentar a credibilidade
Segundo Lawrence Putnam se você quiser
aumentar a sua credibilidade de 95% para
99% você vai precisar aumentar em
aproximadamente 25% o seu custo de mão
de obra. O mesmo valor será necessário ser
acrescentado para passar de 99% para
99,9%.
Medidas de tamanho
Métricas Analise de Pontos de Teste Pontos de Caso de Teste
Análise de Pontos de Teste
Introdução:
Usando a Análise de Pontos de Função (APF ou PF) como base, Martin Pol, Ruud Tennissen e Erik van Veenendaaldesenvolveram uma unidade de mensuração da atividade de teste chamada Análise de Pontos de Teste (APT).
(livro “Software Testing, A Guide to TmapApproach”)
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.
Gráfico geral do processo de medição:
Pontos de Teste
Dinâmicos (PTD)
Pontos de Teste
Estáticos (PTE)
Total de Pontos
de Teste (PT)
Horas de Teste
Primárias (HTP)
Total de Horas de
Teste (THT)
Ambiente de
Teste (AT)
Qualificação da
Equipe de Teste
(QET)
Fatores de
Controle
Cálculo dosPontos de Teste
Cálculo doEsforço de Teste
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.
Pontos de Caso de Teste
Cuidado
Essa métrica como a APT também não tem
uma entidade do tipo IFPUG que ser
responsabilize pela sua manutenção.
Projetos de teste seguem os seguintes modelos
Modelo 1
Geração de casos
de teste
Modelo 2
Geração de scripts
de teste
Modelo 3
Execução de teste
manual (com relato
de defeitos)
Modelo 4
Execução de teste
automatizado
(com relato de defeitos)
Os 7 passos da análise de PCT
Identificar os casos de uso
Identificar os casos de teste
Determinar PCT para a geração de casos de teste
Determinar PCT para automação dos casos de teste
Determinar PCT para execução manual
Determinar PCT para execução automatizada
Determinar o total de PCT para o projeto de teste
Indicadores
Índices de cobertura do planejamento dos testes
Cobertura do planejamento dos testes dos requisitos
ICPR = total dos cenários com cobertura de testes / total de cenários
Objetivo: Verificar a probabilidade de ocorrência de defeitos em produção devido ao nível de cobertura alcançado pelos testes
Índices de cobertura do planejamento dos testes
Cobertura da execução dos testes dos
requisitos
ICET = total dos casos de teste executados /
total de casos de teste planejados
Objetivo: Dimensionar a evolução dos testes.
Bibliografia:
•Teste de Software, Editora Altabooks, Emerson Rios e Trayahu Moreira
•Software Testing, Addison Wesley, Martin Pol, Erik Van Veenendaal e outros.
•Managing the Testing Process, Microsoft Press, Rex Black
•Test Process Improvement, Addison Wesley, Martim Pol e Tim Koomen
• Base do conhecimento em teste de software – Ed Martins Fontes – Emerson
Rios, Trayahu Moreira, Aderson Bastos, Ricardo Cristalli.
• Software Estimation, Microsoft Press, Steve MacConnell.
