Estimativas palestra de 90 minutos

Estimativas e Métricas em Projetos

de Testes

Emerson Rios

emersonrios@iteste.com.br

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.

www.iteste.com.br61

Emerson rios

emersonrios@iteste.com.br