View
12
Download
2
Category
Preview:
DESCRIPTION
Dissertação apresentada como requisito parcial para a obtenção do título de Mestre em Ciências da Computação, área de concentração em Engenharia de Software pelo Programa de Pós-Graduação em Ciências da Computação do Centro de Informática da Universidade Federal de Pernambuco.Resumo:Criado por Dan North, o BDD (Behavior Driven Development) é uma técnica de desenvolvimento ágil de software baseada no TDD (Test Driven Development). Trata-se de uma metodologia de teste de software baseada em comportamentos, isto é, concentra-se nas razões pelo qual o software é criado, nos requisitos de comportamento do negócio. Incentiva a participação de toda pessoa interessada no projeto de software, e não apenas a equipe técnica. Apesar de vários benefícios propiciados pelo BDD, ele não tem uma aceitação tão grande no mercado quanto o TDD, sendo, muitas vezes, preterido em relação a este.Quais características devem fazer parte de uma ferramenta para que ela facilite e dinamize a utilização 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 construído? Como medir o impacto da ferramenta?Através de análises e resultados obtidos em mais de 12 (doze) anos de experiência profissional no setor de tecnologia de instituições públicas e privadas, além de pesquisas na literatura, depoimentos e estudos de casos de profissionais da área, avaliou-se o cenário do BDD no mercado e, como fruto dessa avaliação, foi criado o BDD Plugin for Mantis (BDDPM): uma ferramenta cujo objetivo é facilitar a adoção do BDD em projetos de desenvolvimento de software, através de recursos que propiciem sua fácil aplicação e possibilitem a escrita e acompanhamento de testes pelos clientes.Entretanto, apenas a criação da ferramenta em si, não seria suficiente para sua avaliação quanto ao cumprimento dos objetivos. Fazia-se necessário entender e conhecer o que deveria ser medido, para, com isso, levantar métricas, fazer medições e mensurar resultados. Nesse sentido, para avaliar o plugin enquanto proposta de solução para os questionamentos levantados, foi utilizada uma técnica denominada GQM (Goal/Question/Metric). O GQM é uma abordagem que se orienta através dos objetivos de um artefato para planejar e mensurar métricas relacionadas a eles e, consequentemente, permitir a avaliação do artefato: BDDPM, neste caso.Este trabalho descreve, em detalhes, todo o ciclo de vida do projeto, ou seja, desde a concepção do BDDPM em seus primeiros estágios, passando pela sua justificativa, criação, tecnologias utilizadas, recursos incluídos, etc., até sua implantação dentro de um ambiente de produção real e posterior avaliação dos resultados obtidos com a técnica do GQM.
Citation preview
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
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 7: Questionrio para Interface. Resultado da Pergunta 2 ............................. 31
Figura 8: Questionrio para Interface. Resultado da Pergunta 3 ............................. 32
Figura 9: Questionrio para Interface. Resultado da Pergunta 4 ............................. 32
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
Figura 34: Avaliao do BDDPM: Plano GQM Objetivo 2 .................................... 72
Figura 35: Avaliao do BDDPM: Plano GQM Objetivo 3 .................................... 72
Figura 36: Avaliao do BDDPM: Plano GQM Objetivo 4 .................................... 73
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/HSzCm3
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.html7
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
(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 12 Estudantes do curso de Cincia da Computao 13 Desenvolvido utilizando a tcnica do BDD atravs do BDDPM
mailto:ambn@cin.ufpe.brmailto:vcg@cin.ufpe.brmailto:mdof@pbprev.pb.gov.brmailto:mmfc@pbprev.pb.gov.brmailto:mjpc@pbprev.pb.gov.br9
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/PFBHXV13
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-languages15
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/DWN6Wc19
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/TestManagerForTracPlugin21
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
Recommended