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

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, MAIO/2015

ii

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

iii

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.

iv

"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

v

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.

vi

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.

vii

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.

viii

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

ix

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

x

Captulo 6 Concluso

6.1. Dificuldades Encontradas ............................................................................. 79

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

6.3. Contribuies ............................................................................................... 81

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

xi

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

xii

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

xiii

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

Figura 33: Avaliao do BDDPM: Plano GQM Objetivo 1 .................................... 71




xiv

Lista de Abreviaes

ABNT Associao Brasileira de Normas Tcnicas ACM Association for Computing Machinery AJAX Asynchronous JavaScript and XML API Application Programming Interface ASF Apache Software Foundation BDD Behavior Driven Development BDDPM Behavior Driven Development Plugin for Mantis BSD Berkeley Software Distribution BT Bug Tracker CAPES Coordenao de Aperfeioamento de Pessoal de Nvel Superior CESAR Centro de Estudos e Sistemas Avanados do Recife CMMI Capability Maturity Model Integration COC Convention over Configuration CSS Cascading Style Sheets DOM Document Object Model DR Doutor DRY Don't Repeat Yourself DSL Domain-Specific Language FSF Free Software Foundation GNOME GNU Network Object Model Environment GPL General Public License GQM Goal-Question-Metric GT Grounded Theory HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers ISO International Organization for Standardization JIT Just In Time JR Jnior JS JavaScript JUG Java User Group MIT Massachusetts Institute of Technology MPROF Mestrado Profissional MVC Model-View-Controller NASA National Aeronautics and Space Administration ORM Object Relational Mapping PBPREV Paraba Previdncia PHP Hypertext Preprocessor PL Pleno PMBOK Project Management Body of Knowledge QA Quality Assurance RBAC Role-Based Access Control RIA Rich Internet Application RPC Remote Procedure Call

xv

RSS Rich Site Summary SCM Source Code Management SEO Search Engine Optimization SGBD Sistema de Gerenciamento de Banco de Dados SLA Service Level Agreement SR Snior SSAC SISPROTO - Solicitaes de Alterao e Correo SVN Subversion TDD Test Driven Development TI Tecnologia da Informao UFCG Universidade Federal de Campina Grande UFPE Universidade Federal de Pernambuco UI User Interface URL Uniform Resource Locator VCS Version Control System VS Visual Studio WWW World Wide Web XHTML eXtensible Hypertext Markup Language XML eXtensible Markup Language

1

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 mal-

entendidos: 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.

2

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.
http://goo.gl/kvmLWZhttps://goo.gl/bd2ccahttp://goo.gl/hTFybhttp://goo.gl/IRnemvhttp://goo.gl/HSzCm

3

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:

3 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.).

4

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, constroem-

se 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:

Figura 1 Questionamentos e fatos que culminam no problema Como ir em Direo a um

Ambiente de Desenvolvimento de Software Orientado por Comportamento?

PROBLEMABDD PRETERIDO EM RELAO AO TDD

QUAIS AS CARACTERSTICAS E

RECURSOS FACILITARIAM A

ADOO DO BDD?

COMO PERMITIR O USO DO BDD POR

USURIOS DE DIFERENTES NVEIS?

COMO PERMITIR O ACOMPANHAMENTO

REAL DO TESTE DE SOFTWARE?

COMO AVALIAR O SUCESSO E IMPACTO DESTES RECURSOS?

...

5

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:

Figura 2 Viso Geral da Proposta: Recursos Adoo BDD Avaliao

6 GQM uma abordagem para o estabelecimento de um sistema de medio (levantamento de mtricas de avaliao), normalmente utilizada na rea de software.

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

6

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 process-la 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.
http://opensource.org/http://tiobe.com/index.php/content/paperinfo/tpci/index.html

7

Posio Linguagem de Programao ndice

1 C 17.588%

2 Java 14.959%

3 Objective-C 9.130%

4 C++ 6.104%

5 C# 4.328%

6 PHP 2.746%

7 Java Script 2.433%

8 Python 2.287%

9 Visual 2.235%

10 Perl 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

8

Este o contexto de criao e avaliao do BDDPM:

1. Equipe de desenvolvimento do BDDPM:

01 Analista de Sistemas: Alvaro Magnum Barbosa Neto

([email protected]), 30 anos, Gestor de TI, 12 anos de

experincia.

01 Supervisor/Coordenador: Dr. Vinicius Cardoso Garcia

([email protected]), 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

([email protected]), 24 anos, Coordenador de TI, 03 anos

de experincia.

02 Estagirios12: Marcos Fernando Carneiro

([email protected]) 26 anos, Estagirio, 06 meses de

experincia; e Joo Paulo Cordeiro ([email protected]) 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 12 Estudantes do curso de Cincia da Computao 13 Desenvolvido utilizando a tcnica do BDD atravs do BDDPM
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]

9

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

10

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.
http://www.agilemanifesto.org/

11

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 VERMELHO-

VERDE-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".

12

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.
http://goo.gl/PFBHXV

13

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.
http://martinfowler.com/articles/is-tdd-deadhttp://facebook.com/

14

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
http://dannorth.net/introducing-bddhttps://github.com/cucumber/cucumber/wiki/Spoken-languages

15

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 RED-

GREEN-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; pode-

se 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 26 http://scholar.google.com 27 http://dl.acm.org 28 http://citeseer.ist.psu.edu 29 http://www.periodicos.capes.gov.br
https://goo.gl/AJodLShttps://goo.gl/E4Kqyiwww.google.comwww.bing.comwww.yahoo.comhttps://www.ieee.org/http://scholar.google.com/http://dl.acm.org/http://citeseer.ist.psu.edu/http://www.periodicos.capes.gov.br/

16

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 Qtde. de Resultados - TDD Qtde. de Resultados - BDD

GOOGLE 703.000 177.000

BING 1.040.000 63.000

YAHOO 1.000.000 62.800

Tabela 2 Comparativo de retorno de resultado nos principais buscadores WEB (TDD x BDD)

Sistema de Busca Qtde. de Resultados - TDD Qtde. de Resultados - BDD

IEEE 407.000 34.300

GOOGLE SCHOLAR 11.300 538

ACM Digital Library 1.448 62

CITESEERX 1.745 47

ACM 309 8

PERIDICOS/CAPES 143 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

17

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.

18

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. 31 http://goo.gl/RG7B18 32 http://goo.gl/DWN6Wc
http://goo.gl/RG7B18http://goo.gl/DWN6Wc

19

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. 34 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
http://goo.gl/BZL5kKhttp://hindsightsoftware.com/solutions/behave-for-jirahttp://goo.gl/wYzcgbhttps://www.atlassian.com/software/jirahttp://www.nasa.gov/http://www.adobe.com/http://www.bmw.com/http://www.cisco.com/http://hindsightsoftware.com/

20

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 (GPL40).

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
http://www.softwarepublico.cl/http://dev-eole.ac-dijon.fr/https://cdcvs.fnal.gov/redminehttp://www.redmine.org/pluginshttp://www.redmine.org/http://trac.edgewall.org/wiki/PluginListhttp://trac.edgewall.org/https://code.djangoproject.com/https://trac.torproject.org/projects/torhttp://bugs.jquery.com/http://trac-hacks.org/wiki/TestManagerForTracPlugin

21

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 47 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
https://www.bugzilla.org/https://wiki.mozilla.org/Bugzilla:Addonshttps://www.mantisbt.org/https://github.com/mantisbt-pluginshttp://trac-hacks.org/wiki/TestCaseManagementPluginhttps://www.mozilla.org/https://www.bugzilla.org/installation-listhttps://bugzilla.mozilla.org/http://bugzilla.kernel.org/http://bugzilla.gnome.org/http://bugs.kde.org/http://issues.apache.org/bugzillahttp://bugs.libreoffice.org/http://www.openoffice.org/issues/query.cgihttp://bugs.eclipse.org/bugshttps://bugzilla.redhat.com/bugzillahttp://qa.mandriva.com/http://bugs.gentoo.org/https://bugzilla.novell.com/

22

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.

23

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 Gherkin62. Basicamente uma linguagem

tcnica de alto nvel, que descreve passos, seguindo um conjunto

em direção a um ambiente de desenvolvimento de software orientado por comportamento

Documents