Métricas para estimativa de esforço em projetos de teste de software

UNIVERSIDADE DO GRANDE RIO
PROF. JOSÉ DE SOUZA HERDY
ESCOLA DE CIÊNCIA E TECNOLOGIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO

Samanta Cicília de Barros Souza

Métricas para Estimativa de Esforço em Projetos de Teste de
Software

Duque de Caxias
2012

UNIVERSIDADE DO GRANDE RIO
PROF. JOSÉ DE SOUZA HERDY
ESCOLA DE CIÊNCIA E TECNOLOGIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO


Software

Projeto Final de Curso apresentado à
Universidade do Grande Rio “Prof. José de
Souza Herdy” (UNIGRANRIO) como parte dos
requisitos para conclusão do curso de
Bacharelado em Sistemas de Informação.

Orientador: Prof. Thiago Silva de Souza

Duque de Caxias
2012

Software

Samanta Cicília de Barros Souza - 5304880

Projeto Final de Curso apresentado à
Universidade do Grande Rio “Prof. José de
Souza Herdy” (UNIGRANRIO) como parte dos
requisitos para conclusão do curso de
Bacharelado em Sistemas de Informação

Banca Examinadora:
1. Orientador e Presidente: Prof. Thiago Silva de Souza
2. Membro externo: pesquisadora da Coppe/UFRJ Talita Vieira Ribeiro

Duque de Caxias
2012

Métricas para Estimativa de Esforço em Projetos de
Teste de Software, Duque de Caxias, 2012
XVI, 125 p. 29,7 cm. (Escola de Ciência e Tecnologia,
2012)
Projeto de Final de Curso - Universidade do Grande
Rio, Escola de Ciência e Tecnologia.
1. Engenharia de Software
2. Teste de Software
3. Métricas de Estimativa de Esforço
I. EIN/UNIGRANRIO II. Título (série)

AGRADECIMENTOS

Em primeiro lugar a Deus, sem o qual nada disso seria possível, agradeço pela força e
pela graça concedida e pela oportunidade de alcançar meus sonhos.
Aos meus pais, Gezilene e Paulo, que sempre me apoiaram e confiaram nas minhas
escolhas. Pessoas que nos momentos mais difíceis sempre estiveram do meu lado, me
dando forças e não me deixando desistir. Obrigada por dedicar a vida de vocês a me fazer
feliz.
Aos amigos conquistados na faculdade que viveram comigo esse momento e também
apoiaram e compartilharam alegrias e dificuldades, mas sempre ajudando uns aos outros.
A todos os professores com os quais tive a grande honra de estudar, em especial ao
Prof. Thiago Souza, que como orientador teve muita competência, paciência e amizade,
posso afirmar que tive a grande felicidade de contar com um dos melhores orientadores do
Curso de Sistemas de Informação.
A minha família em geral que sempre acreditou em mim e me deu forças.
Aos colegas de trabalho que de alguma forma sempre procuraram contribuir com o
que eu precisava.
Agradeço também ao meu amigo Josenildo Amorim, que começou esse trabalho
comigo, mas infelizmente não pôde dar continuidade.
Meu muito obrigada a todos vocês!

“If you have an apple and I have an apple and we exchange these apples then you and I will
still each have one apple. But if you have an idea and I have an idea and we exchange these
ideas, then each of us will have two ideas.”
George Bernard Shaw

RESUMO
Planejar e programar as atividades de teste a serem realizadas é um fator
fundamental para garantir a qualidade de um software, possibilitando alocação de recursos
e tempo de forma consistente para essas atividades. A maioria das empresas utiliza apenas
experiência para estimar o esforço a ser gasto em teste de software, já que as técnicas
existentes são complexas demais para serem executadas frequentemente, demandando
muitas vezes um tempo que poderia ser gasto na execução dos testes. Diante disso, foi
realizada uma comparação entre algumas dessas técnicas e um estudo experimental
aplicando-as e avaliando sua precisão de acordo com o valor gasto para testar o sistema
desse experimento. Foram utilizadas as técnicas Análise de Pontos de Teste, Método
Ponderado de Nageswaran, Análise de Pontos por Caso de Teste e Estimativa baseada em
Especificação de Requisito Funcional e Eficiência Acumulada. Este projeto, portanto,
apresenta algumas técnicas existentes na literatura acadêmica e no mercado, assim como
um survey com respostas de profissionais de teste de algumas partes do mundo sobre a
forma que eles estimam o esforço de teste, um protocolo de quasi-Revisão Sistemática e
uma prova de conceito aplicando as técnicas descritas. A maioria das técnicas, no entanto,
ainda se encontra em fase de estudos e não apresenta precisão aceitável.

Palavras-chave: engenharia de software, teste de software, métricas de estimativa.

SUMÁRIO
1 - Introdução .................................................................................................................. 17
1.1 - Motivação ..................................................................................................................... 17
1.2 - Problema ...................................................................................................................... 17
1.3 - Hipótese........................................................................................................................ 18
1.4 - Objetivos e Escopo do Trabalho ................................................................................... 18
1.5 - Organização do Trabalho.............................................................................................. 18
2 - Métricas para Estimativa de Esforço em Projetos de Teste de Software ....................... 19
2.1 - Métricas para Estimativa de Esforço ............................................................................ 19
2.2 - Análise de Pontos de Teste (APT) ................................................................................. 19
2.3 - Estimativa a partir de Bases Históricas de Projetos de Teste ...................................... 26
2.4 - Análise de Pontos por Caso de Teste ........................................................................... 27
2.5 - Estimativa de Capers Jones .......................................................................................... 30
2.6 - Estimativa baseada na Regra 40-20-40 ........................................................................ 30
2.7 - Estimativa Método Ad-Hoc........................................................................................... 30
2.8 - Estimativa por Pontos de Execução ............................................................................. 30
2.9 - Estimativa baseada em Especificação de Requisito Funcional e Eficiência Acumulada
.............................................................................................................................................. 33
2.10 - Estimativa Método Ponderado de Nageswaran ........................................................ 35
3 - Protocolo de quasi-Revisão Sistemática ...................................................................... 37
3.1 - Cenário de Investigação Principal ................................................................................ 37
3.2 - Protocolo de Busca ....................................................................................................... 38
3.2.1 - Foco de Interesse .................................................................................................. 38
3.2.2 - Qualidade e Amplitude da Questão ...................................................................... 38
3.3 - Seleção de Fontes ......................................................................................................... 40

3.3.1 - Definição de Critérios para seleção de fontes....................................................... 40
3.3.2 - Idioma das fontes .................................................................................................. 40
3.3.3 - Identificação das Fontes ........................................................................................ 40
3.4 - Seleção dos Estudos ..................................................................................................... 42
3.4.1 - Definição dos estudos ........................................................................................... 42
3.5 - Resultados da pré-execução......................................................................................... 44
3.6 - Estratégia para Extração da Informação ...................................................................... 45
3.7 - Critérios para Avaliação da Qualidade dos Artigos ...................................................... 45
3.8 - Execução ....................................................................................................................... 45
4 - Survey ........................................................................................................................ 48
4.1 - Definição de Survey ...................................................................................................... 48
4.2 - Questionários ............................................................................................................... 48
4.3 - Resultados .................................................................................................................... 49
5 - Prova de Conceito ....................................................................................................... 54
5.1 - Informações da Prova de Conceito .............................................................................. 54
5.2 - Estimativas de Esforço Total do Projeto de Teste ........................................................ 56
5.2.1 - Análise de Pontos de Teste ................................................................................... 56
5.2.2 - Estimativa Método Ponderado de Nageswaran ................................................... 59
5.3 - Estimativas de Esforço Parcial do Projeto de Teste ..................................................... 60
5.3.1 - Análise de Pontos por Caso de Teste (TCP) ........................................................... 60
5.3.2 - Estimativa baseada em Especificação de Requisito Funcional e Eficiência
Acumulada ........................................................................................................................ 61
5.4 - Considerações sobre as medições................................................................................ 61
6 - Conclusão ................................................................................................................... 64
6.1 - Considerações Finais .................................................................................................... 64
6.2 - Contribuições................................................................................................................ 64

6.3 - Trabalhos Futuros ......................................................................................................... 65
Referências Bibliográficas ................................................................................................ 66
Apêndice I – Modelo de Formulário de Extração .............................................................. 68
Apêndice II – Artigos do protocolo de quasi-Revisão Sistemática...................................... 70
Apêndice III – Regras de Negócio Sistema Escola .............................................................. 86
Apêndice VI – Descrição dos Casos de Uso ....................................................................... 88
Apêndice V – Casos de Teste do Sistema Escola................................................................ 94
Apêndice VI – Evidências de Teste executados com sucesso ........................................... 106
Apêndice VII – Evidências de Teste reprovados .............................................................. 115
Apêndice VIII – Análise de Pontos de Teste (técnica original) ......................................... 123
Apêndice IX – Análise de Pontos de Teste (planilha SERPRO) .......................................... 124
Apêndice X – Análise de Pontos de Teste (ferramenta de APT) ....................................... 125

LISTA DE FIGURAS
Figura 1: Visão Geral da Técnica de Análise de Pontos de Teste (VEENENDAAL, 1999) ......... 20
Figura 2: Visão Geral do Modelo de Estimativa de Pontos de Execução (ARANHA, 2007). .... 31
Figura 3: Atribuindo os pontos de execução para cada passo do caso de teste (ARANHA,
2007). ...................................................................................................................... 32
Figura 4: Estimativa do esforço em homens/hora (ARANHA, 2007). ................................... 33
Figura 5: Diagrama do processo do protocolo de quasi-Revisão Sistemática ....................... 44
Figura 6: Gráfico dos períodos em que os artigos foram publicados ................................... 47
Figura 7: Questionário em português ................................................................................ 48
Figura 8: Questionário em inglês ...................................................................................... 49
Figura 9: Porcentagem de utilização das métricas (no Brasil).............................................. 50
Figura 10: Porcentagem de utilização das métricas (outras partes do mundo) .................... 51
Figura 11: Porcentagem de utilização das métricas (Brasil e outras partes do mundo)......... 51
Figura 12: Empresas que estimam esforço para teste por país ........................................... 52
Figura 13: Técnicas utilizadas por país ............................................................................... 52
Figura 14: Casos de Uso Sistema Escola............................................................................. 54
Figura 15: Características de cada função do Domínio Sistema Escola. ............................... 57
Figura 16: Homens/hora totais de teste. ........................................................................... 59
Figura 17: Medição em Pontos por Caso de Teste. ............................................................. 60
Figura 18: Medição em Especificação de Requisito Funcional e Eficiência Acumulada. ........ 61

LISTA DE TABELAS
Tabela 1: Peso da importância das funcionalidades para o usuário.

21

Tabela 2: Peso da intensidade de uso das funções.

21

Tabela 3: Peso da interface das funções.

21

Tabela 4: Peso da complexidade das condições.

22

Tabela 5: Peso das Características Explícitas.

23

Tabela 6: Ferramentas de Teste.

24

Tabela 7: Testes de precedência.

24

Tabela 8: Documentação de Teste.

24

Tabela 9: Ambiente de Desenvolvimento.

25

Tabela 10: Ambiente de Teste.

25

Tabela 11: Testware.

25

Tabela 12: Tamanho da Equipe de Teste.

26

Tabela 13: Ferramentas de Gerência de Teste.

26

Tabela 14: Descrição do Nível de Complexidade das Pré-condições (traduzido).

27

Tabela 15: Descrição do Nível de Complexidade dos Dados de Teste (traduzido).

28

Tabela 16: Pesos das pré-condições e dados de teste segundo a complexidade (traduzido). 28
Tabela 17: Pesos dos Tipos de Teste (traduzido).

30

Tabela 18: Pesos dos Tipos de Atores (traduzido).

35

Tabela 19: Classificação dos fatores de ambiente (traduzido).

36

Tabela 20: Máquinas de busca utilizadas no protocolo de quasi-Revisão Sistemática.

41

Tabela 21: Tabela com os resultados da pré-execução do protocolo de quasi-Revisão
Sistemática.

44

Tabela 22: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática
pelo primeiro pesquisador.

45

pelo segundo pesquisador.

46

Tabela 24: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática.
46
Tabela 25: Tempo gasto para realizar cada atividade de Teste.

55

Tabela 26: Estimativa do Domínio Sistema Escola em Pontos de Função.

56

Tabela 27: Tempo gasto para realizar cada atividade de Teste segundo APT.

57

Tabela 28: Tempo gasto para realizar cada atividade de Teste segundo APT (planilha
SERPRO).
Tabela 29: Descrição dos Fatores Técnicos de Ambiente.

58
59

LISTA DE ABREVIATURAS E SIGLAS

1. AIE – Arquivo de Interface Externa.
2. ALI – Arquivo Lógico Interno.
3. APT – Análise de Pontos de Teste.
4. APF – Análise de Pontos de Função.
5. C – Complexidade.
6. CE – Características Explícitas.
7. CET - Ciclo de Execução.
8. CF - Fator de Conversão.
9. CI – Características Implícitas.
10. Df – Função dependente.
11. E - Fatores de ambiente.
12. EA - Média Aritmética de Esforço do ciclo.
13. EE – Entrada Externa.
14. Erms - Média da raíz quadrada do erro médio.
15. FG - ferramentas de gerência.
16. FTA - Fatores técnicos de ambiente.
17. HTP - Horas de Teste Primárias.
18. I – Interface.
19. IPC - Índice de planejamento e controle.
20. N - Cenário de caso de uso normal.
21. Ntc - Número de casos de teste do ciclo.
22. PCT – Pontos por caso de teste.
23. PCTA – Pontos por caso de teste ajustados.
24. PCTNA - Pontos por caso de teste não ajustados.
25. PCUA – Pontos por caso de uso ajustados.

26. PCUNA – Pontos por caso de uso não ajustados.
27. PE - Pontos de Execução.
28. Pe - Peso do fluxo de exceção.
29. PF – Pontos de função.
30. Pi – Peso do tipo de teste.
31. Pn - Peso do fluxo normal.
32. PT – Pontos de teste.
33. Pt - Peso total do caso de teste.
34. Qd – Características de Qualidade Dinâmica.
35. Qi - Pontos de Teste Estáticos.
36. Qt - Qualificação da equipe de teste.
37. r - Erro relativo.
38. S - Número de passos de teste.
39. SE – Saída Externa.
40. SERPRO – Serviço Federal de Processamento de Dados.
41. TCP – Ponto por caso de teste.
42. TE - Tamanho da equipe de teste.
43. THT - Total de horas de teste.
44. TPf – Total de pontos de teste dinâmicos.
45. U – Uniformidade.
46. Ue – Importância do usuário.
47. UTCP – Pontos por caso de teste não ajustados.
48. UUCW - Pontos de caso de uso não ajustados.
49. Uy – Intensidade de uso.
50. WEa - Média Aritmética Ponderada.

17

1 -Introdução
Este capítulo está dividido em cinco seções. A seção 1.1 apresenta a motivação para
realização deste trabalho. A seção 1.2 descreve o problema a ser tratado nesta pesquisa. A
seção 1.3 disserta sobre a hipótese levantada para a resolução do problema. A seção 1.4
mostra os objetivos e o escopo deste trabalho. Por fim, a seção 1.5 descreve a estrutura pela
qual este trabalho está organizado.

1.1 -Motivação
O maior desafio das chamadas Fábricas de Software é entregar um produto
funcional, com qualidade e dentro de prazos pré-estabelecidos com os clientes. Entretanto,
como pode ser observado no mercado, muitas fábricas de software ainda deixam de lado as
atividades referentes ao controle e à garantia da qualidade, concentrando seus esforços
apenas em atividades de construção do software. Este tipo de comportamento muitas vezes
é impulsionado por orçamentos e prazos escassos.
A disciplina de Teste de Software é uma dessas atividades frequentemente deixadas
de lado, mas que, com o passar do tempo, tem se tornado independente e importante no
escopo do desenvolvimento de software, exigindo assim planejamento e estimativas mais
específicas, com o objetivo de melhorar a precisão das estimativas envolvendo esforço,
custo e tempo que essa atividade costuma demandar.
Atualmente não existe uma técnica-padrão para estimativa de esforço em projetos
de teste de software. Existem, no entanto, muitas propostas com abordagens diferenciadas,
mas que ainda não alcançaram a precisão esperada para realizar estimativa de forma
confiável em qualquer contexto de desenvolvimento de software.

1.2 - Problema
Este trabalho visa resolver a seguinte questão: como estimar esforço de projeto de
teste de software?

18

1.3 -Hipótese
Através de uma prova de conceito realizada sobre uma aplicação CRUD é possível
caracterizar o nível de precisão das principais técnicas para estimativa de esforço em
projetos de Teste de Software disponíveis.

1.4 - Objetivos e Escopo do Trabalho
Caracterizar o nível de precisão das técnicas de estimativa de esforço em projetos de
teste de software existentes. Tal objetivo pode ser subdividido nos seguintes objetivos
específicos:
Analisar as técnicas de estimativa de esforço em projetos de Teste de Software
existentes no mercado e na literatura técnica;
Demonstrar através de estudo experimental a precisão de algumas técnicas
existentes;
Avaliar os pontos fortes e fracos das técnicas.

1.5 -Organização do Trabalho
Este trabalho está organizado em seis capítulos. O capítulo 1 mostrou a introdução
do trabalho, ressaltando a sua motivação e seus objetivos. No capítulo 2 são apresentadas
algumas métricas para estimativa de esforço em projetos de teste software. Já no capítulo 3
é apresentado um protocolo de quasi-Revisão Sistemática a respeito de técnicas de
estimativa de esforço em projetos de teste de software existentes na literatura. No capítulo
4 é apresentado um survey realizado com profissionais de teste do Brasil e de alguns outros
países sobre quais técnicas de estimativa costumam utilizar. No capítulo 5 é apresentado
uma prova de conceito de algumas técnicas descritas no capítulo 2. No capítulo 6 são
apresentadas as conclusões do projeto. Finalmente, é apresentada a lista de referências
bibliográficas utilizadas.

19

2 - Métricas para Estimativa de Esforço em Projetos de Teste
de Software
Este capítulo está dividido em dez seções. A seção 2.1 apresenta um resumo sobre
métricas de estimativa de esforço. A seção 2.2 descreve a técnica Análise de Pontos de
Teste, a sessão 2.3 descreve a Estimativa a partir de Bases Históricas de Projetos de Teste, a
sessão 2.4 descreve a Análise de Pontos por Caso de Teste, a sessão 2.5 descreve a
Estimativa de Capers Jones, a sessão 2.6 descreve a Estimativa baseada na Regra 40-20-40, a
sessão 2.7 descreve a Estimativa Método Ad-Hoc, a sessão 2.8 descreve a Estimativa por
Pontos de Execução, a sessão 2.9 descreve a Estimativa baseada em Especificação de
Requisito Funcional e Eficiência Acumulada e por fim, a sessão 2.10 descreve a Estimativa
Método Ponderado de Nageswaran.

2.1 -Métricas para Estimativa de Esforço
Seguindo o exemplo das estimativas realizadas nas fases do desenvolvimento de um
Projeto de Software, também nos Projetos de Teste existem problemas quanto estimar da
forma mais precisa possível o esforço, tempo e custo que será demandado para a realização
dessa atividade.
O Teste de Software é uma atividade que impacta todas as outras atividades do
processo de desenvolvimento de software e que custa caro. Sendo estimado junto com as
etapas de Iniciação, Elaboração e Construção, o teste não detinha a atenção devida e,
consequentemente, ficava com prazo apertado. Existem no mercado e na literatura algumas
técnicas específicas para estimar o esforço em Projetos de Teste que serão descritas nas
seções a seguir.

2.2 -Análise de Pontos de Teste (APT)
Conforme pode ser visto em Veenendaal e Dekkers (1999), a técnica é baseada na
Análise de Pontos de Função (APF) e utiliza como base o tamanho da funcionalidade. É uma
técnica que não cobre os testes de alto nível, sendo aplicada aos testes unitários e de
integração. A Figura 1 apresenta uma visão geral da técnica.

20

Figura 1: Visão Geral da Técnica de Análise de Pontos de Teste (VEENENDAAL, 1999)
Essa técnica é baseada em três elementos que determinam a medição, o tamanho do
sistema a ser testado, a estratégia de teste e a produtividade. O volume de trabalho em
pontos de teste (PT) é determinado pelo primeiro e segundo elementos. A estimativa em
horas é resultado da multiplicação do número de pontos de teste pela produtividade.
Conforme a fórmula abaixo, onde THT é o total de horas de teste, HTP são as horas primárias
de teste e IPC são os índices de controle e planejamento.

Para obter os pontos de teste (PT), devem-se calcular os pontos de teste dinâmicos
(TPf) e estáticos (Qi). Os pontos de teste dinâmicos são baseados nas funcionalidades
individuais do sistema medidas em pontos de função (PF). Baseiam-se também nas funções
dependentes (Df) e na qualidade dos requisitos relacionados com as características de
qualidade a serem testadas dinamicamente (Qd).
As funções dependentes (Df) são aquelas que estão relacionadas com as funções
medidas em PF, em cada uma dessas funções é necessário medir alguns fatores, são eles:
Importância do usuário (Ue): o quanto aquela funcionalidade é importante para o
usuário;

21

Intensidade de uso (Uy): utilização daquela função por intervalo de tempo;
Interface (I): quantidade de arquivos utilizados ou atualizados por aquela função;
Complexidade (C): quantidade de comandos de condição;
Uniformidade (U): nível de reutilização do material de teste;
Para cada um desses fatores existe um peso atribuído. Os pesos sobre a importância
do usuário, a intensidade de uso das funções, a interface das funções e a complexidade
estão representados, respectivamente na Tabela 1, Tabela 2, Tabela 3 e Tabela 4.
Importância do Usuário

Peso

Descrição

Baixa

3

A importância dessa função com relação às
outras é baixa

Normal

6

outras é normal

Alta

12

outras é alta

Tabela 1: Peso da importância das funcionalidades para o usuário.
Intensidade de Uso

Peso

Descrição

Baixa

2

A função é executada algumas vezes por
dia/semana

Normal

4

A função é executada muitas vezes por dia

Alta

8

A função é usada continuamente ao longo do
dia

Tabela 2: Peso da intensidade de uso das funções.
Interface

Peso

Descrição

Baixa

2

O grau de interface associado com a função é
baixa.

Média

4

normal.

Alta

8

alta.

Tabela 3: Peso da interface das funções.
Complexidade

Peso

Descrição

22

Baixa

3

A função não contem mais que 5
condições.

Normal

6

A função contem entre 6 e 11 condições.

Alta

12

A função contem mais que 11 condições.

Tabela 4: Peso da complexidade das condições.
Para a uniformidade, o valor varia entre 0,6 e 1, onde o limite inferior indica que o
material de teste pode ser reutilizado e o limite superior indica o contrário.
O valor total das funções dependentes é a soma dos fatores importância do usuário,
intensidade de uso, interface e complexidade, divididos por 20, vezes a uniformidade,
conforme a fórmula:

As características de qualidade dinâmicas (Qd) se referem na forma em que a
qualidade dos requisitos pode afetar a qualidade dos testes. Elas se dividem em
características explícitas (CE) – funcionalidade, performance, segurança e aderência e
características implícitas (CI) – utilizadas sempre que houver indicadores para as
características explícitas;
As características explícitas (CE) apresentam dois tipos de peso, um referente à sua
importância no resultado do teste e outra de mensuração da própria característica.
Quanto à mensuração própria de cada característica, tem-se:
Funcionalidade – 0,75
Performance – 0,10
Segurança – 0,05
Aderência – 0,10
Para os pesos referentes à importância da qualidade dos requisitos para o resultado
dos testes, a Tabela 5 os representa:

23

Peso

Descrição

0

A qualidade dos requisitos não é importante para o resultado dos testes.

3

A qualidade dos requisitos não é importante, mas precisa ser considerada
para o resultado dos testes.

4

A qualidade dos requisitos tem importância de nível médio para o
resultado dos testes.

5

A qualidade dos requisitos é muito importante para o resultado dos
testes.

6

A qualidade dos requisitos é extremamente importante para o resultado
dos testes.
Tabela 5: Peso das Características Explícitas.

O cálculo do resultado das características explícitas é a soma dos pesos multiplicados
pelo valor atribuído a cada característica.
Já as características implícitas (CI) são calculadas através de quantas características
explícitas tem indicador estabelecido vezes 0,02.
Os pontos de teste dinâmicos (TPf) no total são a multiplicação dos pontos de função
vezes as funções dependentes vezes as características de qualidade dinâmicas, ou seja:

Os pontos de teste estáticos (Qi) levam em consideração se são utilizados checklists
para avaliar as características dinâmicas, para cada um é adicionado 16.
De posse desses dois valores, obtemos o número total de pontos de teste, que é o
somatório dos pontos de teste dinâmicos das funções individuais acrescido dos PFs do
sistema (o menor valor atribuído é 500), multiplicado pelos pontos de teste estáticos
divididos por 500:

As horas de teste primárias são baseadas na qualificação da equipe de teste e
ambiente de testes (medido de acordo com características: ferramentas de teste, testes de
precedência, documentação de teste, ambiente de desenvolvimento, ambiente de teste e
testware). A qualificação da equipe de teste varia de 0,7 a 2, quanto mais experiente e
qualificada, menor será esse valor. Já o ambiente de teste deve ser medido seguindo

24

algumas regras que seguem nas tabelas abaixo, a Tabela 6 sobre as ferramentas de teste, a
Tabela 7 sobre os testes de precedência, a Tabela 8 sobre a documentação de teste, a Tabela 9

sobre o ambiente de desenvolvimento, a Tabela 10 sobre o ambiente de teste e a Tabela 11
sobre o testware:
Peso

Descrição

1

Existência de uma ferramenta de automação para
especificação e execução dos testes.

2

Existência de uma ferramenta de automação para
especificação ou execução dos testes.

4

Não existe ferramenta de automação de teste.
Tabela 6: Ferramentas de Teste.

Peso

Descrição

2

Existência de um plano de teste onde a equipe está
familiarizada com os casos de teste e os resultados dos
testes

4

Existência de um plano para o teste precedente

8

Não existe um plano para o teste.
Tabela 7: Testes de precedência.

Peso

Descrição

3

Durante o desenvolvimento do sistema são utilizados
padrões de documentação e templates. Acontecem
revisões periódicas na documentação.

6

Durante o desenvolvimento do sistema são utilizados
padrões de documentação e templates. Não há
verificação formal.

12

Não é utilizado nenhum padrão e nenhum template para
confecção de documentos.
Tabela 8: Documentação de Teste.

Peso
2

Descrição
Sistema desenvolvido em uma linguagem de 4ª
geração, integrada a um sistema de gerenciamento de
banco de dados.

25

4

Sistema desenvolvido com uma combinação de
linguagens de 3ª e 4ª gerações.

8

Sistema desenvolvido em uma linguagem de 3ª
geração.
Tabela 9: Ambiente de Desenvolvimento.

Peso

Descrição

1

O ambiente de teste já foi usado inúmeras vezes.

2

O ambiente de teste é similar ao que já vinha sendo
usado.

4

O ambiente de teste é completamente novo e
experimental.
Tabela 10: Ambiente de Teste.

Peso

Descrição

1

Existem materiais de teste que poderão ser
reutilizados, como bases de teste, casos de teste,
etc.

2

Existem apenas tabelas e bases de dados
disponíveis para reutilização.

4

Não existe testware disponível.
Tabela 11: Testware.

Depois de atribuídos os pesos, o número de pontos de teste é multiplicado pelos
fatores de ambiente e qualificação da equipe de teste. A fórmula das horas de teste
primárias, sendo E = soma dos fatores de ambiente/21 é a seguinte:

O total de horas de teste (THT) é baseado no índice de planejamento e controle (IPC),
que leva em consideração o tamanho da equipe de teste (TE) e ferramentas de gerência de
teste (FG). O tamanho da equipe de teste é dado pela Tabela 12:

26

Peso

Descrição

3

Não mais que 4 pessoas.

6

Entre 5 e 10 pessoas.

12

Mais que 10 pessoas.

Tabela 12: Tamanho da Equipe de Teste.
As ferramentas de gerência de testes (FG) se referem às ferramentas que são
utilizadas para a fase de testes e classificadas segundo a Tabela 13:
Peso

Descrição

2

São utilizadas ferramentas de registro de tempo, gerência
de testes, de defeitos e de configuração.

4

Apenas uma das ferramentas citadas acima é utilizada.

8

Não é utilizada nenhuma ferramenta.
Tabela 13: Ferramentas de Gerência de Teste.

O cálculo do índice de planejamento e controle (IPC) é dado pela seguinte fórmula:

O total de horas de teste (THT) é dado pela fórmula:
.

2.3 -Estimativa a partir de Bases Históricas de Projetos de Teste
É uma técnica baseada no histórico de projetos anteriores, sendo os requisitos do
negócio, a base para estimativa.
Para que essa técnica ofereça o máximo de precisão possível, é necessário que os
dados históricos sejam registrados de forma organizada e metódica.

27

2.4 - Análise de Pontos por Caso de Teste
Segundo Nguyen, Pham e Lam (2009), a Análise de Pontos por Caso de Teste é uma
técnica que utiliza casos de teste como entrada para fornecer a estimativa do esforço a ser
gasto para executar esses casos de testes, gerando a pontuação de casos de teste.
Para técnica a complexidade dos casos de teste está baseada em quatro fatores:
checkpoints, pré-condições, dados de teste e tipo do caso de teste. Esses elementos são
divididos em dois grupos, os três primeiros determinam a grandeza do caso de teste e o
último normaliza a complexidade dos diferentes tipos de teste existentes.
O escopo desse método abrange os testes que são executados manualmente, como
testes de aceite, não cobrindo testes que envolvem a utilização de scripts, como os testes
unitários.
Para calcular pontos de caso de teste (PCT), primeiro deve-se encontrar a
complexidade de cada caso de teste, através dos ckeckpoints, que são os resultados
esperados após a execução de um caso de teste. Para cada checkpoint temos 1 ponto.
Todo caso de teste apresenta pré-condições para sua execução, que podem afetar no
esforço empregado durante essa execução. Para atribuir a classificação, que é dada em
níveis, referente às pré-condições, tem-se a Tabela 14:
Nível de
Complexidade

Descrição

Nenhum

A pré-condição não é aplicável ou importante para executar
o caso de teste. Ou, a pré-condição é apenas reutilizada a
partir do caso de teste anterior para continuar o caso de
teste atual.

Baixo

A condição para a execução do caso de teste está disponível,
com algumas modificações simples requeridas. Ou, algumas
simples configurações de passos são necessárias.

Médio

Alguma preparação explícita é necessária para executar o
caso de teste. A condição para execução é disponível, com
algumas alterações necessárias. Ou, algumas configurações
adicionais de passos são necessárias.

Alto

Hardware pesado e / ou configurações de software são
necessários para executar o caso de teste.

Tabela 14: Descrição do Nível de Complexidade das Pré-condições (traduzido).

28

O próximo passo é atribuir a classificação referente aos dados que são necessários
para execução dos casos de teste, que podem ser gerados no momento da execução ou ser
reaproveitados de outros casos de teste. A Tabela 15 apresenta a classificação referente aos
dados de teste.
Nível de
Complexidade

Descrição

Nenhum

Nenhuma preparação de dados de teste é necessária.

Baixo

Simples dados são necessários e podem ser criados durante o
tempo de execução do caso de teste. Ou, no caso de teste usa uma
versão ligeiramente modificada de dados de teste existentes e
requer pouco ou nenhum esforço para modificar os dados de
teste.

Médio

Os dados de teste são deliberadamente preparados com
antecedência com um esforço extra para garantir a sua
integridade, integralidade e consistência.

Alto

Os dados de teste são preparados com antecedência com um
esforço considerável para garantir a sua integridade, integralidade
e consistência. Isso poderia incluir o uso de ferramentas de apoio
para gerar dados e um banco de dados para armazenar e gerenciar
dados de teste. Scripts podem ser necessários para gerar dados de
teste.

Tabela 15: Descrição do Nível de Complexidade dos Dados de Teste (traduzido).
Para cada um desses níveis de complexidade descritos nas tabelas acima, existe um
número de pontos de caso de teste relacionados, segundo a Tabela 16.
Nível de Complexidade

Número de TCP por précondição

Número de TCP por dados

Nenhum

0

0

Baixo

1

1

Médio

3

3

Alto

5

6

Tabela 16: Pesos das pré-condições e dados de teste segundo a complexidade (traduzido).
Somando-se os pontos referentes aos checkpoints, as pré-condições e os dados de
teste, encontra-se os pontos por caso de teste não ajustados (PCTNA).

29

Como os diferentes tipos de teste apresentam complexidades diferentes, a técnica
apresenta um fator de ajuste a partir desses tipos. A fórmula para se encontrar os pontos
por caso de teste ajustados (PCTA) é a seguinte:

Nessa fórmula, os pontos por caso de teste não ajustados vezes o peso referente ao
tipo de teste, retorna os pontos por caso de teste ajustados para um caso de teste. A Tabela
17 mostra os pesos referentes ao tipo de teste.
Tipo de teste

Descrição

Peso

Interface de usuário e
testes funcionais

Interface de usuário e testes funcionais é
considerada de referência.

1

API

API de teste verifica a exatidão das interfaces na
prestação de serviços

1,22

Banco de Dados

Testar a precisão de scripts de banco de dados,
integridade de dados e / ou migração de dados.

1,36

Segurança

Testando o quão bem o sistema lida com ataques
de hackers, não autorizadas e acessos não
autenticados.

1,39

Instalação

Teste de completo, parcial, atualização ou instalar / 1,09
desinstalar processos de software.

Rede

Testando as comunicações entre as entidades
através de redes.

1,27

Algoritmo e
computação

Verificando algoritmos e cálculos projetados e
implementados no sistema.

1,38

Teste de Usabilidade

Testando a simpatia, facilidade de uso, e os
atributos de usabilidade outros do sistema.

1,12

Desempenho
(manual)

Verificar se o sistema atende aos requisitos de
desempenho, assumindo que o teste é feito
manualmente.

1,12

Performance (manual) Verificar se o sistema atende aos requisitos de
desempenho, assumindo que o teste é feito
manualmente.

1,33

Teste de Recuperação

Teste de recuperação verifica a precisão do
processo de recuperação para se recuperar de
falhas no sistema e outros erros.

1,07

Compatibilidade

Testando se o software é compatível com outros
elementos de um sistema com o qual ele deve

1,01

30

operar, por exemplo, navegadores, sistemas
operacionais ou hardware.
Tabela 17: Pesos dos Tipos de Teste (traduzido).
Depois de encontrado o valor total dos pontos por caso de teste, é utilizada uma
estimativa baseada na experiência dos testadores para descobrir quanto minutos um
testador leva para executar um ponto de caso de teste e, assim, atribuir a estimativa para os
demais casos de teste de um projeto.

2.5 -Estimativa de Capers Jones
Segundo Lopes e Nelson (2008) é uma estimativa que se utiliza de uma fórmula para
estimar os casos de teste a partir dos pontos de função, tendo assim, sua precisão variável
de acordo com a precisão dos pontos de função.

2.6 -Estimativa baseada na Regra 40-20-40
Segundo Lopes e Nelson (2008) é uma regra bem simples, baseada numa constante
que determina 40 % de esforço para análise e projeto, 20% para codificação e os outros 40%
para teste, se aproximando muito da realidade dos projetos, porém essa técnica não leva em
conta fatores como cobertura e complexidade.

2.7 -Estimativa Método Ad-Hoc
Ad-hoc, expressão latina, tem tradução literal por “para isto” ou “para esta
finalidade”.
Nessa técnica de medição, o gestor define um tempo sobre o qual o teste será
executado.

2.8 -Estimativa por Pontos de Execução
Conforme é demonstrado em Aranha e Borba (2007), o principal objetivo dessa
técnica de estimativa é que ela possa ser aplicada a qualquer conjunto de testes funcionais.

31

A entrada do modelo é uma suíte de testes e a saída uma estimativa em
homens/hora para que essa suíte possa ser executada. Considera-se que as especificações
dos casos de teste estão escritas de forma padronizada. Na Figura 2 é apresentada a visão
geral da técnica:

Figura 2: Visão Geral do Modelo de Estimativa de Pontos de Execução (ARANHA, 2007).
Conforme especificado na figura do modelo, a técnica consiste em analisar cada caso
de teste da suíte, atribuindo um valor em pontos de execução (PE), para depois somá-los
obtendo os pontos de execução totais daquela suíte, que é o esforço para executá-la e
transformá-los em homens/hora.
Cada passo de um caso de teste deve ser analisado individualmente como
demonstrado na Figura 3.

32

Figura 3: Atribuindo os pontos de execução para cada passo do caso de teste (ARANHA,
2007).
Cada um dos passos é analisado comparando-se com uma lista de características
relevantes que podem impactar no tamanho e na complexidade de execução do mesmo. O
impacto é avaliado usando uma escala de baixo, médio e alto. Feito isto, são atribuídos
pontos de execução para cada característica, a soma dos pontos de execução de todas as
características retorna o total de pontos de execução daquele passo de teste,
consequentemente a soma de todos os passos retorna o total de pontos de execução
daquele caso de teste. A técnica sugere que a lista de características assim como os níveis de
influência e pesos devem ser avaliados através de estudos empíricos para garantir a precisão
do resultado final.
Depois de ter os pontos de execução basta encontrar o esforço em homens/hora.

33

Figura 4: Estimativa do esforço em homens/hora (ARANHA, 2007).
Como pode ser visto na Figura 4, dados históricos são utilizados para encontrar um
fator de conversão (CF) que é o somatório do esforço das suítes dividido pelo somatório dos
pontos de execução, retornando quanto tempo é gasto para testar um ponto de execução.
Em seguida, multiplica-se o fator de conversão pelos pontos de execução da suíte que se
deseja estimar.

2.9 -Estimativa baseada em Especificação de Requisito Funcional e
Eficiência Acumulada
É uma técnica que estima o esforço para execução de testes funcionais,
especialmente para pequenas equipes de teste, sem automação e pouca documentação,
conforme pode ser visto em Guerreiro e Abreu (2009). Cobre, portanto, apenas a execução
manual de teste. Para chegar a essa técnica foram usados dados de Base Histórica da
execução de testes de uma equipe ao longo de alguns anos.
Essa medição utiliza o conceito de eficiência acumulada, onde quanto mais o testador
é familiarizado com o sistema, menos tempo ele leva para executar os casos de teste. A
execução dos casos de teste é divida em Ciclos de Execução (CETs), é possível que quanto
mais tempo dure o ciclo, mais a equipe de teste fica eficiente.
O procedimento de estimativa leva em consideração essa premissa, de que o esforço
gasto na primeira CET pode ser utilizado para estimar o esforço das CETs posteriores.

34

No primeiro ciclo de execução, é feito um registro da média de passos de teste
executados por minuto em cada dia do ciclo e do número de casos de teste executados
naquele ciclo (Ntc). No final desse primeiro ciclo, deve-se calcular a média aritmética de
esforço do ciclo, que é o somatório do esforço de todos os dias da CET, dividido pelo número
de dias total, segundo a fórmula:

Essa fórmula retorna o número médio de passos por minuto daquela CET. Também
deve ser calculado o erro médio, conforme pode ser visto em Triola (2011), em
passos/minuto.
Em seguida deve-se obter a média aritmética ponderada (WEa) e a média da raíz
quadrada do erro médio (Erms), considerando que essa é a primeira iteração da técnica,
esses dois valores são semelhantes à média aritmética e ao erro médio, respectivamente.
O próximo passo é calcular o erro relativo (r), que serve como um complemento ao
esforço final, prevendo um pouco mais de tempo para evitar problemas. O erro relativo tem
a fórmula:

Deve-se ter disponível nesse passo, uma estimativa de números de passos de teste a
ser executados na próxima CET, que é chamado de S.
O esforço final a ser empregado na próxima CET é dado pela seguinte fórmula,
gerando uma medição em minutos:

É importante observar que nas próximas iterações da técnica a WEa e o Erms devem
ser calculados considerando os valores anteriores. A WEa é o somatório dos passos/minuto
das interações anteriores vezes o número de casos de teste e dividido pela soma dos
números de casos de teste, conforme a fórmula:

35

Já o Erms é dado pela seguinte fórmula, sendo n o número de CETs até o momento:

O conhecimento prévio do número de casos de teste a ser executado é de extrema
importância. A técnica não possui um comportamento regular caso existam mudanças
significativas nos times de teste entre as CETs, ou mesmo mudanças de características e tipo
de software.

2.10 -Estimativa Método Ponderado de Nageswaran
É uma técnica de estimativa baseada em casos de uso, que pode ser calculada no
início do ciclo de vida, assim que os casos de uso estiverem prontos. Segundo Almeida,
Abreu e Moraes (2009), um cenário de fluxo normal leva mais tempo para ser executado que
um fluxo de exceção.
O peso do caso de uso varia de acordo com a quantidade de cenários, a partir de
dados históricos, obteve-se que o tempo para projetar e implementar um cenário normal é
2,5 vezes maior do que um cenário de exceção (peso normal = 1; peso exceção=0,4).
O primeiro passo é identificar os atores do caso de uso e atribuir um peso conforme
segue na Tabela 18:
Tipo de ator

Descrição

Peso

Simples

Interação com o sistema através de interface gráfica.

1

Médio

Gerenciamento de dados e protocolos

2

Complexo

APIs ou interações de baixo-nível

3

Tabela 18: Pesos dos Tipos de Atores (traduzido).
Cada caso de uso possui cenários de validação e exceção, para obter o peso do caso
de uso, deve-se multiplicar a quantidade de cenários de validação por 1 mais a quantidade
de cenários de exceção multiplicados por 0,4, conforme a fórmula:

Os pontos de caso de uso não ajustados (PCUNA) são a soma do peso dos atores e o
peso do caso de uso.

36

O ajuste dos pontos de caso de uso se dá pela inclusão de fatores de ambiente, que
são relevantes para o escopo do caso de uso medido, como ferramentas, ambiente de
desenvolvimento, ambiente de teste, reutilização do testware e características de segurança.
Obtemos primeiro o FTA (fatores técnicos do ambiente) através do somatório de todos os
fatores que influenciam o teste, multiplicando por 0 se o fator não está disponível ou 5 se
está disponível, com o peso da sua importância conforme é dado pela Tabela 19:
Nomenclatura

Descrição

Peso

Inócuo

Não deve ser levado em conta nos testes

0

Dispensável

Não é importante ter esse fator

1

Desejável

Os testes seriam melhores se esse fator estivesse disponível

2

Necessário

É importante ter esse fator

3

Essencial

É primordial para o teste

4

Tabela 19: Classificação dos fatores de ambiente (traduzido).
Finalmente os pontos por caso de uso ajustados (PCUA) são conseguidos através da
seguinte fórmula:

O esforço final é calculado, baseado em fatores históricos, assumindo que 3 horas
são necessárias para planejar, escrever e executar 1 ponto de caso de uso, é o fator de
conversão que assume que o processo de teste é automatizado e controlado, do contrário, o
fator assumido deve ser 7,5. A fórmula do esforço a seguinte:

A técnica sugere que sejam incluídos mais 5% pela complexidade do projeto e 5%
para o gerenciamento do projeto, ou seja, mais 10% do esforço encontrado.

37

3 -Protocolo de quasi-Revisão Sistemática
Este capítulo está dividido em oito seções. A seção 3.1 descreve o cenário de
investigação principal do protocolo de quasi-Revisão Sistemática. A seção 3.2 apresenta o
protocolo de busca e está dividida nas subseções 3.2.1 que descreve o foco de interesse e
3.2.2 apresenta qualidade e amplitude da questão. A seção 3.3 trata da seleção de fontes e
está dividida nas subseções 3.3.1 que descreve a definição de critérios para seleção de
fontes, 3.3.2 que apresenta o idioma das fontes e 3.3.3 que traz a identificação das fontes. A
seção 3.4 cuida da seleção dos estudos e está dividida na subseção 3.4.1 responsável pela
definição dos estudos. A seção 3.5 apresenta os resultados da pré-execução, a seção 3.6
trata da estratégia para extração da informação, a seção 3.7 traz os critérios para avaliação
da qualidade dos artigos e por fim, a seção 3.8 representa a execução.

3.1 -Cenário de Investigação Principal
Atualmente no mercado não há técnicas de estimativa de esforço adotadas como
padrão para teste de software, existem muitas pesquisas e literaturas com abordagens
diferenciadas, mas que ainda não alcançaram a precisão esperada para realizar estimativa
de forma confiável. Existe ainda uma diferença entre estimar o esforço apenas para
execução dos casos de teste e para toda a fase de teste (planejamento, construção dos casos
de teste, execução dos casos de teste).
A maioria dos profissionais em teste de software utilizam uma base histórica ou a
experiência do testador para estimar o esforço na execução de casos de teste.
Esse tipo de estimativa depende de muitos fatores subjetivos. Por exemplo, uma
base histórica pode ter outliers, ou seja, valores que se distanciam muito da realidade. Um
caso de teste pode ser executado em mais ou menos tempo dependendo do conhecimento
do testador sobre aquele caso de teste. Outro exemplo seria a forma de armazenamento
dessas informações, um testador pode estar passando mal em determinado dia e levar mais
tempo para realizar uma tarefa do que levaria se estivesse bem disposto, e se estes dados
forem utilizados para realizar estimativas, é provável que o resultado não seja confiável.

38

Essas variações podem afetar o resultado da estimativa e causar problemas de
cronograma e alocação de recursos. Por esse motivo, existem técnicas sendo avaliadas e
melhoradas para proporcionar uma estimativa mais objetiva.
Para ter um gerenciamento mais eficiente da etapa de teste de software é necessário
estimar o quanto de esforço deverá ser empregado.

3.2 -Protocolo de Busca
O protocolo de revisão sistemática inicial é baseado em Biolchini et al., 2005. É
utilizada a abordagem PICO (Pai et al., 2004) para estruturar e organizar a string de busca.
Esta abordagem separa a questão em quatro partes: População (Population), Intervenção
(Intervention), Comparação (Comparison) e Saída (Outcome). Devido ao objetivo do estudo
não é possível aplicar nenhuma comparação. Portanto, é possível classificar esta revisão
como quasi-revisão sistemática (Travassos et al, 2008).

3.2.1 -Foco de Interesse
O objetivo deste estudo é caracterizar as técnicas de estimativa de esforço em
projetos de teste de software utilizadas em projetos de desenvolvimento e disponíveis na
literatura técnica.

3.2.2 -Qualidade e Amplitude da Questão
- Problema: dada a importância do teste de software no escopo de desenvolvimento,
é imprescindível saber estimar o esforço que será gasto nessa etapa para alocar
corretamente os recursos necessários e não ter problemas futuros em orçamento e pessoal,
fato que muitas vezes é responsável por produtos sendo colocados em produção sem terem
sido testados devidamente por conta de prazos.
- Questões:
Questão Principal: Quais técnicas de estimativa de esforço em projetos de
teste de software têm sido descritas na literatura técnica? Quais são suas
principais características?
Questão Secundária: Quais são suas principais características?

39

- Criação String de busca: As palavras chave que compõem a string de busca foram
baseada nos artigos de controle encontrados através de uma busca ad-hoc. Estes artigos
foram importantes para entender os termos utilizados pelos autores e forneceram um
parâmetro para a criação da string de busca. Ao realizar a extração das palavras chaves dos
artigos de controle pôde-se perceber que alguns artigos estavam indexados de forma
inconsistente nas máquinas de busca, pois as palavras chaves impressas no artigo não
correspondiam com as palavras chaves indexadas pelas máquinas de busca. Portanto, foi
realizado um trabalho no sentido de extrair as palavras chaves pelas quais as máquinas de
busca estavam indexando os artigos. Os seguintes artigos de controle foram utilizados:
Zhu, Xiaochun, et al., Estimate Test Execution Effort at an early Stage: An
Empirical Study, IEEE Journal, Cyberworlds, 2008 International Conference on,
2008.
Aranha, E., Borba, P., Test Effort Estimation Models Based on Test
Specifications, IEEE Journal on Selected Areas in Communications, Testing:
Academic and Industrial Conference Practice and Research Techniques MUTATION, 2007. TAICPART-MUTATION 2007, 2007.
de Almeida, E.R.C., de Abreu, B.T., Moraes, R., An Alternative Approach to
Test Effort Estimation Based on Use Cases, IEEE Journal, Software Testing
Verification and Validation, 2009. ICST '09. International Conference on, 2009.
Silva, D., de Abreu, B.T., Jino, M., A Simple Approach for Estimation of
Execution Effort of Functional Test Cases, IEEE Journal , Software Testing
Verification and Validation, 2009. ICST '09. International Conference on, 2009.
- População: Projetos e processos de software
Palavras Chave:
o software application, software development, software project,
software product, software process, software system, software
measurement, software approach, software management, software
metrics;
- Intervenção:
Questão Principal: Teste de software

40

Palavras Chave
o software testing, testing requirements, testing process, program
testing, reliability requirements, testing the software, testing
procedure, application testing, system testing, program testing;;
- Comparação: Nenhuma
- Saída: Estimativas de esforço para projetos de teste de software.
Palavras Chave:
o test effort estimation, estimating software testing efforts, test
estimation effort techniques, test execution effort estimation,
estimation of software testing efforts, test automation effort
estimation, test execution effort estimation models, estimating test
effort, execution effort of a test, estimate the required effort to test,
estimate the effort to execute the tests, test effort metrics;
- Efeito: Identificar estimativas de esforço para projetos de teste de software.
- Aplicação: Tornar a estimativa de esforço em projetos de teste de software mais
eficiente.
- Projeto Experimental: Nenhum método estatístico será aplicado.

3.3 -Seleção de Fontes
3.3.1 -Definição de Critérios para seleção de fontes
Artigos disponíveis na web através de máquinas de busca que permitam a pesquisa
de strings no abstract, título e palavra chave.

3.3.2 -Idioma das fontes
Inglês.

3.3.3 -Identificação das Fontes
- Método de pesquisa das fontes: busca no abstract, título e palavras chaves através
das máquinas de busca disponíveis.

41

String de busca: ("software application" OR "software development" OR
"software project" OR "software product" OR "software process" OR
"software system" OR "software measurement" OR "software approach" OR
“software management” OR “software metrics”) AND ("software testing" OR
"testing requirements" OR "testing process" OR "program testing" OR
"reliability requirements" OR "testing ate software" OR "testing procedure"
OR "application testing" OR "system testing" OR "program testing") AND
("best effort estimation" OR "estimating software testing efforts" OR "best
effort estimation techniques" OR "test execution effort estimation" OR
"estimation of software testing efforts" OR "test automation effort
estimation" OR "test execution effort estimation models" OR "estimating best
effort" OR "execution effort of e test" OR "estimate time required effort to
test" OR "estimate the effort to execute the tests" OR “test effort metrics”)
- Máquinas de busca:
Nome

Link

Scopus

http://www.scopus.com/

IeeeXplore

http://ieeexplore.ieee.org/

Tabela 20: Máquinas de busca utilizadas no protocolo de quasi-Revisão Sistemática.
String de busca Scopus: TITLE-ABS-KEY("software application" OR "software
development" OR "software project" OR "software product" OR "software
process" OR "software system" OR "software measurement" OR "software
approach" OR “software management” OR “software metrics”) AND
("software testing" OR "testing requirements" OR "testing process" OR
"program testing" OR "reliability requirements" OR "testing ate software" OR
"testing procedure" OR "application testing" OR "system testing" OR
"program testing") AND ("best effort estimation" OR "estimating software
testing efforts" OR "best effort estimation techniques" OR "test execution
effort estimation" OR "estimation of software testing efforts" OR "test
automation effort estimation" OR "test execution effort estimation models"
OR "estimating best effort" OR "execution effort of e test" OR "estimate time

42

required effort to test" OR "estimate the effort to execute the tests" OR “test
effort metrics”)
String de busca IEEE: ("software application" OR "software development" OR
"software project" OR "software product" OR "software process" OR
"software system" OR "software measurement" OR "software approach" OR
“software management” OR “software metrics”) AND ("software testing" OR
"testing requirements" OR "testing process" OR "program testing" OR
"reliability requirements" OR "testing ate software" OR "testing procedure"
OR "application testing" OR "system testing" OR "program testing") AND
("best effort estimation" OR "estimating software testing efforts" OR "best
effort estimation techniques" OR "test execution effort estimation" OR
"estimation of software testing efforts" OR "test automation effort
estimation" OR "test execution effort estimation models" OR "estimating best
effort" OR "execution effort of e test" OR "estimate time required effort to
test" OR "estimate the effort to execute the tests" OR “test effort metrics”)

3.4 -Seleção dos Estudos
3.4.1 -Definição dos estudos
- Definição dos critérios de inclusão e exclusão:
Critérios de inclusão:
o Tratar de testes de software; e
o Descrever técnicas de estimativa de esforço para testes de software; e
o Apresentar alguma demonstração (estudos de caso ou experimentos)
para as técnicas de estimativa de esforço propostas; e
o Apresentar referência bibliográfica que caracterize o critério
apresentado caso não seja de autoria.
Critérios de exclusão:
o Artigos que não tratam de técnicas de estimativa de esforço para
testes de software; ou
o Artigos que não estejam disponíveis por meio digital; ou

43

o Artigos publicados em idiomas diferentes do inglês;
- Procedimento para seleção de artigos
A seleção dos artigos será realizada por dois pesquisadores: Pesquisador A e
Pesquisador B (grande experiência).
O Pesquisador A realizará a leitura do título e abstract de todos os
documentos retornados pelas máquinas de busca. Os artigos serão
classificados com os seguintes status:
o Incluído: documentos que tratam de alguma forma de técnicas de
estimativa de esforço em projetos de teste de software;
o Excluído: documentos que não tratam de técnicas de estimativa de
esforço em projetos de teste de software;
o Dúvida: documentos em que o pesquisador teve dúvida se tratam de
alguma forma de técnicas de estimativa de esforço em projetos de
teste de software;
O Pesquisador B irá realizar a leitura do título e abstract dos documentos que
foram classificados com o status Dúvida e irá reclassificar estes documentos
como Incluído ou Excluído;
O Pesquisador A realiza a leitura de todos os documentos classificados como
Incluídos e os classifica como:
o Incluído: documentos que atendam os critérios de inclusão e não
atendam aos critérios de exclusão. Esses artigos vão ter suas
informações extraídas;
o Excluído: documentos que não atendam os critérios de inclusão ou
que atendam aos critérios de exclusão;
O mesmo processo pode ser representado pelo seguinte diagrama, Figura 5:

44

Figura 5: Diagrama do processo do protocolo de quasi-Revisão Sistemática

3.5 -Resultados da pré-execução
A Tabela 21 mostra os resultados da pré-execução.
Máquina de Busca

Número de artigos encontrados

Controles

Scopus

14

2

IeeeXplore

478

4

Total Bruto

492

-

Duplicados

8

-

Total

484

4

Tabela 21: Tabela com os resultados da pré-execução do protocolo de quasi-Revisão
Sistemática.

45

3.6 -Estratégia para Extração da Informação
Para cada artigo selecionado as informações contidas no Apêndice I – Modelo de
Formulário de Extração devem ser extraídas com a ajuda da ferramenta JabRef Reference
Manager.

3.7 -Critérios para Avaliação da Qualidade dos Artigos
Os critérios a seguir serão utilizados para avaliar a qualidade dos artigos
selecionados. O objetivo é identificar os artigos que possuem uma relação maior com o tema
que está sendo investigado e, com isto, terão maior confiabilidade no resultado final.
A. O artigo apresenta alguma prova de conceito? (1 pt)
B. O artigo caracteriza o software em que o critério pode ser aplicado? (2 pt)
C. O artigo utiliza metodologia e linguagem que facilita o entendimento (2 pt)
D. O artigo utiliza terminologia adequada? (1 pt)

3.8 -Execução
Data de Execução: 14/10/2011
Após o primeiro pesquisador avaliar os artigos seguindo os critérios de inclusão e
exclusão o resultado obtido foi o demonstrado na Tabela 22:
Status

Quantidade

Incluído

9

Dúvidas

7

Excluídos

464

Controles

4

Total

484

pelo primeiro pesquisador.

46

Como houve 7 artigos classificados com o status Dúvida um segundo pesquisador foi
envolvido. Após a avaliação do segundo pesquisador o seguinte resultado foi obtido, Tabela
23:
Status

Quantidade

Incluídos

15

Excluídos

465

Controles

4

Total

484

pelo segundo pesquisador.
Ao longo da do processo de leitura dos artigos, alguns artigos foram desconsiderados,
pois não atendiam aos critérios de inclusão/exclusão. O resultado final é representado na
Tabela 24.
Status

Quantidade

Leitura+Controle

19

Duplicado

5

Total

14

Tabela 24: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática.
Uma divisão por ano dos artigos que foram incluídos também foi realizada para
verificar em que período houve mais interesse em pesquisa por estimativa de esforço em
projetos de testes de software. A Figura 6 representa o resultado encontrado:

47

Figura 6: Gráfico dos períodos em que os artigos foram publicados
Em cada um dos artigos encontrados, pelo menos uma métrica era proposta. Foram
encontradas 15 métricas de estimativa de esforço para teste de software.
Em alguns casos, algumas métricas propostas eram variações de outras. Por exemplo,
Método de Nageswaran e Método Ponderado de Nageswaran cuja diferença está no
tratamento dado aos fluxos do caso de uso, onde os fluxos normais tem um peso maior que
os fluxos de exceção. Neste caso, foram consideradas 2 variações do critério. Assim, foram
encontradas um total de 4 variações. Portanto, caso as variações sejam consideradas, podese dizer que foram encontradas 19 maneiras diferentes para estimar esforço para teste de
software. No Apêndice II se encontram os artigos provenientes da quasi-Revisão Sistemática
e se respectivo status, Incluído ou Excluído.

48

4 -Survey
Este capítulo está dividido em três seções. A seção 4.1 trata da definição de survey. A
seção 4.2 apresenta os questionários utilizados nesse survey. Já a seção 4.3 trata dos
resultados encontrados.

4.1 -Definição de Survey
Um survey, segundo Mafra e Travassos (2006), é “uma investigação usada em
retrospecto”, ou seja, uma pesquisa realizada após determinada tecnologia ser utilizada para
avaliar seus resultados, ou como dizem os próprios autores, o survey permite capturar um
“retrato instantâneo” da situação.
Para esse projeto, foi realizado um survey para saber como os profissionais de teste
estimam o tempo a ser gasto com testes em um projeto.

4.2 -Questionários
Em um primeiro momento foi feito um questionário, conforme a Figura 7, em
português e lançado no Grupo DFTeste do Yahoo Grupos.

Figura 7: Questionário em português

49

O questionário, basicamente, pergunta se a empresa estima esforço de teste e qual
métrica utiliza para isso. Esse questionário teve 48 respostas de profissionais do Brasil, entre
26 de junho e 15 de outubro de 2012.
Outro questionário em inglês foi elaborado e divulgado nos grupos de Teste do
Linkedin, visando abranger mais profissionais e em diferentes países, Figura 8.

Figura 8: Questionário em inglês
A única diferença entre eles foi a inclusão da pergunta para identificar o país. Esse
questionário teve 52 respostas entre 15 de agosto de 2012 e 24 de outubro de 2012.

4.3 -Resultados
Tabulando os dados da pesquisa realizada no grupo de testes DFTeste com
profissionais brasileiros, chegou-se a conclusão de que, nessa amostra de 48 testadores,
aproximadamente 69% estimam esforço para teste de software, sendo a divisão por
métricas a seguinte:
57,58 % utilizam a experiência do testador;
24,24 % utilizam dados históricos;

50

9,09 % utilizam outra métrica;
3,03 % utilizam Análise por pontos de teste;
6,06 % utilizam Pontos de Execução;
0,00 % utilizam Pontos por Caso de Teste conforme pode ser visto na Figura 9.

Figura 9: Porcentagem de utilização das métricas (no Brasil)
Dos profissionais que responderam utilizar outro tipo de técnica, foram citadas:
50% do tempo utilizado para fazer a matriz de regras (começamos agora, é um
chute). Depois iremos utilizar base histórica;
Baseada na complexidade do caso de uso;
Quanto aos resultados da pesquisa em inglês realizada nos grupos de teste do
Linkedin, foi chegada à conclusão que, dessa amostra de dados, de 52 testadores,
aproximadamente 84% estimam esforço. Desses, a distribuição entre as técnicas é a
seguinte:
53,49% utilizam a experiência do testador;
25,58% utilizam dados históricos;
9,30% utilizam Pontos por Caso de Teste;
4,65% utilizam Pontos de Execução;
4.65% utilizam Análise por pontos de teste
2,33% utilizam outra métrica, conforme pode ser visto na Figura 10.

51

Figura 10: Porcentagem de utilização das métricas (outras partes do mundo)
Na Figura 12 pode-se obervar os resultados encontrados no mundo, incluindo o
Brasil.

Figura 11: Porcentagem de utilização das métricas (Brasil e outras partes do mundo)
Dos profissionais que responderam utilizar outro tipo de técnica, foi citada a técnica
WBS por um profissional da Índia.

52

Outros resultados importantes também foram: a quantidade de pessoas que estima
teste por país, conforme a Figura 12 e as técnicas utilizadas por país também, conforme a
Figura 13, todos os resultados baseados nessa amostra.

Figura 12: Empresas que estimam esforço para teste por país

Figura 13: Técnicas utilizadas por país
Pode-se observar que grande parte da amostra estima esforço para disciplina de
teste de software utilizando, principalmente, a experiência do testador e a base histórica de
dados da empresa.

53

A justificativa dos profissionais que responderam esse survey para o fato de que as
métricas de estimativa ainda são pouco utilizadas reside na dificuldade de se obter todas as
variáveis e pela complexidade de aplicação das mesmas.

54

5 -Prova de Conceito
Este capítulo está dividido em quatro seções. A seção 5.1 descreve as informações do
Sistema utilizado na prova de conceito. A seção 5.2 apresenta as técnicas que realizam
estimativas para todo o projeto de teste e está dividida nas subseções 5.2.1, Análise por
Pontos de Teste e 5.2.3, Estimativa Método Ponderado de Nageswaran. A seção 5.3 trata das
Estimativas de Esforço Parcial do Projeto de Teste e está dividida nas subseções 5.3.1,
Análise de Pontos por Caso de Teste (TCP) e 5.3.2, Estimativa baseada em Especificação de
Requisito Funcional e Eficiência Acumulada. Por último, a seção 5.4 traz as conclusões da
aplicação de cada técnica nessa prova de conceito.

5.1 -Informações da Prova de Conceito
Algumas técnicas foram aplicadas utilizando um domínio de um Sistema Escola. A
Figura 14 representa os casos de uso desse domínio. No Apêndice III têm-se as Regras de
Negócio do domínio, no Apêndice VI a Descrição dos Casos de Uso Efetuar Login e Manter
Alunos, no Apêndice V os Casos de Teste derivados desses casos de uso, no Apêndice VI as
Evidências de execução dos testes realizados com sucesso e no Apêndice VII os testes que
falharam.

Figura 14: Casos de Uso Sistema Escola
A prova de conceito foi realizada em cima de um domínio CRUD de um sistema Escola
que possui os casos de uso Efetuar Login e Manter Alunos.

55

A fins de comparar o resultado gasto para testar esse domínio, efetivamente, e o
valor que cada estimativa fornece, toda a fase de teste foi realizada e o tempo registrado,
como segue na Tabela 25:

Tarefa

Tempo gasto
(minutos)

Plano de Testes

30

Elaborar Casos de Teste

50

Executar os Casos de Teste

20

Reportar os erros/Gerar
evidências

30

Elaborar Relatórios sucesso/erro

23

Total

153

Tabela 25: Tempo gasto para realizar cada atividade de Teste.
Foram gastos 153 minutos que equivalem a 2 horas e 30 minutos de 1 analista de
teste para executar todos os processos que envolvem a fase de teste, ou seja 2,5
homens/hora.
Algumas técnicas, como a estimativa a partir de Bases Históricas, Ad-Hoc e Pontos de
Execução não foram aplicadas porque dependem de um conhecimento prévio das médias
históricas de execução de casos de teste de uma equipe, informações que não se econtram
disponíveis nesse experimento.
As estimativas foram divididas entre aquelas que estimam o esforço total do projeto
de teste, desde a fase de planejamento até o report de erros, e as que estimam apenas o
esforço de execução de casos de teste.

56

5.2 -Estimativas de Esforço Total do Projeto de Teste
5.2.1 -Análise de Pontos de Teste
Para simular a medição em pontos de teste, em primeiro lugar, o domínio Sistema
Escola foi medido em pontos de função, conforme pode ser observado na Tabela 26.

#

Processo
Elementar
ou Grupo
de Dados

Tipo

1

Arquivo
Aluno

2

Depois da Melhoria
TD

AR/TR

Complex.

PF

ALI

9

1

Baixa

7

Inserir

EE

13

1

Baixa

3

3

Alterar

EE

5

1

Baixa

3

4

Excluir

EE

1

1

Baixa

3

5

Listar

CE

7

1

Baixa

3

6

Logar

EE

3

1

Baixa

3

7

Desconectar

EE

1

1

Baixa

3

8

Total

25

Tabela 26: Estimativa do Domínio Sistema Escola em Pontos de Função.
Nesse caso o tipo de contagem é um Projeto de Desenvolvimento cujo escopo
abrange as funcionalidades de Logar e Deslogar, do caso de uso Efetuar Login; e Inserir,
Alterar, Excluir e Listar um aluno, do caso de uso Manter Alunos.
Para aplicação dessa abordagem foram utilizados 3 meios de cálculo. Um utilizando
uma planilha montada a partir da técnica descrita em Veenendaal e Dekkers (1999), outra
utilizando uma planilha gerada pelo Serviço Federal de Processamento de Dados (SERPRO) e
a ferramenta APT disponibilizada pela Comunidade de Testadores.
As características comuns utilizadas foram as seguintes, a equipe de teste é muito
experiente, não existe ferramenta de automação para especificação e execução dos testes, a

57

equipe está familiarizada com os testes, são seguidos padrões e templates e realizadas
revisões, as linguagens utilizadas são de 3ª e 4ª gerações, o ambiente de teste já foi utilizado
inúmeras vezes e existem materiais de teste que podem ser reutilizados. A equipe de teste
possui 1 técnico e não são utilizadas ferramentas de registro de tempo, gerência de testes,
gerência de defeitos e de configuração. Na Figura 15 têm-se as características de cada
função específica.

Figura 15: Características de cada função do Domínio Sistema Escola.
A medição realizada pela planilha que utiliza a descrição da técnica original
encontrou 3 horas e 32minutos para preparação, especificação, execução e conclusão dos
testes, conforme pode ser visto no Apêndice VIII, sendo que esse tempo ficou dividido da
seguinte maneira, descrita na Tabela 27:
Tarefa

Tempo estimado (horas)

Preparação - 10%

0,3

Especificação - 40%

1,3

Executar Testes - 45%

1,5

Conclusão - 5%

0,2

Preparação - 10%

0,3

Total

3,3

Tabela 27: Tempo gasto para realizar cada atividade de Teste segundo APT.

58

A planilha utilizada no SERPRO estimou 4 horas de teste, resultado que tem a
disparidade quanto à primeira medição explicada pelos pesos que são dados as
características de performance e segurança, a performance tem peso 0.05 ao invés de 0.1 e
segurança tem peso 0.1 ao invés de 0.05, como ocorre na técnica original, considerando
assim que segurança tem importância maior que performance e também por incluir ao valor
original uma porcentagem referente à etapa de Revisão. Os detalhes podem ser observados
no Apêndice IX, o tempo total foi dividido da seguinte maneira como na Tabela 28:
Tarefa

Tempo estimado
(horas)

Planejar Testes - 10%

0,3

Projetar e Implementar Testes - 15%

0,5

Projetar e Implementar Testes - 20%

0,7

Executar Testes - 45%

1,5

Avaliar Resultados - 10%

0,3

Horas de Revisão
Revisão dos Artefatos de Planejamento - 20% do
planejamento

0,1

Revisão dos Artefatos de Projeto - 40% do projeto

0,1

Revisão dos Artefatos de Projeto - 40% da
implementação

0,2

Revisão dos Artefatos de Avaliação - 20% da
avaliação

0,3

4

Total

Tabela 28: Tempo gasto para realizar cada atividade de Teste segundo APT (planilha
SERPRO).
O terceiro mecanismo utilizado retornou 47 minutos de teste, apresentando um
afastamento maior dos valores citados acima, fato explicado pela forma que a ferramenta
calcula o número de pontos de teste dinâmicos sem levar em consideração os pontos de
função específicos de cada funcionalidade medida. O Apêndice X demonstra o resultado da
ferramenta.

59

Na estimativa em homens/hora, temos que na planilha baseada na técnica original
são necessários 3,3 homens/hora, na planilha do SERPRO, 4 homens/hora e na ferramenta
de APT 0,78 homens/hora.

5.2.2 -Estimativa Método Ponderado de Nageswaran
No domínio do Sistema Escola, o ator interage com o sistema através de uma
interface gráfica. Dos 9 cenários identificados, 6 são de fluxo comum e 3 de exceção. Os
fatores técnicos de ambiente podem ser observados na Tabela 29.
Fator
Ambiente de
Teste

Disponibilidade
Totalmente
Disponível

Documentação Totalmente
de Teste
Disponível

Classificação

Valor da
Disponibilidade

Valor da
Classificação

É primordial

5

4

É importante

5

3

Tabela 29: Descrição dos Fatores Técnicos de Ambiente.
A Figura 16 demonstra que a estimativa retornou 61,5 homens/hora de teste,
assumindo que 7,5 horas são necessárias para planejar, escrever e executar 1 ponto de caso
de uso devido ao processo não ser automatizado.

Figura 16: Homens/hora totais de teste.

60

5.3 -Estimativas de Esforço Parcial do Projeto de Teste
Para as estimativas de execução de casos de teste, é necessário que já exista uma
descrição de Casos de Teste, que constam no Apêndice III.

5.3.1 -Análise de Pontos por Caso de Teste (TCP)

Figura 17: Medição em Pontos por Caso de Teste.
Conforme pode ser observado na Figura 17, para cada caso de teste se tem um ou
mais resultados esperados, que são os checkpoints. Na coluna de pré-condições têm-se os
níveis de complexidade referentes aos casos de teste e simples dados são necessários e
podem ser criados durante o tempo de execução do caso de teste. Foi considerada a
medição para um teste funcional e que são necessários 0,2 minutos para executar 1 ponto
de caso de teste, já que, historicamente, levou-se 20 minutos para executar 24 casos de
teste - 0,8 min para cada um e que 1 caso de teste tem 4,04 pontos. Segundo essa técnica
são necessários 19,4 minutos para executar essa suíte de casos de teste, ou seja, 0,32
homens/hora.

61

5.3.2 -Estimativa baseada em Especificação de Requisito Funcional e
Eficiência Acumulada

Figura 18: Medição em Especificação de Requisito Funcional e Eficiência Acumulada.
Conforme pode ser visto na Figura 18, para essa estimativa, os 24 casos de teste
foram divididos em 2 ciclos, o primeiro com 4 casos de teste e o segundo com 20. No
primeiro ciclo de execução, foi simulada uma média de passos de teste por minuto, sendo no
primeiro dia de 2 passo/minuto (Ef(d)1 = 2) e no segundo dia de 4 passos/minuto (Ef(d)2 =
4), tendo sido executados 4 casos de teste nesse ciclo.
A média aritmética do esforço desse ciclo foi de 3 passos/minuto e o erro médio de
1,5 passos/minuto. Como é a primeira iteração do ciclo, a média aritmética ponderada e a
raiz média quadrada do erro médio são semelhantes à média aritmética e ao erro médio.
O erro relativo encontrado foi de 1,9% e no ciclo 2 serão executados 93 passos. O
esforço final encontrado para executar o ciclo 2 é de 31min 58 seg. Como no primeiro ciclo
foram gastos 5 minutos, o tempo total de execução dos casos de teste é de 36 minutos e 58
segundos, ou seja, 0,61 homens/hora.

5.4 -Considerações sobre as medições
As técnicas utilizadas para mensurar toda a atividade de teste apresentaram
estimativas que superaram o valor real de esforço empregado em cerca de 1 hora, as
diferenciações encontradas se devem ao fato de que as diferentes formas de medição

62

utilizadas levam em consideração que determinada característica tem peso maior que outra,
como foi o caso da medição utilizando a planilha do SERPRO, que estimou 4 homens/hora, e
a Planilha da técnica original, que estimou 3,3 homens/hora. Além disso, a planilha utilizada
pelo SERPRO inclui ao valor original uma porcentagem referente à etapa de Revisão.
Já a ferramenta APT, disponibilizada pela Comunidade Testadores, estimou 0,78
homens/hora devido às diferenças que sua implementação apresenta em relação à técnica
original, a ferramenta calcula o número de pontos de teste dinâmicos sem levar em
consideração os pontos de função específicos de cada funcionalidade medida.
O Método Ponderado de Nageswaran apresentou grande disparidade em relação às
outras técnicas, segundo ela seriam necessários 70 homens/hora para testar esse domínio
CRUD, quando o real gasto foi de 2,5 homens/hora. Essa extrema diferenciação deve-se ao
fato de que poucos fatores são levados em consideração, nesse caso apenas ambiente e
documentação de teste, e que a técnica afirma que são necessárias 7,5 horas para testar
cada ponto de caso de uso quando a execução é manual, valor que pode variar de acordo
com a experiência do testador e não poderia ser fixado.
Já as técnicas que estimam o esforço de execução dos casos de teste dependem da
descrição dos casos de teste e se baseiam em dados históricos de execuções anteriores para
realizar a estimativa dos seguintes. A Análise de Pontos por Caso de Teste seriam
necessários 0,32 homens/hora para executar os 24 casos de teste em questão, lembrando
que essa técnica se baseia na experiência do testador para encontrar quantos minutos ele
gasta para executar 1 TCP, tendo assim variação de estimativa dependendo do
testador/equipe.
Na Estimativa baseada em Especificação de Requisito Funcional e Eficiência
Acumulada os casos de teste são divididos em ciclos. O primeiro ciclo é utilizado como base
histórica para os demais. Segundo ela, para executar os casos de teste 5 a 24 serão
necessários aproximadamente 31 minutos, levando em consideração a base histórica, o
primeiro ciclo, com os casos de teste 1 a 4 levou 5 minutos para ser executado, toda suíte
seria estimada em aproximadamente 36 minutos, que são 0,61 homens/hora.
Comparando os valores que realmente foram gastos para executar o teste nesse
experimento, que foi de 0,33 homens/hora, pode-se observar que a Análise de Pontos por

63

Caso de Teste foi a que mais se aproximou do valor real. Já a Estimativa baseada em
Especificação de Requisito Funcional e Eficiência Acumulada apresentou o dobro do esforço
real, o que pode ser atribuído ao fato de que a técnica não leva em consideração fatores
como o tipo de teste e os dados de teste por exemplo.
De todas as técnicas apresentadas a que mais se aproximou do esforço real foi a
Análise de Pontos por Caso de Teste, quando se trata da execução, e a Planilha da técnica
original de APT.

64

6 - Conclusão
Este capítulo está dividido em três seções. A seção 6.1 apresenta as considerações
finais, a seção 6.2 apresenta as contribuições e, finalmente, a seção 6.3 sugere trabalhos
futuros.

6.1 -Considerações Finais
Esse projeto apresentou algumas técnicas existentes na literatura acadêmica e
utilizadas no mercado para estimar o esforço a ser gasto em projetos de teste de software.
Algumas ainda se encontram em experimentação e outras já são conhecidas dos
profissionais de teste, porém atualmente não se considera um padrão para realizar a
estimativa, visto a complexidade de coleta das variáveis utilizadas e da aplicação das
próprias estimativas. Através do survey realizado com profissionais de algumas partes do
mundo, pode-se observar que a maioria utiliza a experiência em testes passados para
estimar o esforço de atividades de teste futuras.
Além das métricas descritas no projeto, pode-se observar através do protocolo de
quasi-Revisão Sistemática que existem estudos na área visando conseguir uma precisão
maior para a estimativa através de diversos tipos de tecnologia e aplicações, como por
exemplo, Inteligência Artificial.
Por fim, os resultados da prova de conceito mostraram que a técnica Análise de
Pontos por Caso de Teste, utilizada para estimar apenas a fase de execução dos casos de
teste, apresentou um valor bem próximo do real, já que quanto menor for o escopo da
estimativa, menos variáveis são envolvidas e as chances de acerto maiores. Já as técnicas
que estimam esforço para todo o projeto de teste, dado o grande número de variáveis que
muitas vezes são difíceis de quantificar, como a experiência do testador, por exemplo, a
disparidade encontrada é maior.

6.2 -Contribuições
Esse trabalho trouxe um exemplo prático de utilização de diferentes métricas de
estimativa de esforço para projetos de teste de software através da prova de conceito,

65

demonstrando algumas técnicas e suas aplicações e disparidades na estimativa de esforço,
além de trazer, no protocolo de quasi-Revisão Sistemática, uma lista de artigos com várias
outras técnicas que se encontram em fase de estudos.
Além disso, foi possível identificar e comunicar a Comunidade Testadores sobre a
diferença encontrada na implementação da Ferramenta APT em relação à técnica original.

6.3 -Trabalhos Futuros
Como pôde ser observado através do protocolo de quasi-Revisão Sistemática,
existem diversas técnicas para estimar o esforço gasto em teste de software sendo
estudadas, e através da prova de conceito ficou claro que essas estimativas podem não ser
suficientemente precisas. Como trabalhos futuros pode-se apresentar um experimento in
vivo utilizando as técnicas citadas nesse projeto assim como as outras técnicas presentes na
quasi-Revisão Sistemática e propor melhorias para tornar as estimativas mais consistentes.

Referências Bibliográficas
AGAPITO,

R.

Ferramenta

de

APT.

Testadores,

2012.

Disponivel

em:

<http://www.testadores.com/index.php/web-links/40-programas/365-analise-de-pontosde-teste-v104>. Acesso em: 10 mar. 2012.
ARANHA, E.; BORBA, P. Empirical Studies of Test Execution Effort Estimation Based on Test
Characteristics

and

Risk

Factors,

2007.

Disponivel

em:

<http://toritama.cin.ufpe.br/twiki/pub/SPG/SoftwareEstimationModels/idoese2007aranha_final.pdf>. Acesso em: 22 abr. 2012.
BIOLCHINI, J. et al. Systematic Review in Software Engineering. COPPE/UFRJ. Rio de Janeiro,
p. 30. 2005.
GUERREIRO, D. E. S.; T., B. D. A. A Simple Approach for Estimation of Execution Effort of
Functional

Test

Cases.

IEE

Computer

Society,

2009.

Disponivel

em:

<http://www.computer.org/portal/web/csdl/doi/10.1109/ICST.2009.47>. Acesso em: 22
abr. 2012.
JABREF Reference Manager. JabRef. Disponivel em: <http://jabref.sourceforge.net/>. Acesso
em: 01 out. 2012.
LAGARES, V.; ELIZA, R. Estimativa X Teste de Software: Como uma estimativa pode ajudar no
gerenciamento do Teste de Software. Java Magazine, n. 92, p. 58-66, 2011.
LOPES, F. A.; NELSON, M. A. V. nálise das Técnicas de Estimativas de Esforço para o Processo
de

Teste

de

Software,

2008.

Disponivel

em:

<http://ebts2008.cesar.org.br/artigos/EBTS2008Analise_das_Tecnicas_Estimativas_de_Esfor
co.pdf. Acessado em: 13/09/2011>. Acesso em: 13 set. 2011.
MAFRA, S. N.; TRAVASSOS, G. H. Estudos Primários e Secundários apoiando a busca por
Evidência em Engenharia de Software. COPPE/UFRJ. Rio de Janeiro, p. 32. 2066.
NGUYEN, V.; PHAM, V.; LAM, V. Test Case Point Analysis: An Approach to Estimating
Software

Testing

Size,

2009.

Disponivel

em:

<http://www-

scf.usc.edu/~nguyenvu/papers/TR-TCPA-01-2012.pdf>. Acesso em: 10 abr. 2012.

PAI, M. M.; M, G. Systematic Reviews and meta-analyses: An illustrated, step-by-step
guide. The National Medical Journal of India. [S.l.]. 2004.
R. C., É. D. A.; MORAES, R.; T., B. D. A. An Alternative Approach to Test Effort Estimation
Based

on

Use

Cases.

IEEE

Explorer,

2009.

Disponivel

em:

<http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4815360&url=http%3A%2F%2Fiee
explore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4815360>. Acesso em: 22 abr.
2012.
TRAVASSOS, G. H. et al. An Environmente to Support Large Scale Experimentation in
Software Engineering. 13th IEEE International Conference on Engineering of Complex
Computer Systems. Belfast: IEEE. 2008. p. 193-202.
TRIOLA, M. F. Introdução A Estatística. 10ª Edição. ed. São Paulo: LTC, 2011.
VEENENDAAL, E. V.; DEKKERS, T. Test point analysis: a method for test estimation, 1999.
Disponivel

em:

<http://www.vietnamesetestingboard.org/zbxe/?document_srl=22272>.

Acesso em: 15 maio 2012.

Apêndice I – Modelo de Formulário de Extração
Informações Gerais
Título

Título do artigo.

Autores

Lista dos autores

Ano de Publicação

O ano que o artigo foi publicado

Fonte de Publicação

Nome da Conferência, Periódico ou Revista que o
artigo foi publicado.

Resumo

O resumo completo do artigo.

Avaliação
Status

Se o artigo foi Incluído ou Excluído

Critério de Exclusão

Se o artigo foi excluído, informar por qual critério
de exclusão.

Estudos Empíricos
Contexto da Avaliçao Empírica
O que?

O objeto de estudo.

Quem?

Os participantes envolvidos no estudo.

Onde?

O local onde o estudo é realizado.

Quando?

A situação temporal em que o estudo seja
realizado.

Por quê?

Razões para a execução do estudo.

Tipo do Estudo Empírico
Tipo da Avaliação Empírica

O tipo de estudo empírico utilizado para propor
as métricas de estimativa de esforço em teste de
software. As opções são: prova de conceito,
estudo de caso, survey e experimento controlado.

Design Experimental
Número de Participantes

Total de participantes envolvidos no estudo.

Número de Grupos

Total de número de grupos em que os
participantes foram separados.

Número de Participantes em cada Número de participantes por grupo
Grupo
Fator e Tratamento

Número e descrição dos fatores e tratamentos.

Design do Estudo

Descrição sobre a organização dos assuntos e os
tratamentos do estudo.

Resultados de Estudo
Hipóteses

Hipóteses nulas do estudo.

Descrição sobre ameaças à validade
do estudo.
Resultados

Estatíscos

Avaliações Empíricas

das Para cada hipótese e tratamentos envolvidos, os
resultados da avaliação estatística devem ser
descritos.

Ameaças à Validade

Descrição sobre ameaças à validade do estudo.

Atributos das Métricas
Variáveis da métrica

A lista das variáveis que a métrica utiliza e,
correspondentemente, propriedades.

Descrição das Variáveis

A descrição de cada variável utilizada na métrica.

Apêndice II – Artigos do protocolo de quasi-Revisão
Sistemática
Título
A discrete software reliability growth model with testing effort
A metric suite for early estimation of software testing effort using requirement
engineering document and its validation

Status

A Simple Approach for Estimation of Execution Effort of Functional Test Cases
A Multi-objective Particle Swarm Optimization for Test Case Selection Based on
Functional Requirements Coverage and Execution Effort

Incluído

An experience-based approach for test execution effort estimation
An Alternative Approach to Test Effort Estimation Based on Use Cases
Estimate test execution effort at an early stage: An empirical study
An Estimation Model for Test Execution Effort
Optimal software release using time and cost benefits via fuzzy multi-criteria and fault
tolerance

Incluído

Software testing sizing in incremental development: A case study
An Experience-Based Approach for Test Execution Effort Estimation
Machine learning methods and asymmetric cost function to estimate execution effort
of software testing

Incluído

The COTECOMO: COnstractive Test Effort COst MOdel
On estimating testing effort needed to assure field quality in software development
Measuring Program Similarity: Experiments with SPEC CPU Benchmark Suites
Enhancement of Bug Tracking Tools; the Debugger
Multidimentional size measure for design of component-based software system
A method for a priori implementation effort estimation for hardware design
The personal software process: experiences from Denmark
On the Accuracy of Spectrum-based Fault Localization
Practical change impact analysis based on static program slicing for industrial software
systems
Automating Function Points analysis based on functional and non functional
requirements text
Path-based error coverage prediction
Estimating the Cost of Developing Customizations to Packaged Application Software
Using Service Oriented Architecture

Incluído
Incluído

Incluído
Incluído
Incluído
Incluído
Incluído
Incluído
Incluído
Incluído
Incluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído

A GP effort estimation model utilizing line of code and methodology for NASA software
projects
Excluído

Measuring and Enhancing Prediction Capabilities of Vulnerability Discovery Models for
Apache and IIS HTTP Servers

Excluído

Software effort estimation by tuning COOCMO model parameters using differential
evolution

Excluído

Standard multispectral environment and effects model (STMEEM)
Test effort estimation-particle swarm optimization based approach
Quantitative Quality Assurance Approach
On the false path problem in hard real-time programs
Performance Evaluation of Windowing Approach on Effort Estimation by Analogy
Benefits of a TPS virtual layer
Release planning under fuzzy effort constraints
COTS Integrations: Effort Estimation Best Practices
Test Effort Estimation Models Based on Test Specifications
Test blueprint: an effective visual support for test coverage
State Estimation Simulation for the Design of an Optimal On-Line Solution
Applying Test-First and Parallel Processing Techniques to ERP Data Conversion
Parameter tuning of evolutionary algorithm by Meta-EAs for WCET analysis
The role of modeling in the performance testing of e-commerce applications
Using Evolutionary Testing to Find Test Scenarios for Hard to Reproduce Faults
Measures of testability as a basis for quality assurance
Reliability-growth analysis for an Ada-coding process
TUPUX: An Estimation Tool for Incremental Software Development Projects
Single event upset test structures for digital CMOS application specific integrated
circuits
Tightly-coupled image-aided inertial relative navigation using Statistical Predictive
Rendering (SPR) techniques and a priori world Models
Does ""Depth"" Really Matter? On the Role of Model Refinement for Testing and
Reliability

Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído

Comparing fault-proneness estimation models
MedIGrid: a medical imaging application for computational Grids
A Constructive RBF Neural Network for Estimating the Probability of Defects in
Software Modules

Excluído

Predicting software defects: A cost-sensitive approach
Building Scalable Failure-proneness Models Using Complexity Metrics for Large Scale
Software Systems

Excluído

The Soft Computing Approach to Program Development Time Estimation
Degrees of consciousness for reuse of software in practice: Maintainability, balance,
standardization

Excluído

Excluído
Excluído

Excluído

Excluído

Applying event-condition-action mechanism in healthcare: a computerised clinical testordering protocol system (TOPS)
Excluído

Design of a mission management system for the autonomous underwater vehicle
MARIUS
Object oriented metrics useful in the prediction of class testing complexity

Excluído
Excluído

Using empirical testbeds to accelerate technology maturity and transition: the SCRover
experience
Excluído
An enhanced technique for generating hybrid coverage test cases using activity
diagrams
Excluído
Adaptive least mean square behavioral power modeling
Excluído
Simulation-Based Timing Analysis of Complex Real-Time Systems
Excluído
Automated System Testing Using Visual GUI Testing Tools: A Comparative Study in
Industry
Excluído
An overview of Lutess a specification-based tool for testing synchronous software
CARIAL: Cost-Aware Software Reliability Improvement with Active Learning
A blended approach to course design and pedagogy to impart soft skills: An IT
company's experiences from software engineering course

Excluído
Excluído
Excluído

A software falsifier
Excluído
Real-Time Synchronization on Multiprocessors: To Block or Not to Block, to Suspend or
Spin?
Excluído
NSTB version 2 flight test results
A cost model for determining the optimal number of software test cases
Deadline analysis of interrupt-driven software
Cost excessive paths in cloud based services
Knowledge evaluation procedure based on concept maps
A trade-off method between cost and reliability
OpenRDK: A modular framework for robotic software development
Processor allocation in parallel systems
Modeling maintenance effort by means of dynamic systems
Dynamic model for maintenance and testing effort
Experiences in implementation and use of the square root information filter/smoother
for orbit determination
Achieving composability in NoC-based MPSoCs through QoS management at software
level
Automatic, Selective and Secure Deletion of Digital Evidence
Impact of programming and application-specific knowledge on maintenance effort:A
hazard rate model
Optimizing and simplifying software metric models constructed using maximum
likelihood methods

Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído
Excluído

Integrating generalized Weibull-type testing-effort function and multiple change-points
into software reliability growth models
Excluído
A Study of Applying Extended PIE Technique to Software Testability Analysis
Excluído
An Investigation of Software Effort Phase Distribution Using Compositional Data
Excluído

Métricas para estimativa de esforço em projetos de teste de software

Métricas para estimativa de esforço em projetos de teste de software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (14)

Similaire à Métricas para estimativa de esforço em projetos de teste de software

Similaire à Métricas para estimativa de esforço em projetos de teste de software (20)

Plus de Samanta Cicilia

Plus de Samanta Cicilia (20)

Métricas para estimativa de esforço em projetos de teste de software