FACULDADE FARIAS BRITO CIÊNCIA DA...
66
FACULDADE FARIAS BRITO CIÊNCIA DA COMPUTAÇÃO Samantha Kelly Soares de Almeida ENGENHARIA DE SOFTWARE EXPERIMENTAL APLICADA À MELHORIA DO PROCESSO DE TESTE Fortaleza, 2010
Transcript of FACULDADE FARIAS BRITO CIÊNCIA DA...
FACULDADE FARIAS BRITO
CIÊNCIA DA COMPUTAÇÃO
Samantha Kelly Soares de Almeida
ENGENHARIA DE SOFTWARE EXPERIMENTAL APLICADA
À MELHORIA DO PROCESSO DE TESTE
Fortaleza, 2010
Samantha Kelly Soares de Almeida
ENGENHARIA DE SOFTWARE EXPERIMENTAL APLICADA
À MELHORIA DO PROCESSO DE TESTE
Monografia apresentada para obtenção dos créditos da
disciplina Trabalho de Conclusão do Curso da Faculdade
Farias Brito, como parte das exigências para graduação no
Curso de Ciência da Computação.
Orientador: Roberto de Almeida Façanha, Msc.
Fortaleza, 2010
ENGENHARIA DE SOFTWARE EXPERIMENTAL APLICADA
À MELHORIA DO PROCESSO DE TESTE
Samantha Kelly Soares de Almeida
PARECER___________________
NOTA: FINAL (0 - 10): ________
Data: ____/ ____/ ________
BANCA EXAMINARADORA:
__________________________
Nome e Titulação
(Orientador)
__________________________
Nome e Titulação
(Examinador)
__________________________
Nome e Titulação
(Examinador)
RESUMO
O presente trabalho demonstrou como os conceitos presentes na Engenharia de
Software Experimental possibilitaram a melhoria do processo de testes em uma organização
de desenvolvimento de softwares. Para tanto, foi desenvolvido um experimento que originou
uma nova forma de testar aplicações de software denominada Preteste. Com essa metodologia
foi observada uma significativa melhoria dos indicadores de Produtividade e de Densidade de
Defeitos, alvos do estudo da pesquisa. Foi verificado que uma etapa complementar à fase de
testes de software, o Preteste, favorece a liberação do sistema com mais qualidade para a
etapa de testes sistêmicos, diminuindo o retrabalho e a identificação tardia de defeitos graves,
bem como melhorando a produtividade, da densidade de defeitos do projeto, e redução do
custo de correção dos defeitos a nível organizacional. Para auxiliar a execução do processo
modelado foi desenvolvida a ferramenta PretestResults, visando contribuir para o registro de
defeitos realizado por múltiplas pessoas e para a geração automática de relatórios de Preteste.
Palavras chave: Engenharia de Software Experimental, Preteste, Densidade de Defeitos,
Produtividade.
AGRADECIMENTOS
A Deus por ter me iluminado e por estar sempre presente na minha vida.
Aos meus pais e meu noivo pelo incentivo, dedicação e confiança.
Ao meu orientador pela compreensão e confiança.
Aos meus colegas e professores do curso que contribuiram com minha formação profissional.
A todos aqueles que de forma direta ou indireta, colaboraram para a conclusão deste trabalho.
SUMÁRIO MOTIVAÇÃO/JUSTIFICATIVA ...................................................................................................................... 14
OBJETIVOS ............................................................................................................................................. 15
Objetivo Geral ................................................................................................................................ 15
Objetivos Específicos ...................................................................................................................... 15
1.1 ENGENHARIA DE SOFTWARE ................................................................................................................. 16
1.1.1 Processo de Software ............................................................................................................ 18
1.1.2 Engenharia de Software Experimental.................................................................................. 19
1.2 TESTES DE SOFTWARE ......................................................................................................................... 22
1.2.1 Conceitos e Importância de Testes ........................................................................................ 22
1.2.2 Tipos de Teste ....................................................................................................................... 23
1.3 QUALIDADE DO PRODUTO DE SOFTWARE ............................................................................................... 24
1.3.1 Conceitos e Estratégias Principais ......................................................................................... 24
2.1 CARACTERIZAÇÃO DO DOMÍNIO DE EXPERIMENTAÇÃO ............................................................................... 28
2.1.1 Campo Laboral ...................................................................................................................... 28
2.1.2 Políticas de Qualidade da Organização Estudada ................................................................ 29
2.1.3 Principais Atividades do Processo de Teste da Empresa Estudada ....................................... 30
2.2 DETALHAMENTO DO CENÁRIO DO PRETESTE ............................................................................................ 32
2.2.1 Introdução ....................................................................................................................... 32
2.2.2 Caracterização do Cenário do Experimento .................................................................... 32
2.3 ANÁLISE DO PROCESSO DE TESTES DA ORGANIZAÇÃO SELECIONADA ........................................................ 35
2.3.1 Relação do Preteste com a ESE ............................................................................................. 35
2.4 APLICAÇÃO DO PRETESTE NO CAMPO LABORAL ........................................................................................ 36
2.4.1 Identificação da Necessidade ................................................................................................ 36
2.4.2 Etapas do Preteste ................................................................................................................ 38
2.4.3 Objetivo do Preteste .............................................................................................................. 40
3.1 RESULTADOS DOS EXPERIMENTOS ..................................................................................................... 46
3.1.1 Evolução de Indicadores de Produtividade Sem Preteste ................................................ 46
3.1.2 Evolução de Indicadores de Densidade e Defeitos Sem Preteste .................................... 48
3.1.3 Resultados da Execução do Experimento Preteste ............................................................... 50
3.1.4 Evolução de Indicadores de Produtividade com a Aplicação do Presteste............................ 52
3.1.5 Evolução dos Indicadores de Defeitos com a Aplicação do Presteste ................................... 54
3.2 FERRAMENTA PRETESTRESULTS ............................................................................................................ 56
3.2.1 Objetivo ................................................................................................................................. 56
3.2.2 Apresentação da Ferramenta ............................................................................................... 56
3.2.3 Principais Dificuldades e Lições Identificadas ....................................................................... 57
4.1 PRINCIPAIS CONTRIBUIÇÕES ................................................................................................................. 59
4.2 SUGESTÕES DE TRABALHOS FUTUROS .................................................................................................... 59
LISTA DE FIGURAS
FIG. 1 – PRIMEIRA VERSÃO DO PROCESSO PRETESTE ............ ERRO! INDICADOR NÃO DEFINIDO.
FIG. 2 – FLUXO DO PROCESSO PRETESTE .................................. ERRO! INDICADOR NÃO DEFINIDO.
FIG. 3 – TELA DA FUNCIONALIDADE RELATÓRIO DE CONFIABILIDADE DA FERRAMENTA
PRETESTRESULTS ............................................................................ ERRO! INDICADOR NÃO DEFINIDO.
LISTA DE GRÁFICOS
GRÁFICO 1 – REGRA DE 10 DE MYERS.........................................................................................................22
GRÁFICO 2 – EVOLUÇÃO DA PRODUTIVIDADE NO PROJETO A ANTERIOR AO PRETESTE ............ 47
GRÁFICO 3 – EVOLUÇÃO DA PRODUTIVIDADE NO PROJETO A ANTERIOR AO PRETESTE ............ 48
GRÁFICO 4 – EVOLUÇÃO DA PRODUTIVIDADE NO PROJETO B ANTERIOR AO PRETESTE ............ 48
GRÁFICO 5 – EVOLUÇÃO DA DENSIDADE DE DEFEITOS NO PROJETO A ANTERIOR AO PRETESTE
............................................................................................................................................................................... 49
GRÁFICO 6 – EVOLUÇÃO DA DENSIDADE DE DEFEITOS NO PROJETO B ANTERIOR AO PRETESTE
............................................................................................................................................................................... 49
GRÁFICO 7 – ESFORÇO PARA A REALIZAÇÃO DE TESTES (A) SEM PRETESTE E (B) COM
PRETESTE ........................................................................................... ERRO! INDICADOR NÃO DEFINIDO.
GRÁFICO 8 – QUANTIDADE DE DEFEITOS ANTECIPADOS COM O PRETESTE... ERRO! INDICADOR
NÃO DEFINIDO.
GRÁFICO 9 – QUANTIDADE DE DEFEITOS IDENTIFICADOS .. ERRO! INDICADOR NÃO DEFINIDO.
GRÁFICO 10 – EVOLUÇÃO DA PRODUTIVIDADE DA DISCIPLINA DE TESTES NO PROJETO A
.............................................................................................................. ERRO! INDICADOR NÃO DEFINIDO.
GRÁFICO 11 – EVOLUÇÃO DA PRODUTIVIDADE DA DISCIPLINA DE TESTES NO PROJETO B
.............................................................................................................. ERRO! INDICADOR NÃO DEFINIDO.
GRÁFICO 12 – EVOLUÇÃO DO INDICADOR DE DENSIDADE DE DEFEITOS NO PROJETO A ... ERRO!
INDICADOR NÃO DEFINIDO.
GRÁFICO 13 – EVOLUÇÃO DO INDICADOR DE DENSIDADE DE DEFEITOS NO PROJETO B ... ERRO!
INDICADOR NÃO DEFINIDO.
LISTA DE TABELAS
TABELA 1 - TABELA QUE REPRESENTA A MACRO DIVISÃO DOS TIPOS DE TESTE. ............... ERRO!
INDICADOR NÃO DEFINIDO.
TABELA 2 - PROCESSOS DA QUALIDADE COMPREENDIDOS PELA TRILOGIA JURAN ........... ERRO!
INDICADOR NÃO DEFINIDO.
TABELA 3 – EQUIPE PARTICIPANTE DO EXPERIMENTO ........ ERRO! INDICADOR NÃO DEFINIDO.
TABELA 4 – PRINCIPAIS PROBLEMAS QUE INTERFEREM NA PRODUTIVIDADE DA EQUIPE DE
TESTES ................................................................................................ ERRO! INDICADOR NÃO DEFINIDO.
TABELA 5 – PRINCIPAIS PROBLEMAS QUE INTERFEREM NA PRODUTIVIDADE DA EQUIPE DE
TESTES E GERAM AUMENTO DA DENSIDADE DE DEFEITOS. ..................... ERRO! INDICADOR NÃO
DEFINIDO.
TABELA 6 – RESULTADOS DO EXPERIMENTO PRETESTE ..... ERRO! INDICADOR NÃO DEFINIDO.
LISTA DE SIGLAS
ESE - ENGENHARIA DE SOFTWARE EXPERIMENTAL
P&D - PESQUISA E DESENVOLVIMENTO
CMMI - CAPABILITY MATURITY MODEL INTEGRATION
ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION 9001:2000
RFID - RADIO FREQUENCY IDENTIFICATION
TUCP - PONTOS DE CASOS DE USO TÉCNICOS
CRUD - CREATE, RETRIEVE, UPDATE, DELETE
12
INTRODUÇÃO
A Engenharia de Software Experimental, subárea da Engenharia de Software,
pode ser entendida como uma ferramenta utilizada para execução de experimentos em
processos de software (TRAVASSOS,2002). Através do uso da experimentação, pode-se
analisar o grau de eficiência de mudanças significativas, e utilizar esses resultados para
aperfeiçoar o processo, contribuindo assim para a melhoria da qualidade do produto.
De acordo com Holanda (1988), “Experimentação é o ato de experimentar...”,
e “... experimentar é submeter à experiência, por a prova, testar...”, ou seja, o ato de testar e
buscar comprovação para as hipóteses formuladas.
Galilei (1932) afirmou que existe uma resposta adequada para todas as coisas,
desde que se possa usar a razão para formular nossos questionamentos e considerar
experimentos para comprová-los, sendo seus resultados superiores a qualquer argumento
humano. Para Davies (1990), a base do método científico é a construção de uma teoria e, para
se construir uma teoria axiomaticamente, entende-se que é necessária a formulação de
hipóteses que precisam ser analisadas e comprovadas ou descartadas. Por este motivo, o
processo de experimentação desempenha um papel fundamental dentro da ciência.
Para evidenciar a importância da experimentação na ciência, Travassos (2002)
afirma que:
“Experimentação é o centro do processo científico. Somente experimentos verificam
teorias. Somente experimentos podem explorar os fatores críticos e dar luz a um
fenômeno novo para que as teorias possam ser formuladas e corrigidas.
Experimentação oferece o modo sistemático, disciplinado, computável e controlado
para a avaliação da atividade humana. Novos métodos, técnicas, linguagens e
ferramentas não deveriam apenas ser sugeridas, publicados ou apresentados para
venda sem experimentação ou validação”.
13
A experimentação é uma técnica importante para a evolução da produção de
software dentro dos mais variados domínios de aplicação. Wohlin (2000) nos lembra que
existem quatro métodos importantes para se conduzir experimentos dentro da Engenharia de
Software: científico, de engenharia, experimental e analítico (WOHLIN, 2000 apud
TRAVASSOS, 2002).
Na Engenharia de Software, Gattaz (2000) afirma que existe a necessidade da
melhoria contínua do processo de produção, para propiciar a evolução da qualidade do
produto de software. Similarmente a Gattaz, Travassos (2002) ressalta que um dos principais
fatores que contribui para a necessidade de evolução contínua do processo de produção e do
produto é a competição por mercado.
Somando-se os conceitos de experimentação e engenharia de software surgiu a
Engenharia de Software Experimental (ESE) lançada no ano de 1999 pelo estudioso Claes
Wohlin e tem como objetivo a “... aplicação do método científico (indução de base
experimental), para (i) exprimir quantitativamente relações de causa-efeito entre
características do processo de desenvolvimento de software e a qualidade dos produtos e (ii)
compreender as virtudes e limitações de métodos, técnicas e ferramentas” (ABREU, 2005).
Para Sommerville (2003), o processo de software “é um conjunto de atividades
e resultados associados que produzem um produto de software”. Esse Processo de Software é
composto por vários outros processos.
Pretendeu-se, com este projeto, utilizar a Engenharia de Software Experimental
a fim de realizar experimento controlado no processo de teste de uma organização de
desenvolvimento de software proeminente, com intuito de adaptar e aperfeiçoar o processo
para a realidade de dois projetos desenvolvidos na instituição selecionados como campo
laboral. O desenvolvimento do trabalho visa buscar e identificar melhorias que possam ser
aproveitadas pela instituição e analisar se a ESE pode ser utilizada como parte da estratégia
para evolução de processos de software.
14
Motivação/Justificativa
Com a evolução do mercado de software, surge a necessidade da melhoria
contínua dos processos como forma de alcançar uma melhor qualidade dos produtos para
atender às exigências dos clientes. Na busca de se manter competitivas e aprimorar a
qualidade de seus produtos, as instituições da área têm buscado aperfeiçoar o seu processo de
teste devido à sua ênfase primordialmente na avaliação da qualidade do produto (RUP, 2002;
DONEGAN et al, 2005).
A área de qualidade de software pode ser divida em duas subáreas: qualidade
do processo e qualidade do produto. O presente trabalho se propõe a realizar um experimento
buscando aprimorar a primeira subárea a fim de contribuir também para a melhoria da
segunda, pois segundo Sommerville (2003) a melhoria do processo implica diretamente na
melhoria do produto final (SOMMERVILLE, 2003).
De acordo com Rios (2007; p.20) “... as dimensões de qualidade só podem ser
alcançadas quando o teste de software é executado com um processo próprio...” e esse
processo necessita ser evoluído como os demais que compõem todas as fases de produção
(RIOS, 2007).
A escolha do tema se justifica pelo fato da engenharia de software
experimental possibilitar a execução de experimentos orientados e controlados a fim de que se
possa avaliar seus efeitos e validar ou descartar hipóteses levantadas (TRAVASSOS, 2002).
Para permitir que se possa executar e avaliar a eficácia de idéias e práticas para a melhoria
dos processos de software.
O campo laboral selecionado foi uma empresa de desenvolvimento de software
voltada principalmente para projetos em P&D (Pesquisa e Desenvolvimento).
A seleção do Processo de Teste e do campo laboral ocorreu devido à
necessidade de melhoria dos indicadores que medem a densidade dos defeitos encontrados em
testes sistêmicos e da produtividade das atividades de teste de dois projetos de
desenvolvimento de software na instituição. Este indicador é composto pela análise da
quantidade e criticidade dos defeitos identificados durante um ciclo de teste sistêmico. A
15
produtividade é medida baseada na base histórica da instituição orientada por linhas de base
de desempenho organizacional. Com base nessa necessidade observou-se a possibilidade da
utilização da ESE para solução do problema.
Com o objetivo de promover uma melhoria do processo de testes e qualidade
dos produtos, desenvolveu-se um experimento denominado Preteste que, diferentemente dos
demais tipos de teste, foca o fluxo básico de casos de uso, visando a identificação antecipada
de defeitos graves.
Objetivos
Objetivo Geral
O objetivo geral do projeto é aplicar conceitos da Engenharia de Software
Experimental sobre o processo padrão de testes de uma organização de desenvolvimento de
software com o objetivo de melhorar índices dos indicadores de teste e produtividade.
Objetivos Específicos
Compreender a importância da Engenharia de Software Experimental
aplicada a processos de testes e, conseqüentemente, na melhoria de
processos de software;
Identificar, no processo de testes da instituição selecionada como
campo laboral, oportunidades de aplicação de experimentos da ESE;
Reduzir os índices dos indicadores de Densidade de Defeitos e
Produtividade, a partir da incorporação do Preteste ao processo de
testes padrão da organização;
16
1 REFERENCIAL TEÓRICO
Este capítulo objetiva apresentar o referencial teórico que serviu de base para o
desenvolvimento da pesquisa.
1.1 Engenharia de Software
Surgiu a aproximadamente três décadas, por volta do ano de 1967, diante das
dificuldades de desenvolver produtos de software de qualidade frente ao aumento da demanda
no mercado. Cria-se, assim, uma fase simbolizada pela incapacidade de produção que
atendesse às necessidades das organizações. Essa fase foi denominada de Crise de Software,
que emergira no fim da década de 1970. Dentre as principais causas dessa crise estão: a
complexidade dos problemas a ser resolvida, a carência de técnicas estabelecidas para o
desenvolvimento de produtos que atendessem às expectativas dos usuários e a própria
complexidade do processo de desenvolvimento do software (DESCHAMPS,2008).
Engenharia de Software consiste na aplicação de uma abordagem disciplinada,
sistemática e quantificável aos princípios da ciência da computação. Além disso, ela
compreende o estudo e a busca por abordagens para o desenvolvimento de atividades
relacionadas à área de software (FUNKS,2002).
Segundo PURRI (2006), a Engenharia de Software representa o
estabelecimento de princípios científicos juntamente com métodos para a implementação
eficaz de processos, técnicas e ferramentas para a construção do produto.
17
O objetivo principal dessa ciência é oferecer as melhores práticas para o
desenvolvimento de software, além de apresentar alternativas para o gerenciamento do
processo de desenvolvimento, conhecidos como modelos ou metodologias.
Apesar da Engenharia de Software já existir há cerca de três décadas, os
problemas ressaltados pela Crise do Software continuam até hoje. Boa parte das técnicas,
metodologias e ferramentas desenvolvidas através de seu estudo, ainda é algo distante da
realidade de muitas empresas voltadas para o desenvolvimento de software (DESCHAMPS,
2008).
Por conta da abrangência da Engenharia de Software, surgem diversos
problemas durante a construção do produto tais como (MENDONÇA, 2008):
Existe um número enorme de variáveis envolvidas;
Seus efeitos são mal compreendidos e modelados;
Existem poucos modelos;
Existe pouca compreensão dos limites de tecnologias;
Existe pouca análise e experimentação controlada
Pode-se lidar com essas questões através de 4(quatro) formas de pensamento.
O paradigma científico, de engenharia, analítico e o experimental (WOHLIN, 2000 apud
TRAVASSOS, 2002).
Para Travassos (2002), o “método científico observa o mundo, mede e analisa,
verifica as hipóteses do modelo ou da teoria...”. O método de engenharia observa as soluções
existentes, sugere as soluções mais adequadas, desenvolve mede e analisa e repete até que
nenhuma melhoria adicional seja possível. O Paradigma Analítico é fundamentado na
matemática, propõe uma teoria formal ou um conjunto de axiomas, deriva matematicamente
um conjunto de resultados e é à base da ciência da computação.
18
Já o Paradigma Experimental até então discutido e que é o foco desse trabalho
propõe:Observação do mundo ou soluções existentes;
Um novo modelo de comportamento ou solução melhor;
Medir e analisar modelo experimentalmente;
Validar (ou refutar) hipóteses e modelos;
Repetir o processo para evoluir o conhecimento.
De acordo com Travassos (2002), “os objetivos relacionados à execução de
experimentos em engenharia de software experimental são a caracterização, avaliação,
previsão, controle e melhoria a respeito de produtos, processos, recursos, modelos, teorias...”.
Cada etapa exige um nível de esforço superior a anterior e a mais completa de todas é a etapa
de melhoria que pressupõe que podemos caracterizar, avaliar, predizer e controlar um
experimento propondo ainda melhorias através desse experimento, a um produto ou processo.
Portanto ao longo do desenvolvimento desse estudo será utilizada como objetivo a melhoria.
Ainda em concordância com Travassos (2002), a realização de um estudo
experimental envolve uma série de passos: a observação, a construção de um projeto
experimental, a coleta de dados, a análise dos dados de forma qualitativa ou quantitativa e a
avaliação do processo e produtos que estão sob experiência.
1.1.1 Processo de Software
O “Processo de Software é um conjunto de atividades e resultados associados
que produzem um produto de software.” Dentro do âmbito de desenvolvimento este processo
orienta os passos para a execução de determinada atividade com certo grau de maturidade.
(SOMMERVILLE, 2004).
Pressman (2003) apud Pinheiro (2008) defende que um processo de software
pode ser entendido como um framework para as tarefas que são necessárias para a construção
de software de alta qualidade.
19
Na organização estudada os processos definem a forma de trabalho de seus
colaboradores; fatos que ocorrem durante a produção, que não estejam de acordo com os
processos, podem ter dois tratamentos: a) requerem uma adaptação ao processo para aquela
determinada situação ou b) são registrados como não-conformidades ao processo pelo grupo
de qualidade institucional. Com isso percebe-se a importância do processo dentro da
corporação.
1.1.2 Engenharia de Software Experimental
A Engenharia de Software Experimental (ESE) é uma subárea da engenharia
de software e tem como objetivos o aprimoramento de técnicas e a verificação de hipóteses
surgidas na própria engenharia de software. (DANDOLINI, 2006).
Existem diversos autores que definem o termo Engenharia de Software.
Considerando-se como exemplo o autor Mendonça (2008) tem-se: “... a disciplina que estuda
o desenvolvimento e a manutenção de software em escala industrial possuindo métodos,
técnicas e ferramentas para gerência, desenvolvimento, manutenção, reengenharia, e
componentização de software”.
No dia a dia da engenharia de software surgem diversos questionamentos,
como por exemplo: será que a linguagem utilizada é a mais adequada para determinada
situação? Até que ponto a etapa de teste contribui para a melhoria da qualidade do produto?
Alguns desses questionamentos podem ser mais bem entendidos e até solucionados através da
aplicação de métodos experimentais para validarem tais hipóteses.
Para Travassos (2002), o método experimental sugere o modelo, desenvolve o
método qualitativo e/ou quantitativo, aplica um experimento, mede, analisa e avalia o modelo.
Segundo ele é o ideal para se lidar com a engenharia, pois agrupa “a proposição e a avaliação
do modelo com estudos experimentais”.
Para Mendonça (2008), deve-se pensar a engenharia de software de forma
experimental para melhor aproveitar seus recursos, podendo utilizar as seguintes abordagens:
20
Realizar uma revisão sistemática: agrupar, selecionar e sumarizar as
idéias de um conjunto de autores sobre um determinado assunto
gerando resultados repetíveis;
Fazer um levantamento de campo (survey): são coletadas amostras
com intuito de melhor entender o ambiente ou população de onde as
amostras foram retiradas e os dados obtidos facilitam a aplicação do
pensamento lógico (BABBIE, 2001);
Executar um estudo de caso: consiste na “observação detalhada de
um contexto ou indivíduo, de uma única fonte de documentos ou de um
acontecimento específico” (BODGAN e BIKLEN et al., 1994);
Desenvolver um experimento controlado: A idéia de um
experimento científico controlado é reproduzir as condições necessárias
por uma teoria e manipular as variáveis relevantes com objetivo de
medir e proporcionar análise de parâmetros dessa teoria (MONTILIVI,
2003).
Wohlin (2004) apud Mendonça (2008) defende que a abordagem científica
para a realização de experimentos deve responder a três questionamentos:
a) Quais são seus objetivos e qual é o seu problema?
b) Existe evidência na literatura e como esta se aplica ao seu problema?
c) Se não existe a evidência suficiente, que tipo de avaliação experimental se
deve fazer?
A esta abordagem científica dá-se o nome de Engenharia de Software
Experimental.
Barros (2007) afirma que “Um estudo experimental tem como objetivo colher
dados, em um ambiente controlado, para confirmar ou rejeitar a hipótese”.
21
Experimentos são definidos por Kerlinger (1973) como:
“Um experimento é um tipo de pesquisa científica na qual um pesquisador manipula e
controla uma ou mais variáveis independentes e observa a variação na variável ou
variáveis dependentes concomitantemente à manipulação das variáveis
independentes”.
Para o entendimento da forma de utilização da experimentação na Engenharia
de Software, deve-se compreender o paradigma experimental proposto por Travassos (2002)
que fala:
Para entender uma disciplina é necessária a construção de modelos, não
só de produtos, mas também de processos e domínios de aplicação;
Para testar se nossa compreensão está correta precisam-se testar estes
modelos, isto implica em experimentação;
Ao se analisar resultados experimentais aprendem-se e encapsula-se
este conhecimento em modelos mais evoluídos;
Segundo o autor esse paradigma pode ser utilizado nas mais diversas áreas de
conhecimento, e é definido pelo ciclo: “modelar, experimentar, aprender”.
Propõe-se ainda nesse trabalho que seja acrescentado mais um passo ao ciclo
que é reusar. Acredita-se que o reuso das informações aprendidas com o experimento bem
como o reuso das técnicas utilizadas para o desenvolvimento do próprio experimento,
possibilitam não somente a reutilização do aprendizado como a possibilidade de refazer o
experimento gastando um esforço inferior ao da primeira realização.
Existem dois tipos de estudos possíveis na ESE o estudo observacional, no
qual não ocorre qualquer intervenção do pesquisador e o estudo experimental, voltado ao teste
de hipóteses com abordagem quantitativa gerando experimentos controlados.
Este trabalho segue o modelo de estudo experimental através da análise
quantitativa que possui medição controlada, objetividade orientada à verificação, e pela
22
avaliação do processo de teste e dos produtos de software gerados em dois projetos que
constituem o cenário laboral.
1.2 Testes de Software
1.2.1 Conceitos e Importância de Testes
O teste do software é um processo realizado pelo testador que tem como
insumo outros processos como a especificação de requisitos, a modelagem e codificação, até
que se chegue à execução do teste propriamente dito.
Geralmente entende-se que a atividade de teste serve para demonstrar o correto
funcionamento de um programa, mas na verdade ele é utilizado como um processo que busca
identificar defeitos (RIOS, 2007).
Um defeito em um produto pode trazer muitas conseqüências indesejadas,
dentre as quais a própria inutilização do produto. Isso gera perda de esforço, de tempo e
dinheiro para a instituição que o produziu e para o cliente que a solicitou. Rios (2007) defende
que, no mundo do software quanto mais cedo se identifica um problema mais rápido e mais
barato é sua solução. (Gráfico 1 – Regra de 10 de Myers).
Gráfico 1 – Regra de 10 de Myers. Fonte: Rios (2007 p.19)
Como vimos no gráfico 1 a Regra de 10 Myers afirma que quanto mais tarde o
defeito é identificado mais cara será sua correção. Portanto, os ciclos de teste que compõem a
23
execução de todo o processo em cada nova versão da aplicação têm um papel fundamental na
garantia da qualidade do produto e redução do custo.
Como se entende claramente que um produto defeituoso não pode ser
considerado de boa qualidade é extremamente importante que após a codificação exista a
execução de baterias de teste visando identificar os problemas, para que estes possam ser
corrigidos, melhorando a qualidade do produto e mantendo-se positivo o grau de satisfação do
cliente.
1.2.2 Tipos de Teste
O teste é uma forma de buscar melhorar a qualidade de um software. Para
tanto, existem diversas formas de se testar um produto (RIOS, 2007).
A macro divisão dos tipos de teste se dá em duas categorias: os testes caixa
branca em que se pode observar o código (Ex: testes de unidade), e os testes caixa preta nos
quais se observam apenas, a aplicação e a base de dados (Ex: testes sistêmicos) (ROCHA,
2007). A Tabela 1 ilustra essa classificação para cada tipo de teste:
Tabela 1 - Tabela que representa a macro divisão dos tipos de teste
Testes Tipos de Testes
Teste de Unidade Caixa-Branca
Teste de Integração Caixa-Branca e Preta
Teste Funcional Caixa-Preta
Teste de Aceitação Caixa-Preta
Teste de Regressão Caixa-Branca e Preta
Teste de Cobertura Caixa-Branca e Preta Fonte: Rocha (2007)
Rios (2007 p. 255-258) define os principais tipos de teste como sendo:
Teste de Unidade: Estágio mais baixo da escala de testes. Eles são
aplicados aos menores componentes de código criados, visando que
esses atendam as especificações de características e funcionalidade.
24
Teste de Integração: É executado em uma combinação de
componentes para verificar se, integrados, eles funcionam
corretamente, ou seja, para assegurar que as interfaces funcionam
corretamente e que os dados são processados conforme o especificado.
Teste Sistêmico Funcional: É realizado pelos testadores para verificar
se o sistema está fazendo exatamente o que foi especificado.
Teste de Aceitação: Teste feito pelo cliente para validar a liberação do
software para produção.
Teste de Regressão: Retesta partes já testadas em ciclos anteriores e
objetiva garantir a integridade da aplicação após a adição de novos
componentes. Essa regressão pode ser total onde será retestado todo o
software, ou apenas parcial em que parte do produto será retestada.
Existem ainda, segundo Rios (2007), dois testes utilizados em domínios de
aplicação em que o volume de dados é elevado e necessita-se garantir esse requisito na
aplicação. São os testes de desempenho e de volume. No de desempenho, visa-se mostrar se o
produto consegue manter seu tempo de resposta, mesmo com um grande volume de dados.
No caso do de volume, a aplicação é submetida ao limite de dados especificados em seus
requisitos e é analisado seu comportamento.
Os tipos de teste a serem utilizados dependem diretamente do domínio de
aplicação a ser testado e do processo de teste definido na instituição.
1.3 Qualidade do Produto de Software
1.3.1 Conceitos e Estratégias Principais
Os conceitos de Qualidade têm evoluído por mais de cinqüenta anos, criando
um sentido mais amplo, dependente do ambiente onde é analisado. Tais conceitos continuam
com sua validade e são utilizados mundialmente como direcionadores de projetos de
25
Qualidade nas organizações (DANIELEWICZ, 2006). Alguns dos principais conceitos de
Qualidade são:
"Qualidade é a totalidade das propriedades e características de um produto ou serviço
que lhe conferem habilidade para satisfazer necessidades explícitas do cliente"
(Norma ISO 8402 - Vocabulário da Qualidade).
"Qualidade é adequação ao uso" (JURAN, 1992).
Segundo Juran (1992), a gerência da qualidade é realizada através de três
processos, que constituem a chamada “Trilogia Juran”:
Planejamento da Qualidade: consiste na atividade de desenvolver
produtos e processos exigidos para satisfazer as necessidades dos
clientes. Compreende uma série de passos, que resumidamente são:
estabelecer metas de qualidade; identificar os clientes; determinar as
necessidades dos clientes; desenvolver características do produto que
atendam às necessidades dos clientes; desenvolver processos que sejam
capazes de produzir aquelas características do produto; estabelecer
controles de processos e transferir os planos resultantes para forças
operacionais.
Controle da Qualidade: consiste nos passos de avaliar o desempenho
real de qualidade; comparar o desempenho real com as metas da
qualidade; agir a respeito da diferença.
Melhoramento da Qualidade: é o meio de elevar o desempenho da
qualidade a níveis sem precedentes. Consiste nos passos: constituir
uma infra-estrutura suficiente para garantir o melhoramento anual da
qualidade; identificar as necessidades específicas de melhoras;
estabelecer, para cada projeto, uma equipe com responsabilidades bem
definidas para levá-lo a uma conclusão de sucesso; prover recursos,
motivação e treinamentos de que as equipes necessitam para
diagnosticar causas, estimular os estabelecimento de remédios e
estabelecer controles para manter os ganhos.
26
A Tabela 2 mostra as atividades desenvolvidas durante as etapas de cada um
dos três processos para alcance da qualidade do produto através da trilogia Juan.
Tabela 2 - Processos da qualidade compreendidos pela trilogia Juan
Gerência para a Qualidade
Planejamento da Qualidade Controle da Qualidade Melhoramento da
Qualidade
Estabelecer metas de qualidade.
Identificar quem são os clientes.
Determinar as necessidades dos
clientes.
Desenvolver as características
do produto que atendem às
necessidades dos clientes.
Desenvolver processos capazes
de produzir as características do
produto.
Estabelecer controles do
processo; transferir os planos
para as forças operacionais.
Avaliar o desempenho real.
Compara o desempenho real
com as metas de qualidade.
Agir sobre a diferença.
Provar a necessidade.
Estabelecer a infra-estrutura.
Identificar os projetos de
melhoramento.
Estabelecer as equipes do
projeto.
Prover as equipes com
recursos, treinamento e
motivação para:
Diagnosticar as
causas
Estimular os
remédios
Estabelecer controles para
manter os ganhos.
Fonte: Trilogia Juan (1992)
Um Produto de Software é definido pela norma ISO/IEC 9126-1 [ISO9126-1
1997] como "uma entidade disponível para liberação a um usuário". Também segundo essa
norma, Qualidade de Software é definida como "a totalidade das características de um produto
que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas". Tais
necessidades explícitas são expressas na definição de requisitos elaborados pelo produtor e as
necessidades implícitas são aquelas que podem não estar expressas nos documentos do
produtor, mas que são necessárias ao usuário (GLADCHEFF, 2001).
27
Segundo Jimenez (1999), produtos de software são largamente utilizados pela
comunidade nos mais diversos setores, que envolvem desde aplicações simples até sistemas
críticos e complexos, tais como sistemas de segurança militar, sistemas de controle aéreo e
sistemas de controle financeiro. Com isso, a qualidade de um produto de software é uma
questão fundamental, pois estes produtos têm um impacto significativo sobre a sociedade.
Jimenez (1999) afirma que:
“Os objetivos da engenharia de software estão centrados na melhoria da qualidade
dos processos e produtos de software, bem como na redução dos esforços e custos da
produção de software. A reutilização de componentes é uma técnica importante neste
contexto, uma vez que permite a construção de software através de módulos bem
especificados e testados”.
Baseados nos autores citados pode-se compreender que a garantia da qualidade
do produto de software é relevante durante o seu processo de produção, principalmente em se
tratando de domínios de aplicação críticos para a sociedade como: sistemas financeiros, de
saúde e de controle de trânsito (aéreo ou terrestre, dentre outros).
É possível perceber ainda que o controle da qualidade do software ao longo do
processo de produção minimiza os custos, os riscos e favorece a manutenção contínua do
produto.
28
2 PRETESTE
Este capítulo objetiva exibir as informações necessárias para a compreensão do
ambiente onde foi realizado o experimento, descrever o experimento proposto, denominado
Preteste – principal contribuição deste trabalho e apresentar os aspectos envolvidos em sua
aplicação.
2.1 Caracterização do domínio de experimentação
2.1.1 Campo Laboral
O campo laboral selecionado está situado na cidade de Fortaleza no estado do
Ceará. É uma instituição voltada para o trabalho de Pesquisa e Desenvolvimento (P&D) e tem
como missão “agregar valor ao negócio do cliente através de funcionários capacitados e
melhoria contínua dos seus processos” (CISNE, 2008).
A empresa é aderente ao método de maturidade organizacional Capability
Maturity Model Integration (CMMI) nível 5, International Organization for Standardization
(ISO) 9001:2000, Seis Sigma e tem como um dos seus pilares suas políticas institucionais, na
qual está inserida a política relacionada à qualidade. Para atingir essa excelência, a instituição
aposta na melhoria contínua de seus processos de trabalho (DONEGAN et al, 2005).
Por ser uma organização de P&D, o desenvolvimento de projetos de inovação
é bastante comum, gerando uma cultura voltada ao favorecimento da realização de novas
experiências na instituição.
29
2.1.2 Políticas de Qualidade da Organização Estudada
Na organização, a qualidade dos produtos gerados tem grande relevância para
a instituição. A garantia da qualidade é feita através da análise de indicadores e de políticas
organizacionais que regem a forma de trabalho de seus funcionários.
As políticas institucionais de qualidades são definidas pelo grupo de qualidade
institucional composto pelos Quality Assurances em resposta às necessidades apontadas pelos
outros grupos da instituição. Essas diretrizes podem ser observadas nos documentos internos
que orientam os funcionários sobre as políticas de qualidade.
Nesses documentos, pode-se encontrar a missão da instituição que é focada em
proporcionar agregação de valor ao negócio do cliente através de melhoria contínua. (RUP,
2002; DONEGAN et al, 2005).
Para manter o seu padrão de qualidade a empresa é aderente à metodologia de
maturidade organizacional Capability Maturity Model Integration (CMMI) nível 5 e a
metodologia Seis Sigma. É regido ainda pela norma International Organization for
Standardization (ISO) 9001:2000 e desenvolveu diversos instrumentos de trabalho que estão
disponíveis a todo funcionário da instituição no repositório de documentos na intranet. Esses
instrumentos são descritos através quatro principais categorias que são:
Processos: mantidos pelo grupo de Suporte ao Processo de
Desenvolvimento e definidos com ajuda dos colaboradores da empresa;
está de acordo com a norma ISO 9001:2000 e com o modelo CMMI.
Procedimentos Institucionais: mantidos pelo grupo de Suporte ao
Processo de Desenvolvimento e definidos com ajuda dos colaboradores
da empresa; estão de acordo com a norma ISO 9001:2000 e com o
modelo CMMI. Os Procedimentos Institucionais estabelecem as
práticas obrigatórias para a organização.
Orientações: Os documentos de orientações estabelecem guias e
roteiros de trabalhos para os projetos, complementando as práticas
30
institucionais obrigatórias estabelecidas nos Procedimentos
Institucionais.
Registros: constituem todos os demais documentos utilizados pela
organização: modelos, planos, planilhas que registram as informações
de cada projeto e dos grupos institucionais sobre a realização de suas
atividades, de acordo com o estabelecido institucionalmente.
As políticas para a garantia da qualidade são direcionadas para cada setor de
trabalho institucional.
2.1.3 Principais Atividades do Processo de Teste da Empresa Estudada
O processo de teste é composto por Procedimentos, Listas de
Verificação, orientações e Modelos. A execução do processo pode ser divida em ciclos e
iterações, onde um ciclo agrupa diversas iterações e é iniciado na primeira iteração de testes e
concluído quando é realizada a entrega para o cliente onde são executados os testes de
aceitação. A iteração é realizada pela equipe de testes de forma manual onde é testado um
escopo definido em uma determinada versão liberada pela de desenvolvimento.
O processo é definido pelas principais etapas:
Planejar as atividades de teste: Nesta atividade é elaborado o plano
de testes do projeto, definida a liderança de teste responsável e
definidos os critérios de aceitação do projeto pelo cliente;
Elaborar especificações de testes: Nesta etapa são especificados pelo
analista de testes, os testes que cobrem o escopo de testes da iteração e
serão executados fielmente pelos testadores;
Executar testes: são executados os scripts de testes planejados na
atividade Elaborar Especificações de Testes;
31
Reportar falhas: o reporte e gestão de falhas ocorrem paralelamente à
atividade de Executar testes podendo depois ser restados apenas os
casos de testes que deram problemas. Nesta etapa também são gerados
os relatórios de testes contendo os resultados da iteração.
Durante a etapa de planejamento é elaborado o plano de testes do projeto, e são
realizadas as solicitações de alocações de recursos do Grupo de Teste para a fase de execução
dos testes. Ambos são baseados no cronograma de trabalho definido para o projeto.
Na etapa de elaborar especificações de teste são criadas especificações de teste
baseadas em modelos, tendo como insumos os casos de uso do projeto. As especificações
deverão conter as informações necessárias para os testes e serem seguidas fielmente durante a
realização da atividade de execução.
A realização da execução dos testes e registro de falhas ocorre em paralelo. É
liberada uma versão da aplicação para teste e à medida que o testador realiza os testes,
identificam-se os possíveis defeitos, que são registrados imediatamente em uma ferramenta
web para gestão de pendências denominada JIRA. Deste modo, suas correções já podem ser
iniciadas pelo time de desenvolvimento em paralelo a execução do restante dos testes.
Entende-se por pendência o registro na ferramenta de gestão indicada,
enquanto defeito corresponde à falha observada no produto de software durante a execução
das atividades de teste.
Existem 5 (cinco) tipos de testes realizados atualmente na instituição: o teste
de unidade que é realizado pelo time de desenvolvimento; o teste de integração, feito pelo
time de desenvolvimento em parceria com o grupo de teste; o teste sistêmico, que é executado
pelo grupo de teste e o reteste, que visa apenas os testes dos problemas identificados e
corrigidos durante o teste sistêmico executado também pelo grupo de testes.
Estes passos são repetidos até que se chegue a uma versão estável da aplicação
que possa ser entregue ao cliente. Este realiza uma última bateria de testes denominada de
testes de aceitação. Caso sejam identificados problemas nestes testes, a aplicação volta à
empresa para correções ou, caso contrário, emite-se o documento de aceitação do produto.
32
2.2 Detalhamento do Cenário do Preteste
2.2.1 Introdução
Este tópico recebe destaque por ter sido o Presteste uma contribuição adquirida
com a execução desta pesquisa e ter sido metodologia relevante na construção dos resultados
obtidos.
2.2.2 Caracterização do Cenário do Experimento
Por motivo de sigilo industrial, informações confidenciais como os nomes dos
clientes, da organização e dos projetos são omitidas. Deste modo, designam-se os projetos em
questão pelas letras A e B para facilitar a distinção das informações contidas.
O experimento foi aplicado a um incremento do projeto A. O projeto A tem
como objetivo o desenvolvimento de uma solução de inovação para um cliente internacional
desenvolvida nas linguagens C# da Microsoft, Java da empresa SUN Micro Systems e
interfaces em Adobe Flex da empresa Adobe. O projeto conteve o agrupamento de
plataformas de desenvolvimento WEB e Mobile e envolveu a utilização de RFID (Radio
Frequency Identification – Identificação por fequência de rádio) como meio de identificação
de produtos gerando ainda o desenvolvimento de dois novos dispositivos de hardwares.
O projeto B teve como objetivo a criação de uma aplicação WEB utilizando à
linguagem C# que foi desenvolvida para o mesmo cliente do Projeto A. A aplicação visa
modelar o fluxo de trabalho de um determinado setor da empresa e gerar relatórios de
produção.
O projeto B possui complexidade de tecnologia inferior ao projeto A. Em
contrapartida, a complexidade de negócio é consideravelmente superior a do projeto A. O
ambiente e os requisitos de negócio complexos desses projetos geram muitas dificuldades ao
longo do desenvolvimento, o que resulta na construção de hardwares específicos, um para
servir de interface entre a aplicação móbile e a aplicação WEB possibilitando a comunicação
33
via RFID e outro para servir como tag de identificação dos produtos que serão mantidos pelo
sistema, possibilitando a identificação dos produtos. Devido a esse grau de complexidade foi
necessária a criação de uma equipe de testes específica para os projetos.
2.2.2.1 Equipe Envolvida
Tabela 3 – Equipe Participante do Experimento
Perfil Projeto Contribuição
Coordenador de Projetos A Acompanhamento do projeto e dos resultados
obtidos no Preteste.
Desenvolvedor A Resolução dos defeitos e implantação de
melhorias identificadas durante o ciclo de teste.
Desenvolvedor A Resolução dos defeitos e implantação de
melhorias identificadas durante o ciclo de teste.
Analista de Requisitos A Resolução de problemas de requisitos
identificados e suporte ao Testador.
Analista de Teste e
Coordenadora do
Experimento.
A e B Identificação de problemas na aplicação através
do Preteste e gestão de problemas.
Desenvolvimento do modelo Preteste. Coleta e
análise de resultados do experimento.
Desenvolvimento da ferramenta
PretesteResults.
Coordenador de Projetos B Acompanhamento dos resultados obtidos no
Preteste e sugestão de melhorias.
Desenvolvedor B Resolução dos defeitos e implantação de
melhorias identificadas durante o ciclo de teste.
Desenvolvedor B Resolução dos defeitos e implantação de
melhorias identificadas durante o ciclo de teste.
Desenvolvedor B Resolução dos defeitos e implantação de
melhorias identificadas durante o ciclo de teste.
Desenvolvedor B Resolução dos defeitos e implantação de
melhorias identificadas durante o ciclo de teste.
Testador B Identificação de defeitos na aplicação através
da realização do Preteste.
Fonte: Cronograma dos Projetos A e B
34
2.2.2.2 Objetivos/Aplicações
A equipe de Testes dos projetos estudados tem como função reverter o
contexto de baixa produtividade nas atividades e o alto índice de defeitos identificados que
podem estar relacionados à complexidade de negócio ou de ambiente das aplicações
desenvolvidas e minimizar o tempo gasto com ciclos de testes nos projetos. Com isso, foi
aplicada à Engenharia de Software Experimental na busca de alternativas para contornar essa
situação. A aplicação de experiências resultou no desenvolvimento de um processo de
trabalho denominado Preteste, que tem como objetivo validar a estabilidade do build (versão
compilada da aplicação) após ter sofrido alterações e possibilitar a identificação da liberação
da aplicação ou não para o início dos testes sistêmicos.
O Preteste foi proposto objetivando-se a melhoria da produtividade da equipe
de testes e a buscar da redução da densidade de defeitos que interferem em métricas que são
coletadas pelo controle de qualidade da organização para cada projeto.
2.2.2.3 Ferramentas e Materiais
Foi utilizada a ferramenta Microsoft Excel para criação do modelo de planilha
para registro de defeitos. O sistema operacional no qual o Preteste foi aplicado é servidor de
integração dos projetos composto de uma máquina desktop que possui o Windows XP. Como
complementações a esse ambiente, e para paralelizar o Preteste de diversos casos de uso, são
utilizadas também as máquinas desktop de dois testadores, em que o acesso ao ambiente de
integração foi disponibilizado para que se pudesse ter acesso à aplicação.
O registro e acompanhamento dos defeitos foram realizados, inicialmente,
utilizando-se a ferramenta Microsoft Office Excel. A inexistência de uma ferramenta
específica para gerência das alterações de estado e a construção manual de relatórios torna
este trabalho mais lento e sucetível a erros. Pelos motivos expostos, decidiu-se construir uma
ferramenta denominada de PretestResults que soluciona estes problemas.
35
2.3 Análise do Processo de Testes da Organização Selecionada
Com objetivo de se identificar quais eram os pontos fracos que estavam
favorecendo a alta densidade de defeitos nos projetos e a baixa produtividade de trabalho da
equipe de testes, foi realizada uma análise do processo de testes da organização estudada a
fim de se identificar pontos que pudessem contribuir para a melhoria desses fatores. Um dos
principais pontos identificados foi à tardia identificação de defeitos de alta gravidade, gerando
um elevado retrabalho da equipe de testes e a necessidade de execução de diversos ciclos de
testes.
2.3.1 Relação do Preteste com a ESE
Durante o desenvolvimento deste trabalho foram aplicadas 3 (três) das 4
(quatro) principais abordagens da engenharia de software experimental já citada
anteriormente, sendo elas:
Fazer um levantamento de campo (survey): essa abordagem foi
utilizada para levantamentos dos dados dos indicadores para que se
conhecesse a realidade atual dos projetos e se pudesse traçar uma meta
de melhoria a ser atingida;
Executar um estudo de caso: a execução de um estudo de caso foi
necessária para que se tivesse um universo onde se pudessem
desenvolver experimentos na busca de soluções para a melhoria da
densidade de defeitos e da produtividade da equipe de testes. O estudo
de caso envolveu as fases 3 (três) e 4 (quatro) do projeto A e fase 2
(dois) e 3 (três) do projeto B.
Desenvolver um experimento controlado: o experimento foi
realizado de forma controlada no incremento 1 da fase 3 do projeto A.
Objetiva-se validar as hipóteses de que a produtividade estava baixa
devido ao grande volume de defeitos identificados e/ou grande
ocorrência de defeitos de criticidade bloqueadora e ainda de que a
36
densidade de defeitos estava alta devido à aplicação está sendo
preparada para testes sem a liberação a estabilidade mínima necessária.
Esse experimento deu origem ao Preteste.
2.4 Aplicação do Preteste no Campo Laboral
2.4.1 Identificação da Necessidade
O Preteste surgiu na organização em meio a um desafio proposto pelo
coordenador do projeto A de que a equipe de teste buscasse alternativas para que se pudessem
melhorar os indicadores de produtividade principalmente para a disciplina de testes e a
densidade de defeitos identificados em testes sistêmicos que tiveram resultados ruins durante
a primeira e segunda fase do projeto.
Como tentativa de melhorar o indicador de produtividade foram levantados e
organizados por criticidade os fatores que se acredita ter contribuído para a baixa
produtividade da equipe de testes do Projeto A. As criticidades foram definidas de acordo
com o impacto inferido hipoteticamente que o fator produziria no resultado da produtividade
atual da disciplina de testes, sendo dividas em 1 (leve), 2 (Moderada) e 3 (Grave). O objetivo
desta divisão era que se pudesse analisar a gravidade e influência direta dos problemas
identificados para o resultado da produtividade. Os problemas identificados podem ser
observados na Tabela 4.
Foram observados também os fatores que impactavam na alta densidade de
defeitos do projeto e identificou-se serem fatores semelhantes aos de produtividade.
37
Tabela 4 – Principais Problemas que Interferem na Produtividade da Equipe de Testes
Problemas Criticidade Influência
Grande ocorrência de defeitos com
criticidade Bloqueadora
Grave Gera desperdício de tempo do testador,
pois é preparado o início do ciclo de
testes, feita a alocação da equipe, a linha
de base é passada e no início dos testes o
aparecimento de um defeito Bloqueador
impede o restante do teste do caso de
uso bloqueado. Isso gera o desperdício
do tempo gasto até o momento, pois, o
caso de uso obrigatoriamente deverá ser
testado todo novamente. Aumentando a
densidade de defeitos do projeto.
Dificuldades de Compreensão do
contexto de Hardware e Software da
aplicação.
Moderada Gera demora na execução dos testes
principalmente nos testes que não
utilizam comunicação via ethernet. A
execução via GRPS tem demandado
diversos problemas de funcionamento.
Gerando várias interpretações de
defeitos do sistema que na verdade não
eram propriamente defeitos reais e sim
problemas de infra-estrutura.
Não aplicação da planilha de testes
pelos desenvolvedores antes da
liberação do código.
Moderada Gera elevado número de defeitos que
poderiam ter sido filtrados
anteriormente. Este fator ocasiona muito
tempo gasto para o cadastro de feitos no
JIRA. Aumentando a densidade de
defeitos do projeto.
Fonte: Relatório de Preteste
O indicador de qualidade relacionado à produtividade é controlado
estatisticamente pela organização e possui relevância na calibração dos da meta de
produtividade organizacional. Esse hoje é calculado seguindo-se fórmula matemática na qual
a instituição pesquisada não permitiu divulgação pública e é coletado nos projetos.
O indicador de qualidade relacionado à densidade de defeitos identificados é
controlado estatisticamente pela organização e possui relevância na calibração da meta
organizacional de qualidade do produto. Esse hoje é calculado seguindo-se fórmula
38
matemática e forma de coleta na qual a instituição pesquisada não permitiu divulgação
pública.
Os dados coletados para os indicadores são registrados na ferramenta de
controle do projeto e posteriormente são enviados para popular a base histórica
organizacional.
Com a avaliação negativa desses indicadores esses dados passam a influenciar
os indicadores organizacionais e retratam uma visão de baixa produtividade e alta densidade
de defeitos a nível organizacional. Essa realidade gera gastos de recursos com ações de
melhorias podendo chegar até a reformulação de equipes dos projetos envolvidos. Com isso, é
de extrema relevância que se mantenha esses indicadores dentro dos limites de tolerância
aceitos pela organização.
Após a análise dos fatores decidiu-se desenvolver uma etapa de testes
complementar mais ágil, mais efetiva na verificação de se a versão liberada está realmente
pronta para testes sistêmicos evitando-se assim desperdícios de recursos para o projeto A.
Surgiu então o Preteste que posteriormente foi aproveitado para o projeto B.
2.4.2 Etapas do Preteste
Para concepção do Preteste buscou-se orientação através pesquisas sobre
metodologias já existentes no mercado.
As etapas para a construção do Preteste tiveram atividades definidas por etapas
conforme listadas abaixo:
Definir: nesta etapa foi definido o escopo do projeto onde inicialmente
se aplicaria o Preteste e foi definida a primeira versão do processo
como vemos na Figura 1.
39
Fig.1 – Primeira Versão do Processo Preteste
Medir: nesta etapa foram levantados dados referentes aos valores dos
indicadores alvo naquele momento. Identificados os principais pontos
que contribuíram para o desempenho abaixo da média desses
indicadores (Ver Tabela 4). Analisamos a forma de coleta definida em
ferramenta institucional e o armazenamento, revisamos as coletas com
intuito de observar a confiabilidade dos dados.
Analisar: Analisamos os dados coletados e sua fonte, ou seja, quem
era responsável pela geração daqueles dados. Foram observadas
também as causas para os principais problemas identificados conforme
visto na Tabela 5.
40
Tabela 5 – Principais Problemas que Interferem na Produtividade da Equipe de Testes e geram Aumento
da Densidade de Defeitos.
Problemas Causa
Grande ocorrência de defeitos com
criticidade Bloqueadora
Pouco tempo para a codificação de itens novos
devido ao retrabalho com correções de problemas
de iterações anteriores.
Dificuldades de Compreensão do contexto
de Hardware e Software da aplicação.
Falta de treinamento de contextualização do
projeto para a equipe de testes.
Não aplicação da planilha de testes
pelos desenvolvedores antes da
liberação do código.
Falta de tempo e compromisso para a execução
desta tarefa.
Melhorar: nessa etapa foi verificada a necessidade de se manter os
dados do Preteste em um relatório e realizar o registro de defeitos
identificados em algum tipo de ferramenta, pois, como era algo
experimental, a organização não permitiu o registro dos defeitos em sua
ferramenta padrão. Com isso, foi alterado o fluxo do processo de
Preteste para englobar a atividade elaborar relatório (Ver Figura 5) e
foram criados os modelos de Relatório de Preteste e o Registro e
Acompanhamento de Defeitos que estão incluídos em um mesmo
arquivo. (ANEXO 1)
Controlar: nessa etapa foi verificada a necessidade de se acompanhar
a evolução dos indicadores alvo a fim de perceber se a aplicação do
Presteste estava trazendo benefícios ao projeto.
2.4.3 Objetivo do Preteste
O objetivo principal do Preteste foi prover uma forma de se executar a
disciplina de testes de software de maneira produtiva, com redução de problemas e
desperdício de esforço.
41
2.4.3.1 Processo
O processo Preteste é composto por seis principais etapas que são definidas
como macro-atividades, como se pode ver na Figura 2. A Figura 2 contempla a evolução do
processo para versão 1.1 onde dói englobada a elaboração de um relatório após a realização
do Preteste.
Fig. 2 – Fluxo do Processo Preteste Versão 1.1
Planejar Preteste: Etapa em que é definido o escopo a ser aplicado o
Preteste, o esforço a ser utilizado e o cronograma.
Executar Preteste: Etapa em que é realizada a aplicação do Preteste.
São executados testes exploratórios, que é um tipo de teste “... indicado
quando existe pouca documentação para orientar a elaboração dos
testes ou quando o prazo é tão curto que não é possível preparar um
teste mais formal. É um teste executado a partir da experiência do
42
testador” (RIOS, 2007). O escopo é predefinido e o principal objetivo
é verificar a existência de defeitos que impedem a execução do fluxo
principal/fluxo básico de um determinado caso de uso.
Registrar Defeitos: O registro de defeitos identificados foi feito de
forma manual, utilizando-se um modelo construído através de planilha
Excel (Anexo I). O artefato possui como pontos relevantes a
possibilidade do registro das pendências identificadas, a definição de
sua criticidade e o registro da situação de acompanhamento de sua
correção.
Analisar Resultados: A análise dos resultados foi baseada na
quantidade de defeitos identificados a cada ciclo do Preteste e na
criticidade definida para os mesmos.
Acompanhar Defeitos: O acompanhamento dos defeitos foi realizado
através da própria planilha de registro que era atualizada no repositório
sempre pela mesma pessoa. Esse processo dificultava o paralelismo de
correção, pois, as atualizações feitas por várias pessoas no mesmo
arquivo poderiam gerar perdas.
Gerar Relatório: Ao final da execução um relatório era gerado para
informar se a aplicação possuía estabilidade suficiente para que fosse
submetida ao processo de teste formal da instituição. Caso o resultado
fosse negativo a aplicação retornava a disciplina de codificação ou para
a disciplina de requisitos para os devidos ajustes.
2.4.3.2 Aplicação do Preteste
O Preteste foi aplicado como experimento primeiramente no Projeto A, a partir
do incremento 1 da Fase 3 de desenvolvimento do projeto e perdurou como estudo de caso até
a finalização do projeto na Fase 4. A execução ocorria após a finalização da disciplina de
codificação e implementação dos testes unitários de um determinado caso de uso. Não era
necessário que todos os casos de uso do incremento estivessem concluídos para que se
43
iniciasse o Preteste, ele ocorria após a finalização dos testes unitários de algum caso de uso
pertencente ao escopo do incremento. Para execução eram seguidos os seguintes passos
definidos no planejamento do experimento:
Definição do responsável pela aplicação do Preteste;
Envio de email do desenvolvedor informando que já finalizou a
implementação do caso de uso;
Testador realiza o teste do fluxo básico do caso de uso;
Testador reporta os defeitos na planilha modelo Registro e
Acompanhamento de Defeitos;
Testador insere a planilha no repositório do projeto;
Desenvolvedor realiza a correção dos defeitos identificados no caso de
uso;
Desenvolvedor atualiza os estados dos defeitos encontrados para
corrigido;
Desenvolvedor insere a planilha atualizada no repositório do projeto;
Desenvolvedor informa ao testador que finalizou as correções;
Testador realiza reteste dos problemas identificados;
Testador elabora relatório recomendando ou não o caso de uso ser
disponibilizado para testes sistêmicos.
No intuito de realizar o experimento de forma controlada executou-se a
aplicação do Preteste no incremento 1 da Fase 3 do projeto em apenas 50% dos casos de uso.
O objetivo foi manter como variáveis controladas e aleatórias para que se possa observar a
efetividade do Preteste na redução do tempo de execução dos testes sistêmicos aumentando
44
assim a produtividade e objetivando analisar a ocorrência de melhoria na densidade de
defeitos identificados.
A escolha deste incremento para realização do experimento se justifica por ele
ser composto de 6 (seis) casos de uso do tipo CRUD (CRUD é a sigla da expressão em língua
Inglesa Create, Retrieve, Update e Delete) que possuem exatamente o mesmo tamanho,
complexidade e esforço para realização dos testes.
Com o objetivo de analisar o efeito do Preteste, este foi aplicado apenas em 3
(três) dos casos de uso pertencentes ao incremento, enquanto os demais seguiram o processo
de testes anteriormente utilizado. Mesmo que a comparação ocorra sobre grupos distintos,
considera-se esta base de comparação adequada devido à semelhança entre os casos de uso,
conforme exposto anteriormente.
Com o efetivo desenvolvimento do Preteste no projeto A o coordenador do
projeto B interessou-se pela proposta e resolveu adotar em seu projeto. No projeto B o
Preteste foi executado na Fase 2 e 3.
É importante ressaltar que no projeto B problemas de Requisitos e não apenas
de codificação passaram a ser identificados e registrados durante o Preteste. O analista de
requisitos seguia os mesmos passos do desenvolvedor para solução do problema. Este fato
demonstrou que o Preteste pode também ser utilizado para validação lógica de documentos de
caso de uso somando-se o protótipo de tela. Foram identificados ainda problemas nas
especificações de testes sistêmicos que são utilizadas para a aplicação do Preteste,
fortalecendo a hipótese de que o Preteste, não necessariamente valida apenas o sistema mais
também produtos de documentação produzidos que são insumos para a disciplina de testes.
Porém essa análise não fez parte do escopo deste trabalho.
Após a execução do Preteste eram avaliados alguns critérios pelo testador e
documentados no relatório com objetivo de indicar a liberação ou não do caso de uso para
testes sistêmicos. São eles:
A) Foi identificada algum defeito do tipo bloqueadora?
45
B) O total de defeitos identificados é igual ou superior a quantidade de
transações do caso de uso?
C) Foi identificada falta de implementação de algum passo do fluxo
básico?
Respondendo SIM a um dos questionamentos o caso de uso está
automaticamente não recomendado para a etapa de testes sistêmicos, devendo esse ser
devolvido à disciplina de codificação para revisão. A recomendação inapropriada de um caso
de uso para testes sistêmicos pode gerar desperdício de alocação e elevado número de defeitos
que deveriam ter sido eliminados em etapas anteriores. Respondendo NÃO aos 3 (três)
questionamentos o caso de uso é liberado para os testes sistêmicos.
3 ANÁLISE DOS RESULTADOS
Neste capítulo são apresentados os resultados obtidos ao longo da aplicação do
Preteste no Projeto A e no Projeto B. Os resultados dos experimentos (seção 3.1) estão
organizados em dois grupos principais, sendo que o primeiro enfatiza a evolução dos
indicadores de produtividade da disciplina de testes (seção 3.1.1) e o segundo da densidade de
defeitos (seção 3.1.2).
Para a realização da análise dos resultados foi desenvolvida uma nova
ferramenta, denominada PretestResults, cujas características são apresentadas na seção 3.2.
Finalmente, a seção 3.3 apresenta as principais lições identificadas durante a execução dos
experimentos.
3.1 Resultados dos Experimentos
3.1.1 Evolução de Indicadores de Produtividade Sem Preteste
O gráfico 2 apresenta os valores da produtividade do projeto A antes da
implantação do Preteste. A linha azul indica a meta organizacional que é controlada através
de linhas de base de desempenho lançadas periodicamente após a análise de uma amostra de
projetos decorridos durante cada semestre do ano. A linha vermelha indica a produtividade
alcançada durante os dois primeiros ciclos de testes do projeto. A linha verde indica que a
produtividade se mantinha estável.
Com o lançamento da nova linha de base de produtividade organizacional que
reduziu a meta para 20h antes do início do segundo ciclo de testes do projeto a produtividade
da equipe de testes ficou acima da meta da instituição. Ressaltando-se que para a
produtividade quanto menor o valor de horas melhor para a organização, pois indica uma
equipe mais produtiva.
O cálculo ocorre dividindo-se quantidade de horas gastas para realização do
testes pelo tamanho do escopo a ser testado. Sendo , em que significa a
47
produtividade, em horas por TUCP; , o esforço de um ciclo de testes, medido em horas, e ,
o esforço do escopo de testes. Onde o esforço é medido em horas gastas para realização da
atividade e o tamanho em TUCP (Pontos de Caso de Uso Técnicos).
Gráfico 2 – Evolução da Produtividade no Projeto A Anterior ao Preteste. Fonte: Ferramenta de Controle e
Acompanhamento do Projeto A
Notamos que a meta inicial do projeto era 24h e o projeto possuía uma
produtividade de testes de 22h mantendo-se, portanto dentro da meta. Com a evolução
contínua dos indicadores os projetos na organização a nova meta institucional passou a ser
20h a partir da segunda fase do projeto. Este fato levou o projeto a ficar fora acima da meta no
incremento 1 (um) da Fase 3 (três). Observando esse problema a coordenação do projeto
decidiu investir esforço em ações de melhoria visando atingir a meta de produtividade
organizacional. Essa necessidade abriu espaço para o desenvolvimento desta pesquisa.
O gráfico 3 apresenta os valores da produtividade do projeto B antes da
implantação do Preteste.
Gráfico 3 – Evolução da Produtividade no Projeto B Anterior ao Preteste. Fonte: Ferramenta de Controle e
Acompanhamento do Projeto B
24
20 20,0
22 22
1819202122232425
1 2 3
Planejado
Realizado
Evolução da Produtividade no Projeto A Anterior ao Preteste
Pro
du
tividad
e
20,00 20,0 20,020,00
22,0
23,7
18,00
19,00
20,00
21,00
22,00
23,00
24,00
1 2 3
Planejado
Realizado
Evolução da Produtividade no Projeto B
Pro
du
tividad
e
48
É observado no gráfico 3 que o projeto B estava na sua fase 1 (um) dentro da
meta organizacional de produtividade mantendo o valor de 20h gastas por unidade de
tamanho. Porém no primeiro incremento da fase 2 a produtividade em testes do projeto subiu
2(dois) pontos e posteriormente mais 1,7 pontos, passando a apresentar uma linha de
tendência de possibilidade de subida. Lembrando que quanto menor a produtividade melhor
para a organização. Com objetivo de voltar aos limites da meta organizacional a coordenação
do projeto resolveu abrir espaço para inovações que trouxessem melhorias na produtividade
da equipe de testes. Esta situação levou o projeto a fazer parte do escopo desta pesquisa.
3.1.2 Evolução de Indicadores de Densidade e Defeitos Sem Preteste
O gráfico 4 apresenta os valores da densidade de defeitos do projeto A antes da
implantação do Preteste. A linha azul mostra a linha de base da meta organizacional. A linha
vermelha demonstra a evolução da densidade de defeitos identificada nos 3 (três) primeiros
ciclos de teste do projeto. Ressaltando que a densidade de defeitos é calculada dividindo-se a
quantidade de defeitos identificada pelo tamanho do escopo de testes testado. Onde
. Em que significa a densidade de defeitos identificada no ciclo de testes, a
quantidade de defeitos observadae o tamanho em TUCP do escopo de testes..
Gráfico 4 – Evolução da Densidade de Defeitos no Projeto A Anterior ao Preteste. Fonte: Ferramenta de
Controle e Acompanhamento do Projeto A.
É notório através da observação do gráfico 4 que o projeto está bem distante da
meta organizacional, mantendo uma média de 0,78 defeitos/TUCP enquanto que a meta é
0,18 0,18 0,18 0,18 0,18
0,87
0,64
0,82
00,10,20,30,40,50,60,70,80,9
1
1 2 3 4 5
Meta
DD Real
Evolução da Densidade de Defeitos no Projeto A Anterior ao Preteste
Den
sidad
ed
e Defeito
s
Iterações de Teste
49
0,18 defeitos/TUCP. A necessidade de uma ação urgente levou a melhoria da densidade de
defeitos a ser o principal alvo deste trabalho.
O gráfico 5 apresenta os valores da densidade de defeitos do projeto B antes da
implantação do Preteste. Lembrando que quanto menor a densidade de defeitos melhor a
qualidade do produto produzido.
Gráfico 5 – Evolução da Densidade de Defeitos no Projeto B Anterior ao Preteste. Fonte: Ferramenta de
Controle e Acompanhamento do Projeto B
É visivelmente percebível a partir da observação do gráfico 5 que a densidade
de defeitos no projeto B está em estado crítico, bastante distante da meta com uma média de
0,68 defeitos/TUCP e possível tendência de subida. A melhoria desse indicador era essencial
para o projeto, pois, organizacionalmente ele está diretamente ligado a qualidade do produto
que está sendo gerado. A coordenação do projeto abriu espaço para esta pesquisa visando
conseguir alternativas de reverter este quadro.
0,18 0,18 0,18 0,18 0,18 0,18
0,63
0,52
0,74
0,87
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1 2 3 4 5 6
Meta
DD Real
Evolução da Densidade de Defeitos no Projeto B Anterior ao Preteste
Den
sidad
ed
e Defe
itos
Iterações de Teste
50
3.1.3 Resultados da Execução do Experimento Preteste
Tabela 6 – Resultados do Experimento Preteste
Projeto Fase
Incremento
Caso de
Uso
Quantidade
de Defeitos
Identificados no
Preteste
Quantidade
de Defeitos
Identificados no
Teste Sistêmico
Esforço
em horas
Preteste
Esforços em
horas Testes
Sistêmicos
Recomendado
para Testes
Sistêmicos?
Com Preteste
Proj_A/Fase 3_Inc_1
UC10 10 19 1,5h 6h Não
UC11 15 11 2h 8h Sim
UC12 12 13 1h 4h Sim
Sem Preteste
Proj_A/Fase 3_Inc_1
UC13 0 27 0h 12h -
UC14 0 19 0h 11h -
UC15 0 22 0h 8h -
Fonte: Relatório de Preteste do Experimento
(a) Esforço sem Preteste (b) Esforço com Preteste Gráfico 7 – Esforço para a realização de testes (a) sem Preteste e (b) com Preteste.. Fonte: Relatório e Relatório
de Testes do Projeto
Ao analisar o gráfico 7, percebe-se que apesar de se ter uma atividade adicional, que
consiste na execução do Preteste, a duração total do processo é reduzida. Totalizando-se as
horas de testes dos casos de uso considerados, tem-se 31h (trinta e uma) horas para realização
dos testes sem Preteste e 22,5h (vinte e duas horas e 30 minutos) com Preteste. Deste modo,
observa-se uma redução de 8,5 (oito e meia) horas, ou seja, 26% (vinte e seis por cento). Esta
redução é uma conseqüência direta da realização do Preteste.
A redução do total de horas pode ser explicada por duas razões principais, sendo a
segunda uma conseqüência da primeira: (i) os defeitos são identificados antecipadamente, e
(ii) a antecipação da detecção de problemas graves como vemos no gráfico 6, que iriam
51
interferir na execução do ciclo de testes, favorece a resolução destes se eliminado o retrabalho
(repetição de ciclos de testes e correção de defeitos).
Adicionalmente, problemas como o início do ciclo de testes sem que os casos de uso
tenham pelo menos seu fluxo básico funcionando são evitados, elevando-se a produtividade
do testador.
Gráfico 8 – Quantidade de Defeitos Antecipados com o Preteste. Fonte: Relatório de Preteste
Como pode ser observado no gráfico 9 à realização do Preteste antecipou para
o UC10, UC11 e UC 12 a quantidade de 10,15 e 12 defeitos respectivamente para a etapa de
desenvolvimento onde o custo para correção é consideravelmente mais barato de acordo com
a regra de 10 Myers. Mostrando que é possível a identificação prévia de defeitos mesmo após
a revisão do desenvolvedor.
Gráfico 9 – Quantidade de Defeitos Identificados. Fonte: Relatório de Preteste
0
5
10
15
UC10 UC11 UC12
UC10
UC11
UC12
Quantidade de Defeitos Antecipados com Preteste
30
40
50
60
70
80
Com Preteste
Sem Preteste
Quantidade de Defeitos Identificados
52
No gráfico 9 fica claro que a etapa do Preteste favorece a identificação de mais
defeitos em relação à execução de apenas os testes sistêmicos tradicionais. Com a execução
do Preteste foram identificados 80 (oitenta) e sem o Preteste 68 (sessenta e oito). Esse fato é
relevante, pois a identificação de mais defeitos aliados a sua correção favorecem a melhoria
da qualidade do produto entregue ao cliente.
3.1.4 Evolução de Indicadores de Produtividade com a Aplicação do Presteste
O gráfico 10 apresenta a evolução da produtividade da disciplina de testes no
projeto A após a aplicação do Preteste. A linha verde demonstra o aumento da produtividade,
através da redução do fator do total de horas pelo esforço do projeto, medido em TUCPs, após
a aplicação do Preteste.
Gráfico 10 – Evolução da Produtividade da Disciplina de Testes no Projeto A. Fonte: Ferramenta de Controle e
Acompanhamento do Projeto A
No gráfico sete é visível que no ponto 3 (três) da linha do realizado houve uma
piora na produtividade de 0,3h. Esse fato se justifica devido ao esforço demandado para
definição e execução do experimento Preteste. No ponto 4 (quatro) que representa a fase 4 de
desenvolvimento do projeto notamos uma melhoria significativa de 7,83h (sete e oitenta e
três), gerando uma evolução de 35,11% (trinta e cinco e onze por cento). Essa melhoria se
justifica devido à aplicação do Preteste ter eliminado ciclos de testes desnecessários e/ou
improdutivos evitando o gasto de esforço de forma improdutiva.
24
20 20,0 20,0022 22 22,3
14,47
0
5
10
15
20
25
30
1 2 3 4
Planejado
Realizado
Evolução da Produtividade no Projeto A
Pro
du
tividad
e
Ciclo de Teste
53
O gráfico demonstra que foi efetiva a melhoria da produtividade para o projeto
A após a implantação do Preteste. Não foi possível a aplicação do Preteste por um período
maior no universo do projeto devido ao mesmo ter sido finalizado antecipadamente pelo
cliente.
O gráfico 11 apresenta a evolução da produtividade da disciplina de testes no
projeto B após a aplicação do Preteste. A linha verde demonstra o aumento da produtividade
após a aplicação do Preteste que significa uma equipe mais produtiva para a organização.
Gráfico 11 – Evolução da Produtividade da Disciplina de Testes no Projeto B. Fonte:
Ferramenta de Controle e Acompanhamento do Projeto B
No gráfico 11 é possível observar que no ponto 3 (três) da linha vermelha do
realizado houve uma melhora significativa na produtividade de 7h(sete). Esse fato se justifica
devido execução do método Preteste no projeto. No ponto 4 (quatro) que representa a fase 3
de desenvolvimento do projeto notamos uma piora 1,9h (um e nove) na produtividade da
equipe de testes, Esse fato pode ser justificado pelo fato do cliente solicitar testes de
usabilidade que não estavam previstos anteriormente e, portanto estavam fora do
planejamento. Mesmo com essa situação adversa o projeto permaneceu dentro da nova meta
estabelecida pela organização de 0,18h (zero e dezoito). Esse resultado mostra que o Preteste
foi efetivo também para o projeto B na melhoria da produtividade.
20,00 20,0 20,018,0
20,0022,0
23,7
15,016,9
0,00
5,00
10,00
15,00
20,00
25,00
1 2 3 4 5
Planejado
Evolução da Produtividade no Projeto B
Pro
du
tividad
e
Evolução da Produtividade no Projeto B
54
3.1.5 Evolução dos Indicadores de Defeitos com a Aplicação do Presteste
O gráfico 12 apresenta a evolução da densidade de defeitos no projeto A após a
aplicação do Preteste. A linha verde demonstra que a densidade de defeitos tende a zero após
a aplicação do Preteste.
Gráfico 12 – Evolução do Indicador de Densidade de Defeitos no Projeto A. Fonte: Ferramenta de Controle e
Acompanhamento do Projeto A
No gráfico 12 é clara a melhoria na evolução do indicador de densidade de
defeitos. No ponto 4 (quatro) que representa a fase 3 de desenvolvimento do projeto notamos
uma queda de 0,69 defeitos/TUCP (zero e sessenta e nove) na densidade de defeitos levando o
projeto a ficar abaixo da meta pela primeira vez desde seu início. Esse fato pode ser
justificado por a identificação prévia de defeitos, a eliminação de defeitos em fases anteriores
e a redução dos ciclos de testes terem contribuído para a diminuição dos defeitos encontrados
por tamanho de caso de uso, ou seja, redução na densidade de defeitos. Podemos notar ao
observar a linha de tendência que a densidade tende à zero no projeto. No ponto 6 da linha de
DD real podemos observar um aumento de 0,7 defeitos/TUCP com relação ao incremento
anterior. Isso se justifica pelo fato de neste período ter havido testes de regressão gerando um
tamanho maior do escopo de testes e consequentemente o aumento da densidade de defeitos.
0,18 0,18 0,18 0,18 0,18
0,37 0,37 0,37
0,87
0,64
0,82
0,13
0,020,09
0,03
-0,2
0
0,2
0,4
0,6
0,8
1
1 2 3 4 5 6 7 8 9
Meta
DD Real
Evolução da Densidade de Defeitos no Projeto A
Den
sidad
ed
e Defe
itos
Iterações de Teste
55
Podemos concluir então que foi relevante a aplicação do Preteste no projeto
para a melhoria da densidade de defeitos durante a execução do projeto.
O gráfico 13 apresenta a evolução da densidade de defeitos no projeto B após a
aplicação do Preteste.
Gráfico 13 – Evolução do Indicador de Densidade de Defeitos no Projeto B. Fonte: Ferramenta de Controle e
Acompanhamento do Projeto B
No gráfico 13 é clara a melhoria na evolução do indicador de densidade de
defeitos a partir do ponto 8(oito). No ponto 5 (cinco) nota-se uma queda discreta de 0,6
defeitos/TUCP da densidade de defeitos. Devido à complexidade de desenvolvimento do
projeto a densidade de defeitos permaneceu alta mesmo depois da implantação do Preteste. O
projeto necessitou de mais tempo que o projeto A para que o Preteste fosse efetivo.
A partir do ponto 7 é possível verificar uma queda significativa na densidade
de defeitos de 0,57 defeitos/TUCP. Esse fato se justifica devido ao Preteste está sendo
executado em todos os casos de uso do incremento e problemas graves que eram comuns ser
identificados em testes sistêmicos terem sido registrados no Preteste e rapidamente
solucionados.
Nota-se a partir do ponto 7 (sete) uma tendência de queda e posteriormente um
atingimento da meta organizacional. A densidade passa a tender a zero também neste projeto.
0,18 0,18 0,18 0,18 0,19 0,19 0,19 0,19 0,19 0,19 0,19
0,63
0,52
0,74
0,870,81
0,870,81
0,24
0,03 0,01
-0,2
0
0,2
0,4
0,6
0,8
1
1 2 3 4 5 6 7 8 9 10 11
Meta
DD Real
Evolução da Densidade de Defeitos no Projeto B
Den
sidad
ed
e Defe
itos
Iterações de Teste
56
Com isso observamos que o Preteste tanto foi efetivo para a melhoria da Produtividade em
testes como na densidade de defeitos de ambos os projetos. Ressaltamos ser relevante uma
amostra maior de projetos para tornar o Preteste aplicável para outras realidades de projetos.
É importante ressaltar também que as melhorias foram comprovadas apenas para o escopo
estudado.
3.2 Ferramenta PretestResults
3.2.1 Objetivo
O principal objetivo da construção da ferramenta veio da necessidade de
acompanhamento dos defeitos de forma mais eficaz e da geração automática de relatórios. É
relevante ainda que os resultados dos Pretestes realizados nos projetos são guardados em uma
base de dados para consultas futuras. A ferramenta também torna transparente o processo de
comunicação entre o testador e restante da equipe.
3.2.2 Apresentação da Ferramenta
Com a utilização da ferramenta PretestResults desenvolvida durante esta
pesquisa podemos eliminar da utilização dos modelos Relatório de Preteste e a planilha do
Registro e Acompanhamento de Defeitos. Essa solução favorece à execução do processo,
automatiza a geração do relatório, unifica a base de dados do Preteste, facilita a comunicação
entre a equipe e garante a integridade dos dados, comprometida pela alteração de um mesmo
artefato por diferentes pessoas.
Como principal contribuição da ferramenta está o Relatório de Confiabilidade
do Build mostrado na 4 que exibe a quantidade de defeitos de um projeto e calcula o grau de
confiabilidade do build, através dos critérios atribuídos para classificação da estabilidade do
caso de uso do sistema implementado.
57
Fig. 3 – Tela da funcionalidade Relatório de Confiabilidade da ferramenta PretestResults.
Fonte: Ferramenta PretesteResults
3.2.3 Principais Dificuldades e Lições Identificadas
Assim como os testes sistêmicos o Preteste não é efetivo quando
aplicado pelo desenvolvedor;
A gestão de defeitos via planilha Excel é bastante desgastante e
improdutiva;
58
A geração de relatórios manuais para um processo rápido como o
Preteste gera um aumento no esforço do processo como um todo;
O Preteste não é efetivo quando aplicado para aplicações estáveis ou
que já tenham sido testadas sistemicamente anteriormente;
O Preteste minimizar os defeitos identificados em testes sistêmicos e
reduz o custo de correção por antecipar essa correção.
4 CONTRIBUIÇÕES E FUTURO
Este capítulo visa exibir as principais contribuições e lições aprendidas com o
desenvolvimento da pesquisa.
4.1 Principais Contribuições
Aplicação dos princípios da ESE na busca de soluções para melhoria de
um indicador de qualidade institucional.
Criação de um modelo de processo de testes simplificado, ágil e que
realizava a validação da estabilidade da aplicação antes de ser
empregado o esforço do início de um ciclo de testes formal.
Melhoria do indicador de densidades de defeitos através da utilização
do Preteste.
Criação da ferramenta de gestão de defeitos e validação PretestResults.
4.2 Sugestões de Trabalhos Futuros
Evolução do modelo do processo e adequação a novas instituições.
Aplicação do Preteste em outras empresas de software com outros
nichos de mercado para realizar uma análise comparativa com a
empresa de P&D.
Evolução da ferramenta PretestResults para englobar mais
funcionalidades e fornecer mais informações sobre o Preteste.
60
Aplicação do Preteste no âmbito da metodologia ágil unindo-se seus
resultados aos de testes unitários e verificando o grau de confiabilidade
dos testes. Podendo posteriormente substituir-se os testes sistêmicos
para essa aplicação.
Aplicação do Preteste de forma controlada estatisticamente através da
utilização da abordagem Seis Sigma como implantação de um projeto
de melhoria em uma instituição com alto grau de maturidade.
5 CONCLUSÃO
Que o Preteste foi efetivo na melhoria da produtividade e da densidade
de defeitos em testes sistêmicos do campo laboral estudado por ter
melhorado os indicadores nos cenários dos dois projetos;
Que o processo de Preteste não substitui a necessidade de aplicação de
testes sistêmicos, pois objetiva identificar os defeitos no fluxo básico
dos casos de uso;
Que com uma evolução o modelo desenvolvido pode ser aplicado a
outras disciplinas do desenvolvimento de software;
Que a ferramenta PretestResults oferecida como melhoria ao processo
de realização do Preteste pode agilizar o desenvolvimento das
atividades e melhorar a comunicação entre a equipe participante
processo de testes.
62
6 REFERÊNCIAS
1 ABREU, Fernando Brito. O ensino da engenharia de software experimental.
Jornada de Informática. Universidade de Minho; Braga, Portugal. Disponível em
<http://natura.di.uminho.pt/join2005/out/programa_pt.html>, <Acesso em: 13 de
outubro de 2008>, 2005.
2 ATLANTICO Instituto, 2008. Manual da qualidade. Documento interno.
3 BABBIE, Earl. Métodos de pesquisas de survey. Belo Horizonte: Editora UFMG,
2001, 519 p.
4 BARROS, M. O. ; ARAÚJO, M.A.P.; TRAVASSOS, Guilherme Horta; MURTA, L.
G. P. Métodos Estatísticos para a Engenharia de Software Experimental.
Universidade Federal do Estado do Rio de Janeiro – UNIRIO. Rio de Janeiro, 2006.
5 BOGDAN, Robert e BIKLEN, Sari. Investigação qualitativa em educação: uma
introdução à teoria e aos métodos. Porto, Portugal. Porto Editora, 1994.
6 CISNE, Raul Ivana Bezerra. LIMA, Sandra Freitas F. O gerenciamento de projetos
na área de pesquisa e desenvolvimento (p&d) incentivados pela lei de
informática: um estudo de caso no instituto atlântico. Biblioteca do Instituto
Atlântico, Fortaleza-Ce; 2008.
7 DANDOLINI, Jaison. Ferramenta de apoio a experimentos em engenharia de
software. 2006. 80f. Monografia (Graduação em Ciência da Computação) –
Universidade Regional de Blumenau – FURB. Blumenal, SC. <Disponível em:
http://campeche.inf.furb.br/tccs/2006-II/2006-2jeisondandoliniap.pdf>, <Acesso em:
23 de novembro de 2008>, 2006.
8 DANIELEWICZ, Marcio. Procedimentos para rastreabilidade das não-
conformidades no processo produtivo. Dissertação (mestrado) - Universidade
Federal de Santa Catarina, Centro Tecnológico. Programa de Pós-Graduação em
Engenharia de Produção. Florianópolis, 2006.
9 DAVIES, Paul. Pode-se confiar nos cientistas?. Revista Super Interessante. Edição
032 Maio de 1990, p. 47 e 48.
63
10 DESCHAMPS, Alexandro. Engenharia de software. Projeto eleva. Blumenau, Santa
Catarina. 2008.
11 DONEGAN, Paula. BANDEIRA, Liane. et al. Aplicabilidade da automação de
testes funcionais – A experiência no instituto atlântico. Biblioteca do Instituto
Atlântico, Fortaleza-Ce; 2005.
12 ESCOBAR, Jefferson. DMAIC. <Disponível em: http://br.kaizen.com/artigos-e-
livros/artigos/dmaic.html>, <Acesso em: 20 de Junho de 2010>, 2008.
13 FUNKS, H; RAPOSO, A.B. & Gerosa, M.A. Engenharia de groupware:
desenvolvimento de aplicações colaborativas. XXI Jornada de Atualização em
Informática, Anais do XXII Congresso da Sociedade Brasileira de Computação, V2,
Cap. 3, ISBN 85-88442-24-8. Ano 2002.
14 GALILEI, Galileu. Dialogue concerning the two chief world systems. Ano 1632.
Traduzido por Stilman Drake, Adaptado para Dartmouth College, MATC, On-line
reader. <Disponível em: webexhibits.org/calendars/year-text-Galileo.html>, <Acesso
em: 20 de Janeiro de 2008>, 2008.
15 GATTAZ, Fuad. Processo – a máquina contextual nos negócios. O mundo em
processo. <Disponível em: www.labp3.org.br>, <Acesso em: 20 de Janeiro de 2008>,
2000.
16 GIMENES, Itana M. S et al. Um padrão para definição de um gerenciador de
processos de software. Universidade Estadual de Maringá,1999.
17 GLADCHEFF, A.P.; ZUFFI, E.M.; SILVA, D.M. Um Instrumento para Avaliação
da Qualidade de Softwares Educacionais de Matemática para o Ensino
Fundamental. In: VII WORKSHOP DE INFORMÁTICA NA ESCOLA, Fortaleza,
CE, Brasil, julho/agosto, 2001. Anais.
18 JURAN, Joseph. M. 1904. A qualidade desde o projeto: novos passos para o
planejamento da qualidade em produtos e serviços / J. M. Juan; tradução Nivaldo
Montingelli Jr. São Paulo: Pioneira Thomson, 1992.
19 MATTAR, Fauze N. Pesquisa de Marketing. São Paulo, Atlas, 1999.
20 MENDONÇA, Manuel. Engenharia de software experimental. 2008.Universidade
de Salvador, Bahia. 2008.
21 PINHEIRO, Lívia Figueredo Rodrigues. Modelagem do domínio daa utilizando a
tecnologia p3tech©. 2007. 196f. Monografia (graduação) – Curso de bacharelado em
ciência da computação, Faculdade Farias Brito, Fortaleza, 2007.
22 PRESMAN, Roger. Software engineering: a practitioner’s approach”. 5. ed. McGraw
Hill, 2003.
23 PURRI, Marcelle Cristina M. e S. Estudo e propostas iniciais para a definição de
um processo de desenvolvimento para software científico. Dissertação (mestrado) -
64
Mestrado em Modelagem Matemática e Computacional (MMC), Centro Federal de
Educação Tecnológica de Minas Gerais, Belo Horizonte; 2006.
24 RATIONAL. Rational unified process – RUP. RSoftware Corporation; 2002.
25 RIOS, Emerson; CRISTALLI, Ricardo, MOREIRA, Trayahú; e BASTOS, Aderson.
Base de conhecimento em teste de software. Editora Martins Fontes, São Paulo;
2007.
26 ROCHA, Anne. Grupo de Testadores de Software. 2007. (Desenvolvimento de
material didático ou instrucional - Blog Científico).
27 SOMMEVILLE, Ian; Engenharia de software. 6.ed. São Paulo: Addison Wesley,
2003.
28 TRAVASSOS, Guilherme Horta. Introdução à engenharia de software
experimental. Relatório Técnico RT-ES-590/02, Universidade Federal do Rio de
Janeiro, Rio de Janeiro, 2002.
29 WOHLIN, Claes. Are individual differences in software development performance
possible to capture using a quantitative survey?. Massassuchets USA: Empirical
Software Engineering, Volume 9, September 2004. Disponível em
<http://portal.acm.org/citation.cfm?id=990392>, <Acesso em: 10 de outubro de
2008>.
65
ANEXOS
66
Anexo 1
![UNIVERSIDADE FEDERAL DE UBERLÂNDIA SAMANTHA LAU … · F162 Faiola, Samantha Lau Ferreira Almeida, 1986- 2019 As Leis no Contrato Social de Jean-Jacques Rousseau [recurso eletrônico]](https://static.fdocumentos.com/doc/165x107/5fb7b1f669922363b30dd649/universidade-federal-de-uberlndia-samantha-lau-f162-faiola-samantha-lau-ferreira.jpg)
