UNIVERSIDADE DO GRANDE RIO
PROF. JOSÉ DE SOUZA HERDY
ESCOLA DE CIÊNCIA E TECNOLOGIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
...
UNIVERSIDADE DO GRANDE RIO
PROF. JOSÉ DE SOUZA HERDY
ESCOLA DE CIÊNCIA E TECNOLOGIA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
...
Métricas para Estimativa de Esforço em Projetos de Teste de
Software

Samanta Cicília de Barros Souza - 5304880

Projeto F...
Samanta Cicília de Barros Souza
Métricas para Estimativa de Esforço em Projetos de
Teste de Software, Duque de Caxias, 201...
Aos meus pais.
AGRADECIMENTOS

Em primeiro lugar a Deus, sem o qual nada disso seria possível, agradeço pela força e
pela graça concedida...
“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 ...
RESUMO
Planejar e programar as atividades de teste a serem realizadas é um fator
fundamental para garantir a qualidade de ...
SUMÁRIO
1 - Introdução ......................................................................................................
3.3.1 - Definição de Critérios para seleção de fontes....................................................... 40
3.3.2 - Id...
6.3 - Trabalhos Futuros .....................................................................................................
LISTA DE FIGURAS
Figura 1: Visão Geral da Técnica de Análise de Pontos de Teste (VEENENDAAL, 1999) ......... 20
Figura 2: ...
LISTA DE TABELAS
Tabela 1: Peso da importância das funcionalidades para o usuário.

21

Tabela 2: Peso da intensidade de u...
Tabela 27: Tempo gasto para realizar cada atividade de Teste segundo APT.

57

Tabela 28: Tempo gasto para realizar cada a...
LISTA DE ABREVIATURAS E SIGLAS

1. AIE – Arquivo de Interface Externa.
2. ALI – Arquivo Lógico Interno.
3. APT – Análise d...
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 –...
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 tra...
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 p...
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 ...
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 eleme...
21

Intensidade de uso (Uy): utilização daquela função por intervalo de tempo;
Interface (I): quantidade de arquivos utili...
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 f...
23

Peso

Descrição

0

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

3

A qualidade dos requi...
24

algumas regras que seguem nas tabelas abaixo, a Tabela 6 sobre as ferramentas de teste, a
Tabela 7 sobre os testes de ...
25

4

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

8

Sistema desenvolvido em uma linguage...
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...
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 é u...
28

O próximo passo é atribuir a classificação referente aos dados que são necessários
para execução dos casos de teste, q...
29

Como os diferentes tipos de teste apresentam complexidades diferentes, a técnica
apresenta um fator de ajuste a partir...
30

operar, por exemplo, navegadores, sistemas
operacionais ou hardware.
Tabela 17: Pesos dos Tipos de Teste (traduzido).
...
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 execut...
32

Figura 3: Atribuindo os pontos de execução para cada passo do caso de teste (ARANHA,
2007).
Cada um dos passos é anali...
33

Figura 4: Estimativa do esforço em homens/hora (ARANHA, 2007).
Como pode ser visto na Figura 4, dados históricos são u...
34

No primeiro ciclo de execução, é feito um registro da média de passos de teste
executados por minuto em cada dia do ci...
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 ca...
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 cas...
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 d...
38

Essas variações podem afetar o resultado da estimativa e causar problemas de
cronograma e alocação de recursos. Por es...
39

- Criação String de busca: As palavras chave que compõem a string de busca foram
baseada nos artigos de controle encon...
40

Palavras Chave
o software testing, testing requirements, testing process, program
testing, reliability requirements, t...
41

String de busca: ("software application" OR "software development" OR
"software project" OR "software product" OR "sof...
42

required effort to test" OR "estimate the effort to execute the tests" OR “test
effort metrics”)
String de busca IEEE:...
43

o Artigos publicados em idiomas diferentes do inglês;
- Procedimento para seleção de artigos
A seleção dos artigos ser...
44

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

3.5 -Resultados da pré-execução
A Tabela 21 ...
45

3.6 -Estratégia para Extração da Informação
Para cada artigo selecionado as informações contidas no Apêndice I – Model...
46

Como houve 7 artigos classificados com o status Dúvida um segundo pesquisador foi
envolvido. Após a avaliação do segun...
47

Figura 6: Gráfico dos períodos em que os artigos foram publicados
Em cada um dos artigos encontrados, pelo menos uma m...
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 ...
49

O questionário, basicamente, pergunta se a empresa estima esforço de teste e qual
métrica utiliza para isso. Esse ques...
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 %...
51

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

Outros resultados importantes também foram: a quantidade de pessoas que estima
teste por país, conforme a Figura 12 e ...
53

A justificativa dos profissionais que responderam esse survey para o fato de que as
métricas de estimativa ainda são p...
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 util...
55

A fins de comparar o resultado gasto para testar esse domínio, efetivamente, e o
valor que cada estimativa fornece, to...
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 pont...
57

equipe está familiarizada com os testes, são seguidos padrões e templates e realizadas
revisões, as linguagens utiliza...
58

A planilha utilizada no SERPRO estimou 4 horas de teste, resultado que tem a
disparidade quanto à primeira medição exp...
59

Na estimativa em homens/hora, temos que na planilha baseada na técnica original
são necessários 3,3 homens/hora, na pl...
60

5.3 -Estimativas de Esforço Parcial do Projeto de Teste
Para as estimativas de execução de casos de teste, é necessári...
61

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

Figura 18: Medição em Especi...
62

utilizadas levam em consideração que determinada característica tem peso maior que outra,
como foi o caso da medição u...
63

Caso de Teste foi a que mais se aproximou do valor real. Já a Estimativa baseada em
Especificação de Requisito Funcion...
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 a...
65

demonstrando algumas técnicas e suas aplicações e disparidades na estimativa de esforço,
além de trazer, no protocolo ...
Referências Bibliográficas
AGAPITO,

R.

Ferramenta

de

APT.

Testadores,

2012.

Disponivel

em:

<http://www.testadores...
PAI, M. M.; M, G. Systematic Reviews and meta-analyses: An illustrated, step-by-step
guide. The National Medical Journal o...
Apêndice I – Modelo de Formulário de Extração
Informações Gerais
Título

Título do artigo.

Autores

Lista dos autores

An...
Design Experimental
Número de Participantes

Total de participantes envolvidos no estudo.

Número de Grupos

Total de núme...
Apêndice II – Artigos do protocolo de quasi-Revisão
Sistemática
Título
A discrete software reliability growth model with t...
Measuring and Enhancing Prediction Capabilities of Vulnerability Discovery Models for
Apache and IIS HTTP Servers

Excluíd...
Design of a mission management system for the autonomous underwater vehicle
MARIUS
Object oriented metrics useful in the p...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Métricas para estimativa de esforço em projetos de teste de software
Upcoming SlideShare
Loading in...5
×

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

5,470

Published on

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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,470
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
209
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

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

  1. 1. 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
  2. 2. 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 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
  3. 3. Métricas para Estimativa de Esforço em Projetos de Teste de 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
  4. 4. Samanta Cicília de Barros Souza 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)
  5. 5. Aos meus pais.
  6. 6. 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!
  7. 7. “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
  8. 8. 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.
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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 Tabela 23: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática 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
  14. 14. 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
  15. 15. 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.
  16. 16. 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. 17. 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. 18. 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. 19. 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. 20. 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. 21. 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 A importância dessa função com relação às outras é normal Alta 12 A importância dessa função com relação às 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 O grau de interface associado com a função é normal. Alta 8 O grau de interface associado com a função é alta. Tabela 3: Peso da interface das funções. Complexidade Peso Descrição
  22. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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. 37. 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. 38. 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. 39. 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. 40. 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. 41. 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. 42. 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. 43. 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. 44. 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. 45. 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 Tabela 22: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática pelo primeiro pesquisador.
  46. 46. 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 Tabela 23: Tabela com os resultados da execução do protocolo de quasi-Revisão Sistemática 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. 47. 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. 48. 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. 49. 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. 50. 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. 51. 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. 52. 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. 53. 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. 54. 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. 55. 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. 56. 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. 57. 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. 58. 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. 59. 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. 60. 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. 61. 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. 62. 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. 63. 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. 64. 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. 65. 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.
  66. 66. 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.
  67. 67. 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.
  68. 68. 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.
  69. 69. 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.
  70. 70. 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
  71. 71. 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
  72. 72. 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

×