Em Direção A Um Ambiente de Desenvolvimento de Software Orientado Por Comportamento

Ps-Graduao em Cincia da Computao
Em Direo a um Ambiente de Desenvolvimento de Software Orientado por

Comportamento
Por
Alvaro Magnum Barbosa Neto
Dissertao de Mestrado Profissional
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, MAIO/2015
UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMTICA
PS-GRADUAO EM CINCIA DA COMPUTAO
ALVARO MAGNUM BARBOSA NETO
Em Direo a um Ambiente de Desenvolvimento de Software Orientado por

Comportamento
Este trabalho foi apresentado Ps-Graduao em Cincia

da Computao do Centro de Informtica da Universidade
Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre Profissional em Cincia da
Computao.
ORIENTADOR: Prof. Dr. Vinicius Cardoso Garcia
RECIFE, MAIO/2015
ii
Dedico este trabalho a toda minha

famlia, principalmente a minha esposa
que est sempre do meu lado e a quem
amo tanto. Dedico tambm a meus
pais e a minha irm.
AMO VOCS.
iii
"Eu sou o Alfa e o mega, o Primeiro

e o ltimo, o Princpio e o Fim. Felizes
as pessoas que lavam as suas roupas,
pois assim tero o direito de comer a
fruta da rvore da vida e de entrar na
cidade pelos seus portes!"
Apocalipse 22:13-14
iv
Agradecimentos
Inicialmente, agradeo ao nico que digno de toda honra e toda glria: Deus.
Agradeo o dom da vida, a famlia que Ele me deu e, principalmente, Sua graa e
misericrdia que abundam a vida deste grande pecador.
Agradeo a minha esposa, Roberta Arruda, que me incentivou e cobrou
perseverana ao longo de todo trabalho. Sem seu amor, carinho e cuidados muitas de
minhas conquistas no teriam o mesmo sabor que tm hoje. Agradeo sua pacincia e
tolerncia todas as vezes em que tive que me dedicar a pesquisa e no a ela. Agradeo
sua ajuda, pois, ainda que da rea do Direito, e no de Tecnologia, procurou e indicou
pessoas conhecidas de TI para avaliarem meu trabalho. Te amo demais. Juntos, somos
UM.
Aos meus pais, Alvaro Barbosa e Marta Sueli. Muitos de meus princpios e
educao foram enraizados por eles. Seus exemplos e condutas influenciaram a minha
vida. A maior parte de minha vida passei ao lado deles, foram momentos de muitas
alegrias e aprendizados. Meus pais nunca deixaram de me incentivar a crescer tanto
acadmica, quanto profissionalmente. Por estes motivos e muitos outros, a eles dou
honra. Amo vocs.
A minha irm, Marta Monike, por quem tenho grande amor e carinho. Sua ateno
e seu jeito meigo de me tratar me do foras para fazer muitas coisas. Ela me incentivou
bastante com suas especializaes e sua busca por crescimento no meio acadmico.
Amo voc.
Ao meu orientador, o Dr. Vinicius Cardoso, que sempre falou claramente o que
prestava e o que no prestava em minhas pesquisas e por me ensinar que,
independentemente do problema, temos que contornar e ir em frente. Todos passam por
dificuldades e somos responsveis por enfrenta-los e venc-los. Sua objetividade, clareza
e simplicidade em nortear o caminho, se mostraram muito desafiadores e estimulantes:
algo, mais ou menos, como O caminho esse, o resto depende de voc e no de mim.
Aos professores do curso que, pela experincia de fazerem parte de uma das
universidades federais mais importantes do pas, e com grande destaque no cenrio
nacional de tecnologia, nos orientaram e nos incentivaram com paixo e afinco. Souberam
nos mostrar como eliminar o descartvel e focar no que importante e, principalmente,
que nem sempre o caminho ser fcil.
Aos amigos e colegas da turma do mestrado profissional que se uniram durante
todo o curso, estudaram e trocaram ideias. Em especial agradeo a turma de Joo
Pessoa: Ernandes e Tales. Montamos uma equipe arrasadora do incio ao fim.
Estudamos, trabalhamos, sofremos e nos alegramos juntos. Infelizmente por duas notas
B, no ficamos com 100% de nota A. Quem sabe em um doutorado.
Aos companheiros de profisso da Paraba Previdncia que adotaram a
ferramenta (que foi um dos frutos desse trabalho) dentro do ambiente corporativo e
procuraram utilizar e se beneficiar dela, contribuindo com dados estatsticos e ideias.
Resumo
Criado por Dan North, o BDD (Behavior Driven Development) uma tcnica de
desenvolvimento gil de software baseada no TDD (Test Driven Development) e que
foca no teste de software orientado por comportamentos, isto , concentra-se nas
razes pelo qual o software criado e nos requisitos de comportamento do negcio.
A utilizao da tcnica traz uma srie de benefcios para projetos de desenvolvimento
de software, contudo, ela no tem uma aceitao to grande no mercado e , muitas
vezes, preterida em relao ao TDD. Esse trabalho faz uma anlise dessa situao e
tambm prope um ambiente que visa facilitar a adoo do BDD atravs da anlise
dos seguintes questionamentos: quais caractersticas devem fazer parte de uma
ferramenta para que ela facilite e dinamize a utilizao do BDD no contexto de um
projeto de desenvolvimento de software? Como permitir o uso da mesma por um
cliente leigo em testes, e, ao mesmo tempo, agregar valor para o gerente do projeto,
os testadores e os desenvolvedores de software? Como o cliente poderia acompanhar
em tempo real se o que ele espera obter est, de fato, sendo construdo? Como medir
o impacto da ferramenta? Atravs de anlises e resultados obtidos em mais de 12
anos de experincia profissional no setor de tecnologia de instituies pblicas e
privadas, alm de pesquisas na literatura, entrevistas com profissionais de TI e
avaliaes de ferramentas BDD no mercado, foi concebido um plugin: o BDD Plugin
for Mantis (BDDPM), uma ferramenta cujo objetivo facilitar a adoo do BDD em
projetos de desenvolvimento de software. Para avaliar o plugin quanto ao
cumprimento dos objetivos, foi utilizada uma tcnica denominada GQM
(Goal/Question/Metric), que permite, atravs de objetivos bem estabelecidos, planejar
e mensurar mtricas de avaliao. O BDDPM foi avaliado com sucesso dentro de um
ambiente de produo real, uma autarquia do Governo do Estado da Paraba: a
Paraba Previdncia. Este trabalho descreve, em detalhes, todo o ciclo de vida do
projeto, desde sua concepo, passando por sua criao, tecnologias utilizadas,
recursos includos, etc.
Palavras-chave: Plugin, BDD, Mantis, Testes, Software, Projeto, Desenvolvimento,
GQM, Anlise, Medio, Adoo do BDD, Acompanhamento de Testes, Escrita de
Testes.
vi
Abstract
Created by Dan North, BDD (Behavior Driven Development) is a software agile
development technique based on TDD (Test Driven Development). The BDD focuses
on software testing oriented by behaviors, that is, it focuses on the reasons why a
software is created and its business behavior. The use of the technique brings a
number of benefits for software development projects; however, BDD does not have
such a great market as the TDD: the first choice of the majority. This work brings an
analysis of this situation and also proposes an environment to facilitate the adoption of
BDD by examining the following questions: what characteristics should be part of a
tool so that it facilitate and streamline the use of BDD in a context of project software
development? How can it be used by an unexperienced client, and, at the same time,
add value to project managers, testers and developers? How the customer could
follow, in real time, if what he expects to, is really being built? How to measure the
impact of the tool? Through analysis and results obtained from over 12 years of
professional experience in the technology sector of public and private institutions, as
well as research in the literature, interviews with IT professionals and reviews of BDD
tools on the market, a plugin was developed: the BDD Plugin for Mantis (BDDPM), a
tool which aims to facilitate the adoption of BDD in software development projects. To
assess the plugin in meeting the goals, a technique called GQM (Goal / Question /
Metric) was used; it allows, through well-established objectives, plan and measure
evaluation metrics. The BDDPM was successfully evaluated in a real production
environment, a company called Paraba Previdncia. This paper describes in detail the
entire life cycle of the project: from its conception, through its creation, the technologies
used, features included, etc.
Keywords: Plugin, BDD, Mantis, Tests, Software, Project, Development, GQM,
Analysis, Measurement, BDD Adoption, Test Tracking, Test Writing.
vii
Sumrio
NDICE DE TABELAS: ............................................................................................. XI
NDICE DE FIGURAS: ............................................................................................ XII
LISTA DE ABREVIAES: .................................................................................... XIV
REFERNCIAS BIBLIOGRFICAS: ........................................................................ 84
Anexos:
Anexo 1: Questionrio para Criao da do BDDPM ................................................ 88

Anexo 2: Questionrio para Avaliao GQM ........................................................... 89
Anexo 3: Autorizao de Utilizao do BDDPM na PBprev e Divulgao dos
Resultados ............................................................................................................... 90
Anexo 4: Relato Pessoal na rea de Teste de Software ......................................... 91
Captulo 1 Introduo
1.1.
Teste de Software: TDD e BDD na Prtica .................................................... 1
1.2.
Explicitando o Problema................................................................................. 3
1.3.
Viso Geral da Proposta ................................................................................ 5
1.4.
A Metodologia de Pesquisa Aplicada ............................................................. 7
1.5.
Estrutura e Resumo da Dissertao............................................................... 8
Captulo 2 A Situao do TDD e do BDD no Mercado

2.1.
O TDD .......................................................................................................... 10
2.2.
O BDD .......................................................................................................... 13
2.3.
TDD x BDD .................................................................................................. 15
Captulo 3 Ferramentas Disponveis no Mercado e o Plugin Criado

3.1.
Plataformas de Gesto de Projetos Online .................................................. 18
3.1.1.
Sobre o Jira............................................................................................... 19
3.1.2.
Sobre o Redmine ...................................................................................... 20
3.1.3.
Sobre o Trac ............................................................................................. 20
3.1.4.
Sobre o BugZilla ....................................................................................... 21
3.1.5.
Sobre o Mantis .......................................................................................... 21

viii
3.2.
A Escolha da Plataforma .............................................................................. 22
3.3.
O Plugin Criado ............................................................................................ 22
3.4.
Comparativo ................................................................................................. 25
3.5.
Licena do BDDPM ...................................................................................... 28
Captulo 4 O BDDPM: Mais Detalhes

4.1.
Metodologia de Desenvolvimento do BDDPM ............................................. 29
4.1.1.
Fase 1: Levantamento de Requisitos ........................................................ 29
4.1.2.
Fase 2: Desenvolvimento e Testes ........................................................... 34
4.1.3.
Fase 3: Implantao ................................................................................. 40
4.2.
Recursos do BDDPM na Prtica .................................................................. 41
4.2.1.
Configurao............................................................................................. 41
4.2.2.
Criao dos Testes de Aceitao ............................................................. 43
4.2.3.
Gerao do Cdigo de Teste .................................................................... 49
4.2.4.
Resultado dos Testes ............................................................................... 51
Captulo 5 Aplicao do GQM e Anlise dos Resultados

5.1.
Um Breve Contexto ...................................................................................... 52
5.2.
A Tcnica do Goal-Question-Metric (GQM) ................................................. 54
5.3.
O BDDPM segundo o GQM ......................................................................... 58
5.3.1.
Fase de Planejamento .............................................................................. 59
5.3.1.1.
Estabelecimento da Equipe GQM.......................................................... 59
5.3.1.2.
Seleo do Objeto de Avaliao ............................................................ 59
5.3.1.3.
Estabelecimento da Equipe de Avaliao do Projeto ............................ 60
5.3.1.4.
Criao do Plano de Projeto .................................................................. 60
5.3.1.5.
Treinamento e Promoo ...................................................................... 61
5.3.2.
Fase de Definio ..................................................................................... 61
5.3.2.1.
Definio dos Objetivos da Medio...................................................... 62
5.3.2.2.
Conduo de entrevista GQM ............................................................... 63
5.3.2.3.
Definio de questes/perguntas e hipteses ....................................... 65
5.3.2.4.
Definio das Mtricas .......................................................................... 70
5.3.2.5.
Produo do Plano GQM ....................................................................... 71
5.3.2.6.
Produo do Plano de Medio ............................................................. 73
5.3.2.7.
Produo do Plano de Anlise .............................................................. 74
5.3.3.
Fase de Coleta de Dados ......................................................................... 75
5.3.4.
Fase de Anlise de Dados ........................................................................ 75
5.4.
Avaliao do Resultado................................................................................ 76
ix
Captulo 6 Concluso
6.1.
Dificuldades Encontradas............................................................................. 79
6.2.
Trabalhos Futuros ........................................................................................ 80
6.3.
Contribuies ............................................................................................... 81
6.4.
Consideraes Finais ................................................................................... 82
ndice de Tabelas
Tabela 1: Ranking (TOP 10) de Linguagens de Programao da TIOBE
(Dezembro/2014) ....................................................................................................... 7
Tabela 2: Comparativo de retorno de resultado nos principais buscadores WEB (TDD
x BDD) ...................................................................................................................... 16
Tabela 3: Comparativo de retorno de resultado acadmico (TDD x BDD) .............. 16
Tabela 4: Comparativo entre BDDPM (Mantis) e BEHAVE (Jira) ............................ 26
Tabela 5: Testes do BDDPM em nmeros .............................................................. 34
Tabela 6: Objetivo de medio 1: Fcil de utilizar em termos de usabilidade ......... 63
Tabela 7: Objetivo de medio 2: Permitir a aplicao do BDD de maneira eficiente e
eficaz ........................................................................................................................ 63
Tabela 8: Objetivo de medio 3: Facilitar a adoo do BDD .................................. 63
Tabela 9: Objetivo de medio 4: Permitir a escrita dos testes pelos clientes ........ 63
Tabela 10: Avaliao do BDDPM: Resultado da entrevista GQM ........................... 65
Tabela 11: BDDPM: Anlise GQM (Bottom-Up) Mtricas Perguntas ............... 76
Tabela 12: BDDPM: Anlise GQM (Bottom-Up) Perguntas Objetivos............... 76
xi
ndice de Figuras
Figura 1: Questionamentos e fatos que culminam no problema "Como ir em Direo
a um Ambiente de Desenvolvimento de Software Orientado por Comportamento?" .. 4
Figura 2: Viso Geral da Proposta: Recursos Adoo do BDD Avaliao ........ 5
Figura 3: Viso Geral da Proposta: Ferramenta GQM Impactos ....................... 6
Figura 4: Ciclo do TDD ............................................................................................. 11
Figura 5: Teste de Aceitao descrito em GHERKIN ............................................... 15
Figura 6: Questionrio para Interface. Resultado da Pergunta 1 ............................. 31
Figura 10: Questionrio para Interface. Resultado da Pergunta 5 ........................... 32
Figura 11: Questionrio para Interface. Resultado da Pergunta 6 ........................... 33
Figura 12: Arquitetura de Testes do BDDPM ........................................................... 35
Figura 13: Arquitetura do Sistema BDDPM .............................................................. 37
Figura 14: Arquitetura da Aplicao de Pgina nica - BDDPM .............................. 39
Figura 15: Tela inicial do BDDPM aps a instalao ................................................ 42
Figura 16: BDDPM: Configurao do Plugin ............................................................ 42
Figura 17: BDDPM: Configurao do Projeto ........................................................... 43
Figura 18: Requisito do SSAC transformado em teste de comportamento .............. 44
Figura 19: BDDPM: Opo de acesso pgina de criao de testes ...................... 45
Figura 20: BDDPM: Criao de Caso de Uso (funcionalidade e descrio) ............. 45
Figura 21: BDDPM: Criao de Caso de Uso (prioridade do teste) ......................... 46
Figura 22: BDDPM: Criao de Caso de Uso (linguagem dos testes) ..................... 46
Figura 23: BDDPM: Criao de Caso de Uso (descrio do comportamento) ......... 46
Figura 24: BDDPM: Caso de Uso transformado em gherkin .................................... 47
Figura 25: BDDPM: Cdigo de teste gerado em C# ................................................. 48
Figura 26: Gerao de Cdigo de Teste em C# a partir dos testes do cliente ......... 50
Figura 27: Resultado de um teste no Visual Studio.................................................. 51
Figura 28: Resultado de um teste no BDDPM.......................................................... 51
Figura 29: Fases do GQM [Rini van Solingen et al, 1999] ....................................... 55
Figura 30: Paradigma do GQM ................................................................................ 56
Figura 31: Exemplo de um Abstraction Sheet ........................................................ 64
xii
Figura 32: Avaliao do BDDPM: Arquitetura do plano GQM .................................. 71

Figura 33: Avaliao do BDDPM: Plano GQM Objetivo 1.................................... 71
xiii
Lista de Abreviaes
ABNT
ACM
AJAX
API
ASF
BDD
BDDPM
BSD
BT
CAPES
CESAR
CMMI
COC
CSS
DOM
DR
DRY
DSL
FSF
GNOME
GPL
GQM
GT
HTML
HTTP
IDE
IEC
IEEE
ISO
JIT
JR
JS
JUG
MIT
MPROF
MVC
NASA
ORM
PBPREV
PHP
PL
PMBOK
QA
RBAC
RIA
RPC
Associao Brasileira de Normas Tcnicas

Association for Computing Machinery
Asynchronous JavaScript and XML
Application Programming Interface
Apache Software Foundation
Behavior Driven Development
Behavior Driven Development Plugin for Mantis
Berkeley Software Distribution
Bug Tracker
Coordenao de Aperfeioamento de Pessoal de Nvel Superior
Centro de Estudos e Sistemas Avanados do Recife
Capability Maturity Model Integration
Convention over Configuration
Cascading Style Sheets
Document Object Model
Doutor
Don't Repeat Yourself
Domain-Specific Language
Free Software Foundation
GNU Network Object Model Environment
General Public License
Goal-Question-Metric
Grounded Theory
HyperText Markup Language
Hypertext Transfer Protocol
Integrated Development Environment
International Electrotechnical Commission
Institute of Electrical and Electronics Engineers
International Organization for Standardization
Just In Time
Jnior
JavaScript
Java User Group
Massachusetts Institute of Technology
Mestrado Profissional
Model-View-Controller
National Aeronautics and Space Administration
Object Relational Mapping
Paraba Previdncia
Hypertext Preprocessor
Pleno
Project Management Body of Knowledge
Quality Assurance
Role-Based Access Control
Rich Internet Application
Remote Procedure Call
xiv
RSS
SCM
SEO
SGBD
SLA
SR
SSAC
SVN
TDD
TI
UFCG
UFPE
UI
URL
VCS
VS
WWW
XHTML
XML
Rich Site Summary

Source Code Management
Search Engine Optimization
Sistema de Gerenciamento de Banco de Dados
Service Level Agreement
Snior
SISPROTO - Solicitaes de Alterao e Correo
Subversion
Test Driven Development
Tecnologia da Informao
Universidade Federal de Campina Grande
Universidade Federal de Pernambuco
User Interface
Uniform Resource Locator
Version Control System
Visual Studio
World Wide Web
eXtensible Hypertext Markup Language
eXtensible Markup Language
xv
Captulo 1 Introduo
1.
Eu tive um problema. Enquanto estive

usando e ensinando prticas geis como o
desenvolvimento orientado a testes (TDD1)
em projetos em diferentes ambientes, sempre
me deparei com as mesmas confuses e malentendidos: programadores queriam saber
por onde comear, o que testar e o que no
testar, quanto testar, como denominar os
testes e como entender por que um teste
falha.
[DAN NORTH, 2006]
Este captulo faz uma apresentao geral deste trabalho e do problema a ser
tratado justificando-o e elucidando sua proposta de soluo. Tambm descreve as
tcnicas escolhidas, tanto para o desenvolvimento da ferramenta fruto do esforo,
bem como para avaliao dos resultados.
O captulo inicia-se na seo 1.1 com um breve sumrio do cenrio de testes de
software com BDD e TDD. Em seguida, na seo 1.2, o problema foco deste trabalho
explicitado para, na sequncia (seo 1.3), mostrar uma viso geral da proposta
para tratamento do problema. Por fim, a Seo 1.4 descreve a metodologia aplicada
na consecuo do trabalho e a 1.5 discorre sobre a organizao desta dissertao de
maneira a facilitar sua leitura e descrever, resumidamente, o que pode ser encontrado
em cada captulo.
1.1. Teste de Software: TDD e BDD na

Prtica
O objetivo do teste de software investigar o software com o objetivo de avaliar
sua qualidade dentro de um domnio/contexto. Dentro do processo encontra-se a
atividade de identificao de falhas e defeitos [Sommerville, 2011]. Estima-se que,
atualmente, 50% do tempo e do custo de projetos de software so dispendidos em
teste de software, um percentual considervel. Entretanto, mesmo considerando o
impacto dos testes, ou falta deles, na qualidade do software, observa-se que h um
gargalo entre a teoria que vista nas universidades e o que praticado no mercado
nas fbricas de software. Na prtica, a teoria tem que ser adaptada. Estas so
1
Test Driven Development (TDD) ou em portugus Desenvolvimento orientado a testes uma tcnica de
desenvolvimento de software que se baseia em um ciclo curto de repeties: primeiramente o desenvolvedor
escreve um caso de teste automatizado que define uma funcionalidade ou melhoria desejada em uma funo.
Em seguida produzido um cdigo que possa ser validado pelo teste para, posteriormente, o cdigo ser
refatorado para uma verso sob padres aceitveis.
afirmaes de profissionais com mais de 15 anos de mercado na rea de educao

em Teste de Software na obra "Software Testing and Quality Assurance" de
Kshirasagar Naik e Priyadarshi Tripathy. Experincia semelhante pode ser encontrada
em relato disponvel no ANEXO IV deste documento. Ainda em consonncia com
estas informaes, existem dois casos emblemticos de grandes empresas na rea
de tecnologia (Google e Microsoft), que corroboram com esta avaliao.
O artigo How Microsoft Builds Software (http://goo.gl/kvmLWZ), publicado na
Magazine Communications of the ACM por Michael A. Cusumano (49 publicaes,
313 citaes e mdia de 1.974 downloads por publicao) e Richard W. Selby (36
publicaes, 626 citaes e mdia de 1.844 downloads por publicao) fala sobre uma
das metodologias de desenvolvimento de software utilizada pela Microsoft.
Basicamente, a estratgia pela empresa manter o contato constante entre
desenvolvedores e testadores para facilitar a troca de informaes e garantir que a
criao dos testes seja a mais abrangente possvel. Essa tcnica intitulada de
"Aproximao Baseada em Sincronizao e Estabilizao". Ela tambm adota uma
outra tcnica, denominada Engenharia Conectada ao Cliente. Na prtica, a Microsoft
utiliza metodologias prprias para desenvolvimento, teste e qualidade de software.
Estas metodologias se baseiam nas melhores prticas do mercado. Em 2012 a
Microsoft realizou uma srie de visitas s Universidades Federais do Brasil
(https://goo.gl/bd2cca) e reforou a ideia de metodologias prprias
(http://goo.gl/hTFyb).
Seguindo o mesmo caminho, a Google fez uma apresentao para o DallasJUG
(http://goo.gl/IRnemv), um grupo de usurios Java, onde falou a respeito de como
utiliza as metodologias geis de desenvolvimento de software. No evento a empresa
classificou sua metodologia como uma "metodologia prpria" e afirmou utilizar as
melhores prticas encontradas no mercado para desenvolvimento orientado por
testes, contato constante com o cliente, iteraes curtas, definio de processos
claros, etc. Justificou a necessidade de uma metodologia prpria com a resposta de
que, para ela, as prticas tradicionais so muito eficientes para projetos de pequeno
e mdio porte, porm, para projetos de grande porte, necessrio fazer algumas
adaptaes para manter a eficcia e a eficincia.
De acordo com Dan North (http://goo.gl/HSzCm), geralmente as empresas
adotam testes de unidade com a abordagem do TDD2 como requisito bsico e
primordial para testes. Cada desenvolvedor escreve seu cdigo juntamente com
uma bateria mnima de testes de unidade. Depois o software passa por uma bateria
de testes exaustivos junto aos testadores com o objetivo de encontrar defeitos. Nesse
sentido, h muito esforo para evitar que um nico erro passe despercebido, porm
sem preocupao se a funcionalidade construda satisfazia a necessidade cliente.
Uma possvel explicao para as coisas serem assim pode ser o fato de que, muitas
vezes, manter o contato constante com o cliente custoso: ele pode estar localizado
geograficamente em lugar divergente do local da produo do software e/ou ele pode
no ter tempo para este contato constante e/ou ocorrem dificuldades na traduo da
2
Test Driven Development (TDD - Desenvolvimento orientado por teste) uma tcnica de desenvolvimento de
software que se baseia em um ciclo curto de repeties: primeiro cria-se o teste, depois o cdigo, depois
refatora-se o cdigo.
linguagem de negcio de alto nvel deste cliente (requisitos de usurio) para uma
linguagem tcnica (requisitos de sistema). Sob esta perspectiva, muito fcil
descrever e especificar funes tcnicas, por isso o TDD to utilizado. Por outro
lado, quando se fala em BDD3, ou seja, o comportamento do software, no h tantos
esforos em sua prtica: o BDD gera, pelo menos, 75% a menos de resultados em
sites de pesquisas comerciais e acadmicos, por exemplo.
Quando Dan North concebeu o Behavior Driven Development, seu objetivo era
buscar uma maior aproximao com o cliente do produto de software durante o
desenvolvimento do mesmo, pois o cliente um dos melhores stakeholders4 para
descrever o que ele mesmo espera do produto que est adquirindo. Infelizmente,
conforme citado anteriormente, a prtica do mercado mostrou que era muito
complicado trabalhar diretamente com o cliente. Surge, ento, a figura do Analista de
Requisitos, que o responsvel por fazer a ponte ente o que o cliente deseja, que
descrito em alto nvel, e a sua correspondente especificao tcnica, voltada para
desenvolvedores e testadores de software. Com isso, clientes de software se
distanciaram mais dos projetos de desenvolvimento de software e, consequentemente
do teste de software, e os analistas de requisitos ganharam mais responsabilidades.
O Cucumber5 foi um grande passo na tentativa de reaproximar o cliente da fase
de testes de seu produto. Ao utilizar uma linguagem especfica de domnio e Business
Readable, o Gherkin, um novo chamado ao maior engajamento dos clientes em
testes foi feito. Este tipo de linguagem foca na possibilidade de leitura e no
entendimento por parte do cliente. Com essa linguagem eles podem descrever o
comportamento esperado do software.
Apesar dos benefcios, o BDD no se aproxima do TDD em termos de aceitao.
Quais os motivos que levaram a este fato? Por que as empresas priorizam
funcionalidades em detrimento do comportamento? Mas, principalmente, como seria
possvel possibilitar uma maior adoo do BDD? Estes so alguns dos
questionamentos discutidos ao longo deste trabalho.
1.2. Explicitando o Problema

Com base no cenrio descrito anteriormente, e alm dos questionamentos j
apresentados, as seguintes perguntas tambm foram levantadas:
Behavior Driven Development (BDD - Desenvolvimento orientado por comportamento) uma tcnica de
desenvolvimento de software oriunda do TDD e que segue os mesmos princpios desse, entretanto foca no
comportamento do software esperado pelo cliente.
4
Stakeholder (em portugus, parte interessada ou interveniente), um termo usado em diversas reas como
gesto de projetos, administrao, engenharia de software, etc., e se refere a toda e qualquer parte interessada
e/ou afetada em um determinado mbito, contexto, projeto, empreendimento. Pode englobar tanto
participantes externos, quanto internos.
5
O Cucumber uma ferramenta de software utilizada por programadores/desenvolvedores para testar outros
softwares. O Cucumber foi escrito em Ruby e executa testes de aceitao BDD em uma linguagem de alto nvel
e semiformal (Gherkin). O Cucumber permite o teste de aplicaes criadas em diferentes plataformas (Java,
Ruby, PHP, .NET, etc.).
1. Quais caractersticas devem fazer parte de uma ferramenta para que

ela facilite e dinamize a utilizao do BDD no contexto de um projeto
de desenvolvimento de software?
2. Como permitir o uso da mesma pelo cliente do produto de software,
facilitando sua aproximao dos testes, e, ao mesmo tempo, agregar
valor para o gerente do projeto, os testadores e os desenvolvedores
de software?
3. Que caractersticas devem fazer parte de uma soluo para que ela
facilite a adoo do BDD?
4. Como medir o impacto e sucesso da ferramenta proposta?
Foi observado que o BDD , muitas vezes, ignorado em detrimento do TDD e
que o contato com o cliente e o acompanhamento (por este mesmo cliente) dos testes
do projeto em tempo real so falhos e podem ser custosos para uma empresa. As
organizaes esperam entregar um sistema livre de defeitos, mas no priorizam, com
o mesmo afinco, a questo comportamental do software. Dessa maneira, constroemse produtos com funcionamento LIVRE de falhas e comportamento CHEIO de falhas.
Este fato, aliado s perguntas, convergem para um questionamento mais amplo,
Como ir em direo a um ambiente de desenvolvimento de software orientado
por comportamento?, que d nome a este trabalho. A figura a seguir retrata o
problema:
COMO PERMITIR O
USO DO BDD POR
USURIOS DE
DIFERENTES NVEIS?
COMO PERMITIR O
ACOMPANHAMENTO
REAL DO TESTE DE
SOFTWARE?
QUAIS AS
CARACTERSTICAS E
RECURSOS
FACILITARIAM A
ADOO DO BDD?
BDD PRETERIDO EM
RELAO AO TDD
COMO AVALIAR O
SUCESSO E IMPACTO
DESTES RECURSOS?
PROBLEMA
...
Figura 1 Questionamentos e fatos que culminam no problema Como ir em Direo a um

Ambiente de Desenvolvimento de Software Orientado por Comportamento?
1.3. Viso Geral da Proposta

A soluo para o problema deveria ser algo que respondesse, ou ajudasse a
responder, as perguntas enumeradas anteriormente e que vo ao encontro do
ambiente desejado: um ambiente orientado por comportamento. Foram estabelecidos
um conjunto de recursos que auxiliam e automatizam boa parte do processo com o
BDD (participao do cliente, escrita de testes, acompanhamento de testes, gerao
automtica de cdigos, etc.) com o objetivo de facilitar sua adoo. Estes recursos
foram encapsulados em uma ferramenta de software: O BDDPM, um dos frutos deste
trabalho.
Ainda como parte da proposta, os recursos incorporados na ferramenta foram
rigorosa e sistematicamente avaliados a fim de se entender seus resultados e
impactos como soluo do problema. Esta avaliao foi feita com o GQM6 dentro de
um ambiente de produo real. As caractersticas do GQM, detalhado no Captulo 5,
facilitam avaliao de projetos desse tipo, onde, a princpio, no se sabe o que deve
ser medido em relao ao produto de software.
As figuras 2 e 3 retratam a proposta:
RECURSOS PARA
AUXILIAR E
AUTOMATIZAR BOA
PARTE DO PROCESSO
COM BDD.
FOCO EM
CARACTERSTICAS
QUE FACILITEM A
ADOO DO BDD
AVALIAO
SISTEMTICA
AMBIENTE DE DESENVOLVIMENTO ORIENTADO POR COMPORTAMENTO
Figura 2 Viso Geral da Proposta: Recursos Adoo BDD Avaliao
GQM uma abordagem para o estabelecimento de um sistema de medio (levantamento de mtricas de

avaliao), normalmente utilizada na rea de software.
Figura 3 Viso Geral da Proposta: Ferramenta GQM Impactos
Para aplicar a proposta dentro de limites razoveis de pesquisa, o escopo do

problema foi estreitado, minimizando a quantidade de variveis e cenrios. O seguinte
escopo foi definido:
1. Seria
criado
um
plugin
para
uma
plataforma
de
gesto/acompanhamento de projetos de software j estabelecida no
mercado. A plataforma escolhida foi o Mantis Bug Tracker
2. O tipo dos projetos a serem testados com a ferramenta deveriam ser
Projetos de Desenvolvimento de Software. A linguagem dos
projetos deveria ser C#.NET (Microsoft).
3. A ferramenta seria testada em um nico ambiente e conjecturas
sobre sua utilizao em maior escala seriam estabelecidas.
O Mantis um sistema de gesto WEB para acompanhamento de problemas e
defeitos de (geralmente) software e projetos de software. uma ferramenta Open
Source7 construda com a linguagem de programao PHP e que roda em Windows,
Linux ou Mac OS X. Por este motivo, a ferramenta, que recebeu o nome de BDD
Plugin for Mantis BDDPM, foi construda na mesma linguagem.
O Mantis foi a plataforma escolhida pela familiaridade da equipe de
desenvolvimento com a linguagem PHP. Alm disso, na pgina de listagem de plugins
disponveis para o sistema no site oficial da ferramenta, no existem plugins que
ofeream suporte a BDD. Apesar da escolha, muitas das funcionalidades do BDDPM
esto no Front-End8 da aplicao com Java Script para facilitar portabilidade futura
para outras plataformas como o Jira, Mantis, RedMine, Trac, BugZilla, etc.
A linguagem de programao dos projetos (C#.NET) tambm foi escolhida pela
familiaridade da equipe de desenvolvimento com a mesma. De acordo com o Ranking
da TIOBE9, PHP e C# possuem, juntas, 7.074% do mercado; sendo, respectivamente,
a 5 e a 6 linguagens mais utilizadas.
7
De acordo com a OSI (Open Source Initiative - http://opensource.org) um software dito Open Source (Cdigo
Aberto) quando pode ser livremente utilizado, modificado e compartilhado, tanto a verso original quanto a
modificada. A OSI a atual mantenedora do Open Source.
8
Em cincia da computao, front-end e back-end so termos generalizados que se referem s etapas inicial e
final de um processo. O front-end responsvel por coletar a entrada em vrias formas do usurio e processla para adequ-la a uma especificao em que o back-end possa utilizar. O front-end uma espcie de interface
entre o usurio e o back-end.
9
O Ranking da TIOBE (http://tiobe.com/index.php/content/paperinfo/tpci/index.html) um renomado
indicador da popularidade das linguagens de programao do mercado. O ndice atualizado uma vez por ms.
Os resultados so baseados no nmero de usurios/desenvolvedores ao redor do globo, cursos e fabricantes de
software, alm de nmero de resultados nos principais buscadores da WEB.
Posio
1
2
3
4
5
6
7
8
9
10
Linguagem de Programao
C
Java
Objective-C
C++
C#
PHP
Java Script
Python
Visual
Perl
ndice
17.588%
14.959%
9.130%
6.104%
4.328%
2.746%
2.433%
2.287%
2.235%
1.826%
Tabela 1 Ranking (TOP 10) de Linguagens de Programao da TIOBE (Dezembro/2014)
1.4. A Metodologia de Pesquisa Aplicada

O principal objetivo ir em direo ao um ambiente de desenvolvimento de
software orientado por comportamento. Os recursos BDD com objetivo de facilitar a
adoo da tcnica foi feita aps Pesquisa Bibliogrfica descrita neste documento, bem
como pesquisa com 56 profissionais da rea de TI, sendo 47 desenvolvedores /
testadores, 06 gestores de projetos de TI e 03 clientes de produtos de software. O
questionrio pode ser visto no Anexo 1 deste documento. Este conjunto de recursos /
funcionalidades foram agregados a uma ferramenta, o BDDPM (Behavior Driven
Development for Mantis), entretanto, apenas a criao de uma ferramenta no seria
suficiente para avaliao dos resultados. Este produto teria que ser implantado em um
projeto real e tcnicas de avaliao consolidadas teriam que ser empregadas para
avaliao de resultados e estabelecimento de hipteses slidas, inclusive com
conjecturas para utilizao da ferramenta em larga escala. Como isso, seria possvel
entender os nveis de impacto da ferramenta como soluo para o problema
apresentado.
Antes do incio do desenvolvimento da ferramenta, foi feita uma avaliao de
mercado para se entender como o TDD e o BDD estavam sendo utilizadas dentro das
empresas no contexto da Gesto de Projetos de Desenvolvimento de Software. O
TDD foi includo na pesquisa, pois o BDD tem suas origens nesta tcnica; alm disso,
este comparativo evidenciou o quo incipiente se encontra a utilizao do Behavior
Driven Development em detrimento do TDD, alm da escassez de ferramentas
(plugins e extenses) para utilizao do BDD em projetos de software, o que seria
mais uma justificativa para a criao do BDDPM.
Aps a criao e implantao do BDDPM em um ambiente de produo real, a
saber, a Paraba Previdncia PBprev10, que autorizou a divulgao de seu nome e
resultados da avaliao (Anexo 3) que foi obtida atravs da aplicao da tcnica GQM
aps a experimentao do plugin em um projeto de desenvolvimento de software real.
O Captulo 5 descreve a tcnica e detalha como ela foi utilizada para avaliao da
ferramenta proposta.
10
http://www.pbprev.pb.gov.br
Este o contexto de criao e avaliao do BDDPM:

1. Equipe de desenvolvimento do BDDPM:
01 Analista de Sistemas: Alvaro Magnum Barbosa Neto
(ambn@cin.ufpe.br), 30 anos, Gestor de TI, 12 anos de
experincia.
01 Supervisor/Coordenador: Dr. Vinicius Cardoso Garcia
(vcg@cin.ufpe.br), 36 anos, Professor Adjunto - UFPE, 18 anos de
experincia.
2. Tempo de desenvolvimento do BDDPM: 90 dias
3. Empresa onde o BDDPM foi implantado: PBprev
4. Projeto no qual o BDDPM foi utilizado: SISPROTO Solicitaes de
Alterao e Correo (SISPROTO SAC SSAC)11
5. Equipe de desenvolvimento do SISPROTO SAC:
01 Analista de Sistemas: Daniel de Oliveira Fernandes
(mdof@pbprev.pb.gov.br), 24 anos, Coordenador de TI, 03 anos
de experincia.
02
Estagirios12:
Marcos
Fernando
Carneiro
(mmfc@pbprev.pb.gov.br) 26 anos, Estagirio, 06 meses de
experincia; e Joo Paulo Cordeiro (mjpc@pbprev.pb.gov.br) 27
anos, Estagirio, 06 meses de experincia.
6. Tempo de desenvolvimento do SISPROTO SAC: 45 dias13
7. Equipe de Avaliao do BDDPM: Mesma do Item 1
8. Tempo de Avaliao do BDDPM: 30 dias
1.5. Estrutura e Resumo da Dissertao

Esta dissertao est dividida em 04 partes: a primeira parte versa sobre o
contexto, a situao do BDD e ferramentas relacionadas no mercado; e os conceitos
e teorias necessrias para o entendimento do trabalho. A segunda parte descreve o
BDDPM em maiores detalhes, incluindo todo o processo de criao do plugin,
componentes e tecnologias utilizadas, licenas envolvidas, funcionalidades, etc. A
terceira envolve a avaliao do projeto, bem como concluses e comentrios sobre
os resultados aps a utilizao da ferramenta dentro de um ambiente de produo
real: a PBprev, uma autarquia do governo do Estado da Paraba que tem como
objetivo gerir o regime prprio de previdncia dos servidores pblicos estaduais. Por
fim, na ltima parte (PARTE IV), encontram-se as referncias bibliogrficas e os
anexos.
Todos os captulos deste documento contam com um resumo como introduo.
Descrio sumria do contedo de cada captulo:
11
Mais detalhes sobre a ferramenta no Captulo 5

Estudantes do curso de Cincia da Computao
13
Desenvolvido utilizando a tcnica do BDD atravs do BDDPM
12
PARTE I CONTEXTO
CAP. 2 A Situao do TDD e do BDD no Mercado. Discorre sobre as
prticas do TDD e BDD e o cenrio nas quais esto inseridas atualmente
no mercado.
CAP. 3 Ferramentas Disponveis no Mercado e o Plugin Criado.
Apresenta as principais ferramentas com foco em BDD do mercado
considerando-se as seguintes plataformas WEB de gesto de projetos de
desenvolvimento de software: Jira, Mantis, RedMine, Trac e BugZilla.
Tambm apresenta o BDDPM e traz um quadro comparativo com as
demais ferramentas apresentadas.
PARTE II BDDPM EM DETALHES
CAP. 4 O BDDPM: Mais Detalhes. Descrio detalhada de todo o
processo de desenvolvimento do plugin, incluindo desafios, cronograma e
etapas. Descreve a plataforma, utilitrios, ferramentas, componentes e
tecnologias envolvidas no desenvolvimento. Apresenta seus recursos
atravs de exemplos de utilizao e faz o enquadramento da ferramenta
em uma licena de software livre.
PARTE III AVALIAO E RESULTADOS
CAP. 5 Aplicao do GQM e Anlise dos Resultados. Descreve, de
maneira detalhada, como a tcnica do GQM (Goal/Question/Metric) foi
aplicada para o levantamento das medies de resultados alcanados pelo
produto de software.
CAP. 6 Concluso. Uma avaliao geral das dificuldades encontradas,
dos resultados alcanados pelo produto de software, suas contribuies e
um detalhamento das funcionalidades e recursos que sero implementadas
em verses futuras. O captulo finalizado com as consideraes finais a
respeito do trabalho.
PARTE IV REFERNCIAS BIBLIOGRFICAS E ANEXOS
Captulo 2 A Situao do TDD e do

BDD no Mercado
Neste captulo ser apresentar o atual cenrio do mercado em relao Teste
de Software com TDD e BDD.
A Seo 2.1 faz uma abordagem geral do TDD (Test Driven Development), seus
princpios e como ele utilizado no contexto de desenvolvimento de software. A Seo
2.2 aborda o BDD, desde de sua concepo, partindo do TDD, at os dias atuais nas
fbricas de software. Finalmente, a Seo 2.3 mostra um comparativo entre as
tcnicas em termos de uso e aceitao no mercado, onde observa-se que a adoo
do BDD chega a ser, pelo menos, 75% menor do que a do TDD.
2.1. O TDD
creditado a Kent Beck o ttulo de criador do TDD. Kent Beck um Engenheiro
de Software norte-americano, um dos pioneiros na rea de Padres de
Desenvolvimento de Software14 e Desenvolvimento gil de Software15, e tambm foi
um dos 17 signatrios originais do Agile Manifesto16.
A ideia por trs do Desenvolvimento Dirigido por Testes bastante simples: os
testes devem ser criados antes do cdigo de produo. Com qual objetivo? Possibilitar
que todo o cdigo, ou a maior parte dele, possua um teste que garanta seu
funcionamento. Alm disso, durante a evoluo do projeto de desenvolvimento de
software e, fica mais fcil garantir que as alteraes/incrementos no afetem a parte
do sistema que j est coberta por testes.
H uma corrente que afirma que Beck apenas redescobriu o TDD, uma vez que
o conceito fundamental da tcnica j havia sido empregado no passado e estava
apenas esquecido. O prprio Kent confirma a teoria. Um exemplo de utilizao da
metodologia anterior a Kent Beck, entre outros exemplos existentes, pode ser
conferido na obra Digital Computer Programming sob o ttulo Program Checkout
[D.D. McCracken, 1957], quando se sugeria que, para evitar problemas e erros, um
cliente deveria preparar exemplos de respostas esperadas em um caso de uso de um
14
De acordo com a Engenharia de Software, o Software Design Pattern, normalmente traduzido como "Padro
de Projeto de Software", ou "Padro de Desenvolvimento de Software", ou ainda "Padro de Design de
Software", uma soluo genrica e reutilizvel para um problema comum e recorrente em um determinado
contexto no Projeto de Software. No se trata de algo acabado, mas uma ideia, um template, uma receita para
resolver um problema e que pode ser utilizada em diversas situaes.
15
Desenvolvimento gil de software (do ingls Agile Software Development) ou Mtodo gil um conjunto de
metodologias de desenvolvimento de software cujo as solues evoluem atravs da colaborao de times auto
organizados e multifuncionais. O Desenvolvimento gil promove um planejamento adaptativo, desenvolvimento
evolucionrio/incremental, entregas incrementais e antecipadas; e encoraja respostas rpidas e flexveis a
mudanas no cenrio do Projeto de Desenvolvimento de Software.
16
O Agile Manifesto, traduzido para "Manifesto gil" uma declarao de princpios que fundamentam o
desenvolvimento gil de software. O manifesto contm quatro valores fundamentais e 12 princpios. Todos esto
descritos no endereo http://www.agilemanifesto.org.
10
sistema, antes de seu desenvolvimento iniciar. Essas respostas depois seriam

comparadas as sadas geradas pelo sistema.
A mecnica do TDD na prtica muito simples. Basta seguir o ciclo VERMELHOVERDE-REFATORA/RED-GREEN-REFACTOR:
1. Escrever um teste que falha (RED/VERMELHO)
2. Fazer o teste passar da maneira mais simples possvel (GREEN/VERDE)
3. Refatorar o cdigo (REFACTOR/REFATORA).
A ideia por trs de iniciar com uma falha (1) para garantir que o teste realmente
funciona e captura um erro. Conhecendo-se o erro/problema pode-se implementar
uma funcionalidade que faa a correo (2). Posteriormente a soluo pode evoluir,
sendo melhorada e revisada (3).
Geralmente o TDD feito atravs do Unit Testing ou Teste de Unidade17,
entretanto so dois conceitos que no devem ser confundidos. O Teste de Unidade
se refere ao O QUE est sendo testado e o TDD refere-se a QUANDO o teste
feito. Sendo assim, na pratica, a abordagem criar testes de pequenas partes do
cdigo, antes de implement-lo (TDD + Unit Testing).
Figura 7 Ciclo do TDD
O TDD , atualmente, uma das mais populares prticas entre as fbricas e os

desenvolvedores de software. Isso acontece por um motivo bastante simples: no
mercado de software, funcionalidades que no funcionam no agregam nenhum valor
ao negcio. O TDD aumenta a expectativa de funcionamento do software e, dessa
maneira, prov um valor real ao negcio. O mais bvio benefcio do TDD e o mais
facilmente identificado a sua capacidade de reduo de defeitos em um software.
17
Um sistema composto por um conjunto de unidades integradas. Uma unidade uma parte mnima/pequena
do cdigo do sistema que agrega uma funcionalidade. Na Engenharia de Software o teste dessa pequena parte
do cdigo chamado de "Teste de Unidade".
11
No artigo Realizing quality improvement through test driven development:

results and experiences of four industrial teams [Nachiappan Nagappan; E. Michael
Maximilien; Thirumalesh Bhat; Laurie Williams 2008] pesquisadores da Microsoft e da
IBM, duas das maiores fbricas de software do globo, indicam que h uma reduo
que varia de 60% (sessenta por cento) a 90% (noventa por cento) no nmero de
defeitos de software quando ele submetido a abordagem do Test Driven
Development (http://goo.gl/PFBHXV). Os dados foram obtidos atravs de anlises de
04 projetos de desenvolvimento de software, sendo trs na Microsoft e um na IBM.
Em um artigo mais recente, o Test-Driven Development as an Innovation Value
Chain [Ana Paula Ress; Renato de Oliveira Moraes; Mrio Srgio Salerno 2013],
realizado em uma empresa da rea financeira com cerca de 3.500 (trs mil e
quinhentos) funcionrios, obteve-se um resultado semelhante com um ganho variando
de 62% (sessenta e dois por cento) a 84% (oitenta e quatro por cento). Na poca foi
constatado que, quanto maior o projeto e maior a familiaridade dos desenvolvedores
com o TDD, maior era o benefcio da prtica.
Por outro lado, h uma corrente que defende que a utilizao do TDD pode
prejudicar, em vez de trazer benefcios. Os principais pontos criticados so:
Perda de produtividade para programadores de nvel jnior e pleno;

Situaes de difcil uso: bancos de dados, interface com usurio, funes
complexas, etc.;
Uso intenso de Mock Objects18 pode induzir a falhas, uma vez que eles
quem so testados, e no os objetos reais.
A cultura de criar testes antes de cdigo de produo nem sempre bem
aceita por programadores e gestores;
A aplicao tardia do TDD, ou seja, aps um certo ponto do ciclo de vida
do projeto de software, pode ser bastante trabalhoso. O TDD foi
concebido para ser aplicado a partir dos estgios iniciais de um projeto de
desenvolvimento de software;
Os testes do TDD so, tipicamente, escritos pelos desenvolvedores. Caso
haja uma falha na interpretao da especificao e/ou requisitos da
funcionalidade, existiro brechas na cobertura dos testes. Normalmente
os desenvolvedores possuem uma viso de criao, no voltada para
testes, o que pode comprometer a escrita dos mesmos.
A grande quantidade de testes de unidade pode trazer uma falsa
sensao de segurana, impactando na diminuio de esforos em outras
atividades de garantia de qualidade e segurana;
Confuso de conceitos entre TDD e Unit Testing.
Em 2014 ocorreu um debate na WEB entre trs grandes e reconhecidas

autoridades na rea de desenvolvimento de software: Kent Beck, j apresentado
18
Objetos Mock, objetos simulados ou simplesmente Mock (do ingls Mock Object), em desenvolvimento de
software, so objetos que simulam o comportamento de objetos reais de forma controlada. So normalmente
criados para testar o comportamento de outros objetos. Em outras palavras, os objetos Mock so objetos falsos
que simulam o comportamento de uma classe ou objeto real para que possamos focar o teste na unidade a
ser testada.
12
anteriormente e criador do TDD; David Heinemeier, criador do Ruby on Rails19; e

Martin Fowler, autor, conferencista e Engenheiro de Software. O debate ganhou
notoriedade devido a participao dos trs. A srie de conversas entre eles foi
intitulada Is TDD Dead? (O TDD est morto?), foi aberta ao pblico em geral e
tambm disponibilizada na pgina de Martin Fowler atravs do endereo
http://martinfowler.com/articles/is-tdd-dead nos formatos de udio, vdeo e texto.
Tudo comeou quando David expressou sua insatisfao com TDD e Testes de
Unidade na comunidade do Ruby on Rails. Ele explicitou o problema da confuso
entre TDD e Unit Testing, falou dos problemas com a utilizao de Mocking, etc.
Kent explicou que, nem sempre, a utilizao do TDD indicada; exemplificou com um
evento promovido pelo Facebook20, onde metade dos projetos trabalhados no
permitiam uma fcil integrao com o TDD. Kent acrescentou que, com a utilizao
do Test Driven Development, os programadores passam a ter mais confiana em seus
cdigos, porm reconheceu que a utilizao de objetos Mock podem dificultar a
refatorao do cdigo, acrescentando que esta utilizao pode ser evitada.
Apesar de inconclusivo, pois os 03 participantes mantiveram sua opinio no final
do debate (Kent e Martin mais favorveis ao TDD e David menos favorvel), todos
concordaram no ponto que, independentemente da utilizao do TDD, os cdigos de
um sistema deveriam estar cobertos por algum tipo de teste automtico21, que possa
ser facilmente executado ao longo do projeto e escritos de uma maneira a procurar
evidenciar ao mximo falhas no cdigo. Tambm concordaram que o sucesso da
utilizao do Test Driven Development iria variar dependendo do tipo de projeto.
2.2. O BDD
O BDD (Behavior Driven Development) uma tcnica de desenvolvimento gil
de software baseada no TDD. Ela segue, portanto, os mesmos princpios do TDD. Na
verdade, o BDD tambm TDD, entretanto, em vez de focar nas funcionalidades, foca
no comportamento. Foi criado por Dan North com o objetivo de responder/solucionar
algumas perguntas cujo TDD no era capaz de responder, ou respondia de forma
incipiente. North entendeu que, para elucidar os questionamentos, fazia-se necessrio
uma colaborao entre todos os envolvidos no projeto do software, os stakeholders:
desenvolvedores, gestores, setores de qualidade, pessoas no tcnicas, etc. BDD
significa Desenvolvimento Orientado por Comportamento, o objetivo , literalmente,
testar o comportamento esperado do software pelos stakeholders, concentrando-se
nas razes pelas quais o cdigo est sendo criado, e no em detalhes tcnicos. Por
19
Ruby on Rails, ou simplesmente Rails, um framework Open Source para criao de aplicaes web. Enfatiza
a utilizao de padres de projetos e paradigmas bem conhecidos na Engenharia de Software (COC - Convention
over Configuration, DRY - Don't Repeat Yourself, MVC - Model View Controller, etc.)
20
Rede Social online lanada em 2004 e disponvel atravs do endereo facebook.com.
21
Automao de teste o uso de software para controlar a execuo do teste de software, a comparao dos
resultados esperados com os resultados reais, a configurao das pr-condies de teste e outras funes de
controle e relatrio de teste. De forma geral, a automao de teste pode iniciar a partir de um processo manual
de teste j estabelecido e formalizado.
13
esse motivo, os testes so escritos em uma linguagem de maior alto nvel para facilitar
o entendimento e o contato entre todos os envolvidos.
Com esta abordagem, descrita no endereo de Dan North
(http://dannorth.net/introducing-bdd), as perguntas poderiam ser respondidas da
seguinte maneira:
1. Escopo do teste o que deve e o que no deve ser testado? Deve ser
considerado como teste prioritrio tudo que o cliente espera ser entregue,
todos os comportamentos esperados.
2. Como entender melhor os testes e o motivo pelos quais eles falham?
O desenvolvedor deixa a perspectiva da viso de FUNES
implementadas e foca nos COMPORTAMENTOS esperados pelo cliente.
Sendo assim, um teste vai falhar quando um comportamento esperado
pelo cliente no for alcanado.
3. Onde o teste inicia e onde ele termina? Sabendo-se o desejo do cliente,
basta implementar estritamente o que desejado: nem mais, nem menos.
4. Como denominar os testes? Os testes passam a ser uma viso de todos
os stakeholders, ento, em vez de utilizar linguagens puramente tcnicas,
so escritos em mais alto nvel com descries claras e objetivas do que
est sendo testado. Isso facilita a comunicao entre todos os envolvidos.
5. Quanto deve ser testado? O necessrio para garantir o comportamento
desejado pelo cliente.
O grande potencial do BDD encontra-se na possibilidade de escrever testes de
aceitao22 comportamental do software atravs de uma linguagem ubqua23
compartilhada entre todos envolvidos no projeto de desenvolvimento, sejam pessoas
tcnicas ou no. Embora no seja a linguagem oficial do BDD para criao dos testes
de aceitao, o Gherkin, vem sendo amplamente utilizado para este fim devido ao
grande sucesso de sua utilizao no Cucumber.
Dan North indica um padro conhecido como Given When Then / Dado
Quando Ento, onde um cenrio de utilizao do software descrito atravs de uma
sequncia de passos. O Gherkin tem a vantagem de poder ser escrito em diversos
idiomas. Atualmente so 40 lnguas24 suportadas no Cucumber.
Considerando, como exemplo, um sistema de cadastramento de estudantes em
uma biblioteca central, o comportamento esperado do sistema poderia ser descrito da
maneira representada na Figura 8. uma descrio de alto nvel, perfeitamente
compreensvel por todos os stakeholders envolvidos no projeto e que facilita a
compreenso do que precisa ser testado:
22
Teste de aceitao uma fase do processo de teste no qual um sistema testado antes de sua disponibilizao.
Tem por funo verificar o sistema em relao aos seus requisitos originais, e s necessidades atuais do usurio.
23
Quando diferentes grupos ou equipes interagem constituindo uma interlinguagem com conceitos,
elementos e interpretaes comuns a todos, linguagem esta que precisa ser poderosa o suficiente para
potencializar a comunicao, facilitando o entendimento de fato e os acordos entre as partes de forma gil e
segura, com mnimo rudo. Trata-se de uma linguagem semiformal.
24
https://github.com/cucumber/cucumber/wiki/Spoken-languages
14
Funcionalidade: Cadastro de Alunos na Biblioteca Central

Com o objetivo de possibilitar o emprstimo de livros
Como o bibliotecrio
Ele deve ser capaz de cadastrar um aluno atravs do sistema
Cenrio: Cadastro Correto de Aluno
Dado que um aluno esteja matriculado no 2o perodo, ou superior
E que ele fornea uma matrcula vlida
Quando o cadastro for solicitado
Ento o cadastro dever ser aceito
Mas deve recusar, caso contrrio
Figura 8 Teste de Aceitao descrito em GHERKIN
O BDD segue os mesmos princpios do TDD e, consequentemente, o ciclo REDGREEN-REFACTOR. A diferena que o teste est voltado para o
COMPORTAMENTO do software que est sendo desenvolvido, e a maneira como os
testes so construdos envolve no apenas desenvolvedores e testadores, mas
todos os interessados com uma grande aproximao do cliente do produto. De fato, a
prpria poltica do BDD indica que os clientes, em vez de se distanciarem dos testes,
deveriam, eles mesmos, escrever os casos de aceitao. O gherkin permite este fim,
exigindo um mnimo de conhecimento estrutural e de funcionamento da linguagem.
2.3. TDD X BDD

A comunidade BDD online menor e menos ativa que a comunidade TDD; podese citar, como exemplo, o grupo oficial do BDD (https://goo.gl/AJodLS) criado por Dan
North que contava, at a data de publicao deste material, com apenas 604
(seiscentos e quatro) membros, enquanto que um simples grupo no oficial do TDD
(https://goo.gl/E4Kqyi) ultrapassa esta marca. Acrescenta-se que, uma pesquisa por
"TEST DRIVEN DEVELOPMENT" no Google (www.google.com) retorna,
aproximadamente, 703.000 (setecentos e trs mil) resultados enquanto que a
pesquisa por "BEHAVIOR DRIVEN DEVELOPMENT" retorna, aproximadamente,
177.000 (cento e setenta e sete mil) resultados. O comparativo (ver Tabela 2) tambm
foi feito no Bing (www.bing.com) e no Yahoo (www.yahoo.com), incluindo-se assim os
resultados obtidos de 03 importantes e reconhecidas ferramentas de busca de nvel
global. No foi feita uma comparao direta entre os termos TDD e BDD, pois BDD
tambm um acrnimo para termos bastante comuns na lngua inglesa (Binary
Decision Diagram, Body Dysmorphic Disorder, Business Driven Development, etc.), o
que traria erro nos resultados. A diferena tambm foi evidenciada na pesquisa por
artigos acadmicos (IEEE25, Google Scholar26, ACM27, CitesserX28, Capes29). Ver
Tabela 3.
25
https://www.ieee.org
http://scholar.google.com
27
http://dl.acm.org
28
http://citeseer.ist.psu.edu
29
http://www.periodicos.capes.gov.br
26
15
Aliando estes dados s informaes obtidas do ambiente empresarial atual,

conclui-se que, em relao a utilizao e participao no mercado, o BDD ainda se
apresenta de maneira incipiente em comparao ao TDD, gerando pelo menos 75%
(setenta e cinco por cento) a menos de resultados. Todas as pesquisas foram
realizadas em dezembro de 2014.
Sistema de Busca
GOOGLE
BING
YAHOO
Qtde. de Resultados - TDD

703.000
1.040.000
1.000.000
Qtde. de Resultados - BDD

177.000
63.000
62.800
Tabela 2 Comparativo de retorno de resultado nos principais buscadores WEB (TDD x BDD)
Sistema de Busca
IEEE
GOOGLE SCHOLAR
ACM Digital Library
CITESEERX
ACM
PERIDICOS/CAPES
Qtde. de Resultados - TDD

407.000
11.300
1.448
1.745
309
143
Qtde. de Resultados - BDD

34.300
538
62
47
8
7
Tabela 3 Comparativo de retorno de resultado acadmico (TDD x BDD)
A forma como o TDD e o BDD so aplicados dentro das empresas, na prtica,

varia bastante. Alguns dos fatores que afetam esta utilizao so:
Porte dos Projetos Estudos mostram que o TDD obtm melhores

resultados em projetos de grande porte [Nachiappan Nagappan et al,
2008]. Por este motivo as empresas, ou no aplicam TDD nos projetos
pequenos, ou enxugam o TDD para que ele possa ser aplicado nesses
projetos.
Cultura da Empresa e Objetivos da Empresa Algumas empresas no
possuem a cultura de testar o software desenvolvido por elas; o motivo
para isso bastante variado. No caso da PBprev, por exemplo, o TDD
e/ou o BDD foram aplicados em apenas 50% dos projetos de
desenvolvimento de software nos ltimos 02 anos. Todos de maneira
superficial. A justificativa que a empresa no voltada para venda de
software, eles so criados para uso interno e a alta gesto alega que no
h a necessidade de se investir em uma equipe de testes, nem em tempo
e esforos em atividades relacionadas qualidade de software. Alm
disso os projetos so pequenos e de baixa complexidade.
Experincia e Opinio de Colaboradores No h consenso at
mesmo entre especialistas na rea. David Heinemeier, criador do Ruby
on Rails, prega que o TDD est morto. Kent Beck v potencial na tcnica.
Como colaboradores de empresas, essas vises afetam como eles
trabalham e, consequentemente, na forma como os mtodos so
utilizados dentro das empresas.
Em muitas empresas o BDD, ou no adotado, ou colocado em segundo plano

em detrimento do TDD. Na PBprev, por exemplo, o nmero de projetos que utilizam
TDD 03 vezes maior que o de projetos que utilizam BDD. Grande parte disso se
16
deve a, j discutida, cultura amplamente adotada na qual as empresas esperam

entregar um sistema livre de defeitos sem se preocupar com a entrega de valor ao
cliente, ou seja, um produto que atende as expectativas de comportamento esperadas
pelo cliente.
Existe um ponto onde este problema inicia: a escrita dos testes. Quem deveria
escrever os testes, para que o BDD atingisse todo o seu potencial, deveriam ser os
clientes. BDD objetiva aproximar os clientes (parte no tcnica) do pessoal tcnico
envolvido no desenvolvimento do projeto. Como, em muitos casos, o contato com o
cliente do produto nem sempre fcil e frequente, os prprios desenvolvedores e/ou
testadores acabam escrevendo o cdigo na viso de funcionalidades e acabam por
voltar ao TDD.
O BDDPM visa facilitar a adoo do BDD concentrando esforos no ponto da
falha. Ele foi concebido para que os prprios clientes faam a escrita dos testes e
possam acompanhar, eles mesmos, os resultados de maneira remota e atravs de
uma interface simples e amigvel, e deixando o Gherkin transparente, pois, ainda que
o Gherkin seja uma linguagem fcil e de alto nvel, ela pode se tornar um entrave para
clientes que no entendam sua sintaxe e/ou seu padro. O BDDPM procura extrair do
cliente o que importa, seu conhecimento de negcio, sem exp-lo aos conceitos de
BDD e, ainda assim, aplicando BDD.
A partir do prximo captulo o foco deste trabalho ser o BDD, quais plugins
existem nos mercados para se trabalhar com projetos de desenvolvimento de
software, como o BDDPM auxilia nesse processo e como BDDPM foi avaliado
considerando-se seus objetivos.
17
Captulo 3 Ferramentas Disponveis

no Mercado e o Plugin Criado
O objetivo deste captulo mostrar, de maneira geral e sucinta, quais
extenses/plugins BDD esto disponveis no mercado para utilizao em conjunto
com plataformas WEB de gesto de projetos/falhas de software e, com isso,
evidenciar a escassez desses produtos quando focam na tcnica do Behavior Driven
Development.
Embora existam no mercado diversas ferramentas stand-alone30 para trabalho
com o Behavior Driven Development, o BDDPM adota a abordagem de
extenso/plugin, ou seja, necessrio que exista uma plataforma por baixo para que
a ferramenta funcione. Conforme especificado nos captulos anteriores, o BDDPM visa
impulsionar a utilizao do BDD no contexto de projetos de desenvolvimento de
software. Nesse sentido, uma plataforma de gesto de projetos poderia prover todos
os recursos voltados a estes tipos de projetos, enquanto o BDDPM adicionaria os
recursos BDD. As 02 partes seriam beneficiadas: o BDDPM no precisaria se
preocupar em relao aos recursos gerenciais e, ao mesmo tempo, atuaria como
ferramenta de apoio plataforma, fornecendo funcionalidades para testes orientados
por comportamento, com impacto positivo nos ndices de sucesso dos projetos geridos
por ela; uma vez que estudos indicam que pode haver um ganho de at 35% no tempo
de desenvolvimento de software, quando boas prticas de testes so adotadas
[Nachiappan Nagappan et al, 2008]. Sendo assim, o BDDPM entra na categoria de
plugin. As principais plataformas de gesto de projetos do mercado, incluindo
plataforma sob a qual o BDDPM ir atuar, sero apresentadas neste captulo.
A primeira Seo deste captulo, a 3.1, inicia fazendo uma apresentao das
seguintes plataformas: Jira, Mantis, RedMine, Trac e o BugZilla, que so as mais
tradicionais no mercado. Tambm descreve, quando existir, os plugins BDD para cada
uma. A Seo 3.2 elenca os motivos para escolha do Mantis como plataforma para
criao do BDDPM. Para finalizar, na Seo 3.3 faz uma apresentao do plugin, fruto
deste trabalho; a 3.4 faz um comparativo deste plugin com outras ferramentas
encontradas no mercado e a 3.5 descreve a escolha da licena que rege o plugin.
3.1. Plataformas de Gesto de Projetos

Online
As plataformas escolhidas para avaliao e estudo deste trabalho so: Jira,
Mantis, RedMine, Trac e BugZilla. Os critrios para escolha dos mesmos foram: (1)
popularidade31 e (2) tempo de mercado32.
30
Programas autossuficientes, ou seja, para seus funcionamentos no necessitam de um software auxiliar.

http://goo.gl/RG7B18
32
http://goo.gl/DWN6Wc
31
18
As 05 ferramentas esto no TOP 10 entre as mais utilizadas atualmente. O

Mantis tem 15 anos de mercado e o Jira, RedMine, Trac e BugZilla contam com,
respectivamente (em anos): 13, 9, 9 e 17; tratam-se, portanto, de plataformas
consolidadas. Muito embora algumas delas sejam formalmente chamadas de
sistemas de acompanhamento de bugs33, na prtica elas tambm so aproveitadas
para: cadastro de atividades para desenvolvedores e testadores, cadastro de
funcionalidades do produto, comunicaes referentes ao projeto, registro de horas
trabalhadas, entre outros. Com isso, e atravs do acompanhamento desses registros,
elas acabam por ser utilizadas para fazer o acompanhamento do projeto de maneira
geral, e no apenas para gesto de falhas. Algumas delas j se intitulam como
ferramentas de gesto de projetos.
3.1.1.
Sobre o Jira
O Jira uma plataforma proprietria da Atlassian34 para gesto de projetos. De

acordo com a Atlassian, o Jira utilizado por mais de 25.000 clientes em 122 pases,
inclusive por grandes empresas como a Nasa35, Adobe36, BMW37, Cisco38, etc. Em
relao aos plugins que adicionam o suporte ao BDD ao Jira, o repositrio oficial da
Atlassian, o Atlassian Market, lista 02 ferramentas:
Behave for Jira Ferramenta paga para integrar o Jira ao Cucumber,

SpecFlow e outras ferramentas para automao de testes. Permite a
criao de testes de aceitao BDD. O repositrio do plugin
(http://goo.gl/BZL5kK) indica que ele recebeu, desde seu lanamento, 06
avaliaes, recebendo nota 2.5 de um total de 4. O Behave permite a
adio de Cenrios BDD escritos na linguagem Gherkin. Os testes so
executados atravs da integrao com as ferramentas de automao de
testes. Algumas telas do produto podem ser conferidas atravs das
Figuras 11, 12 e 13. uma ferramenta paga da Hindsight39. O site oficial
da ferramenta o http://hindsightsoftware.com/solutions/behave-for-jira.
O custo de uso varia dos $ 100,00/ano para 10 usurios at $1.200,00/ano
para mais de 10.000 usurios.
Cucumber Report Plugin Plugin gratuito que permite a integrao com
o Cucumber apenas para gerao de relatrios de resultados de testes
de comportamento, um front-end mais amigvel para os resultados
gerados no Cucumber. A pgina oficial do plugin indica que a ferramenta
recebeu 3 avaliaes, atingindo a nota 3 de 4 (http://goo.gl/wYzcgb). As
Figuras 14 e 15 exibem algumas telas do plugin. Este plugin distribudo
pela mesma empresa do plugin anterior, a Hindsight, e normalmente
utilizado em conjunto com aquele nos projetos cadastrados no Jira para
adio de suporte ao BDD mais a possibilidade de acompanhar os
33
Uma falha, um problema, um defeito de software comumente chamada de bug de software.

https://www.atlassian.com/software/jira
35
http://www.nasa.gov
36
http://www.adobe.com
37
http://www.bmw.com
38
http://www.cisco.com
39
http://hindsightsoftware.com
34
19
resultados dos testes atravs de relatrios do Cucumber dentro da

interface do Jira.
3.1.2.
Sobre o Redmine
O Redmine uma ferramenta WEB escrita em Ruby on Rails, gratuita e de

cdigo livre (Open Source) sob a licena GNU General Public License v2 (GPL 40).
Objetiva facilitar a gesto de projetos e o controle de falhas. Entre as diversas
entidades que utilizam o produto, encontram-se tambm rgos governamentais
como a Iniciativa de Cdigo Livre do Chile (http://www.softwarepublico.cl), o Ministrio
de Educao da Frana (http://dev-eole.ac-dijon.fr) e o Departamento de Energia dos
EUA (https://cdcvs.fnal.gov/redmine). Em relao aos plugins que adicionam o suporte
a BDD ao Redmine, o repositrio oficial da Plugins, disponvel atravs do endereo
http://www.redmine.org/plugins, no traz resultados. O site oficial do Redmine pode
ser acessado atravs do endereo http://www.redmine.org.
3.1.3.
Sobre o Trac
O Trac uma ferramenta simplificada para acompanhamento de problemas

gesto de projetos de desenvolvimento de software. Trata-se de uma ferramenta WIKI
voltada para este fim. Utiliza uma abordagem minimalista estimulando o contato
colaborativo entre todos os membros da equipe. Foi desenvolvido na linguagem de
programao Python. Inicialmente era distribudo sob a licena GPL, porm, desde a
verso 0.9, disponibilizado sob uma licena BSD41 modificada. O Trac utilizado em
vrios projetos reconhecidos na WEB (Django42, Tor43, Jquery44, etc.). O site oficial da
ferramenta o http://trac.edgewall.org. O repositrio de plugins do Trac acessvel
atravs do endereo eletrnico http://trac.edgewall.org/wiki/PluginList e seu site oficial
atravs do endereo http://trac.edgewall.org. Em relao plugins de testes, o
repositrio oficial lista 02 resultados (Test Manager Plugin for Trac45 e Test Case
40
A GNU General Public License, GNU GPL, ou simplesmente GPL, a designao da licena para software livre
idealizada por Richard Matthew Stallman em 1989, no mbito do projeto GNU da Free Software Foundation
(FSF). GPL a licena com maior utilizao por parte de projetos de software livre. A GPL visa garantir que
qualquer produto de software (regido por suas regras) possa ser compartilhado e modificado por qualquer
pessoa e permanea assim, indefinidamente. O software pode ser vendido, mas deve ser sempre aberto. A
verso 2 da licena prega que qualquer tentativa de impedir esta liberdade acarreta na impossibilidade de
distribuio do software modificado.
41
A licena BSD uma licena de cdigo aberto inicialmente utilizada nos sistemas operacionais do tipo Berkeley
Software Distribution (um sistema derivado do Unix). A licena BSD estabelece que o detentor do copyright cede
os direitos comerciais, mas exige crdito pela autoria e propriedade. A redistribuies do cdigo fonte devem
manter a notcia de copyright, as condies da licena e um aviso de que no h garantias nem se assume a
responsabilidade por prejuzos decorrentes do uso do software. Distribuies binrias devem reproduzir na
documentao essas informaes. Os nomes do autor e seus colaboradores no podem ser usados para endossar
ou promover produtos derivados sem permisso.
42
https://code.djangoproject.com
43
https://trac.torproject.org/projects/tor
44
http://bugs.jquery.com
45
http://trac-hacks.org/wiki/TestManagerForTracPlugin
20
Management Plugin46), nenhum deles especificamente voltados para BDD, ou seja,

suas utilizaes deveriam ser adaptadas para atingirem este fim.
3.1.4.
Sobre o BugZilla
O BugZilla uma ferramenta de software desenvolvido para auxlio na gesto de

projetos de desenvolvimento de software fornecendo um sistema de rastreamento de
defeitos. uma ferramenta consolidada no mercado, com mais de 17 anos de histria,
e um projeto de software livre, sendo mantido por voluntrios e constantemente
testado e utilizado pela Fundao Mozilla47. Mais de 14848 empresas ao redor do globo
utilizam o BugZilla, que utilizado em projetos notoriamente conhecidos na rea de
TI: Mozilla49, Linux Kernel50, GNOME51, KDE52, Apache Project53, Libre Office54, Open
Office55, Eclipse56, Red Hat57, Mandriva58, Gentoo59, Novell60, etc. O site oficial do
BugZilla acessvel atravs da URL https://www.bugzilla.org. A lista de plugins e
extenses disponveis para a plataforma podem ser conferidas atravs do endereo
oficial https://wiki.mozilla.org/Bugzilla:Addons. So listados 11 ferramentas que
podem ser utilizadas em conjunto com o BugZilla para atividades que envolvem testes
de software. Nenhuma delas tem foco em BDD.
3.1.5.
Sobre o Mantis
A plataforma escolhida para o desenvolvimento do BDDPM foi o Mantis. O

Mantis Bug Tracker um aplicativo WEB gratuito e open source para gesto e controle
de falhas. distribudo sob a licena GPL V2 e desenvolvido com PHP. Embora o
MantisBT seja bastante utilizado para controle de defeitos em produtos de software,
tambm utilizado como ferramenta de gesto de projetos. O nome Mantis e a sua
logomarca referem-se a uma famlia de insetos que costuma rastrear e se alimentar
de outros insetos (bugs), da o nome Bug Tracker (MantisBT). O projeto do Mantis foi
iniciado no ano de 2000. O site oficial da ferramenta pode ser acessado atravs do
endereo https://www.mantisbt.org. O canal oficial de plugins do Mantis est
disponvel atravs do endereo https://github.com/mantisbt-plugins. At a data de
publicao deste trabalho, o diretrio no listava plugins de testes e,
consequentemente, nenhum plugin/extenso para trabalho com Behavior Driven
Development.
46
http://trac-hacks.org/wiki/TestCaseManagementPlugin
https://www.mozilla.org
48
https://www.bugzilla.org/installation-list
49
https://bugzilla.mozilla.org
50
http://bugzilla.kernel.org
51
http://bugzilla.gnome.org
52
http://bugs.kde.org
53
http://issues.apache.org/bugzilla
54
http://bugs.libreoffice.org
55
http://www.openoffice.org/issues/query.cgi
56
http://bugs.eclipse.org/bugs
57
https://bugzilla.redhat.com/bugzilla
58
http://qa.mandriva.com
59
http://bugs.gentoo.org
60
https://bugzilla.novell.com
47
21
3.2. A Escolha da Plataforma

Facilitar a adoo do BDD no mercado, um dos principais objetivos do BDDPM.
Qualquer uma das plataformas citadas anteriormente poderia servir como base para
o novo plugin criado. De fato, se o objetivo a adoo da tcnica do Behavior Driven
Development, ento o BDDPM deveria estar disponvel para todas as plataformas,
pois, com isso, atingiria uma comunidade maior de usurios, potencializando os
objetivos. Contudo, para minimizar o escopo de trabalho, uma plataforma foi
escolhida. importante ressaltar, entretanto, que, embora o BDDPM foi desenvolvido
com grandes partes das funcionalidades feitas em Java Script e rodando do lado do
cliente/navegador. Essa estratgia facilitar a portabilidade para outras plataformas
no futuro.
Alguns critrios foram utilizados para escolha da plataforma:
A plataforma deveria estar em uma linguagem conhecida pela equipe

de desenvolvimento do BDDPM: com o objetivo de acelerar o
desenvolvimento do plugin, uma maior familiaridade da equipe de
desenvolvimento com a linguagem de programao da plataforma,
impulsionaria os resultados. A equipe do projeto tem experincia com C#,
Java e PHP.
A plataforma deveria ter poucos, ou nenhum, ferramental BDD
disponvel no mercado: se o objetivo facilitar a adoo, procurar por
um setor ainda no abastecido por recursos torna-se uma estratgia
interessante. No caso de empate, seria escolhida a plataforma com
menos opes gratuitas de plugins, visto que alguns deles so comerciais
e precisam ser comprados.
O Jira permite a criao de plugins e Java, porm j possui alguns componentes

disponveis do mercado, uns pagos, outros no. O Redmine no lista plugins BDD
disponveis em sua pgina de repositrios, porm utiliza a linguagem Ruby. O Trac
possui alguns plugins voltados para testes de software, porm foi escrito em Python.
O BugZilla segue o mesmo caminho do Trac, porm escrito em Perl. O Mantis a
nica plataforma que passa nos 02 critrios estabelecidos: uma plataforma que
utiliza PHP e no possui extenses BDD, por este motivo foi a plataforma escolhida
para criao do BDDPM.
3.3. O Plugin Criado

O BDD Plugin for Mantis (BDDPM) foi criado utilizando PHP no back-end e
HTML5, CSS e Java Script (JS) no front-end. O SGBD61 (Sistema de Gerenciamento
de Banco de Dados) utilizado o padro do Mantis: o MySQL. Toda parte da lgica
de negcios da ferramenta foi desenvolvida com JS para facilitar o porte do plugin
para outras plataformas como o Jira, Mantis, RedMine, Trac, BugZilla, etc. Na parte
do servidor foi colocada apenas a lgica para manipulao de arquivos e integrao
61
Um Sistema de Gerenciamento de Banco de Dados (SGBD) - do ingls Data Base Management System (DBMS)
- o conjunto de programas de computador (software) responsveis pelo gerenciamento de uma base de dados.
22
com o repositrio do projeto. Algumas mtricas do projeto completo (incluindo

componentes de terceiros):
64 arquivos de cdigo
7259 linhas de cdigo
669 linhas de comentrio
Ainda do ponto de vista tcnico, o BDDPM, alm do cdigo prprio, foi construdo
utilizando recursos de frameworks, extenses e componentes de terceiros:
PHP GIT Library (github.com/kbjr/Git.php)

PHP ORM Library (taq.github.io/torm)
AngularJS (angularjs.org)
StringJS (stringjs.com)
JQuery (jquery.com)
JQuery BlockUI Plugin (malsup.com/jquery/block)
JQuery Colorbox Plugin (jacklmoore.com/colorbox)
JQuery qTip Plugin (qtip2.com)
JQuery Sweet Alert Plugin (tristanedwards.me/sweetalert)
JQueryUI (jqueryui.com)
Metro UI CSS (metroui.org.ua)
O objetivo do BDDPM adicionar recursos ao Mantis de maneira a possibilitar a

utilizao do BDD em projetos de desenvolvimento de software. Espera-se agregar
valor para gerentes de projeto, com mais uma opo/tcnica/metodologia de
realizao de testes; para os clientes do projeto de software, com as opes de
incluso de testes por eles mesmos em linguagem simples e de alto nvel e a de
acompanhamento dos testes em tempo real de forma remota; para os
desenvolvedores do projeto com a gerao automtica dos cdigos de teste e de
comunicao com o plugin; e para os testadores do software com a criao automtica
de rotinas de testes.
O cliente participa de todo o processo descrevendo o comportamento desejado
do produto de software atravs de um formulrio dinmico onde ele estabelece o
comportamento para a funcionalidade desejada, dando um ttulo para ela, uma breve
descrio e um conjunto de passos no formato Given-When-Then (Dado que...,
quando..., ento...). Essas informaes so, ento, transformadas em uma linguagem
que utilizada em ferramentas BDD, o Gherkin 62. Basicamente uma linguagem
tcnica de alto nvel, que descreve passos, seguindo um conjunto de regras e que
facilmente processada por ferramentas BDD para realizar os testes de comportamento
do software, ou seja, a linguagem de comunicao intermediria entre a descrio
do comportamento que o cliente quer e a ferramenta que testa estes comportamentos.
Tanto o arquivo com a descrio do comportamento em Gherkin, quanto os
cdigos de testes gerados em C#.NET, so salvos no repositrio do projeto de
software. Os desenvolvedores, ento, tero acesso a estes cdigos atravs de um
62
O Gherkin a linguagem utilizada em ferramentas que trabalham com o BDD. uma linguagem de negcios
que permite descrever o comportamento do software sem detalhar como esse comportamento implementado.
23
ambiente de desenvolvimento configurado para o projeto: tipicamente o Visual

Studio63. Para que os testes possam ser executados a partir da IDE64, necessrio
um componente: o SpecFlow, uma implementao do Cucumber para a plataforma
.NET da Microsoft. Este componente quem entende o Gherkin e executa os testes
criados especificamente para eles. Trata-se de um requisito OBRIGATRIO para o
funcionamento do BDD Plugin for Mantis, cujo repositrio encontra-se no endereo
https://alvaromagnum@bitbucket.org/alvaromagnum/bddpm.git e o SpecFlow pode
ser baixado atravs do http://www.specflow.org.
Durante a criao dos testes, o cliente utiliza uma interface, que segue o padro
Wizard65, para escrever os testes de aceitao no padro GIVEN-WHEN-THEN. Essa
entrada do usurio , posteriormente, convertida em Gherkin e enviada ao repositrio
GIT66 do projeto. Dentre os recursos disponveis no Gherkin, estes so atualmente
suportados pelo BDDPM: Feature, Scenario, Given, When, Then, And, But.
Posteriormente os seguintes recursos sero includos: Background, Transformations,
Examples, Data Tables e suporte mltiplos idiomas. Segue a descrio dos
recursos:
Feature Descreve a funcionalidade que ser testada.

Scenario Descreve um caso de uso para a funcionalidade testada.
Given Descreve uma condio/fato de teste.
When Descreve um evento de teste.
Then Descreve uma consequncia de teste.
And Descreve uma adio de condio/fato de teste.
But Descreve uma ressalva de condio/fato de teste.
Background* Descreve uma situao verdadeira para vrios cenrios
de teste.
Transformations* Permite o trabalho com vrios tipos de dados de
entrada de testes (datas, nmeros, caracteres, valores monetrios,
valores lgicos, etc.).
Examples Permite o trabalho com diversas entradas de dados de testes
em um cenrio.
Data Tables* Permite o trabalho com diversas entradas de dados de
testes em uma condio/fato de teste.
63
O Visual Studio um ambiente de desenvolvimento integrado (IDE) da Microsoft. Ele usado para desenvolver
programas de computador para o Windows, bem como web sites, aplicaes web e servios web. O Visual Studio
capaz de construir software para diversas plataformas Microsoft como o Windows Azure, Windows Forms,
Windows Presentation Foundation, Windows Store, Microsoft Silverlight, etc.
64
IDE, do ingls Integrated Development Environment ou Ambiente Integrado de Desenvolvimento, um
programa de computador que rene caractersticas e ferramentas de apoio ao desenvolvimento de software
com o objetivo de agilizar este processo.
65
Assistente ou Wizard um padro de projeto de software amplamente utilizado em interface grfica do
usurio para prover um meio simples de realizar tarefas complexas em sistemas computacionais, atravs de um
esquema passo-a-passo.
66
GIT um sistema de controle de verso distribudo e um sistema de gerenciamento de cdigo fonte. O controle
de verso um sistema que registra as mudanas feitas em um arquivo ou um conjunto de arquivos ao longo do
tempo de forma que se possa recuperar verses especficas.
*
Recursos a serem adicionados posteriormente.
24
Os Step Definitions so gerados automaticamente na linguagem C#.NET

(posteriormente ser adicionado suporte ao JAVA) e salvos no repositrio do projeto.
Os resultados dos testes so acompanhados em tempo real pelo cliente a medida em
que vo sendo executados. Todas as atividades podem ser realizadas remotamente,
atravs da WEB, o que facilita o contato entre os envolvidos e possibilita um rpido
feedback67 para o cliente; o que faz parte da cultura de fortalecimento de
intercomunicao, pregado pelo BDD, entre os stakeholders do projeto.
De maneira resumida, este o fluxo de funcionamento do BDDPM:
1. O Gerente do Projeto cria o projeto de desenvolvimento de software no
Mantis.
2. O Gerente e/ou o Arquiteto do Projeto configuram o projeto adicionando
os dados de acesso ao repositrio GIT (usurio, senha e URL/Caminho
Local).
3. Os clientes do projeto descrevem, em alto nvel, o comportamento
desejado do software.
4. A descrio do cliente transformada em cdigos e rotinas de testes para
desenvolvedores e testadores. Os cdigos so adicionados
automaticamente ao repositrio do projeto.
5. Desenvolvedores conectados ao repositrio do projeto completam o
cdigo gerado para os testes para faz-los passar68.
6. Os testadores iro executar as rotinas de testes em horrios
estabelecidos pelo Gerente do Projeto. As rotinas geradas pelo BDDPM
iro se comunicar automaticamente com a ferramenta para atualizar o
Banco de Dados com os resultados obtidos nos testes.
7. O cliente, por fim, poder acompanhar os resultados dos testes em tempo
real, pois os resultados so gerados sempre que os testes so
executados. O cliente saber quais testes ainda no foram executados,
quais esto falhando e quais esto passando.
3.4. Comparativo
O BDDPM, conforme j explanado, um plugin/extenso para o MantisBT que
passa a estar disponvel no mercado a partir da publicao deste trabalho. A
ferramenta distribuda sobe a licena GPL. A Tabela 6 exibe um comparativo entre
o Behave, plugin para o JIRA, e o BDDPM. O Behave foi a nica extenso encontrada
para adio de suporte ao Behavior Driven Development considerando-se as
plataformas elencadas anteriormente.
67
O feedback, retorno de informao ou retorno o procedimento que consiste no provimento de informao

a uma pessoa sobre desempenho, conduta, ao ou resultado de algo ou algum.
68
No fluxo de testes do TDD, do qual o BDD deriva, o desenvolvedor espera um teste falhar antes de fazer o
cdigo par que o teste funcione da maneira correta. Essa estratgia chamada de Red-Green-Refactor. Quando
o teste falha, o desenvolvedor obtm uma Barra Vermelha (Red). O programador refaz os testes at que eles
funcionem da maneira correta e obtm uma Barra Verde (Green), depois s refatorar o cdigo para que se
tenha, alm de algo funcional, um cdigo de qualidade.
25
RECURSO
Ferramenta para Automao
Forma de Entrada de Testes de Aceitao
Preo
Gerao de Cdigo de Teste
Linguagem de Programao Suportada
Suporte a Todos os Recursos do Gherkin
Acompanhamento em Tempo Real
Suporte Comentrios e Anexos
BDDPM
SpecFlow
Gherkin/Wizard
Gratuito
SIM
C#
NO71
SIM
NO73
BEHAVE
Cucumber69
Gherkin/Texto
Pago
NO
VRIAS70
SIM
NO72
SIM
Tabela 6 Comparativo entre BDDPM (Mantis) e BEHAVE (Jira)
Ferramenta para Automao do Testes: esta a ferramenta que ir, de

fato, processar e executar os testes criados no plugin. O Behave utiliza o
Cucumber diretamente, o BDDPM utiliza uma implementao do
Cucumber para a plataforma .NET da Microsoft: o SpecFlow. O SpecFlow
compatvel com o Cucumber e listado na pgina oficial do Cucumber
(https://cukes.info/docs#cucumber-implementations).
Forma de Entrada de Testes de Aceitao: descreve a forma como os
testes so criados, trabalhados e inseridos no projeto. Tanto o BDDPM
como o Behave baseiam-se no Gherkin, uma vez que tudo baseia-se no
Cucumber. A diferena que no Behave, necessrio conhecer o
Gherkin e escrever os testes direto na linguagem. No BDDPM isso no
necessrio, o usurio detalha seus testes atravs de um Wizard que ir
fazer a montagem do Gherkin em Background.
Preo: indica se necessrio pagar algum valor para utilizar a
ferramenta. O Behave requer o pagamento de uma licena de uso que
varia de acordo com a quantidade de usurios da ferramenta. O BDDPM
uma soluo de cdigo aberto completamente gratuita.
Gerao de Cdigo de Testes: indica se a ferramenta capaz de fazer
a gerao dos cdigos de testes em alguma linguagem de programao.
O Behave permite apenas a criao/incluso dos testes. A criao dos
cdigos para testar o software do projeto fica a cargo do(s)
desenvolvedor(es) do projeto. O BDDPM atua de maneira diferente, ele
capaz de gerar cdigos de programao em C# com a base necessria
para que os testes possam ser implementados e executados. Alm disso,
o cdigo criado apresenta uma rotina de comunicao com o BDDPM
para envio de status dos testes.
69
H suporte para exportao para o SpecFlow e Behat

Como no h a gerao de cdigo de teste, o Behave independente de linguagem. Os testes sero executados
em cima do projeto cadastrado no Jira. Os projetos podem ser em qualquer linguagem.
71
O Gherkin Wizard do BDDPM ainda no permite o trabalho com todos os recursos do Gherkin. O Behave, por
possuir uma entrada em formato de texto livre, aceita todas as definies Gherkin suportadas pelo Cucumber. O
suporte completo s funcionalidades do Gherkin ser incorporado em uma verso futura do BDDPM.
72
O BDDPM atualizado medida que cada teste rodado, a cada execuo. No Behave os resultados dos testes
so acompanhados externamente, no Cucumber. Para acompanhamento do relatrio de testes, o Jira faz uso de
outra ferramenta, o Cucumber Report Plugin.
73
Estes recursos sero adicionados em uma verso futura.
70
26
Linguagem de Programao Suportada: identifica qual(is) a(s)

linguagem(ens) de programao suportada(s) pelas ferramentas. O
Behave executado em cima do Jira que uma plataforma de gesto de
projetos de software independente de linguagem. A mesma coisa
acontece com o BDDPM, que executa em cima do Mantis. A diferena
que o BDDPM voltado exclusivamente para projetos desenvolvidos em
C# e capaz de gerar cdigos de teste nessa linguagem. O Behave serve
para projetos em qualquer linguagem, entretanto no gera cdigo de
testes em nenhuma delas.
Suporte a todos os recursos do Gherkin: indica se a soluo
implementa todos os recursos suportados pelo Gherkin e,
consequentemente, todos os recursos possibilitados pelo BDD via
Cucumber ou compatvel. O BDDPM trabalha apenas com as
funcionalidades bsicas do BDD, visto que um projeto piloto 74. O
Behave implementa todas as funcionalidades e permite escrever os testes
diretamente em Gherkin.
Acompanhamento em Tempo Real dos Testes: indica se a ferramenta
capaz de prover relatrios em tempo real a respeito do status dos testes
executados. O BDDPM possui esta funcionalidade uma vez que capaz
de gerar cdigos de testes com rotinas de comunicao que enviam estas
informaes para o BDDPM sempre que um teste executado. O Behave
no apresenta esta caracterstica, o acompanhamento dos testes deve
ser feito via Cucumber.
Suporte Comentrios e Anexos: indica se a ferramenta d suporte
insero de informaes auxiliares aos testes criados, como comentrios
e anexos. O BDDPM no apresenta esta funcionalidade que
implementada no Behave.
O BDDPM foca na facilidade de uso com o objetivo de induzir os prprios clientes

do projeto de software a escreverem os testes de aceitao, partindo do princpio de
que eles no precisam entender os conceitos e/ou estrutura do Gherkin. O cenrio
desejado de utilizao da ferramenta o cenrio no qual apenas os clientes criam os
casos de uso das aplicaes, os desenvolvedores e testadores se preocupam no
desenvolvimento e nos testes, e o gestor do projeto faz o acompanhamento com o
auxlio dos ndices exibidos pelo BDDPM.
O BDDPM no tem o objetivo de ser uma ferramenta exaustiva sobre o Behavior
Driven Development, mas algo que traz o mnimo necessrio para aplicao do BDD
com foco no incentivo adoo da tcnica. O resultado deste esforo o fator
determinante para o futuro do BDDPM. Nos prximos dois captulos ser feita a
avaliao do plugin quanto ao atingimento das metas, a avaliao dos resultados e
sero detalhados os prximos passos da ferramenta.
74
A expresso projeto piloto costuma se referir a qualquer plano/projeto preliminar ou de embasamento a um

empreendimento. Pode-se tratar de uma primeira verso de algo, uma proposta preliminar, etc.
27
3.5. Licena do BDDPM

Conforme visto anteriormente, o BDDPM faz uso de componentes de terceiros
que so distribudos apenas sob duas licenas (ou combinao delas): a GPL 75 e a
MIT76. A licena MIT permite que o cdigo regido por ela possa ser modificado e/ou
includo em um outro produto e que o resultado obtido pode ser distribudo novamente
em formato de software livre ou proprietrio; inclusive o produto final pode ser
comercializado e ter o cdigo fechado. uma licena permissiva, pois impe poucas
restries. Por outro lado, a GPL impede que o cdigo no seja aberto.
Obrigatoriamente, todo software disponibilizado sob a GPL deve ter seu cdigo aberto
e livre para ser alterado por qualquer pessoa ou organizao.
De acordo com a FSF77 (Free Software Foundation), toda licena compatvel com
a GPL permite que os cdigos regidos por elas possam ser combinados com cdigos
sob a GPL, desde que o resultado final desta combinao, se for distribudo, deve ser
distribudo sob a licena GPL78. A licena MIT compatvel79 com a GPL.
O BDDPM foi desenvolvido em um ambiente acadmico que, por natureza,
tipicamente colaborativo. O objetivo da ferramenta facilitar/estimular a adoo de
BDD no mercado. Contribuies para o projeto so esperadas e estimuladas. Cada
evoluo da ferramenta, caso venha a ser compartilhada, tambm deve ter o cdigo
aberto para que o processo de melhoria contnua seja vivel a todo tempo. O criador
do BDDPM entende que se algo foi criado com um objetivo bem definido e esse algo
pode ser melhorado, ento seu objetivo tambm ser afetado e ter maior impacto no
que prope. O prprio BDDPM se beneficiou desse pensamento ao utilizar
componentes licenciados sob a GPL. Por estes motivos, o BDDPM ser distribudo
sob a licena GPL v3, a verso mais recente, pois ela estabelece uma srie de
princpios (de maneira mais explcita que a verso 2) que cobe a modificao e/ou
distribuio de software sob a GPL com restries aos usurios, por mal interpretao
da GPL v2; qualquer tentativa de limitar o livre acesso ao cdigo implica na
impossibilidade de distribuio do mesmo. Outras pessoas podero utilizar a
ferramenta criar suas prprias verses, porm, o portal oficial do BDDPM ir estimular
que as contribuies sejam feitas de maneira organizada e centralizada atravs do
repositrio GIT da ferramenta.
75
A GNU General Public License, GNU GPL, ou simplesmente GPL, a designao da licena para software livre
idealizada por Richard Matthew Stallman em 1989, no mbito do projeto GNU da Free Software Foundation
(FSF). GPL a licena com maior utilizao por parte de projetos de software livre. A GPL visa garantir que
qualquer produto de software (regido por suas regras) possa ser compartilhado e modificado por qualquer
pessoa e permanea assim, indefinidamente. O software pode ser vendido, mas deve ser sempre aberto. A
verso 2 da licena prega que qualquer tentativa de impedir esta liberdade acarreta na impossibilidade de
distribuio do software modificado.
76
A licena MIT, tambm chamada de licena X ou de licena X11, uma licena de programas de computadores
(software), criada pelo "Massachusetts Institute of Technology - MIT". Ela uma licena que permite a
reutilizao de software licenciado em programas livres ou proprietrios. Basicamente a nica restrio imposta
por ela a de manter o aviso de copyright.
77
http://www.fsf.org
78
http://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatMean
79
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
28
Captulo 4 O BDDPM: Mais Detalhes

O BDDPM foi criado e testado em ambiente Windows com servidor WEB
Apache80 (httpd.apache.org), verso 2.2.26, com suporte a PHP (verso 5.5.34). Em
teoria no existem impedimentos para que o sistema funcione em ambientes Linux
com configurao semelhante, entretanto a soluo no foi testada em tal cenrio.
Um nico Analista de Sistemas esteve envolvido no projeto de desenvolvimento
do BDDPM: Alvaro Magnum Barbosa Neto, 30 anos, formado em Cincia da
Computao pela Universidade Federal de Campina Grande UFCG81, especialista
em Gesto de Projetos com PMBOK pela Faculdade Anglo Americano 82 e candidato
Mestre em Cincia da Computao pela UFPE83. O projeto foi acompanhado e
supervisionado pelo Dr. Vinicius Cardoso Garcia84, professor adjunto da UFPE e
profissional com experincia em: Reengenharia de Software, Reuso de Software,
Linhas de Produtos de Software, Arquitetura de Software, Programao Generativa,
Computao na Nuvem, Datacenter as a Service, Backend as a Service e Social
Machines.
A Seo 4.1 descreve a metodologia de desenvolvimento do plugin, trazendo os
resultados de um questionrio que foi aplicado no incio do projeto para levantamento
dos requisitos. Tambm descreve como foi seu desenvolvimento, arquitetura e testes
utilizados. A 4.2 finaliza com uma demonstrao prtica de alguns dos recursos da
ferramenta.
4.1. Metodologia de Desenvolvimento e

Implantao do BDDPM
4.1.1.
Fase 1: Levantamento de Requisitos
O incio do desenvolvimento do BDDPM deu-se com a definio de seus

requisitos. Para tal, foi utilizada uma simples tcnica de investigao atravs da
elaborao de um questionrio com perguntas objetivas, e respostas de mltipla
escolha, que foi respondido por 47 programadores / testadores de sistemas, 06
gerentes de desenvolvimento de software e 03 clientes de produto de software. O
formulrio pode ser conferido no Anexo 1. As justificativas e explanaes para as
perguntas so as seguintes:
80
O servidor Apache (ou Servidor HTTP Apache, em ingls: Apache HTTP Server, ou simplesmente: Apache) um
popular servidor web livre. Foi criado em 1995 por Rob McCool, ento funcionrio do NCSA (National Center for
Supercomputing Applications).
81
http://www.ufcg.edu.br
82
http://www.angloamericano.edu.br
83
http://www.ufpe.br
84
http://viniciusgarcia.com/about
29
PERGUNTA 1: Em sua opinio, para uma aplicao WEB ser

considerada de fcil uso e simples, inclusive para usurios com
pouco, ou nenhum, conhecimento tcnico; qual deveria ser o
nmero de telas teis dessa aplicao? Considere que TELA TIL
aquela que contm ou permite a entrada informaes importantes
e/ou essenciais para utilizao do sistema. A resposta para esta
pergunta no se relaciona com o conhecimento da tcnica do BDD por
parte do interrogado. Baseia-se em sua opinio em relao a usabilidade
e facilidade de uso considerando-se a quantidade de telas em um sistema.
O BDDPM teria a quantidade de telas com maior quantidade de votos
obtidos atravs do questionrio.
PERGUNTA 2: Qual seu nvel de experincia/conhecimento em
relao ao BDD (Behavior Driven Development)? Esta pergunta tem
forte impacto nas demais respostas (exceto a pergunta 6), pois o
entendimento do que a tcnica do BDD e a experincia com a mesma
afetam o entendimento do que uma ferramenta voltada para o Behavior
Driven Development faz, contm, ou deveria conter. Se a maior parte dos
usurios tivesse respondido que desconheciam o BDD (letra a), ento o
questionrio teria que ser aplicado novamente, dessa vez com a
preocupao de seleo do pblico interrogado.
PERGUNTA 3: Em sua opinio, considerando uma aplicao WEB
voltada para o BDD (Behavior Driven Development) e que permite a
criao de testes de aceitao com Gherkin, qual a melhor proposta
em termos de facilidade de uso? (Inclusive para usurios com pouco,
ou nenhum, conhecimento tcnico). Esta foi, provavelmente, a
pergunta mais difcil do questionrio. Para respond-la com propriedade
seria necessrio conhecer o BDD e o que um teste de aceitao escrito
em Gherkin, com toda sua estrutura e regras. O questionamento tambm
envolve alguns conceitos de componentes de interface com o usurio
(text box, combo box, radio, etc.). O interrogado teria que usar a
imaginao para conceber mentalmente uma tela com o uso dos
componentes indicados e objetivando a criao de testes de aceitao.
Por um lado, estes pensamentos poderiam ser completamente distintos
do que foi imaginado quando da elaborao da questo por parte do
avaliador; por outro dava liberdade para que o avaliado refletisse e
chegasse as suas prprias concluses, que poderia tambm envolver a
utilizao dos mesmos componentes propostos nas opes de resposta.
Assim sendo, ainda que a interface e/ou disposio dos elementos sejam
imaginadas de maneira diferente por cada interrogado, o fator escolha
dos componentes quem teria o maior peso na hora de criar o BDDPM.
PERGUNTA 4: Na sua opinio, qual seria o recurso mais importante
em uma aplicao WEB voltada para o BDD (Behavior Driven
Development)? O objetivo aqui seria entender o que um potencial
usurio do BDDPM esperaria encontrar como principal funcionalidade,
considerando a tcnica do BDD. Caso a maior parte das respostas
estivesse concentrada na letra E, isto , que nenhuma das
30
funcionalidades listadas eram consideradas prioritrias, um novo

questionrio teria que ser aplicado, dessa vez incluindo a opo para
especificar qual o recurso desejado. A verso utilizada do questionrio
no permitia a possibilidade de incluso de respostas subjetivas/abertas
em nenhum item.
PERGUNTA 5: Na sua opinio, qual seria o recurso mais importante
PARA O CLIENTE DE UM PRODUTO DE SOFTWARE em uma
aplicao WEB voltada para o BDD (Behavior Driven Development)?
A justificativa a mesma da pergunta 4, aqui, entretanto, sugerido que
o questionado se coloque na posio de cliente.
PERGUNTA 6: Voc ... Para melhor avaliar as respostas das perguntas
de 1 a 5, era importante conhecer o papel do avaliado, uma vez que o
questionrio foi enviado para uma quantidade indefinida de pessoas de
diferentes empresas atravs de e-mail.
Os resultados obtidos, e suas respectivas avaliaes, foram os seguintes:
Pergunta 1 - Quantidade de Telas

A. 31. 55%
B. 20. 36%
C. 3. 5%
D. 1. 2%
E. 1. 2%
Figura 16 Questionrio para Interface. Resultado da Pergunta 1
Pergunta 2 - Tempo de Experincia

A. 11. 20%
B. 14. 25%
C. 19. 34%
D. 5. 9%
E. 7. 12%
31
Pergunta 3 - Forma de Criao de Teste
A. 10. 18%
B. 3. 5%
C. 20. 36%
D. 8. 14%
E. 15. 27%
Pergunta 4 - Recurso Importante do BDD

A. 17. 30%
B. 13. 23%
C. 11. 20%
D. 12. 22%
E. 3. 5%
Pergunta 5 - Recurso Importante do BDD

(Para o Cliente)
A. 27. 48%
B. 3. 5%
C. 0. 0%
D. 20. 36%
E. 6. 11%
32
Pergunta 6 - Perfil
A. 47. 84%
B. 6. 11%
C. 3. 5%
D. 0. 0%
E. 0. 0%
Na primeira pergunta, a letra A (de 1 a 4 telas) foi a mais votada. Provavelmente

pelo fato de que muitos usurios acreditam que, quanto menor a complexidade de
algo, e quanto mais simples este algo for, melhor. Esta teoria conhecida como o
princpio KIS (Keep It Simple). Os avaliados provavelmente acreditam que uma
quantidade menor de telas torna a utilizao da aplicao mais fcil e simples. Para a
segunda pergunta, a letra de maior marcao foi a letra C, indicando que 34% das
pessoas avaliadas tinham menos de 01 ano de experincia com o BDD. um grupo
grande de pessoas. A terceira questo tambm teve a letra C com maior nmero de
marcaes. Esta reposta influenciou o desenvolvimento do BDDPM que utilizou os
componentes citados (combo box e text box) em o padro Wizard para montagem dos
testes de aceitao. Para as perguntas 4 e 5, que so iguais e mudam apenas o ponto
de vista de anlise, todas as propostas sugeridas como respostas foram
implementadas, exceto a funcionalidade de execuo automtica dos testes de
aceitao. Finalmente, os resultados obtidos atravs da sexta pergunta possibilitaram
a classificao dos avaliados.
Com base nos resultados obtidos atravs do questionrio definiu-se que o
BDDPM teria 04 telas principais:
Tela de Incio Contm as informaes de resumo referente ao projeto

de desenvolvimento de software. Apresenta os quantitativos gerais de
resultados testes (testes com falha, testes que passaram, testes que
ainda no foram executados, etc.). Tambm apresenta um log de
atividades dos usurios da ferramenta.
Tela de Configurao Concentra todas as configuraes possveis do
plugin, incluindo os caminhos do sistema para o aplicativo GIT, a seleo
do tipo de repositrio (local ou remoto), as configuraes de dados de
acesso ao repositrio (URL, login/usurio e senha) e os dados referente
ao cdigo do projeto em C#.
Tela de Casos de Uso a tela que ser utiliza pelos usurios para
criao/adio dos testes de aceitao utilizando formulrios com campos
de mltipla escolha e campos de texto abertos organizados em um
33
Wizard. Na tela tambm possvel classificar os testes em nveis de

prioridade (normal, importante, muito importante), alm da edio e
remoo dos testes.
Tela de Resultado de Testes Esta a tela de acompanhamento em
tempo real dos testes realizados com base nos testes de aceitao
escritos pelos usurios. O acompanhamento feito em tempo real:
sempre que um teste executado, o resultado atualizado na interface
com o usurio.
A interface do usurio foi pensada de maneira a facilitar/exibir/simplificar/otimizar

os seguintes recursos: (i) Possibilidade de acompanhamento do resultado dos
testes; (ii) Gerao de Cdigo de Testes e; (iii) Escrita de Testes de Aceitao de
forma Simplificada. O sistema tambm dispe de outras telas secundrias: (i) sobre
a ferramenta; (ii) licena da ferramenta; (iii) ajuda da ferramenta e; (iv) contato
com os desenvolvedores.
4.1.2.
Fase 2: Desenvolvimento e Testes
A segunda etapa envolveu a criao da ferramenta propriamente dita, todo o

processo de programao e juno dos componentes de terceiros utilizados. O
processo de desenvolvimento fez uso das tcnicas de TDD com Testes de Unidade
atravs do Visual Studio e de BDD com o PHP Storm, Behat, Selenium Server e
PHPUnit.
Um resumo, em nmeros, dos quantitativos relacionados a testes podem ser
conferidos na Tabela 5:
Descrio
Testes de Comportamento
Testes de Unidade
Arquivos Gherkin
Classes de Teste
Quantidade
21
83
18
19
Tabela 5 Testes do BDDPM em nmeros
Todos os 83 testes de unidade foram executados a partir de uma nica classe.

J os 21 testes de comportamento foram distribudos em 18 classes de testes, cada
uma responsvel por tratar os testes de aceitao descritos nos 18 arquivos Gherkin.
Ainda em relao os testes, foi utilizado o padro Facade/Fachada 85 para centralizar
as chamadas dos testes em um nico ponto central (fachada). Sendo assim, embora
existam 19 classes de testes que separam os testes de maneira lgica, classificados
de acordo com o que testado, todos eles chamam uma nica classe de acesso
(fachada) para execuo dos testes. A arquitetura dessa estratgia pode ser vista na
Figura 22:
85
O padro de projeto Facade um padro estrutural que fornece uma interface unificada para um conjunto de
interfaces em um subsistema. O padro Facade define uma interface de nvel mais elevado que faz com que o
subsistema fique mais fcil de ser utilizado. De forma mais simples podemos dizer que o padro Facade tem
como objetivo esconder a complexidade de um sistema expondo apenas as interfaces que o cliente precisa
enxergar. Com isso o sistema fica mais simples e fornece uma coleo de mtodos mais fceis de entender.
34
Figura 22 Arquitetura de Testes do BDDPM
A lista dos requisitos esperados na definio inicial do BDDPM era a seguinte:

1.
2.
3.
4.
O plugin deve ser de rpida instalao

O plugin deve ser de rpida desinstalao
Deve ser uma ferramenta de pgina nica.
A ferramenta ser acessvel por trs papis bsicos: gestor do projeto de
software, testador/desenvolvedor do projeto de software e cliente do
5. A partir da pgina inicial deve ser possvel ter acesso ao log do sistema
na pgina inicial
6. A partir da pgina inicial deve ser possvel ter acesso ao resumo dos
testes na pgina inicial
7. A ferramenta deve ter integrao com o GIT (O GIT deve estar instalado
na mquina servidora)
8. A ferramenta deve permitir a configurao do path (caminho) do sistema
para o GIT, alm da configurao de login/usurio, URL e senha do
repositrio.
9. A ferramenta deve suportar repositrios GIT remotos e locais
10. O plugin deve permitir algumas configuraes do projeto de software
(nome do pacote, diretrios utilizados para salvar os arquivos,
nomenclatura de classes, etc.)
11. A ferramenta deve possibilitar a criao, edio e remoo de cenrios de
testes de aceitao
12. A ferramenta deve possibilitar a criao, edio e remoo de passos dos
cenrios de testes de aceitao.
13. A ferramenta deve prover um meio de pesquisa de testes de aceitao
por contedo.
35
14. Os testes de aceitao devero poder ser classificados em: normal,

importante e muito importante.
15. A classificao dos testes de aceitao dever seguir um padro de cores:
cinza, amarelo e vermelho para as classificaes de normal, importante e
muito importante, respectivamente.
16. O plugin deve permitir a construo/criao de testes de aceitao sem o
conhecimento da estrutura/sintaxe do Gherkin
17. O Gherkin deve ser gerado automaticamente a partir das entradas do
usurio.
18. Deve ser possvel o envio e sincronizao automtica dos arquivos de
testes de aceitao escritos em Gherkin para/com o repositrio do projeto.
19. O cdigo de teste de software em C# deve ser gerado automaticamente
pela ferramenta.
20. O cdigo de testes de software em C# deve ser de maneira tal que, a cada
execuo, se comunique com a ferramenta para enviar o resultado do
teste executado.
21. Deve ser possvel o envio e sincronizao automtica dos arquivos de
cdigos de testes escritos em C# para/com o repositrio do projeto.
22. O cliente, ao utilizar a ferramenta, dever poder ver os resultados dos
testes em tempo real (sempre que forem executados). Cada teste pode
ter o um dos seguintes status: sucesso, falha ou inconcluso.
23. Os status de erro devero seguir um padro de cores: verde, vermelho e
amarelo para sucesso, falha e inconcluso, respectivamente.
24. Dever ser possvel acessar a pgina de ajuda da ferramenta atravs da
interface com o usurio em todas as telas do sistema.
25. Dever ser possvel acessar a pgina com as informaes do sistema
atravs da interface com o usurio em todas as telas do sistema.
26. Dever ser possvel acessar a pgina que descreve a licena do plugin
atravs da interface com o usurio em todas as telas do sistema.
27. Dever ser possvel acessar a pgina de contato com a equipe
desenvolvedora do sistema atravs da interface com o usurio em todas
as telas do sistema.
28. Os resultados dos testes devem ser atualizados em tempo real (sempre
que cada teste for executado) na interface do usurio.
Estes requisitos foram transformados em testes de comportamento e foram
criados os testes de aceitao descritos em Gherkin para utilizao do BDD. Alm
disso, as funes e algumas unidades de cdigo eram testadas atravs de testes de
unidade.
Com todos os requisitos em mos e com os testes criados, o desenvolvimento
do BDDPM durou 90 (noventa) dias. Na figura 23 pode ser conferida a arquitetura da
verso final do projeto, que ser chamada de Arquitetura do Sistema BDDPM86:
86
Sistema BDDPM Para fins deste trabalho, ser considerado Sistema BDDPM o conjunto de todos os
componentes da Arquitetura do Projeto BDDPM.
36
Figura 23 Arquitetura do Sistema BDDPM
O BDDPM possui um nico ponto de acesso, o Controlador nico. Todos os

clientes que quiserem fazer uso dos recursos da ferramenta devem acessar esta
camada. A priori existem dois tipos de clientes: os usurios humanos (clientes,
desenvolveres, testadores e gerentes de projetos de software); e os usurios no
humanos. Outros clientes podem se beneficiar das funcionalidades do BDDPM uma
vez que o plugin prov uma interface de comunicao que segue os padres do
RPC87. Sendo assim, conhecendo-se a API do BDDPM pode-se fazer chamadas
remotas aos seus mtodos e funes a partir de quaisquer outros sistemas.
Os usurios acessam o controlador para ter acesso a interface WEB do plugin.
Eles interagem com esta viso enviando dados e observando os resultados de
maneira visual. O VS (Visual Studio), por sua vez, se comunica com o BDDPM apenas
enviando dados: os resultados dos testes. Toda vez que um teste executado, o VS
envia as informaes contendo o retorno da avaliao (sucesso, falha ou inconclusivo)
87
Em Cincia da Computao, a Chamada Remota de Procedimento (RPC, acrnimo de Remote Procedure Call)
um princpio/protocolo de comunicao que permite que programas de computador possam executar
procedimentos em outros sistemas computacionais, ainda que eles estejam em diferentes domnios em uma
rede. Esta conexo se d de maneira tal que seus detalhes de implementao so transparentes: do ponto de
vista do cdigo, a chamada se assemelha de mtodos locais; s que estes procedimentos so executados
remotamente em outro ambiente. Muito utilizado para implementao do modelo cliente-servidor de
computao distribuda.
37
para a ferramenta atravs de uma requisio HTTP88, pois o plugin roda em cima de
uma aplicao WEB.
Uma API89 (API RPC) permite o acesso a todos os recursos pblicos do
BDDPM (adicionar teste, remover teste, salvar configuraes, obter resultados de
testes, enviar teste para o repositrio, etc.). neste mdulo que est concentrada a
lgica de negcio (do lado do servidor) do BDDPM responsvel pela recepo,
manipulao, transformao e repasse de dados para a camada da lgica de domnio
da aplicao: a camada de Modelo. Esta API, que foi desenvolvida em PHP, tambm
capaz de se comunicar com o repositrio do projeto de software atravs da criao
e envio de arquivos para o mesmo, porm no recebe nenhuma informao deste.
Dependendo de onde veio a requisio, o Controlador nico do BDDPM faz a
chamada da lgica de negcio correta atravs da API. Quando o cliente do controlador
o VS, h uma comunicao do tipo simplex90, onde o transmissor o Visual Studio
e o receptor o Controlador. Esta comunicao (VS Controlador) juntamente com
a comunicao da API com o Repositrio da aplicao testada (em GIT) so as nicas
comunicaes simplex do sistema, as demais comunicaes so do tipo duplex91.
O Controlador foi desenvolvido em PHP seguindo as definies constantes no
manual do desenvolvedor92 do Mantis, que estabelece uma arquitetura voltada para
eventos: aes, comandos e interaes com o usurio tornam-se eventos que so
capturados pela API que executa as aes correspondentes no servidor.
Na camada da lgica de domnio (o Modelo), os dados so persistidos e passam
a ter sentido: entradas dos clientes tornam-se testes, resultado de testes so
classificados, etc. O dado, que algo quantificvel e que pode ser guardado,
transforma-se em informao persistida, que algo que tem significado e transmite
mensagem. Este um mdulo PHP com persistncia em Banco de Dados MySQL
atravs da tcnica de ORM.
88
HTTP sigla de HyperText Transfer Protocol que em portugus significa "Protocolo de Transferncia de
Hipertexto". um protocolo de comunicao entre sistemas de informao que permite a transferncia de dados
entre redes de computadores, principalmente na Internet. O HTTP funciona como um protocolo de requisioresposta no modelo computacional cliente-servidor. Um navegador WEB, por exemplo, pode ser o cliente e uma
aplicao em um computador que hospeda um site da web pode ser o servidor. O cliente submete uma
mensagem de requisio HTTP para o servidor. O servidor, que fornece os recursos, como arquivos HTML e
outros contedos, ou realiza outras funes de interesse do cliente, retorna uma mensagem resposta para o
cliente. A resposta contm informaes de estado completas sobre a requisio juntamente com o contedo
solicitado pelo cliente.
89
API, de Application Programming Interface (em portugus: Interface de Programao de Aplicaes) um
conjunto de rotinas e padres estabelecidos por um software para a utilizao das suas funcionalidades por
aplicativos que no pretendem envolver-se em detalhes da implementao do software, mas apenas usar seus
servios.
90
Uma comunicao dita simplex quando h um dispositivo emissor e outro dispositivo receptor, sendo que
este papel no se inverte no perodo de transmisso. A transmisso tem sentido unidirecional, no havendo
retorno do receptor.
91
Duplex um sistema de comunicao composto por dois interlocutores que podem comunicar entre si em
ambas direes. Diz-se, portanto, bidirecional.
92
http://www.mantisbt.org/docs/master-1.2.x/en/developers/dev.plugins.building.html
38
Por fim, a Aplicao de Pgina nica uma parte do Sistema BDDPM que tem
sua prpria arquitetura conforme exibida na Figura 24:
Figura 24 Arquitetura da Aplicao de Pgina nica - BDDPM
Os principais recursos do BDDPM foram includos na Aplicao de Pgina

nica que executa no lado do cliente. O Controlador nico do BDDPM, a API e os
componentes que a ela se relacionam rodam no lado do servidor. No h a camada
de Modelo no cliente, uma vez que ela acessvel atravs da comunicao entre o
Controlador da Aplicao e o Controlador nico do BDDPM. A Aplicao de
Pgina nica formada por apenas 02 mdulos: o Controlador da Aplicao e a
Viso da Aplicao.
O Controlador da Aplicao contm a parte da lgica de negcio (do lado do
cliente) do BDDPM relacionada a tcnica do Behavior Driven Development e
responsvel por processar todas as informaes provenientes da interface com o
usurio repassando-as para o servidor quando necessrio. Tambm tem a tarefa de
atualizar a interface WEB com o usurio de acordo com a situao. Este mdulo se
comunica indiretamente com o Controlador nico, pois depende de requisio da
interface (Viso da Aplicao).
A Viso da Aplicao um conjunto de telas que so trocadas dinamicamente
de acordo com as interaes dos usurios. Embora existam diversas pginas
distribudas em arquivos HTML, logicamente elas so exibidas e carregadas como se
fossem uma nica pgina para o usurio. Enquanto a lgica da aplicao fica dividida
e modularizada, para o cliente este processo transparente e ele percebe apenas
uma pgina funcionando.
Tanto o Controlador da Aplicao como a Viso da Aplicao utilizam JS
(JavaScript) de maneira que as principais funcionalidades do BDDPM sejam
independentes de linguagem de servidor; isto , o BDDPM s depende do servidor
para realizao de duas principais atividades: (i) persistncia de informaes e (ii)
acesso ao repositrio do projeto do software que est sendo testado. As outras
funcionalidades (relacionadas tcnica do BDD) rodam no navegador/browser. Esta
39
estratgia facilita a migrao do plugin para outras plataformas WEB de gesto de

projetos em outras linguagens (Java, C#, Python, Ruby, etc.).
A juno destas arquiteturas, formando o Sistema BDDPM, obedece ao padro
MVC . O Modelo representado pela prpria camada de Modelo, a Viso fornecida
pela camada da Aplicao de Pgina nica; e a API RPC e o Controlador nico
do BDDPM so responsveis pela parte do Controlador.
93
4.1.3.
Fase 3: Implantao
A ltima etapa de desenvolvimento do BDDPM envolveu sua instalao em um

ambiente de produo real para avaliao de resultados e impactos da ferramenta
como proposta de soluo para o problema.
A empresa escolhida para implantao e utilizao do BDDPM foi a PBprev
(Paraba Previdncia). De acordo com o prprio portal (http://www.pbprev.pb.gov.br)
da instituio, ela se intitula como uma autarquia criada pela Lei Estadual n 7.517,
de 30 de dezembro de 2003. Por fora do art. 7 da Lei n 7.721/2005, a PBPREV
encontra-se vinculada Secretaria de Estado do Governo da Paraba.
Compete ao rgo gerir o regime prprio de previdncia dos servidores pblicos
efetivos do Estado da Paraba de acordo com os princpios jurdicos e legais
estabelecidos na Constituio brasileira e por fora de lei.
O critrio utilizado para escolha foi o acadmico: este trabalho uma dissertao
de Mestrado Profissional (MPROF) em Cincia da Computao oferecido pelo Centro
de Informtica da UFPE (Universidade Federal de Pernambuco) que em seu site
prega o seguinte94: O MPROF difere do Mestrado Acadmico por lidar com
problemas que o profissional vivencia dentro do mercado. Sendo assim, os
projetos de concluso normalmente tratam de temas de interesse direto da
empresa em que o mestrando trabalha. A interao dos acadmicos com as
problemticas enfrentadas no dia-a-dia das instituies contribui para a melhoria
das empresas, e consequentemente para o desenvolvimento da regio. A empresa
no qual o mestrando trabalha (trecho sublinhado) a PBprev.
O BDDPM foi instalado na instituio com autorizao do Gerente de Tecnologia
da empresa em dezembro de 2014. O plugin foi utilizado no projeto de
desenvolvimento do projeto SISPROTO SAC (SSAC). O SSAC (l-se SAC,
primeiro S mudo), um pequeno95 sistema de 02 mdulos, um desktop e outro WEB,
que permite os funcionrios da instituio solicitem correes nos processos que
tramitam dentro da empresa. Nesse caso, o processo um documento eletrnico que
criado quando da entrada de uma aposentaria ou penso de um servidor pblico
93
Model-View-Controller (MVC), em portugus Modelo-Viso-Controlador, um padro de projeto de software

que separa a informao (e as suas regras de negcio) da interface com a qual o usurio interage. uma forma
de estruturar uma aplicao de forma que sua interface (View) esteja separada do controle da informao que
ela manipula (Model), separao essa que intermediada por uma camada controladora (Controller).
94
http://www2.cin.ufpe.br/site/secao.php?s=3&c=116
95
Pequeno, nesse casso, no sentido de ser uma ferramenta de baixa complexidade e com projeto de
desenvolvimento de curto prazo.
40
estadual. Estes documentos podem conter dados errados: o telefone de contato de

um servidor, por exemplo. O mdulo WEB do SSAC fornece a interface para que as
correes/alteraes sejam solicitadas, e o mdulo Desktop funciona como um
servio que fica monitorando todas as solicitaes feitas atravs da interface WEB.
Sempre que uma solicitao for detectada, o programa notifica um funcionrio de TI
da Paraba Previdncia para que ele possa fazer o atendimento da solicitao.
Aps o perodo de 45 dias de desenvolvimento do projeto o BDDPM ainda foi
avaliado por mais 30 (trinta) dias atravs da tcnica Goal-Question-Metric (explanada
em detalhes no prximo captulo). Juntando-se os 02 perodos, o BDDPM passou por
75 dias de avaliao. Durante este perodo a ferramenta foi avaliada sob diferentes
perspectivas:
Validao do BDDPM O BDDPM cumpriu com o que foi prometido?

Falhas Problemas e bugs no software do BDDPM
Vantagens Que valores foram agregados ao projeto devido a utilizao
do BDDPM.
Adequao ao BDD O BDDPM realmente permite a fcil utilizao do
BDD no projeto de desenvolvimento de software?
Desempenho da Ferramenta A ferramenta BDDPM eficiente?
Desempenho do projeto no qual o BDDPM foi utilizado O projeto foi mais
eficiente com o uso do BDDPM?
Validao do produto de software do projeto no qual o BDDPM foi utilizado
Foi criado o produto correto?
Verificao do produto de software do projeto no qual o BDDPM foi
utilizado O produto foi criado corretamente?
4.2. Recursos do BDDPM na Prtica

Nesta Seo os recursos do BDDPM sero descritos atravs da
exemplificao de sua utilizao em um projeto real: o projeto SSAC, ou seja, ao
mesmo tempo em que mostrado como a ferramenta utilizada, tambm so
destacados os seus recursos.
4.2.1.
Configurao
A Configurao do BDDPM dividida em duas partes: a Configurao do

Plugin e a Configurao do Projeto. A Configurao do Plugin contm opes
relacionadas prpria ferramenta do BDDPM. As duas partes so tratadas de maneira
separada, de maneira que preciso salvar cada uma individualmente, sempre que
forem alteradas. Atualmente, a nica opo funcional a de configurao do caminho
para o executvel do GIT. necessrio ter o GIT instalado no ambiente de produo
para que o BDDPM funcione.
importante destacar que, sem este recurso instalado, no ser possvel a
utilizao do BDDPM. Eis os passos para fazer a configurao adequada da
ferramenta (a configurao feita pelo gerente do projeto):
1. Ao acessar o BDDPM, selecionar a opo Configuration:
41
Figura 29 Tela inicial do BDDPM aps a instalao
2. A primeira parte da configurao envolve a Configurao do Plugin, onde

possvel configurar o caminho para o GIT no ambiente de produo. Este
caminho deve ser completo, incluindo o prprio executvel. A verso do git
utilizada no projeto foi a 1.9.4 de junho de 2014. O caminho de instalao do
git foi o C:\Program Files (x86)\Git\bin\git.exe. Aps a incluso das
informaes, elas foram salvas atravs do boto Save Config:
Figura 30 BDDPM: Configurao do Plugin
3. A segunda e ltima parte da configurao envolve a Configurao do Projeto.

O projeto se refere ao projeto de desenvolvimento de software que est sendo
testado. O BDDPM sempre altera as configuraes do projeto corrente (projeto
selecionado no Mantis). Esta etapa possui oito configuraes: (i) a seleo do
tipo de repositrio/VCS. Apenas o GIT est disponvel; (ii) o tipo do repositrio
remoto/online ou local; (iii) o caminho completo para o repositrio do projeto,
seja ele local ou remoto; (iv) o login do usurio utilizado para acessar o
repositrio; (v) a senha do usurio utilizada para acessar o repositrio; (vi) o
42
namespace96/pacote do projeto de testes; (vii) o diretrio, a partir da raiz do

repositrio, onde sero salvos os arquivos com os testes de aceitao descritos
em gherkin; e (viii) o diretrio, a partir da raiz do repositrio, onde sero salvos
os arquivos com os cdigos de testes em C#. O projeto do SSAC foi colocado
em um repositrio GIT local, sem necessidade de login e senha, acessvel
atravs do caminho C:\dev\SSAS\SSAS.Web. O namespace do projeto de
testes foi o SASS.Tests, o diretrio onde os testes de aceitao foram salvos
foi o SASS.Tests\Features e o diretrio onde os cdigos de testes foram
salvos foi o SASS.Tests\Steps97. Aps a incluso das informaes, elas foram
salvas atravs do boto Save Config:
Figura 31 BDDPM: Configurao do Projeto
4.2.2.
Criao dos Testes de Aceitao
Ao todo, no projeto do SSAC, foram gerados 56 (cinquenta e seis) testes de

comportamento distribudos em 43 arquivos de testes de aceitao escritos em
Gherkin. No objetivo deste trabalho detalhar o processo de desenvolvimento do
SSAC. Alm disso, a exposio de detalhes de cdigo e estratgias da soluo no
foi liberada pela presidncia/diretoria da PBprev. Por este motivo, o recurso de criao
96
Namespaces so usados intensamente nos programas de C# de duas maneiras. O principal objetivo o de

organizar as diversas classes que podem existir em um sistema, alm de ajudar a controlar o escopo dessas
classes. Possuem um conceito semelhante ao "Pacote/Package" do Java.
97
Curiosidade: O erro de nomenclatura (de SSAC para SSAS) na configurao do projeto s foi percebido ao final
do desenvolvimento do SSAC. Os caminhos foram utilizados com a nomenclatura incorreta at o final do projeto.
O problema no impactou nos resultados e no criou impedimentos que pudessem comprometer o
desenvolvimento do projeto ou quaisquer uma de suas funcionalidades.
43
de testes do BDDPM ser demonstrado atravs de UM NICO exemplo do SSAC,

cujo comportamento foi obtido atravs do seguinte requisito:
A cada 5 minutos, o sistema desktop dever checar se h novas

solicitaes de correes de processos. Caso exista alguma solicitao,
dever ser exibida uma notificao na tela do usurio Desktop (com
opes de atendimento e recusa de atendimento), porm ela no dever
ser exibida caso algum funcionrio de TI j a tiver atendido.
No BDDPM os comportamentos so descritos atravs de Casos de Uso, ou

seja, em uma determinada situao de uso do software (caso de uso), espera-se um
ou mais comportamentos. Ao final do processo, cada Caso de Uso criado no BDDPM
ir gerar um arquivo escrito em Gherkin. Este processo transparente para o usurio,
ou seja, ele (cliente) cria o teste em alto nvel e, em background (segundo plano), o
plugin ir fazer a converso do teste para a linguagem. Cada Caso de Uso tambm
descreve uma Funcionalidade/Feature que contm um ou mais cenrios de utilizao
da aplicao. Para todos os fins deste trabalho, os termos Caso de Uso,
Funcionalidade e Feature sero utilizados como sinnimos e como contedos de um
teste de aceitao.
Diferentemente das opes de configurao do BDDPM, que devem ser
modificadas pelo gestor do projeto, os recursos de criao de testes de aceitao
podem, e deveriam, ser utilizados pelo cliente do projeto. Com base no requisito
citado anteriormente, o cliente do SSAC (o setor de TI representado por seu
coordenador) criou o seguinte Caso de Uso (a numerao das instrues foi inserida
para fins didticos):
Funcionalidade: Notificaes
Como um desenvolvedor e usurio da verso Desktop do SSAC, o sistema dever monitorar novas
solicitaes a cada 5 minutos e exibir notificaes sempre que encontrar uma nova solicitao.
Cenrio: Notificao de Nova Solicitao
1 - Dado que o SSAC Desktop esteja aberto
2 - Dado que a cada 5 minutos o SSAC deve checar se existem novas solicitaes
3 - Quando uma nova solicitao for identificada
4 - Ento o SSAC deve exibir uma mensagem de alerta a respeito da solicitao
5 - E o alerta deve conter as opes de atendimento e de recusa de atendimento da solicitao
6 - Mas o alerta no dever ser exibido caso a notificao j esteja marcada com em atendimento
Figura 34 Requisito do SSAC transformado em teste de comportamento
Este teste de comportamento pode ser criado no BDDPM seguindo-se os

seguintes passos:
1. Selecionar a opo Use Cases para ter acesso a tela de criao dos testes
de aceitao:
44
Figura 35 BDDPM: Opo de acesso pgina de criao de testes
2. O primeiro conjunto de opes para criao de um teste de aceitao engloba

a insero do (i) ttulo da funcionalidade/feature e (ii) e da descrio da
funcionalidade/feature. No caso em especfico foram inseridos os seguintes
contedos Notificaes e Como um desenvolvedor e usurio da verso
Desktop do SSAC, o sistema dever monitorar novas solicitaes a cada cinco
minutos e exibir notificaes sempre que encontrar uma nova solicitao.,
respectivamente:
Figura 36 BDDPM: Criao de Caso de Uso (funcionalidade e descrio)
3. Em seguida, deve-se escolher a prioridade do teste que ser executado.

Existem trs opes: normal, importante e muito importante; sendo que a
prioridade Normal a de menor relevncia e a prioridade Muito Importante
a de maior relevncia. Alm da classificao por nomenclatura e significado,
tambm h a classificao por cores: cinza, amarelo e vermelho,
respectivamente. A prioridade do teste ser utilizada por desenvolvedores e
testadores na hora da criao e execuo dos testes, sendo que as
funcionalidades de maior prioridade recebero maior ateno. Tambm um
recurso til para clientes e gerentes do projeto para que eles possam
acompanhar quais comportamentos prioritrios j foram implantados e
45
testados. A funcionalidade Notificaes foi classificada com maior prioridade

(Muito Importante) no projeto do SSAC.
Figura 37 BDDPM: Criao de Caso de Uso (prioridade do teste)
4. Na sequncia possvel escolher a linguagem de programao utilizada para

gerao dos cdigos dos testes. Atualmente a opo funcional a linguagem
C#, linguagem do projeto SSAC:
Figura 38 BDDPM: Criao de Caso de Uso (linguagem dos testes)
5. Na parte final disponibilizado um formulrio seguindo o padro Wizard, onde

possvel inserir instrues passo a passo. O BDDPM segue a estrutura de
um documento escrito em Gherkin. Cada cenrio de utilizao de um software
tem uma descrio resumida do comportamento e um conjunto de instrues
que descreve este comportamento de forma sequencial. O cliente no precisa
se preocupar com a estrutura do Gherkin, nem com a ordem dos elementos,
pois o BDDPM oferece as opes na sequncia correta. O cliente precisa
apenas escolher os tipos de instrues (dado que, quando, ento, etc.) e
preencher os campos. Existem botes de adio e remoo de cenrios e de
adio e remoo de instrues. Eles esto o tempo todo visveis no formulrio.
O caso de uso descrito pelo cliente do SSAC envolve 06 instrues (ver Figura
34). As instrues foram inseridas conforme a Figura 39:
Figura 39 BDDPM: Criao de Caso de Uso (descrio do comportamento)
importante perceber que, no BDDPM, o cliente do produto de software no

precisa entender sobre a estrutura e conceitos do Gherkin. De fato, ele no precisa
nem saber que o Gherkin existe, bastando apenas entender os tipos de instrues
46
(Dado que, Quando, Ento, etc.) para descrever o comportamento esperado do

software.
O repositrio oficial do Cucumber descreve a linguagem Gherkin no seguinte
endereo: http://goo.gl/1psVj. Ela considerada uma Linguagem Especfica de
Domnio98. Um detalhe importante que ela tambm considerada uma linguagem
Business Readable, ou seja, que foca na possibilidade de leitura, no entendimento
pelo cliente. um conceito diferente do Business Writable, cujo foco permite ao
cliente, no apenas entender, mas tambm escrever na linguagem. Em seu site 99,
Martin Fowler entende que, embora uma linguagem Business Writable tenha
grandes benefcios (inclusive com reconhecimento por parte dos clientes), alcanar
algo nesse sentido pode ser bastante custoso.
O BDDPM procura dar um passo nesta direo sem especificar uma nova
linguagem, mas passando a responsabilidade de formatao, estruturao e
formalizao (da mesma) para a mquina; deixando com o ser humano apenas a parte
mais lgica, simples e intuitiva do processo de criao.
Esse mecanismo estimula a participao do cliente, no apenas como um
auxiliar na escrita de testes, mas como o principal agente criador dos testes; tudo isso
atravs da reduo da Curva de Aprendizado100 para adoo do BDD. Como
resultado da criao do Caso de Uso via BDDPM, a ferramenta se encarrega de
gerar o Gherkin conforme a Figura 40:
Feature: Notificaes
Como um desenvolvedor e usurio da verso Desktop do SSAC, o sistema dever monitorar novas
solicitaes a cada 5 minutos e exibir notificaes sempre que encontrar uma nova solicitao.
@2
Scenario: Notificao de Nova Solicitao
Given que o SSAC Desktop esteja aberto
Given que a cada 5 minutos o SSAC deve checar se existem novas solicitaes
When uma nova solicitao for identificada
Then o SSAC deve exibir uma mensagem de alerta a respeito da solicitao
And o alerta deve conter as opes de atendimento e de recusa de atendimento da solicitao
But o alerta no dever ser exibido caso a notificao j esteja marcada com em atendimento
Figura 40 BDDPM: Caso de Uso transformado em gherkin
A Figura 34 e 40 se assemelham bastante. Logicamente so a mesma coisa. A

diferena que o contedo da primeira foi escrito por algum com conhecimento em
BDD e Gherkin, e a segunda pode ser gerada por uma pessoa sem esses
98
Em desenvolvimento de software, uma linguagem de domnio especfico, do ingls: Domain-Specific Language

(DSL), um tipo de linguagem de programao, ou linguagem de especificao, para resolver problemas
especficos, focadas em um domnio de problema particular.
99
http://www.martinfowler.com/bliki/BusinessReadableDSL.html
100
Curva de aprendizagem uma representao do nvel mdio cognitivo de aprendizagem para uma
determinada atividade ou ferramenta.
47
conhecimentos (atravs do BDDPM). O BDDPM tambm gera, automaticamente, os

cdigos de testes em C# conforme exemplo da a Figura 41:
[Given(@"que o SSAC Desktop esteja aberto")]

public void GivenQueOSsacDesktopEstejaAberto()
{
ScenarioContext.Current.Pending();
}
...
#region BddPluginComunication
// -----------------------------------------------------------------------------// FROM THIS POINT: This code was generated by BDD Plugin for Mantis 1.0
//
// Changes to this file may cause incorrect behavior and will be lost if the code is regenerated.
// -----------------------------------------------------------------------------[AfterScenario]
public void AfterScenario()
{
var error = ScenarioContext.Current.TestError;
var id = ScenarioContext.Current.ScenarioInfo.Tags[0];
if (error == null)
{
status = "1";
}
else
{
errorMessage = Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(error.Message));
status = "0";
}
WebRequest.Create(string.Format(url, id, status, errorMessage)).GetResponse();
}
#endregion
}
}
Figura 41 BDDPM: Cdigo de teste gerado em C#
O cdigo gerado pelo BDDPM dividido em duas partes: (i) o cdigo de teste
em si, onde o programador/desenvolvedor do projeto ir trabalhar e; (2) o cdigo de
48
comunicao com o BDDPM, esta parte inicia a partir do trecho #region

BddPluginComunication.
A primeira parte ser utilizada pelos programadores para incluso dos cdigos
que, efetivamente, iro testar a aplicao. Conforme j citado anteriormente, uma
execuo de um teste pode ter 03 resultados: (i) sucesso, quando aquele
recurso/instruo/funcionalidade foi implementado e est funcionando conforme a
especificao feita pelo cliente; (ii) falha, quando ocorreu um erro no
recurso/instruo/funcionalidade especificado pelo cliente, ou seja, o comportamento
obtido no era o esperado e; (iii) inconclusivo, quando o teste para aquele
recurso/instruo/funcionalidade no foi executado, ou implementado, ainda.
Toda as vezes que um teste executado, a segunda parte do cdigo envia estes
resultados para a aplicao do BDDPM, de maneira que as informaes sejam
registradas/persistidas em banco de dados. As informaes so enviadas via HTTP
GET101 (atravs de uma Chamada Remota de Procedimento, RPC, conforme sugerido
no manual102 de desenvolvimento de plugins do Mantis). Com isso, os clientes so
notificados em tempo real sempre que houver algum resultado de teste disponvel, ou
seja, este conceito quebra o paradigma atual no qual os clientes no percebem, ou
acompanham, o processo de teste do software do qual eles so donos (uma vez que
esto comprando o desenvolvimento).
Esse recurso d uma maior percepo aos clientes a respeito do andamento e
do fluxo de desenvolvimento do projeto; alm de abrir portas para negociao de quais
funcionalidades poderiam ser includas, excludas ou adicionadas (considerando um
modelo flexvel onde as entregas podem ser negociadas em cada iterao 103 do
desenvolvimento). Tambm uma excelente ferramenta que permite ao gestor ter um
relatrio que inclui os quantitativos de erros por comportamento esperado, ele pode
responder as seguintes perguntas:
Quantas vezes um comportamento falhou antes de funcionar?

Quais os motivos que levaram ao erro e, principalmente, como evitalos nas prximas iteraes?
A ordem em que as funcionalidades so desenvolvidas e testadas
obedece ordem de prioridade dos Casos de Uso criados pelos
clientes?
Qual o ritmo de testes da equipe do projeto?
4.2.3.
Gerao do Cdigo de Teste
O BDDPM capaz de, a partir da descrio em Gherkin, criar o cdigo de teste

em C# para utilizao dos desenvolvedores e testadores: os Step Definitions.
101
O protocolo HTTP define oito mtodos (GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS e CONNECT) que
indicam a ao a ser realizada no recurso especificado. O GET solicita algum recurso por meio do protocolo HTTP.
Alm disso, tambm suporta o envio de dados atravs da URL atravs de pares (chave, valor) na estrutura do
endereo. Ex: http://[endereo]?chave1=valor1&chave2=valor2....
102
https://www.mantisbt.org/wiki/doku.php/mantisbt:plugins_overview
103
Desenvolvimento iterativo uma estratgia de planejamento de retrabalho em que o tempo de reviso e
melhorias de partes do sistema pr-definido.
49
Utilizando a funcionalidade de soma de 2 nmeros em uma calculadora, a Figura XX

mostra os passos lgicos que so efetuados pelo plugin:
Figura XX Gerao de Cdigo de Teste em C# a partir dos testes do cliente
O cdigo de gerao aberto e pode ser conferido ao fazer o download do

plugin. Para que ele possa ser gerado, algumas regras devem ser obedecidas:
1. O SpecFlow, motor BDD do BDDPM, assim como outros do mercado, o
do Cucumber, por exemplo, trabalha com expresses regulares104 para
identificar a qual passo o teste pertence.
2. Existem palavras reservadas que identificam o incio de um passo: dado,
quando, ento, etc. Estas palavras reservadas so convertidas para o
ingls: given, when, then, etc.
3. Estas palavras reservadas devem ser inseridas nas anotaes do
mtodo exatamente com a mesma descrio / frase inserida pelo usurio.
Ex: Dado que o nmero A 5 Given Que o nmero A 5
[Given(@"Que o nmero A (.*)")]. Nmeros e palavras entre aspas no
Gherkin devem ser transformados em parmetros. Neste exemplo o 5
virou (.*), indicando que um parmetro do teste. Por expresso
regular, estas informaes so mapeadas de maneira que se possa
saber a qual passo elas pertencem.
4. Os nomes dos mtodos devem ser formados a partir da concatenao da
descrio daquele passo. Aps a concatenao a assinatura105 do
mtodo passa por um tratamento para deixa-lo no padro
CammelCase106. Assim como no passo 3, nmeros e palavras entre
aspas no so, novamente, transformados em parmetros.
5. O corpo de cada mtodo sempre formado pelo cdigo
ScenarioContext.Current.Pending(), indicando que aquele teste ainda
no foi implementado.
104
Em cincia da computao, uma expresso regular prov uma forma concisa e flexvel de identificar cadeias
de caracteres de interesse, como caracteres particulares, palavras ou padres de caracteres.
105
Nome do mtodo.
106
CamelCase a denominao em ingls para a prtica de escrever palavras compostas ou frases, onde cada
palavra iniciada com Maisculas e unidas sem espaos.
50
4.2.4.
Resultado dos Testes
O resultado dos testes pode ser acompanhado em tempo real pelo cliente, isto
, sempre que um teste for executado no Visual Studio, os resultados so enviados
automaticamente para o servidor do BDDPM no momento da execuo.
O mesmo resultado (Figura 44) obtido, no Visual Studio, pelo testador do projeto
ser enviado para o cliente (Figura 45) que ter acesso ao motivo das falhas, caso o
teste falhe. Esta informao til, tanto para acompanhamento, quanto para que o
cliente saiba quais funcionalidades foram implementadas e testadas com sucessos,
quanto as que esto com falhas e as que ainda no foram includas em seu sistema.
Figura 44 Resultado de um teste no Visual Studio
Figura 45 Resultado de um teste no BDDPM
51
Captulo 5 Aplicao do GQM e

Anlise dos Resultados
O BDDPM teve todo seu ciclo de vida avaliado desde o primeiro captulo deste
documento. Do Captulo 1 at o Captulo 4 a ferramenta foi justificada, seu contexto
de utilizao foi apresentado, seus objetivos foram delineados, o cenrio do BDD no
mercado foi avaliado, a metodologia de desenvolvimento do BDDPM foi abordada e
seus recursos foram demonstrados atravs de um caso de uso real na Paraba
Previdncia, um rgo do governo estadual da Paraba.
Conforme citado anteriormente, a ferramenta seria avaliada atravs da tcnica
GQM (Goal-Question-Metrics) que alvo de estudo deste Captulo, bem como os
resultados oriundos da aplicao da mesma. A Seo 5.1 faz uma breve anlise sobre
o contexto para avaliao do BDDPM. A 5.2 discorre sobre o GQM. Na sequncia, na
Seo 5.3, mostrado como o GQM foi utilizado para avaliao do BDDPM; e na 5.4
mostrado o desfecho da aplicao do GQM com a avaliao dos resultados obtidos.
A Seo 5.5 faz uma avaliao geral da aplicao da tcnica no projeto.
5.1. Um Breve Contexto

A busca pela melhora do processo de desenvolvimento de software algo
recente. NO SE TRATA DO PROCESSO de desenvolvimento de software que foi
iniciado entre 1842 e 1843 quando Ada Augusta Byron King, a Condessa de Lovelace,
atualmente conhecida como Ada Lovelace, escreveu o primeiro algoritmo107 para ser
processado por uma mquina, a mquina analtica de Charles Babbage 108. O objetivo
deste primeiro programa de computador era calcular os nmeros de Bernoulli109 ("The
Universal History of Computing" [Georges Ifrah, 2001]). SE TRATA DA BUSCA pela
melhoria da arte de desenvolver softwares, o que, consequentemente, envolve a
avaliao e medio do mesmo. Medio um processo pelo qual nmeros e
smbolos so ligados a atributos de entidades do mundo real de tal maneira que os
107
Um algoritmo uma sequncia finita de instrues bem definidas e no ambguas, cada uma das quais pode
ser executada mecanicamente em um perodo de tempo finito e com uma quantidade de esforo finita. Um
algoritmo no representa, necessariamente, um programa de computador, e sim os passos necessrios para
realizar uma tarefa. Sua implementao pode ser feita por um computador, por outro tipo de autmato ou
mesmo por um ser humano. Diferentes algoritmos podem realizar a mesma tarefa usando um conjunto
diferenciado de instrues em mais ou menos tempo, espao ou esforo do que outros.
108
Charles Babbage foi um cientista, matemtico, filsofo, engenheiro mecnico e inventor ingls que originou
o conceito de um computador programvel. Ele mais conhecido e, de certa forma, referenciado como o
inventor que projetou o primeiro computador de uso geral, utilizando apenas partes mecnicas, a mquina
analtica. Ele considerado o pioneiro e pai da computao. Seu invento, porm, exigia tcnicas bastante
avanadas e caras na poca. Apenas em 1991, o museu de Cincia de Londres criou a mquina diferencial de
Babbage provando que suas teorias estavam corretas e teriam funcionado.
109
Na matemtica, os nmeros de Bernoulli so sequncias de nmeros racionais com profundas conexes na
teoria dos nmeros. So definidos como os coeficientes da Expanso de Taylor:
52
descrevem de acordo com um conjunto claro de regras ("Software Metrics, a rigorous

and practical approach" [Fenton, Pfleeger, 1996]). O resultado numrico chamado
de medio e pode ser aplicado tanto ao desenvolvimento de software como ao
De acordo com o livro Engenharia de Software [Ian Sommerville, 2011], esta
busca comeou em na dcada de 60, quando o termo Engenharia de Software tornouse conhecido aps uma conferncia em 1968, que abordou as dificuldades e
armadilhas de projetar sistemas complexos, algo que foi denominado de Crise do
Software. Antes disso no havia preocupao com adoo de boas prticas. A
qualidade tinha uma aparncia exagerada, uma perda na corrida pelo lucro e pelo
pioneirismo; o rpido crescimento do poder computacional das mquinas tornou
possvel aplicar computao em tarefas cada vez mais complicadas, e a busca das
empresas por QUANTIDADE reduziu os cuidados para um projeto de QUALIDADE.
De l para c surgiram diversos mtodos e tcnicas para melhoria e avaliao de
software e do processo de desenvolvimento de software.
O principal fator motivacional para que fbricas de software, desenvolvedores,
gerentes, etc., se preocupem com estes mtodos e tcnicas que a qualidade do
produto final depende diretamente da qualidade do processo de software adotado. Um
produto final de qualidade entrega VALOR ao cliente, isto , utilidade e garantia
(utilidade se relaciona com O QUE o cliente deseja, e garantia com o COMO o cliente
deseja).
De l para c diversas normas e modelos surgiram com os objetivos de medir,
avaliar e melhorar o processo de ciclo de vida do software: GQM110 (1994), ISO/IEC
12207111 (1995), ISO/IEC 15504112 (1997), CMMI113 (2002), etc. No paper114 The Goal
Question Metric Approach [Victor R. Basili, Gianluigi Caldiera, H. Dieter Rombach;
1994] dito que:
Como em toda disciplina de engenharia, o desenvolvimento de software requer
mecanismos de medies para avaliao e feedback. Nesse sentido, a medio
torna-se um mecanismo de auxlio corporativo criado para ajudar a responder a
uma srie de questes associadas consolidao de qualquer processo de
software. Ajuda a suportar o planejamento do projeto, determinar as foras e
fraquezas dos processos e produtos da empresa, prov um meio racional para
adotar e refinar tcnicas, permite avaliar a qualidade dos processos e produtos,
etc. A medio tambm ajuda, no decorrer do projeto, acompanhar seu progresso e
adotar medidas corretivas quando necessrio, inclusive com avaliao de impacto
da ao, ou aes, tomadas.
110
http://www.cs.umd.edu/~mvz/handouts/gqm.pdf
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43447
112
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=37458
113
http://cmmiinstitute.com
114
Para a ABNT (1989) paper um pequeno artigo cientfico, elaborado sobre determinado tema ou resultados
de um projeto de pesquisa para comunicaes em congressos e reunies cientficas, sujeitos a sua aceitao por
julgamento.
111
53
Ainda de acordo com Basili e seus colegas, uma medio, para ser efetiva, deve
ser passvel de aplicao em todo o ciclo de vida115 de produtos, processos e
recursos. A proposta do GQM engloba esta perspectiva. A tcnica vem sendo utilizada
a dcadas (desde a dcada de 70). Inicialmente foi utilizada pela NASA, mais
especificamente pelo Centro de Voos Espaciais de Goddard116, quando Dr. David
Weiss e Victor Basili de depararam com um problema no qual tentavam entender os
tipos de mudanas que eram realizados nos projetos de software da instituio.
Mudanas eram comuns, mas eles se fizeram a seguinte pergunta: Como possvel
decidir o que deve ser medido para se atingir os objetivos?. Para trabalhar no
problema, eles decidiram levantar todos os objetivos (Goal) juntamente com uma srie
de questes (Question) relacionadas aos objetivos. Os questionamentos tornavam os
objetivos mais especficos e claros, e era mais fcil levantar mtricas (Metric)
relevantes para medi-los. Surgia ento, o GQM. "The Goal/Question/Metric Method: a
practical guide for quality improvement of software development" [Rini van Solingen,
Egon Berghout; 1999]
Com o passar dos anos, o GQM evoluiu e passou a ser utilizado em outros
ambientes e contextos, inclusive com contribuies significativas do Victor Basili que
publicou diversos artigos sobre estratgias de utilizao da tcnica. O GQM define um
modelo de medio baseado em mtricas para avaliao. Este modelo parte de metas
e objetivos organizacionais (e/ou de projeto), estabelecidos e bem claros. Uma grande
vantagem da tcnica que, embora ela tenha sido concebida para avaliao/medio
de software, seus conceitos tambm podem ser aplicados em uma situao onde
deseja-se avaliar se objetivos foram alcanados.
O BDDPM enquadra-se em um perfil que pode ser avaliado com o GQM:
encontra-se na fase de introduo de seu ciclo de vida e foi criado com objetivos claros
e especficos. A tcnica foi utilizada para "medir" o BDDPM. As prximas sees
descrevem o funcionamento da metodologia, bem como os resultados obtidos.
5.2. A Tcnica do Goal-Question-Metric

(GQM)
Conforme visto na anteriormente, O GQM um modelo para definir, implantar,
medir, analisar e melhorar processos/produtos/recursos. O foco primrio da
metodologia relaciona-se ao ambiente de desenvolvimento de software, podendo ser,
entretanto, utilizado em outros contextos. De acordo com Victor, o GQM parte do
pressuposto de que, para que uma empresa consiga medir objetivamente,
necessrio que ela primeiro estabelea metas e objetivos para si mesma e para seus
projetos, para, em seguida, levantar um conjunto de dados que definam estes
objetivos de maneira operacional para, por fim, estabelecer um framework para
interpretar os dados de acordo com as metas/objetivos.
115
O modelo de ciclo de vida de um recurso/produto/servio uma representao de sua histria (completa)

atravs de suas diversas fases: concepo, introduo, crescimento, maturidade e declnio.
116
http://www.nasa.gov/centers/goddard/home
54
Em linhas gerais, o GQM permite entender um conjunto de informaes

necessrias a organizao/projeto/processo/produto/recurso. Estas informaes
devem, sempre que possvel, ser quantificadas de maneira a permitir anlises sob o
ponto de vista do cumprimento, ou no, dos objetivos. A estratgia parte dos objetivos,
passando pelo levantamento de questes para, enfim, estabelecer mtricas (Objetivos
Questes Mtricas / Goals Questions Metrics). Da vem seu nome: o GQM,
que consiste de quatro fases (ilustrao da Figura 46):
Fase de Planejamento: fase na qual escolhido um projeto para

medio. Ele deve ser definido, caracterizado e planejado. O resultado
desta fase o plano do projeto.
Fase de Definio: nesta fase o programa de medio definido
(objetivos, questionamentos e mtricas). Algumas hipteses tambm
podem ser formuladas. Tudo deve estar documentado.
Fase de Coleta de Dados: os dados do projeto devem ser colhidos nesta
fase.
Fase de Interpretao: na ltima fase os dados coletados na fase
anterior so processados de acordo com as mtricas estabelecidas e
transformados em resultados de medio que devem responder s
perguntas estabelecidas na segunda fase. Depois verifica-se se as
respostas atendem aos objetivos.
Figura 46 Fases do GQM [Rini van Solingen et al, 1999]
Na fase de planejamento so definidos todos os detalhes e requisitos

necessrios para permitir que a aplicao do GQM tenha sucesso. Esta etapa inclui
estudos, treinamentos, planejamento do projeto, etc. A segunda fase envolve as
etapas que do nome a metodologia do GQM, isto , a identificao do(s) objetivo(s),
a criao das perguntas emanadas dos objetivos, levantamento de mtricas
relacionadas e expectativas (hipteses) sobre os questionamentos. Ao final desta fase
(segunda), as medies j podem ser iniciadas, entretanto, elas precisam de uma
fonte de informao, que vem da fase de coleta de dados. A fase da coleta de dados
de extrema importncia, pois, quanto melhor a informao colhida, quanto mais
significativa ela for, melhores sero os resultados da tcnica. Alm disso, a terceira
fase a maior das fases, em termos de durao: ela inicia aps o final do
planejamento e dura o projeto todo. Informaes so colhidas o tempo todo, novas
55
informaes so geradas e analisadas novamente. Existem diversas formas de coletar

dados, o importante que tudo deve ficar registrado. Na ltima etapa, por fim, os
resultados das medies obtidos atravs das mtricas so utilizados para responder
as perguntas e avaliar se os objetivos foram atendidos.
O paradigma do GQM pode ser dividido em trs nveis e est representado na
Figura 47:
Figura 47 Paradigma do GQM
Nvel Conceitual (Objetivos): Objetivos so definidos para um objeto

(produto/processo/recurso) por uma infinidade de razes, levando em
considerao vrios modelos de qualidade, sob diferentes pontos de vista
e relativos a um cenrio particular. Um objetivo especifica um motivo de
medio, o objeto de medio, uma questo a ser medida e o ponto de
vista de anlise da medida. Este nvel chamado de conceitual por aqui
onde so desenvolvidos os conceitos a respeito de onde se quer chegar.
No se pode medir o que no conhecido.
Nvel Operacional (Questes/Perguntas): Um conjunto de questes
utilizado para caracterizar o modo pelo qual um objetivo especfico pode
ser
atingido,
alm
de
caracterizar
o
objeto
medido
(produto/processo/recurso) de maneira qualitativa a partir de uma
determinada perspectiva. Cada questo deve definir seu objetivo de
maneira operacional, ou seja, envolvendo uma operao concreta para
facilitar a interpretao, dado que os objetivos so definidos de forma mais
conceitual e abstrata. Por isto este nvel chamado de nvel operacional.
Nvel Quantitativo (Mtricas): As mtricas identificam as medidas
necessrias para responder as questes. Essas medidas so associadas
cada questo de modo a respond-las de forma quantitativa. As
mtricas podem ser objetivas, quando dependem apenas do objeto
medido independentemente de perspectivas de anlise; e podem ser
subjetivas, quando dependem, tanto do objeto medido, como da
56
perspectiva sob o qual o objeto est sendo analisado. Um exemplo de

uma mtrica objetiva a quantidade de pginas de um documento:
independentemente do ponto de vista de anlise, o nmero fixo. Por
outro lado, existem mtricas que podem variar dependendo do ponto de
vista da anlise; a mtrica "qualidade do documento" obtida atravs de
notas (variando de 1 a 10, por exemplo) atribudas por avaliadores, uma
mtrica subjetiva, pois cada avaliador pode atribuir uma nota diferente,
pois podem analisar um documento de maneiras distintas.
Independentemente do tipo da mtrica, todas elas quantificam um objeto,
por isto este nvel chamado de nvel quantitativo.
O GQM utiliza uma abordagem TOP-DOWN (de cima para baixo) para definio
dos objetivos, questes e mtricas; nesta ordem. A anlise e interpretao dos
resultados segue o processo inverso, ou seja, atravs de uma abordagem BOTTOMUP (de baixo para cima) com utilizao das mtricas para medio e resposta s
questes e, consequentemente, avaliao de atendimento dos resultados.
importante ressaltar que a relao entre objetivos e questes; e entre as questes e
as mtricas, no de UM para UM. Um objetivo pode levar a um ou mais
questionamentos. Cada questionamento pode se relacionar a um ou mais objetivos e
ter uma ou mais mtricas de avaliao. Cada mtrica pode medir uma ou mais
questes. No podem existir objetivos, questes, ou mtricas soltas; isto :
Um objetivo deve ter, ao menos, uma questo associada.

Uma questo deve estar associada a, pelo menos, um objetivo e uma
mtrica.
Uma mtrica deve estar associada a, pelo menos, um objetivo.
De maneira extremamente simplificada, um exemplo da utilizao do GQM

poderia ser resumido da seguinte maneira:
1. Uma fbrica de software est com o seguinte problema: atualmente, cada
software que ela entrega para o cliente tem uma taxa de defeitos em torno
de 5%, ou seja, 95% das funcionalidades do sistema esto corretas,
porm 5% delas so entregues com falhas. O cliente desta fbrica props
um novo acordo de nvel de servio (SLA117) onde essa taxa de erro
dever ser reduzida para 2%.
2. Os gestores da organizao se reuniram e propuseram duas novas
metodologias de desenvolvimento e teste de software que poderiam
resolver o problema: a metodologia Alfa e a metodologia Beta.
3. Para avaliar as propostas e optar pela melhor delas, sugeriu-se a
utilizao do GQM. Os Stakeholders se reuniram para fazer o
planejamento do projeto (Fase de Planejamento) para aplicao do GQM.
117
uma documentao sobre Service Level Agreement (SLA) ou Acordo de Nvel de Servio. Trata-se de um
documento detalhado que define os padres de um nvel de servio e a relao entre duas partes: solicitador e
o executor. um instrumento para a gesto das expectativas do cliente. Sua meta definir uma estrutura para
a gesto da qualidade e quantidade dos servios entregues e, por consequncia, atender demanda dos clientes
a partir de um entendimento claro do conjunto de compromissos.
57
4. Na Fase de Definio, que envolve os trs nveis do GQM, chegaram s

seguintes definies utilizando uma abordagem TOP-DOWN:
a. Objetivo: Reduzir a taxa de defeito do software de 5% para 2%.
b. Pergunta: Qual a taxa de defeito do software, quando desenvolvido
utilizando a metodologia?
c. Mtrica: Taxa de defeito do software
5. Na fase de coleta de dados as duas metodologias foram implantadas e os
softwares foram avaliados quanto a taxa de erros. Os softwares
desenvolvidos com a metodologia Alfa tiveram uma taxa de erro de 6% e
os que foram desenvolvidos com a metodologia Beta tiveram uma taxa de
erro de 1,5%.
6. Na fase de avaliao, as mtricas medidas (6% e 1,5%) tornaram-se
respostas para cada uma das metodologias. Ao checar o cumprimento do
objetivo, constatou-se que a metodologia Alfa falhou (6% responde
pergunta, mas no atinge o objetivo); e a metodologia Beta foi aceita, pois
1,5% responde pergunta e atinge o objetivo.
5.3. O BDDPM segundo o GQM

Antes de iniciar a descrio da metodologia de avaliao e medio do BDDPM
com o GQM, extremamente importante ressaltar que ela no foi feita para avaliar o
processo de desenvolvimento do plugin, mas para avaliar (com objetivos acadmicos)
uma verso finalizada do produto colocado em produo dentro de uma empresa.
Nesse sentido, o tamanho da equipe de avaliao, o tempo de avaliao e os custos
envolvidos diferiram significativamente dos cenrios apresentados na anteriormente.
Alm disso, no objetivo deste Captulo discutir sobre problemas e desafios
encontrados, o que ser feito no Captulo 6.
Esta Seo ir, portanto, se ater apenas explanao da forma como o GQM
foi aplicado (dentro das condies do projeto) para avaliao/medio do BDDPM,
sem detalhar as problemticas encontradas.
A equipe de avaliao do BDDPM foi composta por trs integrantes: a equipe
desenvolvedora do SSAC. O tempo da avaliao foi de dois meses. Excetuando-se
os esforos de trabalho, a aplicao da metodologia no implicou em custos para a
PBprev e/ou os envolvidos. Todo o processo foi aplicado com objetivos acadmicos
dentro de um projeto real que j era previsto pela Paraba Previdncia dentro da
normalidade de utilizao de recursos humanos e materiais, portanto no houve
preocupao em registrar e/ou acompanhar quaisquer aspectos financeiros e/ou
humanos e/ou de infraestrutura emanados/oriundos da aplicao do GQM.
A literatura prope vrias formas de trabalho para aplicao do GQM, todas com
os mesmos objetivos. Rini van Solingen e Egon Berghout sugerem uma abordagem
em forma de checklist118 no livro "The Goal/Question/Metric Method: a practical guide
118
Checklist uma palavra em ingls que significa "lista de verificaes". Esta palavra a juno de check
(verificar) e list (lista). Uma checklist um instrumento de controle, composto por um conjunto de condutas,
nomes, itens ou tarefas que devem ser lembradas e/ou seguidas. Uma checklist pode ser aplicada em vrias
atividades
58
for quality improvement of software development. Christiane Gresse, em "Utilizao

do GQM no Desenvolvimento de Software" sugere um modelo de fases e etapas. A
abordagem utilizada no BDDPM mescla as duas sugestes na consecuo dos
trabalhos e atividades, ou seja, a equipe seguiu as fases padro do GQM e mantinha
um checklist interno que devia ser satisfeito antes de se passar para a prxima etapa.
5.3.1. Fase de Planejamento

O projeto tem incio na primeira fase do GQM, a fase de planejamento, cujos
principais objetivos so coletar toda informao necessria para um sucesso da
introduo do GQM, estratgias para anlise e interpretao dos resultados, bem
como para preparar e motivar os membros da equipe no programa de mensurao. O
final da fase de planejamento tem como resultado a confeco do plano de projeto
que descreve os procedimentos, cronogramas e objetivos da medio, define
(precisamente) as medidas, suas justificativas e como sero utilizadas, alm de prover
uma base para promoo e aceitao pela gesto O plano de projeto contm, ainda,
um plano de treinamento para os envolvidos.
De acordo com a literatura, a fase de planejamento pode ser dividida nas
seguintes etapas:
1.
2.
3.
4.
5.
Estabelecimento da equipe GQM

Seleo do objeto de avaliao
Estabelecimento da equipe de avaliao do projeto
Criao do plano de projeto
Treinamento e promoo
5.3.1.1.
Estabelecimento da Equipe GQM
As boas prticas de aplicao do GQM pregam que, sem uma equipe

independente responsvel pela continuidade do programa de medio, as atividades
envolvidas no processo tendem a falhar. Quando deadlines surgem, as pessoas
tendem a dar menos ateno as atividades de medio, a no ser que um time GQM
independente seja estabelecido [Basili et al, 1994].
Neste sentido, no projeto de avaliao do BDDPM, a equipe GQM foi constituda
com um nico integrante: Alvaro Magnum, Analista de Sistemas e criador do BDDPM.
Estatsticas comprovam que, quanto maior o nvel de confiana mtua e cooperao
entre a Equipe GQM e a Equipe de Avaliao, maiores as chances de sucesso no
resultado ("Assessing feedback of measurement data: Schlumberger practices with
reflection to theory" [Solingen et al, 1997]). Este fato (do relacionamento) se
concretizou no projeto de avaliao do BDDPM, uma vez que todos os envolvidos se
conheciam profissionalmente, pessoalmente e com anos de experincia de trabalho
em equipe.
5.3.1.2.
Seleo do Objeto de Avaliao
O objetivo deste trabalho sempre foi muito claro: propor um conjunto de recursos
para facilitar a adoo do BDD no mercado; recursos estes que foram inseridos em
59
uma ferramenta que foi avaliada dentro de um ambiente de produo real atravs da
tcnica GQM. A ferramenta criada recebeu o nome de BDDPM (Behavior Driven
Development Plugin for Mantis).
5.3.1.3.
Estabelecimento
Avaliao do Projeto
da
Equipe
de
A equipe de avaliao do BDDPM foi composta por trs integrantes: a mesma

equipe desenvolvedora do SSAC:
Daniel de Oliveira Coordenador, Cliente e Analista do SSAC

02 Estagirios Desenvolvedores/Testadores
As atividades de medio do projeto foram realizadas por esta equipe. O sucesso

de uma avaliao depende fortemente de sua metodologia, entusiasmo e motivao;
sendo de fundamental importncia a atuao do time GQM para treinamento,
motivao e monitorao contnua da equipe (descritos na Seo 5.3.1.5).
5.3.1.4.
Criao do Plano de Projeto
A criao do Plano de Avaliao do Projeto foi feita pela Equipe GQM, ou seja,
Alvaro Magnum. Foi estabelecido um cronograma de dois meses para avaliao do
BDDPM quanto aos seus objetivos. Embora a aplicao do estudo j tivesse sido
autorizada pela PBprev para fins acadmicos; para estimular o rgo, bem como a
equipe de avaliao do projeto, que tambm uma equipe de desenvolvimento dentro
da Paraba Previdncia, foi feita uma apresentao geral do BDDPM como uma
ferramenta que poderia melhorar o processo de testes dentro da instituio atravs
da utilizao do Behavior Driven Development conforme proposto pelo plugin. Caso
os resultados da avaliao fossem promissores, toda a equipe j estaria treinada e
apta a utilizar o BDDPM dentro dos projetos do rgo e os prprios clientes dos
produtos de software a serem criados poderiam participar do processo de
desenvolvimento com a criao dos testes de aceitao para os mesmos.
Como o prprio gestor de TI da PBprev (Alvaro Magnum) participou de todo o
projeto, tanto como proponente, como acompanhador da avaliao, como
desenvolvedor, como gestor e como analista; os avanos e resultados eram
registrados e propagados semanalmente junto a alta gesto do rgo. Tambm foi
definido que o BDDPM seria utilizado em um projeto real dentro da instituio e seria
avaliado nessas condies. Por se tratar de uma primeira aplicao da metodologia
do GQM, pelo curto prazo para aplicao da avaliao e pelas incertezas dos riscos
envolvidos em relao ao GQM, ficou definido que todo e qualquer problema seria
tratado sob demanda, ou seja, a medida que acontecesse; seguindo, mais ou menos,
o modelo proposto pela tcnica do Just in Time (JIT119), isto , para reduzir os custos
de tempo relacionados ao levantamento de possveis problemas que pudessem
ocorrer no projeto, estabeleceu-se que as decises seriam tomadas na hora em que
119
Just in Time um sistema de administrao da produo que determina que nada deve ser produzido,
transportado ou comprado antes da hora certa. O termo just in time, vem do ingls e significa na hora certa.
O sistema "just in time" pode ser aplicado em qualquer organizao, e auxilia na reduo de custos.
60
ele ocorressem. Esta seria a forma de gesto dos riscos. Por fim, ficou estabelecido
um cronograma de dois dias para o treinamento da equipe de avaliao do projeto em
cima do GQM e que todas as comunicaes se dariam de forma oral, atravs de
reunies e encontros, para evitar rudos120 de comunicao.
5.3.1.5.
Treinamento e Promoo
Antes de iniciar as atividades de avaliao do BDDPM, houve um treinamento

de dois dias em relao s prticas do GQM bem como a apresentao da proposta
do BDDPM e os motivos de sua avaliao. Foi elaborada uma estratgia
especificamente voltada para a avaliao do projeto do BDDPM, com coleta de dados
dirias e anotaes de opinies pessoais (inclusive com estmulo a opinies
colaborativas para melhoria da ferramenta com possibilidade de incluso da
funcionalidade na mesma) a respeito da utilizao do sistema. Os princpios de
medio, o paradigma GQM e a metodologia GQM foram explanados.
Os papis de cada membro foram definidos a importncia de cada integrante foi
evidenciada a partir das atividades delegadas. Com uma equipe pequena a definio
de papis foi simplista: todos fariam tudo e participariam de todos os processos e
fases do GQM. O nico ponto que estava fixo e definido era que: (i) o BDDPM estava
criado; (ii) seu objetivo era facilitar a adoo do BDD dentro das organizaes,
permitindo criao dos testes pelos prprios clientes de produtos de software e (iii) o
BDDPM precisava ser avaliado quanto aos seus objetivos. Todos os processos
restantes, como estabelecimento das metas a partir dos objetivos, levantamento de
mtricas, coleta de dados e avaliao dos resultados seriam feitas por todos. Este
processo se mostrou bem produtivo e eficiente, com reunies regulares,
brainstorming121 eficaz e alinhamento da equipe com os objetivos e atividades.
Em relao a promoo dos resultados, ela acontecia em tempo real, uma vez
que o principal interessado neles participou ativamente de todas as etapas de todos
os projetos: criao do BDDPM, criao do SSAC com utilizao do BDDPM,
avaliao do BDDPM, criao de dissertao sobre o BDDPM e sua avaliao.
5.3.2. Fase de Definio

A segunda fase de aplicao do GQM a fase de definio. nesta fase onde
o mtodo de avaliao formalmente definido. As metas a serem alcanadas como
GQM so definidas com base nos objetivos da organizao/empresa e do projeto.
Esta fase termina com 03 entregas: (i) o plano GQM, (ii) o plano de medio e; (iii) o
plano de anlise, todos contendo informaes pertinentes ao programa de medio.
A fase de medio pode ser dividida, de acordo com a literatura, em 11 etapas:
120
Rudo so todas as interferncias que prejudicam o entendimento da mensagem pelo receptor durante o
processo da comunicao.
121
Brainstorming, ou "Tempestade de Ideias", o nome dado uma tcnica grupal ou individual na qual
potencialidades criativas so exploradas e colocadas a servio de objetivos pr-determinados. Em termos
simples, trata-se de uma reunio de trabalho em que as ideias devem fluir livremente e sem compromisso para
que a inovao possa emergir.
61
1. Definio do(s) objetivo(s) da medio

2. Revisar ou produzir modelos de processos de software122
3. Conduo de entrevista GQM
4. Definio de questes/perguntas e hipteses
5. Reviso das questes/perguntas e hipteses
6. Definio das mtricas
7. Reviso das mtricas
8. Produo do plano GQM
9. Produo do plano de medio
10. Produo do plano de anlise
11. Reviso dos planos
Os itens 8, 9 e 10 podem ser iniciados logo aps o item 7 (reviso das mtricas),
e podem ser realizados em paralelo. A forma como estes passos foram
implementados na avaliao do BDDPM descrita a partir da prxima Seo. Cabe
ressaltar que esta foi a ltima fase feita antes do incio da utilizao do BDDPM no
desenvolvimento do SSAC. Com isso, foi possvel captar as expectativas dos
avaliados antes deles comearem a utilizar a ferramenta e avalia-la, de fato. As fases
de coleta de dados e anlise dos mesmos foram conduzidas durante o
desenvolvimento do SSAC e aps sua concluso.
5.3.2.1.
Definio dos Objetivos da Medio
Os objetivos da medio foram definidos por toda equipe de avaliao do

BDDPM e baseiam-se nos objetivos e motivaes que deram incio ao BDDPM. So
eles:
1.
2.
3.
4.
Fcil de utilizar em termos de usabilidade

Permitir a aplicao do BDD de maneira eficiente e eficaz
Facilitar a adoo do BDD
Permitir a escrita dos testes pelos clientes
Os objetivos 3 e 4 so o carro chefe do BDDPM, mas podem ser fortemente

impactados pelos objetivos 1 e 2. Em resumo: a ferramenta teria que ser fcil de
utilizar, at mesmo porque os prprios clientes podero criar testes com ela; e, uma
vez sendo uma ferramenta BDD com o objetivo de entregar valor para seus usurios,
ento teria que ser eficaz (permitir a utilizao e aplicao do BDD, de fato) e eficiente
(ser rpida, acelerar a aplicao da metodologia, reduzir tempos de testes, etc.).
Entregar valor entregar utilidade (o que o cliente quer) e garantia (como o cliente
quer). Em qualquer projeto, os quesitos escopo, prazo e custo tm grande peso.
Nesse caso escopo o BDD e, atravs da facilidade, eficincia e eficcia, pode haver
reduo de custos e prazos; o que bastante desejado, impulsiona a aceitao da
ferramenta e, consequentemente a adoo do BDD.
122
Etapa dispensada uma vez que no h avaliao de processos de desenvolvimento e/ou de melhoria de
processos e/ou de qualidade de software, mas avaliao estrita de cumprimento de objetivos.
62
A equipe chegou concluso que, se estes 04 itens pudessem ser medidos,

seus resultados poderiam dar um forte indcio dos potenciais do BDDPM. Embora as
questes envolvam posicionamentos subjetivos, as 04 perguntas podem fornecer
mtricas quantificveis. Com isso, foram definidos os objetivos/metas da avaliao
(ver Tabelas 7, 8, 9 e 10):
Objeto de Estudo
Objetivo
Enfoque
Ponto de Vista
Contexto
BDDPM
Impulsionar a aceitao e utilizao do BDDPM
Facilidade de Uso
Usurios do BDDPM
Projetos de desenvolvimento de software testes
Tabela 7 Objetivo de medio 1: Fcil de utilizar em termos de usabilidade

Objeto de Estudo
Objetivo
Enfoque
Ponto de Vista
Contexto
BDDPM
Aplicao do BDD em testes de Software
Eficincia e Eficcia
Gestores, desenvolvedores e testadores de software
Tabela 8 Objetivo de medio 2: Permitir a aplicao do BDD de maneira eficiente e eficaz

Objeto de Estudo
Objetivo
Enfoque
Ponto de Vista
Contexto
BDDPM
Adoo da tcnica do Behavior Driven Development
Facilidade de Aplicao da tcnica
Clientes, gestores, desenvolvedores e testadores
Tabela 9 Objetivo de medio 3: Facilitar a adoo do BDD
Objeto de Estudo
Objetivo
Enfoque
Ponto de Vista
Contexto
BDDPM
Criao de testes sem necessidade de conhecimento tcnico
Escrita de testes
Clientes de produtos de Software
Tabela 10 Objetivo de medio 4: Permitir a escrita dos testes pelos clientes
Para futuras referncias ficou estabelecido que os objetivos seriam

referenciados na sequncia da lista acima, recebendo um prefixo O, de objetivo.
Sendo assim, existem 04 objetivos de avaliao: do O1 at o O4.
5.3.2.2.
Conduo de entrevista GQM
O objetivo das entrevistas adquirir mais informaes a respeito dos objetivos

de maneira a facilitar sua compreenso e facilitar a criao das perguntas e
levantamentos de mtricas nas etapas posteriores. Recomenda-se entrevistar a
equipe do projeto [Rini van Solingen et al, 1999] e cada uma das pessoas citadas no
item Ponto de Vista dos objetivos levantados [Christiane Gresse, 2000]. Tambm
recomenda-se executar entrevistas individuais para evitar influncias. As entrevistas
so feitas utilizando-se uma ferramenta chamada Abstraction Sheet que, para fins
de simplicidade e objetividade; trata-se de um documento de uma nica pgina com
04 quadrantes contendo as seguintes informaes cada um (ver Figura 48):
63
Possveis Mtricas: De acordo com a experincia do entrevistado, quais

as possveis mtricas que poderiam ser utilizadas para medir os
objetivos? Ex: nmero total de defeitos.
Expectativas de medio (hipteses): De acordo com a experincia do
entrevistado, qual a hiptese dele para a resultados de mensurao para
cada mtrica levantada por ele? Ex: nmero total de defeitos: 30.
Fatores de Impacto: De acordo com a experincia do entrevistado, quais
fatores podem impactar nas mtricas levantadas por ele? Ex: forma como
o cdigo foi inspecionado a procura de defeitos.
Impactos dos Fatores: De acordo com a experincia do entrevistado,
quais os impactos que os fatores citados no ponto anterior tero nas
mtricas, ou seja, como elas sero influenciadas? Ex: a rigorosidade da
inspeo do cdigo influencia na quantidade de defeitos encontrados.
Antes da aplicao das entrevistas, foi feita uma reunio para que todos os
envolvidos entendessem plenamente os objetivos levantados no passo anterior, pois
eles seriam o foco da avaliao. Vale a pena ressaltar que nem todas as medies
estaro presentes no Abstraction Sheet, apenas as mais importantes do ponto de
vista de cada colaborador. Conforme explanado anteriormente, foi decidido que todos
os integrantes da equipe de avaliao participariam de todas as etapas de aplicao
do GQM. Desta maneira, o questionrio foi respondido pelos trs membros:
Daniel de Oliveira: Analista de Sistemas, Coordenador e Cliente do

Projeto SSAC, Integrante da Equipe de Avaliao do BDDPM.
Marcos Fernando: Estagirio, Desenvolvedor do SSAC
Joo Paulo: Estagirio, Desenvolvedor do SSAC
Figura 48 Exemplo de um Abstraction Sheet
As entrevistas foram realizadas com todos os avaliadores e considerando os

quatro objetivos do BDDPM. A Tabela 11 mostra uma parte dos resultados colhidos
atravs da Abstraction Sheet para o objetivo de medio 1:
64
Objetivo de medio 1: Fcil de utilizar em termos de usabilidade

1.
Daniel de Oliveira:
Possveis Mtricas:
i. Poucas funes / opes em tela.
ii. Complexidade das funes / opes em tela (Nvel de dificuldade).
iii. Nota para nvel de facilidade.
iv. Nota em termos de facilidade de uso.
v. Quantidade de cliques para se chegar onde quer.
vi. Nota em termos de intuitividade de interface.
Expectativas de Medio:
i. Poucas funes / opes em tela: At 4.
ii. Complexidade das funes / opes em tela: 1 (3 Mais Difcil).
iii. Nota para nvel de facilidade: de 2 a 3 (3 Mais Fcil).
iv. Nota em termos de facilidade de uso: 3 (Mais Fcil).
v. Quantidade de cliques para se chegar onde quer: At 3.
vi. Nota em termos de intuitividade de interface: 3 (Mais Intuitivo).
Fatores de Impacto:
i. Complexidade da funcionalidade.
ii. Subjetividade da facilidade.
iii. Maturidade do usurio em relao a uso de Sistemas de Informao.
iv. Subjetividade da Pergunta
Impactos dos Fatores:
i. Normalmente, quanto mais complexa a funcionalidade, mais complexa a tela.
ii. O conceito de fcil e difcil subjetivo e depende do nvel de conhecimento de cada
pessoa.
iii. Quanto maior a maturidade do usurio, mais confivel ser o resultado da medio.
iv. Alguns usurios podem necessitar de maiores interaes (cliques) para alcanar seus
objetivos.
v. A valorao do atributo facilidade varia de pessoa para pessoa.
Tabela 11 Avaliao do BDDPM: Resultado da entrevista GQM
5.3.2.3.
Definio de questes/perguntas e
hipteses
Esta etapa inicia-se com o refinamento da etapa anterior para obteno das
perguntas GQM, que devem ser claras, objetivas e operacionais para que as mtricas
possam ser avaliadas/medidas a partir delas. Com a participao de todos os
membros envolvidos, foram levantadas diversas possveis perguntas e hipteses.
Ainda que as entrevistas tenham sido conduzidas individualmente, houve redundncia
de informao, provavelmente pela similaridade de perfis e pela alta expectativa em
relao ao BDDPM.
Aps dois dias de reunies, a equipe de avaliao do BDDPM, com a
participao de todos, chegou-se as seguintes concluses/definies:
A avaliao do BDDPM envolver bastante subjetividade, ainda que

colocada em termos quantitativos.
Os integrantes utilizaram diferentes escalas de notas. Elas teriam que ser
padronizadas. Estabeleceu-se uma escala crescente de 1 a 4. A nota 1 e
nota 4 teriam suas descries fornecidas nas perguntas e as notas 2 e 3
65
deveriam ser inferidas pela pessoa questionada. A nota 2 teria valor

prximo ao da nota 1, e o valor 3 teria o valor prximo ao da nota 4. No
foi estabelecido um valor mdio/intermedirio pelo qual o avaliado
pudesse optar. Essa foi uma opo estratgica para evitar a neutralidade
da resposta. Todos os avaliados teriam que se posicionar de um lado, ou
de outro, da escala.
Na etapa anterior houve grande preocupao com o nvel de
conhecimento tcnico dos usurios do BDDPM, mas chegou-se
concluso que esta preocupao deve ser restrita aos clientes dos
projetos de desenvolvimento de software; uma vez que o BDDPM ser
utilizado por gestores, desenvolvedores e testadores que deveriam
possuir o conhecimento tcnico necessrio para aplicao do BDD. Em
relao aos clientes, seria necessrio apenas familiaridade na interao
homem-mquina e entender a forma de utilizao do BDDPM.
Foram levantadas as seguintes perguntas (com suas respectivas
hipteses):
1. Em relao a facilidade de uso do BDDPM, que nota, de 1 a 4,
voc atribui ferramenta? Considere uma escala onde 1
significa "Difcil de Usar" e 4 "Fcil de Usar". As notas 2 e 3
representam nveis intermedirios com aproximao dos
conceitos de "Fcil" e "Difcil", respectivamente.
Espera-se que a grande parte das respostas atribuam notas
3 e 4 (alta expectativa).
2. Para utilizar o BDDPM de maneira satisfatria, qual o nvel (de
1 a 4) de conhecimento tcnico empregado por voc?
Considere uma escala onde 1 significa "Nenhum
Conhecimento Tcnico" e 4 significa "Muito Conhecimento
Tcnico". As notas 2 e 3 representam nveis intermedirios
com aproximao dos conceitos de "Nenhum" e "Muito",
respectivamente.
3. Considerando o objetivo do BDDPM de permitir a utilizao da
tcnica do BDD em um projeto de desenvolvimento de
software, bem como os recursos oferecidos pela ferramenta;
classifique a interface da ferramenta atribuindo uma nota de 1
a 4. Considere uma escala onde 1 significa "Pouco Intuitiva" e
4 significa "Muito Intuitiva". As notas 2 e 3 representam nveis
intermedirios com aproximao dos conceitos de "Pouco" e
"Muito", respectivamente.
4. Considerando os recursos do BDDPM, como voc classificaria
sua interface considerando-a como um meio de acesso eficaz
e atraente a estes recursos? Considere uma escala onde 1
significa "Baixa Qualidade" e 4 significa "Alta Qualidade". As
66
5.
6.
7.
8.
notas 2 e 3 representam nveis intermedirios com

aproximao dos conceitos de "Baixo" e "Alto",
respectivamente.
Qual a mdia de tempo (em minutos) para execuo da fase de
testes dos projetos de desenvolvimento de software da
empresa, sem a utilizao do BDDPM? (Pergunta de Suporte)
Pergunta para dar suporte avaliao da pergunta 6. No
causa impacto(s) sobre o(s) objetivo(s). Na PBprev, uma
vez o sistema tendo sido desenvolvido, eram dedicados 05
dias para realizao de testes. Sendo que dois dias para a
equipe de testes e trs dias para os usurios do sistema.
Cada dia computado com 08 horas de trabalho. Dessa
maneira, tem-se: 5 x 8 x 60 = 2400 minutos.
Qual a mdia de tempo (em minutos) para execuo da fase de
testes dos projetos de desenvolvimento de software da
empresa, com a utilizao do BDDPM?
Espera-se que a utilizao do BDDPM traga uma reduo
dos tempos de testes, tanto para a equipe de testes, quanto
para os usurios do sistema desenvolvido. Espera-se que
os novos prazos sejam de um dia para a equipe de testes e
dois dias para os usurios do sistema. Dessa maneira, temse: 3 x 8 x 60 = 1440 minutos. Isso representaria uma
melhora de 40%.
Qual a mdia de tempo (em minutos) de durao dos projetos
de desenvolvimento de software da empresa, sem a utilizao
do BDDPM? (Pergunta de Suporte)
causa impacto(s) sobre o(s) objetivo(s). Na PBprev, cada
projeto tem uma durao que varia entre 01 e 02 (meses).
Algo em torno de 45 dias, com 08 horas de trabalho dirio.
Sendo assim, tem-se: 45 x 8 x 60 = 21600 minutos.
Qual a mdia de tempo (em minutos) de durao dos projetos
de desenvolvimento de software da empresa, com a utilizao
do BDDPM?
Espera-se que, para uma primeira utilizao do BDDPM, o
tempo de desenvolvimento permanea o mesmo, ou um
pouco mais elevado, se comparado ao histrico de tempos
de projetos. Entretanto, com a familiarizao em relao a
utilizao da ferramenta, e com expectativas de reduo dos
tempos de testes reduzidos em at 40%, espera-se que o
tempo do projeto seja reduzido em at 15%; ou seja, seriam
em torno de 38 dias de desenvolvimento. Sendo assim, temse 38 * 8 * 60 = 18240 minutos, aproximadamente.
67
9. Levando-se em considerao a utilizao do BDDPM no

projeto de desenvolvimento de software, como voc classifica
(nota de 1 a 4) o impacto dos benefcios agregados ao projeto?
Considere uma escala onde 1 significa "Baixo Impacto" e 4
significa "Alto Impacto". As notas 2 e 3 representam nveis
intermedirios com aproximao dos conceitos de "Baixo" e
"Alto", respectivamente.
10. Considerando a tcnica do BDD, como voc classificaria (nota
de 1 a 4) o nvel de alinhamento e atendimento do BDDPM a
ela? Considere uma escala onde 1 significa "Fraco" e 4
significa "Forte". As notas 2 e 3 representam nveis
intermedirios com aproximao dos conceitos de "Fraco" e
"Forte", respectivamente.
2 e 3 (expectativa mdia). A equipe j sabe que vrias
funes do BDD no so includas na ferramenta.
11. Qual o quantitativo mdio de falhas/bugs encontrados nos
produtos dos projetos de desenvolvimento de software da
empresa, sem a utilizao do BDDPM? (Pergunta de Suporte)
causa impacto(s) sobre o(s) objetivo(s). Na PBprev, aps
um sistema ser colocado em produo, encontram-se, em
mdia, 12 bugs/falhas/defeitos no mesmo (ao longo de sua
vida).
12. Qual o quantitativo mdio de falhas/bugs encontrados nos
produtos dos projetos de desenvolvimento de software da
empresa, com a utilizao do BDDPM?
Espera-se que a quantidade de bugs/falhas/defeitos
encontrados
caia
para
5,
uma
melhora
de,
aproximadamente, 58% (alta expectativa).
13. Qual o seu nvel (nota de 1 a 4) de satisfao em relao a
eficcia e utilizao do BDDPM em um projeto de
desenvolvimento de software? Considere uma escala onde 1
significa "Pouco Satisfeito" e 4 significa "Muito Satisfeito". As
notas 2 e 3 representam nveis intermedirios com
aproximao dos conceitos de "Pouco" e "Muito",
respectivamente.
Espera-se que a grande parte das respostas atribua nota 3,
uma vez que alguns recursos BDD esto ausentes da
ferramenta.
14. Ao utilizar o BDDPM no projeto de desenvolvimento de
software, voc precisou recorrer outras ferramentas para
aplicao do BDD? Responda com Sim, ou No.
68
Caso o projeto seja simples, espera-se que a maior parte

das respostas seja Sim, porm, no caso de projetos
maiores e mais complexos, essa quantidade pode cair
drasticamente e ser superada pela quantidade de Nos.
15. Voc pretende utilizar o BDDPM em outros projetos?
Responda com Sim, ou No.
Espera-se que a maior parte das respostas seja Sim,
principalmente com a possibilidade de evoluo da
ferramenta e incluso de novas facilidades e recursos.
16. Considerando a forma de disponibilizao do BDDPM, como
voc classificaria (nota de 1 a 4) sua acessibilidade e
visibilidade? Considere uma escala onde 1 significa "Pouca
acessibilidade / visibilidade" e 4 significa "Muita
acessibilidade / visibilidade". As notas 2 e 3 representam
nveis intermedirios com aproximao dos conceitos de
"Pouco" e "Muito", respectivamente.
1 e 2 (baixa expectativa), uma vez que no previso de
disponibilizao/divulgao da ferramenta em portais com
grandes visitaes. Ela est apenas acessvel atravs de
um repositrio GIT hospedado no Bitbucket123
(https://alvaromagnum@bitbucket.org/alvaromagnum/bddp
m.git).
17. Quantas linguagens de programao devem ser suportadas,
em sua opinio, para que BDDPM tenha grande aceitao no
mercado?
Espera-se que as pessoas pensem nas linguagens de
programao mais utilizadas no mercado e respondam com
um quantitativo em torno de 05 linguagens.
18. Qual o seu nvel de dificuldade (nota de 1 a 4) para criar um
teste no BDDPM? Considere uma escala onde 1 significa
"Fcil" e 4 significa "Difcil". As notas 2 e 3 representam nveis
intermedirios com aproximao dos conceitos de "Fcil" e
"Difcil", respectivamente.
19. Quanto tempo, em mdia (minutos), voc leva para criar um
teste no BDDPM?
Espera-se que este tempo varie, dependendo da
complexidade do projeto e do teste a ser criado. Tambm
existem 02 cenrios. O primeiro cenrio refere-se quele no
qual o cliente est concebendo os testes medida em que
usa o BDDPM. No segundo cenrio, os clientes j
conceberam o teste e apenas vo utilizar a ferramenta para
123
Bitbucket um servio de hospedagem de repositrios para projetos que usam o Mercurial ou Git. O rgo
oferece planos comerciais e gratuitos, pblicos e privados.
69
insero do mesmo. Considerando-se o primeiro cenrio,

para testes mais simples a equipe acredita que alguns
poucos minutos (5 no mximo) seja suficiente para cada
teste. Para projetos mais complexos, este tempo poderia
chegar at 10 minutos. No segundo cenrio, estes tempos
passam a ser de 2 e 5 minutos, respectivamente.
Para futuras referncias ficou estabelecido que as perguntas seriam
referenciadas na sequncia da lista acima, recebendo um prefixo P, de pergunta.
Sendo assim, existem 19 perguntas de avaliao: da P01 at a P19.
5.3.2.4.
Definio das Mtricas
nesta etapa que as mtricas so definidas para prover toda informao

quantitativa necessria para responder as perguntas de maneira satisfatria. As
mtricas podem ser consideradas como refinamento das perguntas em modelos
quantitativos e/ou medies de produto. Uma vez que as mtricas forem medidas,
dever haver informao suficiente para responder s questes. No projeto de
avaliao do BDDPM as mtricas estabelecidas foram as seguintes:
1. Facilidade de Uso (Nota).
2. Quantidade de Cliques para se Atingir o Objetivo.
3. Nvel de Conhecimento Necessrio para Utilizao do BDDPM (Nota).
4. Interface Intuitiva (Nota).
5. Complexidade de Uso (Nota).
6. Qualidade da Interface (Nota).
7. ndice de Melhora no Tempo de Execuo dos Testes (Percentual).
8. ndice de Melhora no Tempo de Desenvolvimento do Projeto (Percentual).
9. Impacto Positivo no Projeto (Nota).
10. Adequao ao BDD (Nota).
11. Relevncia das Funcionalidades BDD implementadas (Nota).
12. Nvel de Atendimento s Funes do BDD (Nota).
13. ndice de Melhora da Quantidade de Falhas em Sistemas (Percentual).
14. Satisfao do Cliente do Projeto (Nota).
15. Satisfao do Gestor do Projeto (Nota).
16. Satisfao do Desenvolvedor do Projeto (Nota).
17. Satisfao do Testador do Projeto (Nota).
18. Necessidade de Utilizao de Ferramenta Auxiliar Externa (Sim | No).
19. Pretenso de Utilizao da Ferramenta em Outros projetos (Sim | No).
20. Relevncia dos locais/formas de distribuio do BDDPM (Nota).
21. Quantidade de Linguagens Suportadas pelo BDDPM.
22. Relevncia da Forma de Divulgao do BDDPM (Nota).
23. Esforo Necessrio para Criao de um Teste (Nota).
24. Tempo Necessrio para Criao de um Teste (Em Minutos).
25. Facilidade de Escrita dos Testes (Nota).
A escala adotada para atribuio das notas variou de 1 a 4. Para cada mtrica
atribuvel por nota, existe uma pergunta referente a ela que descreve a escala. Em
70
relao as mtricas avaliadas pelas respostas Sim e No, a avaliao seria feito
aps a verificao do quantitativo de pessoas que marcaram cada uma das respostas.
Para futuras referncias ficou estabelecido que as mtricas seriam referenciadas na
sequncia da lista acima, recebendo um prefixo M, de mtrica. Sendo assim, existem
25 mtricas de avaliao: da M01 at a M25.
5.3.2.5.
Produo do Plano GQM
O plano GQM nada mais do que a documentao dos objetivos, perguntas e

mtricas estabelecidas anteriormente. Seu objetivo servir de guia para interpretao
dos dados e servir de base para as duas ltimas etapas: coleta e anlise de dados. O
plano GQM de avaliao do BDDPM contm 04 objetivos, 19 perguntas e 25 mtricas.
A arquitetura do plano GQM do projeto de avaliao do BDDPM pode ser consultado
atravs da Figura 49:
Figura 49 Avaliao do BDDPM: Arquitetura do plano GQM
Para uma melhor visualizao dos relacionamentos, da Figura 50 a 53 possvel

conferir a relao Objetivo Perguntas Mtricas separada por objetivo (as
perguntas 5 e 7 servem apenas para dar suporte s perguntas 6 e 8, respectivamente):
Figura 50 Avaliao do BDDPM: Plano GQM Objetivo 1
71
72
5.3.2.6.
Produo do Plano de Medio
O principal objetivo do Plano de Medio integrar todas as mtricas e medidas

no plano do projeto identificando-se o momento, a forma e a responsabilidade da
coleta da informao.
No projeto do BDDPM foi estabelecido que todos os 03 integrantes da equipe de
avaliao eram responsveis por avaliar TODAS as perguntas estabelecidas. O
momento da avaliao ocorreu durante o desenvolvimento do SSAC, no qual o
BDDPM foi utilizado. Ao final do projeto a coleta das avaliaes (medies) foram
feitas atravs de um questionrio contendo todas as perguntas. Cada integrante
recebeu o questionrio e respondeu s questes.
Por exemplo, supondo a primeira pergunta do questionrio. A pergunta 01:
Est relacionada a 03 objetivos:

O1 - Fcil de utilizar em termos de usabilidade
O2 - Permitir a aplicao do BDD de maneira eficiente e eficaz
O3 - Facilitar a adoo do BDD
Est relacionada a 07 mtricas:
M01 - Facilidade de Uso
M02 - Quantidade de Cliques para se Atingir o Objetivo
M05 - Complexidade de Uso
M14 - Satisfao do Cliente do Projeto
M15 - Satisfao do Gestor do Projeto
M16 - Satisfao do Desenvolvedor do Projeto
M17 - Satisfao do Testador do Projeto
73
O texto da pergunta um diz: Em relao a facilidade de uso do BDDPM, que

nota, de 1 a 4, voc atribui ferramenta? Considere uma escala onde 1 significa
"Difcil de Usar" e 4 "Fcil de Usar". As notas 2 e 3 representam nveis
intermedirios com aproximao dos conceitos de "Fcil" e "Difcil",
respectivamente.
O avaliador deve responder pergunta diretamente (mtrica M01), mas tambm
deve atribuir valores s outras mtricas sob o ponto de vista da pergunta. Por exemplo:
o foco da pergunta 1 a facilidade, ento o avaliador tem que atribuir um valor a
cada uma das outras mtrica com este enfoque at que todas as mtricas
relacionadas sejam medidas. Nos casos onde a mtrica sugere uma perspectiva; seja
do cliente, do gestor, do desenvolvedor, ou do testador; o avaliador deve-se colocar
na posio de um deles e fazer a medio.
Ao final da avaliao todas as mtricas estaro medidas por todos os avaliadores
e sob diferentes pontos de vista. Isso fez-se necessrio, pois todas as mtricas
relacionadas a uma pergunta tm impacto sob ela e, consequentemente, nos objetivos
relacionados.
5.3.2.7.
Produo do Plano de Anlise
O plano de anlise um documento que simula a interpretao dos dados

baseando-se nas hipteses estabelecidas na fase de definio. Este plano servir de
guia a respeito de como os resultados devem ser analisados a fim de se alcanar um
resultado. Alm disso, tambm d uma indicao de qual seria um possvel resultado
da avaliao baseando-se nas expectativas iniciais do time.
Em relao ao projeto de avaliao do BDDPM, a avaliao final se dar com a
anlise e consolidao dos 03 questionrios respondidos, de maneira individual, pelos
03 integrantes da equipe. Como cada pergunta tem muitas mtricas associadas,
estabeleceu-se que a avaliao seria dada da seguinte maneira:
1. A cada mtrica seria atribudo o valor BOM ou o valor RUIM de acordo
com a medio (lembrando que a escala atualizada no d margens para
valores neutros).
2. Para as questes com resultados em percentual, qualquer ndice superior
a 10% seria classificado como BOM.
3. Para as questes cujas respostas fossem SIM ou NO, a anlise seria
obtida pela quantidade de votos obtidos, sendo que a maioria absoluta iria
definir pelo resultado BOM ou RUIM.
4. Com todas as mtricas avaliadas, obter-se-ia a quantidade de medies
boas.
5. Caso o quantitativo de marcaes obtido no passo anterior representasse,
pelo menos, 70% da quantidade de mtricas relacionadas pergunta, a
avaliao final seria de ATENDE AO(S) OBJETIVO(S). Caso contrrio,
a avaliao final seria NO ATENDE AO(S) OBJETIVO(S).
6. O mesmo processo seria aplicado para todos os objetivos com mais de
uma pergunta. Caso, pelo menos, 70% das perguntas fossem
respondidas satisfatoriamente, o objetivo seria considerado como
74
ATENDIDO. Caso contrrio, o objetivo seria considerado como NO

ATENDIDO.
7. Para que o objeto avaliado fosse classificado como um SUCESSO, pelo
menos 80% dos objetivos relacionados deveriam ser atendidos. Caso
contrrio, a classificao seria de FRACASSO.
8. Caso fosse necessrio fazer arredondamento em algum dos clculos
citados nos passos anteriores, dever-se-ia arredondar para o valor inteiro
mais prximo.
9. No caso de a avaliao ser conduzida por mais de uma pessoa, a mesma
regra do item 7, deveria ser aplicada, ou seja. Pelo menos 80% das
pessoas deveria classificar o objeto como um SUCESSO, para que ele,
de fato, esse status se concretizasse. Ou ento, o resultado final seria de
fracasso.
Seguindo-se estas instrues, o BDDPM seria considerado um sucesso se
cumprisse com 03, dos seus 04 objetivos. Uma simulao de avaliao foi feita
antecipadamente (Plano de Anlise). Nela o projeto do BDDPM atingiu o ndice
mnimo aceitvel para ser considerado um sucesso (80).
5.3.3. Fase de Coleta de Dados

Esta fase se deu incio com o desenvolvimento do SSAC. Durante todo o
desenvolvimento do sistema da PBprev foi solicitado que os envolvidos estivessem
sempre atentos a itens como: complexidade de uso, quantidade de cliques
necessrios para concretizar aes, etc. Cada observao e/ou detalhe importante
deveria ser anotado e registrado.
O SSAC um sistema muito simples, seu desenvolvimento no deveria ter
levado mais de 30 (trinta) dias, porm, como projeto piloto do BDDPM, bem como o
esforo extra para coleta e documentao dos dados para aplicao do GQM, o tempo
de desenvolvimento subiu para 45 (quarenta e cinco) dias; mas acabou dentro da
mdia de tempo dos projetos dentro da instituio. Este foi o tempo de durao da
fase de coleta, que foi acompanhada todos os dias pela equipe GQM do projeto.
O fato da equipe GQM ser composta pelo chefe de todos os envolvidos na
avaliao auxiliou na manuteno da motivao, alm disso a integrao da equipe e
o coleguismo de longa data tambm ajudaram nesse sentido e na fluidez dos
trabalhos.
No final do perodo, havia informaes suficientes, alm das prprias opinies e
experincias de cada um na utilizao da ferramenta.
5.3.4. Fase de Anlise de Dados

Esta fase se deu incio com o trmino do SSAC. O BDDPM foi avaliado de acordo
com as regras do Plano de Anlise. Houve concordncia entre os 03 avaliadores e o
BDDPM recebeu o status de SUCESSO, pois cumpriu com todos os seus objetivos
considerando o desenvolvimento do SSAC.
75
A Tabela 13 mostra o resumo da anlise (MTRICAS PERGUNTAS):

P01: 100,00% de atendimento aos objetivos
P02: 100% de atendimento aos objetivos
Tabela 13 BDDPM: Anlise GQM (Bottom-Up) Mtricas Perguntas
A Tabela 14 mostra o resumo geral da anlise (PERGUNTAS OBJETIVOS)

aps a consolidao de todos os questionrios de avaliao:
O1: 100,00% atendido
O3: 87,50% atendido

Tabela 14 BDDPM: Anlise GQM (Bottom-Up) Perguntas Objetivos
Baseado nos dados analisados, o BDDPM atingiu 100% de seus objetivos no

projeto do SSAC.
5.4. Avaliao do Resultado

De acordo com a equipe de avaliao, o BDDPM foi considerado um sucesso.
Entretanto, necessria muita cautela. Existem uma srie de questes que devem
ser analisadas, pois afetaram diretamente a avaliao. So elas:
1. Equipe de avaliao formada por profissionais de informtica: esse
fator afeta todo os objetivos, mas, em particular, os objetivos O1 e 04 que
esto relacionados aos clientes do produto de software. O BDDPM foi
criado para que pessoas sem conhecimentos tcnicos pudesse utiliz-lo
e para que clientes, tambm sem conhecimentos tcnicos, pudesse criar
os testes para os produtos dos quais eles so clientes. O fato da equipe
de avaliao do BDDPM j ter experincia com computadores e o cliente
do SSAC ser um especialista na rea, influenciou, positivamente, os
resultados medidos.
2. Equipe de avaliao da PBprev formada por profissionais sem
experincia de testes de software com a tcnica do BDD: o projeto do
SSAC foi o primeiro projeto da equipe a utilizar o Behavior Driven
Development. Nesse sentido, e embora preparaes e treinamentos
tenham sido ministrados, tudo era novidade. Devido falta de maturidade
76
3.
4.
5.
6.
7.
em relao a tcnica, essa no seria a melhor equipe para fazer uma

avaliao de um produto com enfoque no BDD: a avaliao pode ser
distorcida por falsas vises, conceitos, expectativas, empolgao, etc.
O SSAC um projeto muito pequeno: embora trate-se de um produto
real com o objetivo de ser utilizado dentro de um rgo governamental, o
SSAC um projeto incipiente para se fazer uma anlise mais aprofundada
e que tivesse requisitos mais exigentes em relao ao BDD. Um resultado
de sucesso no SSAC apenas indica que o BDDPM promissor, ou seja,
tem potencial: funcionou em um projeto pequeno, provavelmente funciona
em outros projetos pequenos, tem um bom potencial para projetos de
mdio porte, mas carece de maior avaliao em relao a projeto de
grande porte. Sendo assim, o resultado permite fazer conjecturas e
prospeces em um cenrio otimista.
Quase todos os objetivos terem alcanado 100% de satisfao
estranho: Foram estabelecidas duas hipteses para justificar o fato. A
primeira delas sugere erro no levantamento das mtricas, ou seja, elas
no respondem s perguntas de maneira adequada. Esta hiptese foi
refutada aps nova reviso e avaliao da equipe, que j havia dedicado
bastante tempo no levantamento e reviso das mesmas. A segunda
hiptese, que foi aceita, sugere que, devido subjetividade de grande
parte das perguntas, seria necessrio um maior nvel de maturidade em
relao ao BDD para responde-las mais adequadamente. A falta dessa
maturidade talvez tenha levado a percepo de que tudo estava 100%
satisfatrio.
Objetivo O3 como elo fraco: o objetivo 3 foi o que teve menor ndice de
atendimento, tanto no plano de anlise, como na avaliao de fato. Como
j foi abordado, por diversas vezes, trata-se, praticamente, do principal
objetivo do BDDPM; ou seja, necessrio dar ateno a este problema.
Existem dois motivos principais pelo ocorrido, e que merecem ateno: (i)
preciso aumentar o leque de recursos BDD oferecido pela ferramenta,
pois o BDDPM s entrega alguns e; (ii) facilitar a adoo da ferramenta
envolve disponibiliz-la atravs de canais de impacto e usar boas
estratgias de divulgao na comunidade de teste de software. At a data
da avaliao, a ferramenta s estava disponvel para download atravs de
seu repositrio GIT.
Primeira avaliao com GQM: esta foi a primeira avaliao com GQM
feita pela equipe, inclusive do prprio fiscal do GQM (time GQM). Isso
quer dizer que, em algum(ns) momento(s), pode ter havido falha em algum
passo/etapa; o que pode ter prejudicado, em algum nvel, a avaliao
Expectativas elevadas da equipe: o Plano de Anlise evidenciou que
havia uma expectativa elevada em relao ao BDDPM. Como o BDD
estava sendo utilizado pela primeira vez, criou-se a expectativa de que o
BDDPM era uma grande soluo para o problema. Isso afetou a postura
da equipe, mudando-a: deveria ser mais crtica, foi uma postura mais
complacente, fazendo com que a avaliao atingisse melhores resultados.
77
8. Participao do criador do BDDPM no processo de

acompanhamento da avaliao: A participao de Alvaro Magnum,
criador do BDDPM, como acompanhador da avaliao da ferramenta,
pode ter impactado na avaliao. Ainda que o avaliador tenha procurado
manter uma postura neutra, ele era o chefe da equipe e criou o BDDPM.
A equipe pode ter sido influenciada por estes fatores, fazendo com que a
avaliao atingisse melhores resultados.
O resultado da avaliao do BDDPM foi resumido em uma nota (pela equipe):
O BDDPM foi utilizado com sucesso no projeto do SSAC. Seus objetivos foram
alcanados e seus resultados levam a acreditar que o projeto uma boa opo para
adoo do BDD em pequenos projetos de desenvolvimento de software. A ferramenta
tambm apresenta grande potencial de crescimento. Equipe de Avaliao do
BDDPM.
78
Captulo 6 Concluso
Este o ltimo captulo do trabalho. Seu objetivo falar sobre as dificuldades
(Seo 6.1) encontradas no decorrer do projeto de criao de avaliao do BDDPM,
falar sobre alguns trabalhos futuros (Seo 6.2) que partiram de necessidades
identificadas no decorrer do projeto, elencar algumas contribuies (Seo 6.3)
advindas do BDDPM e fazer as consideraes finais (Seo 6.4) sobre o trabalho.
Trata-se de um objetivo sucinto e objetivo, dado que grande parte dos
comentrios e anlises foram feitos nos captulos anteriores.
6.1. Dificuldades Encontradas

Alguns problemas e dificuldades foram encontradas no transcorrer de
desenvolvimento deste trabalho, que envolveu o projeto de concepo, criao,
desenvolvimento, implantao, testes e avaliao do BDDPM. Foram eles:
Durante o desenvolvimento do BDDPM, alguns plugins Jquery de

interface, ou seja, voltados para a interao homem-mquina, que
reduziriam o tempo de desenvolvimento, caso fossem utilizados; tiveram
que ser descartados, pois seria necessrio pagar uma licena de uso por
cada verso distribuda do sistema criado, o que ficaria invivel em
relao ao BDDPM que seria distribudo livremente.
Durante o desenvolvimento do BDDPM, no foi possvel test-lo em
outros ambientes que no a plataforma Windows. Em teoria, o plugin deve
funcionar em qualquer ambiente com um servidor WEB com suporte a
PHP instalado; mas na prtica essa teoria no foi avaliada.
O questionrio para levantamento de requisitos do BDDPM obteve menos
respostas do que o esperado. Apenas 54 pessoas participaram do
processo de avaliao. Esperava-se que este nmero fosse bem maior,
em torno de 80, visto que foi enviado para vrias empresas de TI.
Objetivava-se fazer a avaliao do BDDPM com uma outra tcnica,
denominada Grounded Theory, mas, por questes de prazos, no foi
possvel aplica-la. Ela entrou para a listagem de trabalhos futuros.
A empresa onde o BDDPM foi utilizado, testado e avaliado no uma
empresa cujo foco a produo de software, ou seja, no possui equipe
com experincia em desenvolvimento e teste de software, o que seriam
atributos importantes para se avaliar uma ferramenta focada em uma
tcnica de testes de software: o Behavior Driven Development.
No incio de 2015, momento pelo qual o BDDPM comearia a ser avaliado
com a tcnica do GQM, o Gerente de TI da empresa, Alvaro Magnum
(tambm criador do BDDPM, integrante da equipe GQM e de
acompanhamento da equipe de avaliao do BDDPM), foi exonerado do
cargo em comisso que ocupava. Nesse ano houve reestruturao do
quadro de servidores devido s mudanas polticas decorrentes das
eleies para Governadores de Estado, ocorridas em todo o pas no ano
79
de 2014. Com a mudana da presidncia da PBprev, o gerente foi

destitudo do cargo. Como o projeto j havia sido iniciado, ele continuou,
mas o acompanhamento passou a ser a distncia.
Durante a utilizao do BDDPM no projeto de desenvolvimento do SSAC,
em vez do cliente do projeto, antes de utilizar o BDDPM para fazer a
criao dos testes, utilizava o bloco de notas para escrever o cdigo
Gherkin. Uma vez com o cdigo em mos, ele o utilizava para inserir os
passos no BDDPM. O cliente justificou que no era necessrio fazer isso,
mas facilitava o fluxo de pensamento e concepo de testes dele. O
objetivo do BDDPM que os clientes escrevam os testes nele, sem
precisar de ferramentas auxiliares. No se sabe se isso foi um fato
isolado, mas foi registrado como problema para estudo e avaliao em
outros projetos.
A equipe de avaliao GQM era pequena e sem experincia de aplicao
da tcnica em outros projetos, o que pode ter afetado, em algum nvel e
em algum momento, o processo de avaliao.
As expectativas da equipe em relao ao BDDPM eram altas, esse fato
foi intensificado pelo fato do BDD tambm ter sido utilizado pela primeira
vez pela equipe. As expectativas podem ter impactado o discernimento
do time durante o processo de avaliao.
No foi possvel garantir 100%, aps a avaliao, que o BDDPM atende
seus objetivos; entretanto, o status de potencial para atingi-los foi
considerado satisfatrio.
6.2. Trabalhos Futuros

Todas as propostas de trabalho a serem executadas no futuro baseiam-se nos
04 objetivos do BDDPM e os resultados de sua avaliao. Os objetivos so:
1.
2.
3.
4.
Fcil de utilizar em termos de usabilidade

Permitir a aplicao do BDD de maneira eficiente e eficaz
Facilitar a adoo do BDD
Permitir a escrita dos testes pelos clientes
Para impulsionar o OBJETIVO 1, os seguintes trabalhos sero executados:
Adicionar mais assistentes e vdeos de ajuda nas telas do BDDPM.

Colher dados de formas de utilizao da ferramenta e fazer pesquisas em
relao facilidade e usabilidade para implantao de melhorias.
Adio de mais recursos do BDD atravs da linguagem Gherkin, com

opes como: Background, Transformations, Examples, Data Tables, etc.
Adicionar integrao com o Cucumber.
Permitir a execuo dos testes a partir do prprio BDDPM.

80
Aumentar o nmero de linguagens suportadas: Java, C#, Ruby, Python,

etc.
Aumentar o nmero de plataformas suportadas: Jira, RedMine, Trac,
BugZilla, etc.
Criar formas de divulgao para impulsionar a promoo da ferramenta
no meio acadmico e em fbricas de software.
Disponibilizar a ferramenta atravs de diversos canais.
Incluir um modo de utilizao avanado na interface de criao dos testes

para usurios mais experientes que preferirem inserir dados textuais e
optarem por este modo.
Melhorar o Wizard atual para tornar ainda mais intuitiva a criao dos
testes para usurios sem conhecimentos tcnicos.
Criar um mdulo/extenso/abstrao em cima do Gherkin, que uma
linguagem Business Readable, para torna-la Business Writable.
Objetivo do doutorado.
Uma vez que todos esses trabalhos forem concludos o BDDPM ser novamente
analisado. No apenas com GQM, mas agora tambm com uma tcnica denominada
Grounded Theory124, que permite, atravs de uma anlise rigorosa e sistemtica,
entender determinada situao sem uma teoria a ser testada; apenas atravs da
anlise de dados que emergirem de um determinado evento
6.3. Contribuies
Entre as principais contribuies do trabalho, pode-se destacar:
1. Facilitou a adoo do BDD dentro de uma empresa real - entregar
valor aos clientes faz parte da vantagem competitiva de qualquer
empresa. Facilitar a adoo do BDD e permitir que clientes de projetos de
desenvolvimento de software participem mais ativamente dos projetos e
eles mesmos possam escrever os testes para os produtos que esto
comprando, entregar valor. O ferramental fruto deste trabalho garantiu,
dentro de um ambiente real, a PBprev, esta entrega.
2. Exemplificao real e prtica de como aplicar o GQM para avaliao
de software este documento descreve, em detalhes, como o GQM pode
ser aplicado de maneira prtica para avaliar um produto de software
quanto ao cumprimento de objetivos;
3. Definio dos requisitos bsicos para uma ferramenta BDD no
mercado aps pesquisa bibliogrfica e pesquisa com 56 profissionais
do mercado de TI, foi possvel estabelecer um conjunto de funes
mnimas para que uma ferramenta BDD permita, de fato, a utilizao e
adoo da tcnica;
4. Definio de um conjunto de funcionalidades para facilitar a adoo
do BDD no mercado dentre eles esto a possibilidade de criao de
124
http://www.groundedtheory.com
81
5.
6.
7.
8.
testes pelo prprio cliente do produto de software que pode escrever os

testes de maneira remota e atravs de um Wizard; e a possibilidade de
acompanhamento de testes em tempo real pelos stakeholders;
Motor de converso de cdigo de alto nvel, descrito em Gherkin,
para cdigo de teste em C# uma grande vantagem do BDDPM
permitir a criao de cdigos de teste, escritos em uma linguagem de
programao, serem gerados a partir da definio do comportamento do
software feito pelo cliente. Este motor utiliza expresses regulares e de
cdigo aberto, podendo ser adaptado e reutilizado para gerao de cdigo
de teste em outras linguagens como Java, Python, Ruby, PHP, etc.
Criao de uma ferramenta open-source a opo de tornar o BDDPM
uma ferramenta de cdigo aberto, livre para ser incrementado e
melhorado pela comunidade e profissionais de TI ligados ao
desenvolvimento e testes de software, permitir, ainda mais, facilitar a
adoo do BDD e, consequentemente, ir ao encontra de um ambiente de
desenvolvimento orientado por comportamento.
Primeiro plugin BDD para o Mantis o repositrio oficial do Mantis no
listava opes para trabalho com o Behavior Driven Development. O
BDDPM o primeiro plugin a oferecer este recurso para a plataforma.
Tratamento de tema de interesse direto da empresa em que o
mestrando trabalha O BDDPM melhorou e facilitou a atividade de teste
de software dentro da Paraba Previdncia e, consequentemente,
melhorou os produtos de softwares criados dentro da instituio. Este
objetivo est alinhado aos objetivos do mestrado profissional que,
conforme j citado anteriormente, diz o seguinte: O MPROF difere do
Mestrado Acadmico por lidar com problemas que o profissional
vivencia dentro do mercado. Sendo assim, os projetos de concluso
normalmente tratam de temas de interesse direto da empresa em que
o mestrando trabalha. A interao dos acadmicos com as
problemticas enfrentadas no dia-a-dia das instituies contribui para a
melhoria das empresas, e consequentemente para o desenvolvimento
da regio125.
6.4. Consideraes Finais

O BDDPM foi criado com alguns objetivos iniciais, o principal deles: ser uma
ferramenta capaz de agregar recursos que facilitem a adoo do BDD no mercado.
Durante os quase 06 (meses) de desenvolvimento do projeto, objetivos foram
refinados, recursos do plugin foram adicionados e excludos, problemas foram
detectados, etc.; entretanto, a partir do momento em que o BDDPM passou a ser
utilizado dentro de um projeto real, percebeu-se que ele agregou valor, principalmente
para uma equipe no familiarizada com a metodologia de testar comportamento de
software. Todos ficaram satisfeitos com os resultados alcanados.
125
http://www2.cin.ufpe.br/site/secao.php?s=3&c=116
82
A aplicao de uma tcnica de avaliao/medio reconhecida (GQM)

consolidou o pensamento de que o BDDPM um plugin que pode ser evoludo para
que seus objetivos sejam alcanados, de fato, em outras organizaes.
Independentemente de conjecturas, o BDDPM foi adotado pela PBprev que ir
utiliz-lo nos prximos projetos de desenvolvimento de software do rgo. H de se
considerar que o BDD foi aplicado pela primeira vez, e com sucesso, por uma equipe
sem experincia com a tcnica. Estes resultados vo ao encontro dos objetivos do
BDDPM. Sendo assim, e aps anlise da avaliao da equipe GQM, este trabalho
conclui que o BDDPM tem grande potencial de atingir seus objetivos, principalmente
em projetos de pequeno e mdio porte.
83
Referncias Bibliogrficas
Beck, K. Test Driven Development: By Example. Boston, MA, USA: Addison-Wesley
Longman Publishing Co., Inc., 2002. ISBN: 0321146530.
Solis, C and Xiaofeng Wang (2011). A Study of the Characteristics of Behaviour Driven
Development. In the proceedings of the 37th EUROMICRO conference on Software
Engineering and Advanced Applications (SEAA) (pp. 383 - 387). Oulu, Finland.
I. Necas. BDD as a Specification and QA Instrument. Diplomov prce. Masarykova
univerzita, Fakulta informatiky, 2011 [cit. 2014-01-30].
K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J.
Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor,
K. Schwaber, J. Sutherland e D. Thomas. Manifesto for Agile Software Development.
Acessado em Novembro de 2014. URL: http://www.agilemanifesto.org.
D. Chelimsky, D. Astels, B. Helmkamp, Z. Dennis, D. North e A. Hellesoy. The Rspec
Book: Behaviour Driven Development With Rspec, Cucumber, and Friends. Pragmatic
Bookshelf Series. Pragmatic Programmers, LLC, 2010. ISBN: 9781934356371.
Naik, Kshirasagar, Tripathy, Priyadarshi. Software testing and quality assurance.
Wiley. 2008. ISBN 978-0-471-78911-6
C. Feduke. Instant RSpec Test - Driven Development How-to. Packt Publishing, 2013.
ISBN: 1782165223, 9781782165224.
Ye, Wayne. Instant Cucumber BDD How-to. Packt Publishing. 2013. ISBN 978-178216-348-0.
A. Hellesoy e M. Wynne. The Cucumber Book: Behaviour-Driven Development for
Testers and Developers. Pragmatic Programmers. Pragmatic Bookshelf, 2012. ISBN:
9781934356807.
D. North. Introducing BDD.
http://dannorth.net/introducing-bdd.
Acessado
em
Julho
de
2014.
URL:
R. S. M. Rogerio Atem de Carvalho Fernando Luiz de Carvalho e Silva. Business

Language Driven Development: Joining Business Process Models to Automated
Tests. CoRR (2011).
H. L. Tavares, G. G. Rezende, V. M. dos Santos, R. S. Manhes e R. A. de Carvalho.
A tool stack for implementing Behaviour-Driven Development in Python Language.
CoRR abs/1007.1722 (2010).
84
V. R. Basili, "Data Collection, Validation, and Analysis," in Tutorial on Models and

Metrics for Software Management and Engineering, IEEE Catalog No. EHO-167-7,
1981, pp. 310-313.
V.R. Basili, "Software Modeling and Measurement: The Goal Question Metric
Paradigm," Computer Science Technical Report Series, CS-TR-2956 (UMIACS-TR92-96), University of Maryland, College Park, MD, September 1992.
Soingen, R.V., Berghout, E.: The Goal/Question/Metric Method: a practical guide for
quality improvement of software development. McGraw-Hill Co. (1999).
V.R. Basili, G. Caldiera and H. D. Rombach. Goal Question Metric Paradigm. In John
C. Marciniak, editor, Encyclopedia of Software Engineering, volume 1. John Wiley &
Sons, 1994.
V. R. Basili and D. M. Weiss. A Methodology for Collecting Valid Software Engineering
Data. IEEE Transactions on Software Engineering, SE-10(6):728-738, November
1984.
B. Hoisl, M. Oivo, G. Ruhe, and F. van Latum. No Improvement without Feedback:
Experiences from goal-oriented measurement at Schlumberger. Fifth European
Workshop on Software Process Technology, Nancy, France, October 1996.
H. D. Rombach. Practical Benefits of Goal-Oriented Measurement. Software Reliability
and Metrics, Elsevier Applied Science, 1991.
Christiane G. von Wangenheim, Gnther Ruhe. Anlise de Custo e Benefcio de
Mensurao Baseada em GQM.X CITS QS, 1999
R. van Solingen, F. van Latum, M. Oivo, and E. Berghout. Application of Software
Measurement at Schlumberger RPS: Towards Enhancing GQM. Proceedings of the
Sixth European Software Cost Modelling Conference (ESCOM), May 1995.
R. van Solingen. Goal-Oriented Software Measurement in Practice: Introducing
Software Measurement in Schlumberger Retail Petroleum Systems. Master Thesis
Report, Schlumberger RPS, Netherlands, 1995.
JBehave. Acessado em Julho de 2014. URL: http://jbehave.org.
Cucumber. Acessado em Julho de 2014. URL: http://cukes.info.
RSpec. Acessado em Julho de 2014. URL: http://rspec.info.
SpecFlow. Acessado em Julho de 2014. URL: http://www.specflow.org.
85
R. Carvalho, R. Soares Manhes, and F.L. de Carvalho, Filling the Gap between
Business Process Modeling and Behavior Driven Development, CoRR, 2008.
Krzysztof Czarnecki, Generative Programming - Principles and Techniques of
Software Engineering Based on Automated Configuration and Fragment-Based
Component Models, 1998, Department of Computer Science and Automation.
Van Solingen, Rini; Egon Berghout (1999). The Goal/Question/Metric Method.
McGraw-Hill Education. ISBN 0-07-709553-7.
Basili, V.R.; J. Heidrich, M. Lindvall, J. Mnch, C.B. Seaman, M. Regardie, A.
Trendowicz (2009). "Determining the impact of business strategies using principles
from goal-oriented measurement". Business Services: Konzepte, Technologien,
Anwendungen. Internationale Tagung Wirtschaftsinformatik. Books OCG. Vienna,
Austria: sterreichische Computer Gesellschaft. ISBN 978-3-85403-246-5.
M.K. Daskalantonakis. A Practical View of Software Measurement and Implementation
Experiences within Motorola. IEEE Transactions on Software Engineering, Vol. 18, No.
11, 1992.
C. Differding, B. Hoisl, C. Lott. Technology Package for the Goal/Question Metric
Paradigm. Technical Report 281-96, University of Kaiserslautern, Department of
Computer Science, D-67653 Kaiserslautern, Germany, 1995.
Is TDD Dead? Acessado em Julho de 2014. URL: http://martinfowler.com/articles/istdd-dead.
Popular Bug Tracking Software. Acessado em Julho de
http://www.softwaretestinghelp.com/popular-bug-tracking-software.
2014.
URL:
Generative
Programming.
Acessado
em
Julho
de
2014.
URL:
http://www.programtransformation.org/Transform/GenerativeProgrammingWiki.
Jerkovic, John I. SEO Warrior. O'Reilly, 2009.ISBN: 978-0-596-15707-4.
Sommerville, Ian. Software Engineering. 9. ed. Harlow, England: Addison-Wesley,
2010. ISBN 978-0-13-703515-1.
Nagappan, N., Maximilien, E., Bhat, T., Williams, L.: Realizing Quality Improvement
through Test Driven Development: Results and Experiences of Four Industrial Teams.
Empirical Software Engineering, pp. 289-302 (2008).
Arnold, D., Corriveau, J., Shi, W.: Validation against Actual Behavior: Still a Challenge
for Testing Tools. Software Engineering Research and Practice (SERP). CSREA
Press. (2010).
86
VAGAS. Voc Jnior, Pleno ou Snior? Acessado em Janeiro de 2015. URL:

http://www.vagas.com.br/profissoes/acontece/no-mercado/voce-junior-pleno-senior.
McFarlan, F.W. 1984. Information Technology Changes the Way You Compete,
Harvard Business Review, 62(3): 98-103.
McCracken, D.D., Digital Computer Programming, John Wiley, 1957.
RESS, Ana Paula, DE OLIVEIRA MORAES, Renato y SALERNO, Mrio Srgio. TestDriven Development as an Innovation Value Chain. Journal of Technology
Management & Innovation, 2013, vol.8, no., p.10-10. ISSN 0718-2724.
WANGENHEIM, Christiane Gresse von. Utilizao do GQM no desenvolvimento de
software. Laboratrio de Qualidade de Software, Instituto de Informtica, Universidade
do Vale do Rio dos Sinos. So Leopoldo, 2000.
Andreas Birk, Rini van Solingen, Janne Jrvinen, Business Impact, Benefit, and Cost
of Applying GQM in Industry: An In-depth, Long-term Investigation at Schlumberger
RPS, Proceedings of the 5th International Symposium on Software Metrics
(Metrics98), Bethesda Maryland, November 19-21, 1998.
Solingen, R. van, E.W. Berghout, E. Kooiman, Assessing feedback of measurement
data: Schlumberger practices with reflection to theory, Proceedings of the 4th
International Symposium on Software Metrics (Metrics97).
Glaser, Barney. Strauss, Anselm. Awareness of Dying. Chicago: Aldine Publishing
Company. 1965. ISBN 0-202-30763-8.
Rediscovery of Test Driven: https://www.quora.com/Why-does-Kent-Beck-refer-to-therediscovery-of-test-driven-development
The ROI of TDD: http://powersoftwo.agileinstitute.com/2012/08/the-roi-of-test-drivendevelopment.html
What is Grounded Theory? Acessado em
http://www.groundedtheory.com/what-is-gt.aspx.
Dezembro
de
2014.
URL:
You wont believe how old TDD is. Acessado em Dezembro de 2014. URL:
https://arialdomartini.wordpress.com/2012/07/20/you-wont-believe-how-old-tdd-is.
Selenium. Acessado em Dezembro de 2014. URL: http://www.seleniumhq.org.
87
Anexo 1 Questionrio para Criao da

do BDDPM
1. Em sua opinio, para uma aplicao WEB ser considerada de fcil uso e simples, inclusive
para usurios com pouco, ou nenhum, conhecimento tcnico; qual deveria ser o nmero de
telas teis dessa aplicao? Considere que TELA TIL aquela que contm ou permite a
entrada informaes importantes e/ou essenciais para utilizao do sistema.
a. De 1 a 4
b. De 4 a 8
c. De 8 a 12
d. Mais de 12
e. Outro
2. Qual seu nvel de experincia/conhecimento em relao ao BDD (Behavior Driven
Development)?
a. Desconheo completamente
b. Sei o que , mas nunca trabalhei com a tcnica
c. Menos de 1 ano de experincia
d. Menos de 3 anos de experincia
e. Mais de 3 anos de experincia
3. Em sua opinio, considerando uma aplicao WEB voltada para o BDD (Behavior Driven
Development) e que permite a criao de testes de aceitao com Gherkin, qual a melhor
proposta em termos de facilidade de uso? (Inclusive para usurios com pouco, ou nenhum,
conhecimento tcnico).
a. Campo de texto livre para insero do Gherkin
b. Recursos de arrastar e soltar componentes para montagem do Gherkin
c. Mistura entre campos de mltipla escolha (combo box, radio, etc.) e campos de texto livre
para montagem do Gherkin
d. Importao de testes de aceitao prontos de outra ferramenta
e. Nenhuma das opes e/ou no me considero apto a responder pergunta
4. Na sua opinio, qual seria o recurso mais importante em uma aplicao WEB voltada para o
BDD (Behavior Driven Development)?
a. Possibilidade de acompanhamento do resultado dos testes
b. Execuo automtica dos testes de aceitao
c. Gerao de cdigo de testes
d. Eu poder escrever testes de aceitao de maneira fcil
e. Outro
5. Na sua opinio, qual seria o recurso mais importante PARA O CLIENTE DE UM PRODUTO
DE SOFTWARE em uma aplicao WEB voltada para o BDD (Behavior Driven Development)?
a. Possibilidade de acompanhamento do resultado dos testes
b. Execuo automtica dos testes de aceitao
c. Gerao de cdigo de testes
d. Eu poder escrever testes de aceitao de maneira fcil
e. Outro
6. Voc :
a. Um(a) desenvolvedor(a)/testador(a) de software
b. Um(a) gestor(a) de projetos de software
c. Um(a) cliente de projeto de software
d. Diretor(a)/Scio(a) de uma fbrica de software
e. Outro
88
Anexo 2 Questionrio para Avaliao

GQM
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Em relao a facilidade de uso do BDDPM, que nota, de 1 a 4, voc atribui ferramenta? Considere uma
escala onde 1 significa "Difcil de Usar" e 4 "Fcil de Usar". As notas 2 e 3 representam nveis intermedirios
com aproximao dos conceitos de "Fcil" e "Difcil", respectivamente.
Para utilizar o BDDPM de maneira satisfatria, qual o nvel (de 1 a 4) de conhecimento tcnico empregado
por voc? Considere uma escala onde 1 significa "Nenhum Conhecimento Tcnico" e 4 significa "Muito
Conhecimento Tcnico". As notas 2 e 3 representam nveis intermedirios com aproximao dos conceitos de
"Nenhum" e "Muito", respectivamente.
Considerando o objetivo do BDDPM de permitir a utilizao da tcnica do BDD em um projeto de
desenvolvimento de software, bem como os recursos oferecidos pela ferramenta; classifique a interface da
ferramenta atribuindo uma nota de 1 a 4. Considere uma escala onde 1 significa "Pouco Intuitiva" e 4 significa
"Muito Intuitiva". As notas 2 e 3 representam nveis intermedirios com aproximao dos conceitos de "Pouco"
e "Muito", respectivamente.
Considerando os recursos do BDDPM, como voc classificaria sua interface considerando-a como um meio
de acesso eficaz e atraente a estes recursos? Considere uma escala onde 1 significa "Baixa Qualidade" e 4
significa "Alta Qualidade". As notas 2 e 3 representam nveis intermedirios com aproximao dos conceitos
de "Baixo" e "Alto", respectivamente.
Qual a mdia de tempo (em minutos) para execuo da fase de testes dos projetos de desenvolvimento de
software da empresa, sem a utilizao do BDDPM? (Pergunta de Suporte)
Qual a mdia de tempo (em minutos) para execuo da fase de testes dos projetos de desenvolvimento de
software da empresa, com a utilizao do BDDPM?
Qual a mdia de tempo (em minutos) de durao dos projetos de desenvolvimento de software da empresa,
sem a utilizao do BDDPM? (Pergunta de Suporte)
Qual a mdia de tempo (em minutos) de durao dos projetos de desenvolvimento de software da empresa,
com a utilizao do BDDPM?
Levando-se em considerao a utilizao do BDDPM no projeto de desenvolvimento de software, como voc
classifica (nota de 1 a 4) o impacto dos benefcios agregados ao projeto? Considere uma escala onde 1
significa "Baixo Impacto" e 4 significa "Alto Impacto". As notas 2 e 3 representam nveis intermedirios com
aproximao dos conceitos de "Baixo" e "Alto", respectivamente.
Considerando a tcnica do BDD, como voc classificaria (nota de 1 a 4) o nvel de alinhamento e atendimento
do BDDPM a ela? Considere uma escala onde 1 significa "Fraco" e 4 significa "Forte". As notas 2 e 3
representam nveis intermedirios com aproximao dos conceitos de "Fraco" e "Forte", respectivamente.
Qual o quantitativo mdio de falhas/bugs encontrados nos produtos dos projetos de desenvolvimento de
software da empresa, sem a utilizao do BDDPM? (Pergunta de Suporte)
Qual o quantitativo mdio de falhas/bugs encontrados nos produtos dos projetos de desenvolvimento de
software da empresa, com a utilizao do BDDPM?
Qual o seu nvel (nota de 1 a 4) de satisfao em relao a eficcia e utilizao do BDDPM em um projeto de
desenvolvimento de software? Considere uma escala onde 1 significa "Pouco Satisfeito" e 4 significa "Muito
Satisfeito". As notas 2 e 3 representam nveis intermedirios com aproximao dos conceitos de "Pouco" e
"Muito", respectivamente.
Ao utilizar o BDDPM no projeto de desenvolvimento de software, voc precisou recorrer outras ferramentas
para aplicao do BDD? Responda com Sim, ou No.
Voc pretende utilizar o BDDPM em outros projetos? Responda com Sim, ou No.
Considerando a forma de disponibilizao do BDDPM, como voc classificaria (nota de 1 a 4) sua
acessibilidade e visibilidade? Considere uma escala onde 1 significa "Pouca acessibilidade / visibilidade" e 4
significa "Muita acessibilidade / visibilidade". As notas 2 e 3 representam nveis intermedirios com
aproximao dos conceitos de "Pouco" e "Muito", respectivamente.
Quantas linguagens de programao devem ser suportadas, em sua opinio, para que BDDPM tenha grande
aceitao no mercado?
Qual o seu nvel de dificuldade (nota de 1 a 4) para criar um teste no BDDPM? Considere uma escala onde 1
significa "Fcil" e 4 significa "Difcil". As notas 2 e 3 representam nveis intermedirios com aproximao dos
conceitos de "Fcil" e "Difcil", respectivamente.
Quanto tempo, em mdia (minutos), voc leva para criar um teste no BDDPM?
89
Anexo 3 Autorizao de Utilizao do

BDDPM na PBprev e Divulgao dos
Resultados
AUTORIZAO
Eu, Alvaro Magnum Barbosa Neto, gestor de TI da Paraba Previdncia, matrcula
460.212-9, autorizo a utilizao do BDDPM (plugin para aplicao da tcnica de teste de
software denominada Behavior Driven Development) no projeto SISPROTO SSAC desta
instituio, para fins de avaliao acadmica (dissertao de mestrado de aluno da UFPE
Universidade Federal de Pernambuco).
A partir desta data, ficam disponveis para o projeto, 04 colaboradores e toda
infraestrutura de TI da PBprev para serem utilizados de acordo com as necessidades de
utilizao e avaliao do BDDPM at a data de finalizao do projeto.
Ressalte-se que, para todos os fins e sem ressalvas, que o SISPROTO SSAC de
propriedade da PBprev e foi utilizado apenas como suporte para avaliao do BDDPM. A
presidncia da PBprev no autoriza detalhamento de cdigos da ferramenta, apenas a
divulgao do nome da empresa, da avaliao dos resultados e da metodologia empregada.
Joo Pessoa - PB, 01 de dezembro de 2014
________________________________________
ALVARO MAGNUM BARBOSA NETO
GESTOR DE TI PARABA PREVIDNCIA
MATRCULA 460.212-9
TELEFONE: (0xx83) 2107.1128
E-MAIL: alvaromagnum@pbprev.pb.gov.br
90
Anexo 4 Relato Pessoal na rea de

Teste de Software
Comecei a trabalhar na rea de Desenvolvimento de Software aos 18 anos, atualmente tenho 30. Durante
esse perodo tive a oportunidade de ocupar cargos de nvel jnior, pleno e snior e trabalhar em empresas de
diversos portes, desde as que operavam "no vermelho", passando pelas que faturam alguns milhares, at as que
movimentam bilhes de reais por ano. Tambm tive a oportunidade de trabalhar em projetos locais de pequeno
porte e de grandes projetos distribudos globalmente. Tive, ainda, a oportunidade de vivenciar duas realidades
bem distintas uma vez que trabalhei em empresas privadas e atualmente trabalho em uma instituio pblica.
Fui estagirio, tcnico, consultor e gerente. Passei por empresas de pequeno, mdio e grande porte, com setores
financeiros que movimentavam mais de R$ 115 mi/ms.
Percebi que cada uma dessas empresas se preocupava bastante com construir um produto de alta
qualidade e livre de defeitos, porm nem todas davam a mesma ateno para construir o que o cliente queria,
exatamente com o comportamento previsto: o velho e clssico problema do V & V, verificao e validao.
Havia, nas empresas, grande preocupao com a verificao, ou seja, checar se o produto atendia aos seus
requisitos funcionais e no funcionais; porm no com a validao, isto , checar se o produto realmente estava
de acordo com as expectativas do cliente. Nem sempre um produto que funciona o que o cliente realmente
quer. Um produto livre de erros pode ser completamente intil para um cliente se no este no se comporta da
maneira como ele espera.
Nesse sentido todos adotavam testes de unidade com a abordagem do TDD como requisito bsico e
primordial para testes. Cada desenvolvedor tinha que escrever seu cdigo com sua bateria mnima de testes
de unidade. Depois o software passava por uma bateria de testes exaustivos junto aos testadores cujo os
objetivos eram de encontrar defeitos. Muitos testes eram realizados para evitar que um nico erro passasse
despercebido, mas no havia teste para saber se a funcionalidade satisfazia a necessidade cliente.
Uma possvel explicao para as coisas serem assim pode ser o fato de que, muitas vezes, manter o
contato com o cliente custoso. Nem sempre o cliente est disponvel para acompanhar o desenvolvimento de
seu produto, o cliente pode at mesmo estar localizado distante geograficamente; em um outro pas, por
exemplo. Muitas vezes os requisitos so levantados em uma nica reunio e outros contatos so realizados por
telefone ou pela Internet. Muitas vezes esses encontros s so realizados quando existe algo palpvel que pode
ser mostrado e entregue, e o cliente no tem acesso ao produto durante o desenvolvimento das entregas.
Sob esta perspectiva, era muito fcil descrever e escrever funes tcnicas. Por isso o TDD foi to utilizado:
desenvolvedores tinham acesso s funes e escreviam cdigo e testes para estas funes. O comportamento
do software era esquecido, ou, um melhor atributo, evitado. Evitado por ser custoso. Ter acesso ao cliente tempo
o suficiente ou com a frequncia suficiente para descrever, testar e acompanhar comportamentos poderia ser
muito custoso.
BDD uma evoluo do TDD, continua sendo TDD e agrega o teste de comportamento; entretanto, em
12 anos de experincia profissional nunca participei de um projeto onde BDD fosse uma exigncia assim como o
TDD. Nunca me pediram BDD, nunca pedi BDD. Por qu? O que faltou? Ser que alguma tcnica ou estratgia de
adoo do BDD poderia ser utilizada da mesma maneira em todas as empresas, ou teria que se adaptar a cada
uma delas?
Estas perguntas me levaram a algumas reflexes em relao ao BDD e foram alguns dos motivos que me
fizeram pensar neste trabalho.
ALVARO MAGNUM BARBOSA NETO, JOO PESSOA - PB, 2014
91

Em Direção A Um Ambiente de Desenvolvimento de Software Orientado Por Comportamento

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Em Direção A Um Ambiente de Desenvolvimento de Software Orientado Por Comportamento

Enviado por

Direitos autorais:

Formatos disponíveis

Ps-Graduao em Cincia da Computao

Em Direo a um Ambiente de Desenvolvimento de Software Orientado por

Universidade Federal de Pernambuco

UNIVERSIDADE FEDERAL DE PERNAMBUCO

ALVARO MAGNUM BARBOSA NETO

Em Direo a um Ambiente de Desenvolvimento de Software Orientado por

Este trabalho foi apresentado Ps-Graduao em Cincia

ORIENTADOR: Prof. Dr. Vinicius Cardoso Garcia

Dedico este trabalho a toda minha

"Eu sou o Alfa e o mega, o Primeiro

LISTA DE ABREVIAES: .................................................................................... XIV

REFERNCIAS BIBLIOGRFICAS: ........................................................................ 84

Anexo 1: Questionrio para Criao da do BDDPM ................................................ 88

Teste de Software: TDD e BDD na Prtica .................................................... 1

Viso Geral da Proposta ................................................................................ 5

A Metodologia de Pesquisa Aplicada ............................................................. 7

Estrutura e Resumo da Dissertao............................................................... 8

Captulo 2 A Situao do TDD e do BDD no Mercado

TDD x BDD .................................................................................................. 15

Captulo 3 Ferramentas Disponveis no Mercado e o Plugin Criado

Plataformas de Gesto de Projetos Online .................................................. 18

Sobre o Redmine ...................................................................................... 20

Sobre o Trac ............................................................................................. 20

Sobre o BugZilla ....................................................................................... 21

Sobre o Mantis .......................................................................................... 21

A Escolha da Plataforma .............................................................................. 22

O Plugin Criado ............................................................................................ 22

Licena do BDDPM ...................................................................................... 28

Captulo 4 O BDDPM: Mais Detalhes

Metodologia de Desenvolvimento do BDDPM ............................................. 29

Fase 1: Levantamento de Requisitos ........................................................ 29

Fase 2: Desenvolvimento e Testes ........................................................... 34

Fase 3: Implantao ................................................................................. 40

Recursos do BDDPM na Prtica .................................................................. 41

Criao dos Testes de Aceitao ............................................................. 43

Gerao do Cdigo de Teste .................................................................... 49

Resultado dos Testes ............................................................................... 51

Captulo 5 Aplicao do GQM e Anlise dos Resultados

Um Breve Contexto ...................................................................................... 52

A Tcnica do Goal-Question-Metric (GQM) ................................................. 54

O BDDPM segundo o GQM ......................................................................... 58

Fase de Planejamento .............................................................................. 59

Estabelecimento da Equipe GQM.......................................................... 59

Seleo do Objeto de Avaliao ............................................................ 59

Estabelecimento da Equipe de Avaliao do Projeto ............................ 60

Criao do Plano de Projeto .................................................................. 60

Treinamento e Promoo ...................................................................... 61

Fase de Definio ..................................................................................... 61

Definio dos Objetivos da Medio...................................................... 62

Conduo de entrevista GQM ............................................................... 63

Definio de questes/perguntas e hipteses ....................................... 65

Definio das Mtricas .......................................................................... 70

Produo do Plano GQM ....................................................................... 71

Produo do Plano de Medio ............................................................. 73

Produo do Plano de Anlise .............................................................. 74

Fase de Coleta de Dados ......................................................................... 75

Fase de Anlise de Dados ........................................................................ 75

Trabalhos Futuros ........................................................................................ 80

Consideraes Finais ................................................................................... 82

Figura 32: Avaliao do BDDPM: Arquitetura do plano GQM .................................. 71

Associao Brasileira de Normas Tcnicas

Rich Site Summary

Eu tive um problema. Enquanto estive