INSTITUTO DE ENSINO SUPERIOR DA

GRANDE FLORIANPOLIS
Curso de Cincia da Computao
Campus So Jos

William Melchior Jablonski 32020000013

Estudo da aplicao de prticas geis de teste em uma

startup de software

Professor Orientador: Patryck Ramos Martins

SO JOS/SC
2014

SUMRIO
1. LISTA DE SIGLAS ......................................................................................................................... 4
2. LISTA DE FIGURAS...................................................................................................................... 5
3. LISTA DE TABELAS ..................................................................................................................... 7
4. RESUMO ......................................................................................................................................... 8
5. INTRODUO ............................................................................................................................... 9
6. TEMA ............................................................................................................................................. 10
6.1.

DELIMITAO DO TEMA .................................................................................................... 10

6.2.

PROBLEMATIZAO DO TEMA ........................................................................................ 10

7. HIPTESES ................................................................................................................................. 11
8. METODOLOGIA DE PESQUISA .............................................................................................. 12
9. OBJETIVOS .................................................................................................................................. 13
9.1.

OBJETIVO GERAL DA PESQUISA .................................................................................... 13

9.2.

OBJETIVOS ESPECFICOS ................................................................................................ 13

10. FUNDAMENTAO TERICA ................................................................................................. 13

10.1.

ENGENHARIA DE SOFTWARE..................................................................................... 13

10.2.

QUALIDADE DE SOFTWARE ........................................................................................ 14

10.3.

TESTE DE SOFTWARE .................................................................................................. 16

10.3.1.

NVEIS DE TESTE DE SOFTWARE ............................................................................. 19

10.3.2.

TCNICAS DE TESTES DE SOFTWARE.................................................................... 21

10.3.3.

TIPOS/CATEGORIAS DE TESTE DE SOFTWARE ................................................... 22

10.4.

IMPACTOS DA FALTA DE QUALIDADE NO SOFTWARE ....................................... 24

10.5.

DESENVOLVIMENTO DE SOFTWARE: VISO GERAL .......................................... 24

10.5.1.

FASES DO DESENVOLVIMENTO DE SOFTWARE ....................................... 24

10.6.

PROCESSOS TRADICIONAIS DE DESENVOLVIMENTO ....................................... 26

10.7.

PROCESSOS GEIS DE DESENVOLVIMENTO ....................................................... 26

10.7.1.

SCRUM .................................................................................................................... 30

10.7.2.

EXTREME PROGRAMMING (XP) ...................................................................... 32

10.7.2.1.

VALORES BASE DO EXTREME PROGRAMMING ......................................... 33

10.7.2.2.

ATIVIDADES BSICAS DO EXTREME PROGRAMMING ............................. 33

10.7.2.3.

CINCO REGRAS DO EXTREME PROGRAMMING ........................................ 35

10.8.

TCNICAS GEIS DE TESTE ....................................................................................... 37

10.8.1.

TEST DRIVEN DEVELOPMENT (TDD) ............................................................. 37

10.8.1.1.

CONCEITO DO TDD ............................................................................................. 37

10.8.1.2.

MOCK OBJECT ...................................................................................................... 41

10.8.1.3.

VANTAGENS DO TDD .......................................................................................... 41

10.8.1.4.

DESVANTAGENS DO TDD .................................................................................. 43

10.8.1.5.

FERRAMENTA DE TDD ....................................................................................... 44

2

10.8.2.

ACCEPTANCE TEST DRIVEN DEVELOPMENT (ATDD) .............................. 44

10.8.2.1.

CONCEITO DO ATDD ........................................................................................... 45

10.8.2.2.

FERRAMENTA DE ATDD ..................................................................................... 45

10.8.3.

BEHAVIOR DRIVEN DEVELOPMENT (BDD) ................................................... 46

10.8.3.1.

HISTRIAS DE USURIO PARA O DESENVOLVIMENTO COM O BDD .. 46

10.8.3.2.

CONCEITO DO BDD ............................................................................................. 48

10.8.3.3.

MOTIVAO DO BDD .......................................................................................... 49

10.8.3.4.

FERRAMENTA PARA BDD .................................................................................. 50

STARTUP ........................................................................................................................... 51

10.9.

APLICAO DO TRABALHO .............................................................................................. 54

11.

11.1.

EXEMPLO DE TDD.................................................................................................... 54

11.2.

EXEMPLO DE ATDD ................................................................................................. 60

11.3.

EXEMPLO DE BDD ................................................................................................... 64

11.4.
APLICAO DE PRTICAS GEIS DE TESTE DESENVOLVIMENTO DE
SOFTWARE EM STARTUP ..................................................................................................... 68
12.

ESTUDO DE CASO ............................................................................................................... 70

12.1.

PROBLEMATIZAO ...................................................................................................... 70

12.2.

ABORDAGEM TCNICA ................................................................................................. 70

12.3.

DEFINIO DOS PARAMETROS QUALITATIVOS DOS DADOS .......................... 76

12.4.

OBTENO E ANALISE DOS DADOS/INFORMAO ............................................ 80

12.5.

RESULTADO DO ESTUDO DE CASO ......................................................................... 88

13.

CONSIDERAES FINAIS .................................................................................................. 90

14.

TRABALHOS FUTUROS ...................................................................................................... 91

15.

BIBLIOGRAFIA ....................................................................................................................... 92

1.

LISTA DE SIGLAS

ATDD - Acceptance Test Driven Development

BDD - Behavior Driven Development
ROI - Return of Investment
TDD - Test Driven Development
XP - Extreme Programming
CMMI - Capability Maturity Model Integration
RUP - Rational Unified Process
PO - Product Owner
EUA Estados unidos da Amrica

2.

LISTA DE FIGURAS

Figura 1: Regra 10 de Myers: Custo de correo de defeitos ao decorrer do processo de

desenvolvimento do software. ............................................................................................................. 18
Figura 2: Relao entre nveis, tcnicas e tipos de teste. ..................................................................... 19
Figura 3: Escala dos benefcios com times geis. .................................................................................. 28
Figura 4: Ciclo de vida do Scrum ........................................................................................................... 31
Figura 5: Prticas XP .............................................................................................................................. 34
Figura 6: Relacionamento das prticas do XP. ...................................................................................... 36
Figura 7: Processo de TDD..................................................................................................................... 40
Figura 8: Exemplo de especificao no JBehave. .................................................................................. 47
Figura 9: Cdigo de exemplo JBehave................................................................................................... 47
Figura 10: Processo de BDD .................................................................................................................. 49
Figura 11: Histria exemplificando um relatrio de vendas ................................................................. 50
Figura 12: Classe EstacionamentoTest .................................................................................................. 55
Figura 13: Criao dos mtodos ............................................................................................................ 55
Figura 14: Teste falhando ...................................................................................................................... 56
Figura 15: Criao da classe Estacionamento ....................................................................................... 57
Figura 16: Refatorao da classe Estacionamento................................................................................ 57
Figura 17: Classe EstacionamentoTest com as Trs regras implementadas. ........................................ 58
Figura 18: Classe Estacionamento com os mtodos implementados. .................................................. 59
Figura 19: JUnit informando que os testes passaram ........................................................................... 59
Figura 20: Criao do projeto ProjetoATDD. ......................................................................................... 60
Figura 21: Criao da classe CalculadoraSimples. ................................................................................. 61
Figura 22: Implementando a classe CalculadoraSimples ...................................................................... 61
Figura 23: Inicializando o framework Fitnesse. ..................................................................................... 62
Figura 24: Servio do Fitnesse ativo. ..................................................................................................... 62
Figura 25: Criando critrio de aceitao. .............................................................................................. 63
Figura 26: Critrio de aceite salvo e visualizao da tabela. ................................................................. 64
Figura 27: Execuo dos testes e feedback do framework. .................................................................. 64
Figura 28: Criao da funcionalidade. ................................................................................................... 65
Figura 29: Escrevendo o cenrio ........................................................................................................... 66
Figura 30: Criao da classe ExecutaTestes.java ................................................................................... 66
Figura 31: Classe falha e a informao e exibida no console ................................................................ 67
Figura 32: Criao da classe steps. ........................................................................................................ 68
Figura 33: Classe executada com sucesso. ............................................................................................ 68
Figura 34: Processo de planejamento da Sprint arquitetado pela equipe............................................ 71
Figura 35: Kambam do antigo processo de desenvolvimento Flexy. .................................................... 73
Figura 36: Antigo processo de desenvolvimento. ................................................................................. 74
Figura 37: Novo processo de desenvolvimento. ................................................................................... 75
Figura 38: Resultado da pesquisa de satisfao aplicada em alguns clientes antes da implantao das
tcnicas geis de teste. ......................................................................................................................... 81
Figura 39: Aumento de 30% do tempo de analise do Product Ower.................................................... 82
Figura 40: Reduo de 30% do tempo de analise do programador para codificao. ......................... 82
Figura 41: Aumento de 20% do tempo codificao da tarefa pelo programador. ............................... 83
Figura 42: Reduo de 50% do tempo execuo de testes da tarefa pelo testador. ........................... 83
Figura 43: Reduo de 50% do tempo execuo de testes da tarefa pelo testador. ........................... 84
Figura 44: Aumento de 40% no numero mdio de defeitos reportados durante o teste de regresso
por Sprint............................................................................................................................................... 84
Figura 45: Ganho de 50% na produtividade mdia por Sprint. ............................................................. 85
5

Figura 46: Aumento de 70% na documentao do sistema. ................................................................ 85

Figura 47: Reduo de 60% no tempo de resoluo das tarefas de suporte........................................ 86
Figura 48: Reduo de 50% no numero de tarefas de suporte ao ms. ............................................... 86
Figura 49: Ganho de 200% em produtividade atravs da adoo das tcnicas geis de teste no
perodo de um ms. .............................................................................................................................. 87
Figura 50: Ganho acumulado em economia financeira atravs da adoo das tcnicas geis de teste
no perodo de um ms. ......................................................................................................................... 87
Figura 51: Ganho acumulado em economia financeira atravs da adoo das tcnicas geis de teste
no perodo de um ano ........................................................................................................................... 88
Figura 52: Resultado da pesquisa de satisfao aplicada em alguns clientes aps da implantao das
tcnicas de testes geis. ........................................................................................................................ 88

3.

LISTA DE TABELAS

Tabela 1: Treze prticas do XP. ............................................................................................................. 35

Tabela 2: Estrutura da histria em BDD. ............................................................................................... 46
Tabela 3: Ferramentas que sero agregadas ao processo para complementarem a adoo das
tcnicas geis de teste. ......................................................................................................................... 77
Tabela 4: Custo de mo de obra Flexy. ................................................................................................. 77
Tabela 5: Estimativa de tempo e custo direto da adequao ao processo da Flexy. ........................... 78
Tabela 6: Custo de manuteno mensal da arquitetura. ...................................................................... 78
Tabela 7: Cronograma de implantao e avaliao das tcnicas geis de teste. ................................. 79
Tabela 8: Cronograma treinamento de Tcnicas geis de teste. .......................................................... 81

4.

RESUMO

A presente pesquisa visa apresentar o estudo de caso da aplicao de

prticas geis de teste de software como soluo para a reduo de custos do
processo de desenvolvimento de software em empresas startup.
Apresenta-se com base nos autores Kent Beck, um entusiasta das
metodologias e prticas geis de engenharia de software e Glendford J. Myers
referncia no estudo das prticas e benefcios do teste de software.
Atravs desta pesquisa observou-se que a adoo de prticas geis de teste
de software vem de encontro a uma cultura preventiva, evitando que os defeitos
inseridos no software sejam disponibilizados para o cliente. A adoo auxilia
tambm em um ganho de produtividade e qualidade no software assim
consequentemente gerando uma melhora na imagem da empresa com os clientes e
mercado, um aumento do ndice de documentao do sistema e uma cobertura
constante de testes no sistema. Estas prticas necessitam de um ferramental
especfico, mudana no processo de desenvolvimento e mudana cultural da equipe.
Os resultados obtidos comprovam que a aplicao de tcnicas geis de teste, dentro
do processo de desenvolvimento de software, efetivamente vem a trazer aumento da
qualidade do produto final, reduo de custos, um melhor entendimento do que o
cliente espera receber no final do projeto e aumento da produtividade da equipe.

Palavras chave: Teste gil, Startup, TDD, ATDD, BDD.

5.

INTRODUO

Com a popularizao da internet e a evoluo tecnolgica, construir software

robustos e com qualidade deixou de ser um diferencial e se tornou uma necessidade
para que as empresas de software possam se manter no mercado.
O teste de software uma etapa do processo de garantia de software com
foco na garantia de qualidade do produto que visa avaliar se o software atende os
padres de qualidade especificados. Qualidade de software, segundo autores a
conformidade de requisitos funcionais e de desempenho que foram explicitamente
declarados, a padres de desenvolvimento claramente documentados, e a
caractersticas implcitas que so esperadas de todo software desenvolvido por
profissionais.
Os processos de desenvolvimento de software vm se aperfeioando para
auxiliar na produo de software que alinhem qualidade e custo sustentvel, com
este fim, o mercado vem apresentando ferramentas e prticas no ciclo de vida gil,
dois processos se destacam o Scrum1 e o XP.
No caso do XP, se tem um processo focado no desenvolvimento efetivo do
software e no tanto na gesto do processo de desenvolvimento do software como
o caso do Scrum. Um dos principais diferenciais do XP est nos seus princpios e
prticas. Uma das principais prticas que o XP incentiva a adoo do TDD.
Tratando-se do TDD, se prope a busca de uma codificao simples,
efetivamente focado na soluo, funcional e de arquitetura objetiva. O TDD
apresenta a tcnica de programar os testes como primeiro passo do processo de
desenvolvimento, e posteriormente o cdigo para faz-los atender os testes.
Na tcnica XP tambm se incentiva a prtica do desenvolvimento de testes
de aceite antes do desenvolvimento, o ATDD, que se prope a ser utilizado como
medida de progresso e indicador dos nveis de qualidade do software, ele citado
tambm como uma documentao funcional do sistema dando mais segurana aos
envolvidos durante o processo de reescrita, correo e evoluo do sistema.
Stakeholders2 usam scripts de testes para descrever as necessidades do cliente e
os objetivos na forma de testes automatizados e casos de uso.
Com a utilizao do ATDD surgiu necessidade de ampliar a viso dos
requisitos de uma forma padronizada e automatizada, surgindo o BDD. O BDD se
prope a destacar a linguagem natural e da interao entre todos os envolvidos no
processo de desenvolvimento de software. Stakeholders usam sua lngua nativa
para descrever as suas necessidades e objetivos na forma de exemplos.
Subsequentemente, estes exemplos proporcionam uma base de requisitos que
devem ser contemplados pelo desenvolvimento.
Este conjunto de prticas de testes geis aplicados individualmente em
empresas de desenvolvimento de software, como por exemplo, startup de software,
segundo autores, tendem a reduzir custos de retrabalho, prevenir a disponibilizao
de software em produo com erros crticos de negcio e consequentemente
aumentar o potencial de sucesso destas empresas, assim chegando ao retorno do
investimento de custo de implantao e manuteno.
H diversas definies para o termo startup, mas a que melhor se encaixa
neste contexto devido nfase do alto risco do negcio que seu sucesso influencia
1
2

Scrum segundo Beck (1999) uma mtodogia de desenvolvimento gil.

Stakeholders segundo Myers (2004) como so chamados os interessados no processo de software.

diretamente na sobrevivncia da empresa no mercado e a utilizao de recursos

financeiros finitos que startups so pequenas empresas montadas em casa ou em
faculdades e que recebem pequenos aportes de capital. Elas exploram reas
inovadoras de determinado setor (mais comumente a de tecnologia), possuindo uma
acelerao de crescimento muito alta j nos primeiros meses de existncia em
virtude de investimentos feitos por fundos de investimento especializados.
Neste sentido este trabalho visa apresentar conceitos e exemplos do campo
da engenharia de software, desenvolvimento orientado a testes, desenvolvimento
orientado a testes de aceite e desenvolvimento orientado a comportamento, tal como
aplicar as praticas geis de teste e avaliar seus resultados em um cenrio real
atravs de um estudo de caso na startup de software Flexy negcios digitais. Aps
apresentado o mtodo, ser apresentado os resultados obtidos e as consideraes
finais.

6.

TEMA

Estudo da aplicao de prticas geis de teste no desenvolvimento de

software em empresas startup como tcnica de garantia de qualidade na startup de
software Flexy negcios digitais.

6.1. DELIMITAO DO TEMA

Aplicam-se a este trabalho conceitos de testes unitrios, desenvolvimento
guiado a testes (TDD), desenvolvimento guiado a testes de aceite (ATDD) e
desenvolvimento guiado a comportamento (BDD), XP e Java3.
Este trabalho de pesquisa trata do estudo de aplicaes de tcnicas de
desenvolvimento orientado a testes em empresas startup de desenvolvimento de
software, que limita-se ao estudo de caso da startup Flexy negcios digitais, uma
startup de desenvolvimento de software com menos de um ano de mercado e
recursos financeiros limitados.
O perodo de estudo de caso da aplicao desta pesquisa ocorrera entre os
meses janeiro a dezembro de 2013.

6.2. PROBLEMATIZAO DO TEMA

Com um aumento da competitividade no mercado de tecnologia da
informao, produzir software de qualidade tornou-se uma necessidade para que as
empresas se mantenham no mercado, conquistem reconhecimento e sucesso em
suas solues desenvolvidas para seus respectivos clientes.
Defeitos em software custaram aos EUA 60 bilhes de dlares. O estudo foi
realizado em empresas de tamanho e domnio variados. Uma das mais importantes
concluses do estudo foi que este elevado custo ocorre no apenas pela enorme
quantidade de defeitos, mas tambm pelo elevado tempo que um defeito leva para
ser identificado e corrigido (TASSEY, 2002).
Estima-se que 80% do tempo de um desenvolvedor dedicado
identificao e correo de defeitos. Mais de 50% dos defeitos4 no so detectados
at a fase de homologao, aproximadamente 50% dos defeitos so introduzidos na
fase implementao e cerca de 50% do oramento total de um projeto de software

Java segundo Deitel (2005) uma linguagem de programao orientada a objetos desenvolvida na dcada de
90.
4
Defeitos segundo Myers (2004) um erro no funcionamento comum de um software ou hardware.

10

gasto na aplicao da correo de defeitos inseridos no software (TASSEY, 2002).

Ajudar na reduo de defeitos importante, pois o custo de correo de
falhas alto, crescendo exponencialmente com o decorrer do tempo. Citando um
exemplo de Viega e McManus (2000) na fase de especificao custa em mdia
US$139,00 para ser corrigida, enquanto que na fase de desenvolvimento, custa
US$7.000,00 e para descobrir e corrigir uma falha depois da implantao do
software custa US$14.000,00.
Segundo a IEEE (2012) caso um desenvolvedor introduza uma falha no
cdigo fonte, e esta no sendo corrigida, se torna um defeito na aplicao, podendo
causar um erro em tempo de execuo, como exemplificado posteriormente.
Utilizando o exemplo de uma loja virtual, caso o boto de finalizar compra
esteja com defeitos em uma de suas aes, considerando que as aes deste boto
sejam: 1 Efetuar a cobrana do pedido; 2 Salva o pedido para que o lojista possa
enviar o produto e 3 enviar o e-mail para o cliente avisando que a compra foi
efetuada com sucesso. No cenrio que a ao 2 (salva o pedido para que o lojista
possa enviar o produto) esteja com defeito, o pedido cobrado do cliente, mas no
disponibilizado para que o lojista possa enviar o produto, ou seja, todos os clientes
dessa loja vo pagar pelo produto, mas no iram receb-lo, isso mostra quanto
transtorno uma falha no sistema pode causar aos usurios e empreendedores.
Outro exemplo histrico foi o ocorrido na metade do ano de 1962, ocorreu a
primeira tentativa dos seres humanos de explorar outros planetas. O foguete Marier I
foi lanado em uma misso para Vnus. O controle terrestre ordenou o abatimento
do foguete aps o mesmo desviar da sua rota. Investigaes revelaram que a falta
de um simples hfen no programa de computador no foi percebida, causando assim
falhas no software. O prejuzo dessa falha ultrapassou 18 milhes de dlares.
(TONSIG, 2008). De acordo com o relatrio The Economic Impact Inadequate Infrastructure
for Software Testing estima-se que os custos com defeitos em softwares custem s
empresas americanas um valor prximo de 1% do PIB dos Estados Unidos
(TASSEY, 2002).
Em decorrncia do histrico da ocorrncia de tantos problemas notrio que
uma pesquisa do IBGE, em seus dados de 2010, exiba que 30% das empresas
fecham nos dois primeiros anos de vida (IBGE, 2010).
Para empresas startup de software a qualidade um item primordial j que
um erro em produo tem alto custo de correo e pode comprometer a imagem da
empresa levando at a falncia. A aplicao de testes geis em startup vem de
encontro a reduo custos de manuteno e garantia de qualidade por meio da
preveno de erros e execuo contnua de validaes durante o processo de
software e um melhor alinhamento entre os requisitos dos stakeholders e a
codificao.

7.

HIPTESES

A implantao das prticas de teste gil gera um aumento da qualidade dos

produtos e servios da empresa avaliada.
A utilizao das prticas de teste gil gera reduo de custos no processo de
manuteno do software na empresa avaliada.
Com a aplicao das prticas de teste gil possvel mapear de forma
automatizada o atendimento dos requisitos acordados entre os stakeholders.

11

8.

METODOLOGIA DE PESQUISA

A metodologia presente neste trabalho apresenta o tipo de pesquisa que ser

adotado, as etapas metodolgicas da pesquisa, um esboo da soluo e as
delimitaes da pesquisa.
Esta pesquisa, de acordo com Thomas (2007) classificada como uma
pesquisa bibliogrfica devido a abranger a leitura, anlise e interpretao de livros,
peridicos, documentos mimeografados ou fotocopiados, mapas, imagens,
manuscritos, entre outros. Pode ser classificada tambm como pesquisa
exploratria, pois tem por premissa buscar a resoluo de problemas melhorando
as prticas por meio da observao, anlise e descries objetivas, atravs de
entrevistas com peritos para a padronizao de tcnicas e validao de contedo. A
pesquisa descritiva tem por finalidade observar, registrar e analisar os fenmenos
sem, entretanto, entrar no mrito de seu contedo.
Conforme dito por Gil (2002), buscando obter uma maior familiaridade, com o
ambiente ou fenmeno de estudo, a fim de formular os problemas e hipteses
necessrias para anlise, optou-se pelo tipo de pesquisa qualitativa, cuja natureza
dos dados definida por Romero e Nascimento (2008) como a mais adequada para
dados subjetivos, onde a partir de seus resultados se aprofunda na anlise
interpretativa.
Conforme o ponto de vista de sua natureza, este trabalho tende a ser avaliado
como uma pesquisa aplicada, pois existe o interesse na aplicao, execuo e
resultados prticos dos conhecimentos absorvidos e documentados durante a
evoluo do trabalho (GIL, 2008).
O estudo de caso, conforme definido por Gil (2002), o estudo profundo e
exaustivo de um ou poucos objetos, de maneira a permitir conhecimento amplo e
detalhado do mesmo. Para isso, foi necessrio coletar mtricas do processo de
software antes e durante a aplicao das tcnicas .
Os procedimentos metodolgicos para a execuo da pesquisa so:
pesquisa bibliogrfica em livros, teses e artigos relacionados a engenharia de
software.
pesquisa sobre processos de desenvolvimento, metodologias e tcnicas de
teste gil.
pesquisa sobre test driven development (TDD), ou desenvolvimento dirigido
por teste.
pesquisa sobre acceptance
desenvolvimento dirigido por aceite.

test

driven

development

(ATDD),

ou

pesquisa sobre behavior driven development (BDD) ou desenvolvimento

dirigido por comportamento.
estudo de caso da aplicao das tcnicas geis de teste na empresa startup
Flexy negcios digitais, coleta de mtricas (detalhamento na seo 12.3) e seus
resultados.
Portanto, a partir dos resultados, foi possvel comparar os resultados com os da
metodologia utilizada anteriormente pela empresa e obter uma anlise qualitativa
dos resultados.

12

9.

OBJETIVOS

Este item visa apresentar os objetivos gerais e especficos deste trabalho.

9.1.

OBJETIVO GERAL DA PESQUISA

Validar os benefcios da adoo das tcnicas de testes geis como

Desenvolvimento orientado a teste (TDD), desenvolvimento orientado a teste de
aceite (ATDD) e desenvolvimento orientado ao contexto (BDD) atravs do estudo de
caso na empresa startup Flexy negcios digitais.

9.2.

OBJETIVOS ESPECFICOS

Apresentar os conceito das tcnicas geis de teste TDD, ATDD, BDD.

Aplicar no processo de software da startup Flexy negcios digitais as tcnicas
geis apresentadas no decorrer do trabalho de pesquisa.
Avaliar se a implantao das prticas de teste gil gera um aumento da
qualidade dos produtos e servios da empresa.
Atestar se a utilizao das prticas de teste gil gera reduo de custos no
processo de software e caso aplicado resulta uma maior produtividade.

10.

FUNDAMENTAO TERICA

Neste captulo so abordados assuntos que auxiliam o melhor entendimento

deste trabalho.

10.1. ENGENHARIA DE SOFTWARE

Segundo Deek (2005) o termo engenharia de software surgiu ao final da
dcada de 60, em meio a uma crise no desenvolvimento de software. Nesta poca,
o interesse por mtodos padronizados a serem usados no local de trabalho com o
intuito de criar aplicaes de qualidade, j havia se tornado um interesse importante
para muitas organizaes. Abordagens foram definidas para identificar como a
produo de software de qualidade podia ser alcanada nas organizaes, visto que
a maioria das aplicaes foram produzidas naquele tempo sob as regras de
desenvolvimento da empresa onde nenhuma padronizao verdadeira nem
qualidade eficiente eram realmente atingveis para aplicaes de software. De fato, a
mistura de novas abordagens e recomendaes, possivelmente s adicionaram
maiores complicaes e contriburam ainda mais para crise na indstria de
software.
Conforme Deek (2005) ainda nos anos 60, ocorreram duas importantes
conferncias onde se originou o termo engenharia de software, realizadas em
reconhecimento a esta crise que estava ocorrendo. Foi uma reao a fracassos de
projeto, perdas econmicas, atrasos na entrega, mercados competitivos e uma
exigncia crescente para funcionalidade, qualidade, e confiabilidade com menor
custo possvel.
De acordo com Ieee (1990), o termo engenharia foi usado justamente para
associar o "conceito" engenharia ao desenvolvimento de software, em outras
palavras ter uma abordagem sistemtica, disciplinada e quantificada ao
desenvolvimento, operao e manuteno de software.
Segundo Asee (2000), a engenharia aplicao de princpios matemticos e
cientficos, experincia, julgamento e bom senso para trazer coisas que beneficiam
as pessoas. A engenharia de software segue este mesmo raciocnio, tendo como
13

objetivo definir e exercitar processos, mtodos, ferramentas e ambientes para

construo de software que satisfaa necessidades de cliente e usurio dentro de
prazos e custos previsveis.
A engenharia de software apresenta estratgias de desenvolvimento de
software denominadas de modelos de ciclo de vida de desenvolvimento de software
ou modelos de processo. Estes modelos, tal como o nome informa, auxiliam o
desenvolvimento do incio ao final do projeto.
Conforme Asee (2000), a engenharia de software compreende um conjunto
de etapas que envolvem mtodos, ferramentas e procedimentos. Essas etapas
muitas vezes so citadas como paradigmas da engenharia de software. Um
paradigma de engenharia de software escolhido tendo-se como base a natureza
do projeto e da aplicao, os mtodos e ferramentas a serem usados, os controles e
os produtos que precisam ser entregues. Neste contexto, dois paradigmas tm sido
discutidos e debatidos com maior nfase: ciclo de vida clssico ou cascata e o ciclo
de vida gil.

10.2. QUALIDADE DE SOFTWARE

Conforme Juran (1992), qualidade de software uma das reas de
conhecimento da engenharia de software que tem como objetivo garantir a
qualidade do software atravs de definio de processos dentro do ciclo de
desenvolvimento. Embora os modelos aplicados na garantia da qualidade de
software atuam com foco no processo, o objetivo mais importante garantir um
produto final que atenda s expectativas do cliente.
Segundo Pressman (2006) qualidade a conformidade com os requisitos
funcionais e de desempenho previamente declarados, as normas de
desenvolvimento documentadas e as caractersticas implcitas que so esperadas
de todo software que desenvolvido profissionalmente. A partir desta definio
possvel enfatizar trs importantes pontos:
partindo dos requisitos de software pode-se avaliar a qualidade do mesmo,
uma vez que a falta de conformidade com os requisitos falta de qualidade;
a definio de normas auxilia no modo como o software submetido
engenharia, uma vez que as normas so um conjunto de critrios de
desenvolvimento. Se esses critrios no so seguidos, existe uma grande
possibilidade de no se obter qualidade;

os requisitos implcitos, na maior parte dos casos, no so mencionados,

como, por exemplo, o bom desempenho ou a fcil manuteno do sistema,
porm so requisitos esperados. Assim, se o software satisfaz os requisitos
explcitos, mas no satisfaz os implcitos, a qualidade do software pode ser
considerada suspeita.

Uma vez que so satisfeitos tanto os requisitos explcitos (requisitos

funcionais do software) quanto os implcitos (requisitos no mencionados, mas
essenciais para o software) as chances de se obter um software de qualidade so
maiores.
Para Swebok (2004), essa rea o conjunto de atividades relacionadas com
garantia de qualidade de software, entre elas as atividades de verificao e
validao, onde as particularidades de um modelo de qualidade de software variam
para outro modelo, devido a que cada um tem um nmero diferente de nveis
hierrquicos e um nmero total de diferentes caractersticas.
14

A medio, utilizada como apoio para avaliar a qualidade de um software ou

produto, pode ser realizada a partir de mtricas de qualidade.
Mtricas de qualidade indicam o quanto um software se adapta s exigncias
implcitas e explcitas do cliente. Tais mtricas podem ser:

custo da execuo de uma tarefa;

esforo aplicado na realizao de uma tarefa;
grau de satisfao obtido do cliente;
nmero de pessoas necessrio para implementar um caso de uso;
nmero de defeitos reportados por etapa de desenvolvimento;
tamanho do sistema;
intervalo de tempo necessrio para a execuo de devida tarefa.

Para Pressman (2006), com base em um conjunto de regras claramente

definidas, mesmo que as mtricas de produto para software no sejam sempre
absolutas, elas tornam possvel avaliar de modo sistemtico a qualidade.
Segundo Juran (1992) um software implementado a tempo e de acordo com o
oramento, que no apenas satisfaz as exigncias, pode ser dito como um software
de qualidade. Um software isento de erros no , necessariamente, um software de
qualidade. Mesmo apresentando um programa sem erros, ele pode no satisfazer as
necessidades do usurio.
Para Pressman (2006), as necessidades do cliente so expressas nos
requisitos explcitos descritos ao analista, e tambm nos implcitos. Dentre os
implcitos podem ser citados: ser flexvel, fcil de operar, barato, construdo no
prazo, alm de ter que ser mais prtico, mais rpido, porttil, realizar integrao com
outros softwares, ter fcil manuseio, ser mais seguro e mais barato em relao ao
processo anterior, fosse ele manual ou j informatizado.
A ausncia de funes necessrias para o usurio no pode ser
compensada por funes auxiliares genricas no solicitadas, como uma
calculadora, um bloco de notas, um layout diferenciado ou qualquer outro aplicativo
do gnero.
Pfleeger (2004) afirma que o surgimento da ISO 9126, modelo utilizado como
padro mundial para medir a qualidade de software resultado da busca para
consolidar todas as inmeras vises de qualidade em um modelo s, firmada no
incio da dcada de 1990 pela comunidade da engenharia de software.
So caractersticas de qualidade, segundo a ISO 9126 de 2003:
funcionalidade: a capacidade do software de prover funes que cumpram
s necessidades implcitas e explcitas quando o software estiver sendo
utilizado sob condies especificadas;
confiabilidade: a capacidade do produto de software de manter um nvel
de desempenho especificado, quando usado em condies especificadas;

15

 usabilidade: a capacidade do produto de software de ser compreendido,

aprendido, usado e de ser atraente ao usurio, quando usado sob
especificadas condies;
eficincia: a capacidade do produto de software de apresentar
desempenho apropriado, relativo quantidade de recursos usados, sob
condies especificadas;
manutenibilidade: a capacidade do produto de software de ser alterado.
As alteraes podem ser correes, melhorias ou adaptaes do software
ocasionado por mudanas no ambiente e nos seus requisitos ou
especificaes funcionais;
portabilidade: Capacidade do produto de software de ser transferido de um
ambiente para outro.
Para ser considerado um produto de qualidade, deve atender todas as
especificaes acima. O teste de software tem entre outras funes o papel de
garantir a funcionalidade do sistema.

10.3. TESTE DE SOFTWARE

De acordo com Magela (2006), so definies de alguns termos importantes
sobre o assunto:
erro: Resultado indevido retornado na execuo do software ocasionado por
uma ou mais falhas. Viso de verificao.
falha: Quebra da especificao
componente.

existente

no

cdigo-fonte de um

defeito: Composto de falhas que gera um resultado incoerente do software.

Viso de validao.
necessrio grande investimento logo no inicio do desenvolvimento do
software para conseguir qualidade no produto.
Segundo Molinari (2003), o custo total efetivo do gerenciamento de
qualidade a soma dos quatro fatores: preveno, inspeo, falha interna e falha
externa..
A preveno a ao que visa identificar as falhas antes que eles apaream;
A inspeo, porm foca a medio, avaliao e auditoria dos produtos conforme os
padres e especificaes. O custo de falhas internas identificado a partir dos
testes. O custo de falhas externa so falhas identificadas pelos clientes, que
necessitam de correo.
De acordo com Mller et al. (2007), os testes devem fornecer dados que
possam auxiliar a tomada de deciso dentro do projeto, para as fases seguintes do
desenvolvimento de um software ou at mesmo da sua implantao. Porm, o
sucesso de um processo de testes baseia-se em encontrar um defeito e corrigi-lo o
mais cedo possvel, assim, os custos de correo sero menores.
O teste de software deve ser uma etapa bem planejada e cuidadosa, para
Vasconcelos et al. (2006), parte dos esforos no desenvolvimento do software no
sentido de garantir a qualidade do software.
16

Com a inteno de trabalhar conforme o que foi definido e respeitar aos

requisitos dos stakeholders, as atividades de validao e verificao compem um
processo que inicia com as revises de requisitos, posteriormente tem-se as
revises da anlise e do projeto do software e as inspees do cdigo e por fim os
testes em si (SOMMERVILLE, 2003).
Segundo Koscianski et al. (2007) a verificao consiste em encontrar
possveis problemas de um componente pronto e defeitos, enquanto a validao
busca avaliar a conformidade com os requisitos predefinidos na construo do
componente.
Para Magela (2006) o erro atrelado a viso formal da especificao e tem a
oportunidade de ser invisvel ao usurio final. Poder ter um erro no software, mas
no um defeito. Isso no quer dizer que o software no possua um erro. Tem-se
assim uma averso matemtica, ou melhor, caso ter um defeito, logo se tem um
erro, porem o inverso no.
De acordo com Myers (2004), o objetivo de revelar a presena de erros ou
defeitos aps executar o programa com dados de entrada pr-definidos e verificar os
resultados obtidos comparando-os com os resultados esperados teste.
Para Herbert (1999), teste de software um composto de operaes de
validao e verificao com o intuito de localizar defeitos no processo e no produto
de software.
Conforme Villas Boas (2007), a disciplina de teste adquiriu carter formal
apenas aps a execuo da primeira conferncia formal em teste de software (na
universidade da Carolina do norte, 1972).
De acordo com Swebok (2004), o teste de software representa a ltima
reviso do projeto, especificao e codificao, uma etapa crtica da garantia de
qualidade de software e segundo o autor, o processo de teste tem que ser
executado durante todo o ciclo de vida do projeto do software.
Em torno de 55% de todas as atividades realizadas pelo setor de
desenvolvimento de software de uma companhia tem o intuito de corrigir os erros
reportados no sistemas j em execuo, o que explica o instituto de engenharia de
software (SEI), rgo criado pelo departamento de defesa americano.
Segundo Back (2000), defeitos reportados na etapa de desenvolvimento
custam R$ 10,00 cada para serem consertados e defeitos identificados pelos
clientes custam US $ 1.000 cada para corrigir. Logo quanto mais cedo do processo
de desenvolvimento do software uma falha for reportada, menor vai ser o custo para
sua correo.
A rigor, o teste de software que est atrelado a vidas (de controladores de voo
por exemplo) tende a custar de trs a cinco vezes a mais que todos os diferentes
passos da engenharia de software reunidos. Pressman (2006) complementa
expondo que no difcil uma companhia de desenvolvimento de software consumir
entre 30 e 40% do custo total do projeto em testes.
Myers (2004) refere que o custo de reparao de defeitos pode subir 10
vezes a cada etapa da elaborao do sistema, conforme a Figura 1.

17

Figura 1: Regra 10 de Myers: Custo de correo de defeitos ao

decorrer do processo de desenvolvimento do software.
Fonte: (Myers, 2004)
O teste, dentro de sua funo, pode ser classificado em nveis, objetivos e
tcnicas de teste, segundo Swebok (2004). O teste de software, em seu processo
mais comum, realizado em trs nveis diferentes durante o processo de
manuteno e desenvolvimento de software: nvel unitrio, nvel de integrao e
nvel de sistema. Quando o teste tem o objetivo de verificar se o desenvolvimento
atende as especificaes funcionais, esses so os testes funcionais. A verificao
de requisitos no funcionais como confiabilidade, desempenho, usabilidade, entre
outras conhecido como testes no funcionais. E por fim, tcnicas de teste que
foram elaboradas com o intuito de localizar o maior nmero de falhas possveis. As
tcnicas de teste so classificadas em caixa-branca, caixa-preta e caixa-cinza,
caixa-cinza denominada uma combinao entre as outras duas tcnicas. As
tcnicas de teste descritas anteriormente sero detalhadas posteriormente.
Dentre as etapas, uma delas a definio da estratgia do teste. Na definio
do plano de teste, segundo Crespo (2004), a tcnica compreende a definio dos
seguintes itens:
qual o nvel de teste a ser aplicado, ou seja, definir qual fase do
desenvolvimento do software o teste ser executado.
que tcnica de teste ser utilizada;
de que critrio de teste ser aplicado;
qual tipo de teste vai ser exercitado no software.
A Figura 2 demonstra graficamente a conexo presente entre as tcnicas de
teste, os nveis de teste, os critrios de teste e os tipos de teste que tem a
oportunidade de serem utilizados ao se escolher uma estratgia de teste conforme
os padres de qualidade pr-definidos ao produto. (CRESPO 2004).

18

Figura 2: Relao entre nveis, tcnicas e tipos de teste.

Fonte: (CRESPO, 2004)

A Figura 2 representa as trs perguntas chaves no processo do teste de

software em seus relativos tipos, tcnicas e nveis de testes em que tem a
oportunidade de serem utilizados.

10.3.1. NVEIS DE TESTE DE SOFTWARE

De acordo com Villas Boas (2007), o esforo do teste no meio de um plano de
sistema pode ser categorizado em quatro nveis de trabalho, decorrido do alvo que
est sendo testado:
Segundo Villas Boas (2007), o teste unitrio, ou teste de unidade, o primrio
e mais bsico teste em que um sistema resultado de projeto pode passar. Tem-se
que memorizar que unidade, neste contexto, compreendido como o elemento
indivisvel de cdigo que est na incumbncia de um nico programador e
fragmentado em duas etapas. A primeira foca-se em depurar no seu contexto lxicosinttico a unidade (como exemplo, aplicado a compiladores), nesta etapa, a
aplicao de check-list (listas de verificao) e inspeo visual do cdigo do mesmo
modo conduz a bons resultados. Logo a segunda possui o objetivo de averiguar a
lgica de unidade. Nesse momento, a ideia exercitar os comandos iterativos, a
manipulao das estruturas de dados, os comandos condicionais, as interfaces e
verificar a sequencia de controle.
Como as unidade so validadas individualmente, para Delamaro et al. (2007),
de acordo com a implementao das unidades o teste de unidade tem a
disponibilidade de ser aplicado pelo desenvolvedor, no tendo a exigncia de ter o
sistema pronto.
Conforme Delamaro et al. (2007), o teste Integrado (ou teste de integrao)
deve ser executado aps os testes de unidades de forma individual, o realce dado
na concepo da estrutura do sistema. Conforme os diferentes componentes do

19

software so postos para operar em conjunto, necessrio verificar se a

comunicao entre elas no leva a erros e trabalha de maneira correta.
Koscianski et al. (2007), referindo-se a integrao de componentes, afirma
que h duas abordagens predominantes no desenvolvimento de software, o bottomup e o top-down.
Em bottom-up, o sistema desenvolvido com base em rotinas bsicas que
trabalham para rotinas com mais alto nvel. Como exemplo, uma verificao se o
CPF valido, essa rotina tem a disponibilidade de ser chamada em varias etapas da
execuo do programa. Logo ser codificada antecipadamente. No modelo topdown, executa-se uma abordagem inversa, o programador trabalha supondo que o
cdigo de baixo nvel esteja pronto. Dessa forma, podem-se implementar chamadas
de verificao do CPF, mesmo tendo conhecimento que ainda no existe. No seu
lugar, pode ter um stub, ou rotina fantasma", que meramente sempre retorna um
valor efetivo afirma Koscianski et al. (2007).
Segundo VILLAS BOAS (2007), o teste efetuado com o software completo
anteriormente que ele fique disponibilizado ao cliente o teste de sistema. Este
teste tem o intuito de assegurar que as necessidades do cliente (pr definidos na
especificao dos requisitos do software) foram codificados. No teste, as interfaces
externas so validadas e evidencia-se que o software atendeu os requisitos
funcionais e no funcionais especificados.
Delamaro et al. (2007) descreve que o teste de sistema tem como objetivo
validar se as necessidades descritas nos documentos de requisitos foram
implementadas corretamente. Caractersticas de completude, coerncia e correo
devem ser analisados to quanto requisitos no funcionais como por exemplo
performance, segurana e robustez. Um grande numero de empresas utilizam da
ttica de estabelecer um grupo de pessoas separado com o intuito de realizar os
testes nos sistemas.
De acordo com Koscianski et al. (2007), o teste de aceitao realizado com
o intuito de analisar a qualidade externa do produto e, na medida do possvel
tambm a qualidade em uso. Desta forma, s pode ser executado se o software est
finalizado e aguardando a implantao. Claramente, um teste com grande
relacionamento ao cliente, o mesmo colabora no planejamento e execuo destas
atividade.
Vasconcelos et al. (2006) categoriza os testes de aceitao em duas
categorias:
testes alfa: So testes que so executados por um cliente, normalmente
dentro da rea de desenvolvimento, neste teste se percebe e toma-se
nota dos erros e problemas percebidos e reportados.
testes beta: executado por clientes em potencial dentro do prprio
ambiente do cliente no possuindo o acompanhamento do
desenvolvedor. O cliente por si s comunica os problemas reportados ao
desenvolvedor em seguida.
Segundo Delamaro et al. (2007) h tambm o quinto nvel de teste, o teste de
regresso. Ainda segundo o autor, tal tipo nunca realizado durante a aplicao da
metodologia padro de desenvolvimento, mas sim na manuteno do software. Em
qualquer alterao executada no sistema, posteriormente a sua liberao, tem-se o
risco de outros defeitos sejam inseridos. Devido a este motivo, se faz necessrio,
posteriormente a manuteno, executar testes que comprovem que as alteraes
20

executadas esto conformes, ou seja, os novos requisitos inseridos (caso for o

cenrio) operam conforme o desejado e que os requisitos previamente testados
continuam funcionais.

10.3.2. TCNICAS DE TESTES DE SOFTWARE

Segundo Peters e Pedrycz (2001), o teste de software abrange diversas
estratgias/tcnicas/abordagens de teste, tal como o teste dinmico, o teste esttico,
o teste de caixa preta e o teste de caixa branca, que vai ser explicado a seguir.
Tosetto (2004) esclarece que o teste esttico, conhecido tambm como
reviso de software, j que no envolve a execuo em si do programa. As tcnicas
de teste esttico se baseiam em inspeo visual, ou seja, na leitura em si do cdigo
dos programas por um grupo de indivduos com o intuito de encontrar erros. O custo
de correo dos erros reportados neste mtodo aparenta ser de menor custo devido
que a origem precisa do erro localizada antecipadamente, enquanto que os testes
dinmicos localizam apenas os sintomas dos erros. O autor ainda afirma que estes
mtodos no so eficazes na deteco de erros de anlise de requisitos ou
modelagem do sistema, relata tambm que alguns autores no consideram que as
atividades estticas sejam atividades do teste de software, mas sim que seja uma
reviso tcnica formal.
Alguns exemplos clssicos das tcnicas do teste esttico podem ser as
inspees de cdigo, o percorrimento e as avaliaes em pares conhecidas tambm
como peer-reviews (MYERS, 2004).
O teste dinmico tambm chamado anlise dinmica necessita que o
software seja realizado com dados de teste. Este teste se apoia na utilizao de
dados inseridos no programa. Estes dados podem ser apenas uma bsica instruo
de entrada e sada para monitorar valores de variveis em tempo de execuo do
programa ou podem executar os mdulos de anlise que analisam o nmero de
vezes em que os elementos do sistema so processados (PETERS E PEDRYCZ,
2001).
Tcnicas dinmicas so utilizadas para localizar defeitos e averiguar a
qualidade do software (BURNSTEIN, 2003). As principais tcnicas de testes
dinmicos so o teste de caixapreta, tambm conhecido como testes funcionais,
que conforme Villas Boas (2007), executado acompanhando o software apenas
atravs de suas telas, assim, testando efetivamente as sua funcionalidade. Os erros
reportados nesta tcnica, segundo o autor, pertencem s seguintes categorias: erros
de interface, funes incorretas, erros na estrutura de dados ou se for o caso de
acesso a dados externos (tal como dados armazenados em um banco de dados),
erros de inicializao ou finalizao e erros de desempenho.
Uma tcnica exposta por Pressman (2006) neste tipo de teste o
particionamento de equivalncia, que nada mais que um mtodo de teste caixapreta em que divide-se o domnio de entrada de um programa em classes de dados
a partir do qual os casos de teste podem ser derivados para se ter um menor
nmero de cenrios de teste possveis. Uma classe de equivalncia interpreta um
aglomerado de dados vlidos ou invlidos para condies de entrada. Normalmente,
uma condio de entrada um dado especfico, uma srie de valores, um conjunto
de valores relacionados, ou uma condio booleana, essa condio de entrada
demonstrariam a classe toda (PRESSMAN, 2006). A anlise do valor limite que um
adicional ao critrio de particionamento de classes de equivalncia, necessita que o
testador utilizem valores prximos s bordas, assim os limites superior e inferior vo
ser cobertos pelos cenrios de teste (BURNSTEIN, 2003). O grafo de causa-efeito
21

ou tabela de deciso uma tcnica que tem a oportunidade de ser usada para
combinar as condies de entrada e assim ter um conjunto mais eficaz de cenrios
de teste que deste modo podem encontrar inconsistncias na especificao do
sistema. Contudo, a especificao tem que ser transformada em um grfico que se
seja similar a um circuito de lgica digital. Este grfico ser convertido em uma
tabela de deciso em que quem ir executar os testes possa utilizar l para elaborar
seus casos de teste (BURNSTEIN, 2003).
Teste estrutural ou teste de caixa-branca uma tcnica em que se permite
analisar a estrutura interna do sistema, isto , analisar a lgica do programa e
ocasionalmente, erros na codificao do mesmo (MYERS, 2004).
Pressman (2006) descreve que empregando mtodos de teste caixa-branca,
o engenheiro de software tende a construir casos de teste que asseguram que todos
os caminhos independentes dos mdulo foram exercitados pelo menos uma vez, foi
exercitado todas as decises lgicas em seus lados falsos e verdadeiros, executa se
todos os ciclos em seus limites e no interior de seus intervalos operacionais assim
como exercite se as estruturas dos dados de forma internas para assim garantir sua
validade e efetividade.

10.3.3. TIPOS/CATEGORIAS DE TESTE DE SOFTWARE

De acordo com Peters e Witold (2001), considerando a variedade do teste de
software existente, benfico levar em considerao os tipos de testes, conforme se
tornam pronto a um projetista. Tal da mesma forma ir ajudar a reconhecer a
cobertura em um determinado teste e explicar as vantagens e desvantagens, tal
como auxiliar o desenvolvedor a entender as suas limitaes.
Os tipos de teste amplamente difundidos so testes funcionais e testes no
funcionais. Conforme Myers (2004) os testes funcionais so um processo de
experimentao com o intuito de localizar desconformidades entre as especificaes
externas que nada mais que precisas descries do funcionamento do sistema no
ponto de vista do usurio final e o sistema em si. A etapa de testes no funcionais
exclusivamente aplicada para o fim de deteco de defeitos externos na interface de
hardware e software (BURNSTEIN, 2003).
Conforme Magela (2006) apenas o teste funcional no fornece a garantia
primordial para que o software entre na produo, por causa disso se faz necessrio
conjuntamente o teste no funcional.
Um dos teste no funcional categorizado como usabilidade que de acordo
com Ferreira (2002) relativo eficincia e eficcia da interface frente ao usurio e
na reao deste usurio frente a interface.
Myers (2004) traa motivos de porque a usabilidade deve receber testes:
- Cada interface de usurio foi construda com foco aos objetivos do usurio
final?
- Os retornos do sistema so de fcil entendimento e com uma linguagem
simples e objetiva, no de computador?
- As mensagens de advertncia apresentadas pelo sistema so diretas e de
fcil entendimento?
- Todas as interfaces seguem o mesmo padro visual?
- Onde a exatido fundamental, como por exemplo um sistema bancrio,
apresentado todos os dados suficiente de entrada?
22

- O sistema apresenta um design simples e objetivo, apresentando ao usurio

somente as funes que ele ira usar naquele momento?
- O sistema fcil de usar? No cenrio de o usurio necessitar navegar por
varias telas, fica claro este caminho para ele, o sistema apresenta est informao
de um modo simples e visual ao usurio?
Em teste de volume, conforme Myers (2004), o sistema sujeitado a um
grande volumes de dados.
Magela (2006) complementa informando que o teste de volume afere a
capacidade do sistema de comportar uma grande massa de dados sem se
preocupar com o tempo, em que executado o teste de carga.
No teste de ambiente validado o atendimento aos requisitos necessrios de
ambiente. Restries como temperatura do lugar, interferncia ou umidade, entre
outros itens tem que ser validadas e verificadas (MAGELA, 2006).
Testes de segurana asseguram o sigilo de informaes tal como a proteo
dos dados para a defesa de acessos indevidos de terceiros. O nvel de segurana
aplicado depende diretamente dos riscos associados ao negcio. A garantia de sigilo
das informaes planejada com o intuito de proteger os recursos da organizao.
Diversas informaes, caso reveladas ou manipuladas, podem comprometer o
negcio da empresa ou at elevar a vantagem competitiva de seus concorrentes
(BASTOS et al., 2007).
Em dias atuais, com o advento da internet, segurana adicional deve ser
fornecida. Entretanto, itens como proxy, entre outros no referem-se ao software e
sim dados da empresa. Logo, se faz responsabilidade da empresa operar na
popular zona segura, e no no sistema em processo de evoluo (MAGELA, 2006).
Teste de desempenho ou conhecido tambm como teste de performance,
estruturado com o intuito de aferir o desempenho do sistema em tempo de execuo
dentro de seu contexto de integrao. O mesmo ocorre a durante todas as etapas do
processo de teste. Referido ao nvel de teste de unidade, o desempenho de um
mdulo separado tende a ser aferido quando os testes caixa-branca so executados
(SWEBOK, 2004).
Referente a instalao, diversos tipos de sistemas de software possuem
procedimentos de instalao complexos. Validar as etapas de instalao e
configurao uma etapa relevante do processo do teste de sistema. Essa etapa
primordial num sistema com instalao automatizada. O mau funcionamento da
etapa de instalao automtica do sistema arrisca barrar que o usurio consiga
instalar a aplicao e utiliza-la. A experincia inicial do usurio com o sistema se
iniciar j no processo de instalao do mesmo. Caso nessa etapa ocorra algum erro
pode acarretar que o usurio ou cliente perca a confiana no produto (MYERS,
2004).
Ao que se refere recuperao, definido por Magela (2006) extremante
necessrio analisar o tempo necessrio de recuperao do software quando um de
seus recursos falham com o intuito de sempre garantir que o sistema seja auto
suficiente em seu processo de recuperao. Ainda segundo o autor, este requisito
se faz somente em cenrio especficos devido ao seu auto custo de mapeamento de
cenrios possveis e elaborao de solues sistemticas.
Atravs do teste de software possvel validar e garantir a qualidade do
software.

23

10.4. IMPACTOS DA FALTA DE QUALIDADE NO SOFTWARE

A reduo da quantidade de defeitos em software colabora fortemente para a
diminuio do custo de manuteno, dado que o custo de correo aumenta
exponencialmente de acordo com a fase em que encontrada a falha, e com o
tempo decorrido desde a incluso do defeito no software. De acordo com Viega e
McManus (2000), uma falha encontrada na fase de especificao custa em mdia
US$139,00 para ser corrigida, enquanto que na fase de desenvolvimento, custa
US$7.000, e para descobrir e corrigir uma falha depois da implantao do software
custa cerca US$14.000.

10.5. DESENVOLVIMENTO DE SOFTWARE: VISO GERAL

Durante a dcada de 70, os empreendimentos de desenvolvimento de
software eram marcados por problemas comuns como execuo desorganizada,
desestruturada e sem planejamento adequado entregues fora do prazo estipulado,
que acabava por gerar produtos de m qualidade, sem documentao e sem
correspondncia entre o tempo e o esforo orados e a real necessidade. Projetos
como esses no satisfaziam as necessidades do cliente, desperdiavam recursos da
empresa e elevavam os custos do projeto, que no seriam compensados para o
cliente. Pressman (2006) se refere a essa poca como A crise do software.
Nesse cenrio, segundo Pressman (2006) ficou evidente a necessidade de
estruturar os processos de desenvolvimento de software, de forma planejada e
padronizada. A inteno que as necessidades fossem atendidas, e os custos com
a informatizao dos processos de informao se tornassem economicamente
viveis.
Pressman (2006) cita que para realizar essa padronizao, foram criadas
metodologias de desenvolvimento comeando pelas metodologias de
desenvolvimento linear, conhecidas inicialmente por modelo em cascata, at os
atuais processos geis de desenvolvimento, que dividem o processo de
desenvolvimento em diferentes fases ou etapas pr-definidas. As metodologias
aplicadas devem se adequar s caractersticas da organizao em que so
aplicadas, e ao ambiente que essa organizao implementa para o desenvolvimento
de software. Tambm devem estar alinhadas com o paradigma de desenvolvimento5
e ao tipo de plataforma para a qual o software deve ser desenvolvido. As
caractersticas dos projetos (tempo que pode ser utilizado, e as reais necessidades
dos interessados) devem ditar os custos e os prazos para o planejamento.
Mesmo com o desenvolvimento das tcnicas avanadas e padres
consolidados nos processos de desenvolvimento de software, caracterstica
marcantes da crise do software perduram at hoje, em projetos que sofrem ainda
com atrasos, erros de estimativas de custo e tempo e imprevisibilidade.
Segundo Somerville (2003) o processo de desenvolvimento de software pode
ser divido em fases.

10.5.1.

FASES DO DESENVOLVIMENTO DE SOFTWARE

Conforme Somerville (2003), em uma viso mais abrangente do processo de

desenvolvimento de software, independentemente da rea de aplicao, tamanho ou
complexidade do projeto, possvel identificar trs fases genricas: definio,
desenvolvimento e manuteno.
5

De acordo com Scott (2006), um paradigma de desenvolvimento fornece e determina a viso que o
programador possui sobre a estruturao e execuo do programa.

24

Somerville (2003) cita que na fase de definio o objetivo identificar as

funcionalidades, restries, validaes, interfaces e os requisitos principais que o
projeto precisa atender. essencial a interao com o cliente para validar as
definies coletadas ou construdas em conjunto com ele, para garantir que os
requisitos essenciais sejam atendidos no decorrer do projeto.
Independentemente dos mtodos utilizados, ou o paradigma aplicado, essa
fase composta por trs subtarefas principais: a engenharia de sistemas, que a
compreenso e definio dos objetivos do sistema, o planejamento do projeto, que
pretende determinar os custos, o tempo, o esforo e os recursos necessrios para
concluir o projeto, e a anlise dos requisitos, que o levantamento, compreenso e
detalhamento dos requisitos (necessidades) que devem ser atendidos para que o
software possa ser considerado de qualidade.
Na fase de desenvolvimento, Somerville (2003) descreve que nessa fase, o
objetivo transformar o planejamento e detalhamento do projeto de software em
cdigo funcional. Em qualquer que seja a linguagem de programao, as tcnicas e
mtodos utilizados, tarefas bsicas devem ser executadas, como a criao do
projeto de software, que define o qu e como o software ser desenvolvido, e a
gerao do cdigo, que a traduo do que foi especificado em linguagem de
programao.
Diversos autores incorporam tambm nessa etapa a fase de testes, como
parte das tarefas bsicas. Independente da classificao, essa fase no pode deixar
de existir nos projetos de software, dado que nela que so localizadas as no
conformidades entre o produto e o que foi especificado na fase de definio. Essas
no conformidades podem ser referenciadas como a diminuio da qualidade final
do produto, e o no atendimento s exigncias e padres do cliente.
Segundo Somerville (2003), na fase de manuteno que o produto est em
funcionamento aplicado em seu contexto. Nessa fase, se analisa todo o produto,
com foco na identificao das modificaes necessrias. Essas modificaes podem
ser correes de erros, adaptaes s mudanas no contexto ou na necessidade, ou
mesmo novas funcionalidades. Essas modificaes caracterizam a evoluo do
produto de software.
A fase de manuteno engloba algumas atividades das fases anteriores, com
o diferencial de se aplicar a um produto de software existente e em funcionamento.
Somerville (2003) classifica as modificaes que ocorrem na fase de
manuteno em quatro tipos:
manuteno corretiva: Correo de defeitos inseridos no produto de software
durante uma das fases de desenvolvimento.
manuteno adaptativa: Modificao que visa adaptar o produto de software a
uma mudana no contexto em que o mesmo est inserido, mas que no fazem parte
de seu escopo, como uma atualizao de software externo, ou uma alterao em
uma norma ou legislao qual o software est submisso.
manuteno perfectiva: Insero de novas funcionalidades no produto de
software, com o objetivo de torn-lo mais completo. Essas funcionalidades no
faziam parte do escopo inicial do produto, e so consideradas como melhorias.
manuteno preventiva: Modificaes que visam preparar o software para que
o impacto de mudanas no seja to crtico. Partindo da noo de que mudanas no

25

ambiente, na demanda ou at nos requisitos do software iro acontecer. Essas

funcionalidades tambm podem ser referenciadas como reengenharia de software.
Segundo Pressman (2006) as metodologias de desenvolvimento so
basicamente divididas em dois grupos, metodologias de desenvolvimento linear,
conhecidas inicialmente por modelo em cascata e processos geis de
desenvolvimento, que dividem o processo de desenvolvimento em diferentes fases
ou etapas pr-definidas.

10.6. PROCESSOS TRADICIONAIS DE DESENVOLVIMENTO

No incio do amadurecimento dos processos de desenvolvimento de software,
foram mantidos alguns conceitos tpicos da rea da engenharia, que foram teis na
sistematizao dos processos, e com o passar do tempo contriburam para o
surgimento da denominao engenharia de software.
Conforme Bauer (1969) Engenharia de software criao e utilizao de
slidos princpios da engenharia a fim de obter software de maneira econmica, que
seja confivel para trabalhar eficientemente em mquinas reais. Engenharia o
conjunto das atividades de anlise, projeto, desenvolvimento, verificao e
gerenciamento dos elementos tcnicos.
De acordo com Pressman (2006), a engenharia de software se divide em
camadas, todas focadas na qualidade final do produto. Para se atingir essa
qualidade, o processo de desenvolvimento deve ser aperfeioado atravs da criao
de documentao, artefatos e marcos capazes de representar os elementos que
envolvem o desenvolvimento de um produto de software.
Com esse intuito, foram criados mtodos e ferramentas de engenharia de
software. Os mtodos abrangem as atividades de anlise de requisitos,
planejamento, controle, desenvolvimento, testes e manuteno de software. As
ferramentas fornecem o apoio automatizados para a execuo desses mtodos.

10.7. PROCESSOS GEIS DE DESENVOLVIMENTO

Desenvolvimento gil de software conforme Steffen (2012) um processo de
desenvolvimento de software que usa uma abordagem de planejamento e execuo
iterativa e incremental no qual divide as tarefas em outras tarefas menores e tem
foco em entregar o software em estado funcional, da nfase na aproximao e maior
colaborao do time de desenvolvimento com os especialistas de negcio e, ou,
cliente.
Segundo Steffen (2012), basicamente o principal objetivo de desenvolvimento
gil entregar um produto de qualidade dentro das reais necessidades do cliente.
Conforme Highsmith (2004) agilidade em tecnologia da informao a
habilidade de criar e responder a mudanas, buscando a obteno de lucro em um
ambiente de negcio turbulento. O autor ainda enfatiza que a ausncia de estrutura
ou estabilidade pode levar ao caos, mas que a estrutura em demasia gera rigidez. A
flexibilidade dos processos geis vem em busca de diminuir est rigidez.
Segundo Steffen (2012) por intermdio do mtodo gil pode-se atingir uma
srie de benefcios para os clientes, estes benefcios podem ser:
foco e maximizao do ROI, ou retorno do investimento, tal como do valor de
negcio;

26

 entregas do produto mais rpida, frequentes e regulares;

acelerao do tempo de entrada no mercado o que se traduz em ganho de
competitividade;
maximizao do valor agregado ao mercado. Foco no que prioridade e
agrega maior valor para o usurio, o que se traduz em ganho de usabilidade;
transparncia e visibilidade do andamento da execuo do projeto;
flexibilidade para alterao de requisitos e prioridades tal como maior rapidez
na tomada de decises;
aumento da qualidade do produto final;
produtividade;
reduo dos riscos e das indesejveis surpresas.
Complementarmente Steffen (2012) afirma que o mtodo gil pode tambm
atingir uma serie de vantagens para os gestores e para a equipe, como:
escopo e objetivos claros e priorizados;
equipes auto gerenciveis, maior autonomia, disciplina e regularidade;
maximizao do comprometimento;
melhoria na comunicao. A comunicao intensa com o cliente e a gesto de
suas expectativas parte do processo;
analise e adequao constante do processo com o intuito da busca na
melhoria contnua e reduo de desperdcios;
antecipao dos problemas e maior agilidade na tomada de aes.
Steffen (2012) ainda cita uma pesquisa realizada mostrando uma escala dos
benefcios mais obtidos atravs do uso de times geis, o resultado da pesquisa
apresentado na Figura 3.

27

Figura 3: Escala dos benefcios com times geis.

Fonte: (STEFFEN, 2012).

Percebe-se que os maiores ganhos identificados na utilizao de times geis

conforme a Figura 3 a produo de software funcional acompanhado do
acompanhamento efetivo dos interessados, assim diminuindo a diferena entre a
expectativa do cliente e o que est sendo entregue pela equipe.
Com o surgimento do processo de desenvolvimento gil de software foi criado
tambm o manifesto gil que que um documento que rene os princpios e
prticas desta metodologia de desenvolvimento.
Conforme Beck (2001) "Estamos descobrindo maneiras melhores de
desenvolver software, fazendo-o ns mesmos e ajudando outros a fazerem o
mesmo. Com este trabalho, passa-se a valorizar:
indivduos e interaes mais que processos e ferramentas.
software em funcionamento mais que documentao abrangente.
colaborao com o cliente mais que negociao de contratos.
responder a mudanas mais que seguir um plano.
Explanando um pouco mais sobre os princpios, Beck (2001) cita que
referente ao primeiro certo que o nvel dos profissionais envolvidos no projeto afeta
diretamente a qualidade do produto e o bom desempenho da equipe no projeto, no
entanto, ter os melhores profissionais no garantia de sucesso no projeto, pois o
resultado dos mesmos depende diretamente do processo. Mais importante que as
ferramentas e o meio onde se vai trabalhar so a qualidade e o grau de interao da
equipe.
28

Referente ao segundo princpio, Beck (2001) cita que a documentao de um

projeto extremamente necessria para o sucesso do projeto, j que o cdigo no
o melhor meio de comunicao, uma boa documentao se faz necessria na
tomada de decises, porem necessrio tomar muito cuidado, pois em excesso de
documentao pior do que a falta dela. Para nada serve uma enxuta
documentao se ela no se mantm atualizada e em sincronia com o que est
sendo desenvolvido e especificado. Segundo o Manifesto Nenhum documento
gerado a no ser que seja necessrio e significante, ou seja, deve-se documentar
somente o importante e necessrio.
Referente ao item trs do manifesto, Beck (2001) cita que necessrio que
exista sempre um acompanhamento do cliente para garantir que o software esteja
sendo desenvolvido de maneira que atenda as suas necessidades, contratos que
determinam requisitos, prazos e custo de um projeto so, fundamentalmente, falhos.
Isso acontece devido, pois no decorrer do desenvolvimento alguns requisitos
tornam-se menos importantes ou dispensveis enquanto surge a necessidade de se
adicionar outros no previstos em contrato ou especificao. Logo o melhor
determinar como acontecer a comunicao e o relacionamento do cliente com a
equipe de desenvolvimento.
Ao tratar-se do quarto e ltimo manifesto, Beck (2001) cita que deve-se
assumir que mudanas de especificao sempre vo ocorrer em todos os projetos, e
possvel afirmar, que melhor ser o projeto que mais se adaptar a estas
mudanas. Quanto menor for o tempo para equipe responder mudana maior ser
a chance de sucesso do projeto, este um fator fundamental, no deve-se afirmar
que os planos no devem ser traados, mas sim que no possvel prever o futuro,
logo este planejamento no deve ser de longo prazo.
Juntamente com o manifesto surgiram os doze princpios do gil, que formam
mais um pilar deste processo. Conforme Beck (2001) os princpios so:
nossa maior prioridade satisfazer o cliente atravs da entrega contnua e
adiantada de software com valor agregado;
mudanas nos requisitos so bem-vindas, mesmo tardiamente no
desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem
competitiva para o cliente;
entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferncia menor escala de tempo;
desenvolvedores e pessoas de negcio tem a obrigao de trabalhar
diariamente em equipe por todo o projeto;
construa projetos em torno de indivduos motivados. D a eles o ambiente e o
suporte necessrio e confie neles para fazer o trabalho;
o mtodo mais eficiente e eficaz de transmitir informaes para e entre uma
equipe de desenvolvimento atravs de conversa;
software funcionando a medida primria de progresso;
os processos geis promovem desenvolvimento sustentvel. Os
patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo
constante indefinidamente;
apropriado design e ateno contnua em excelncia tcnica aumenta a
agilidade;
29

 simplicidade, a arte de maximizar a quantidade de trabalho no realizado,

essencial;
a melhores arquiteturas, requisitos e designs emergem de equipes auto
organizveis;
de tempos em tempos, a equipe analisa sobre como se tornar mais eficiente e
ento adqua seu comportamento em conformidade com o propsito.
Bissi (2007) afirma que uma das metodologias geis mais utilizadas o Scrum.

10.7.1.

SCRUM

Conforme Bissi (2007) O Scrum assume-se como uma metodologia

extremamente gil e flexvel, que tem por objetivo definir um processo de
desenvolvimento interativo e incremental podendo ser aplicado a qualquer produto
ou no gerenciamento de qualquer atividade complexa..
De acordo com Gonalves (2008) o Scrum se tratando de uma metodologia
gil no s de desenvolvimento, mas tambm de gerenciamento de projetos. O
Scrum foi criado por Ken Schwaber e Jeff Sutherland, ele tem como objetivo
introduzir um processo de desenvolvimento com ciclos iterativo e incremental,
possibilitando ser usada na gesto de qualquer atividade. Como base o
desenvolvimento do Scrum centraliza-se na equipe com ciclos de iterao
pequenos. Complementarmente Gonalves (2008), afirma que Scrum a
metodologia de desenvolvimento gil de software no qual vem conquistando a cada
dia mais adeptos no mercado.
Segundo Maral (2007) o Scrum compreendido da seguinte maneira:

O Scrum um mtodo que aceita que o desenvolvimento de

software inesperado e realiza a abstrao, e adequado a mbitos
volteis. O Scrum se destaca nos mtodos geis devido grande
importncia dada ao gerenciamento do projeto. Envolve prticas de
controle e feedback, em reunies dirias e rpidas com toda a equipe,
com objetivo corrigir e identificar os impedimentos no processo de
desenvolvimento. (MARAL, 2007).

Segundo Gonalves (2008), o Scrum alinha um conjunto de regras e tcnicas

de gerenciamento que possibilitam garantir resultados positivos nos projetos, focado
para atividades em equipe e avano na comunicabilidade, possibilitando que cada
integrante da equipe desenvolva o melhor.
De acordo com Bossi (2003), a nomenclatura inerente utilizada na
metodologia Scrum possui os seguintes significados:
product Backlog: Relao de todas as funcionalidades que deveram ser
desenvolvidas no decorrer do projeto completo.
scrum Team: Equipe de desenvolvimento de um Sprint.
scrum Master: Personagem da equipe responsvel pela gesto do projeto.
Esse personagem embora seja gestor, no tem autoridade sobre os demais
integrantes da equipe.
product Owner (PO): Proprietrio do produto.
sprint: Tempo no ser maior que 30 dias, onde somente algumas
funcionalidades do projeto so desenvolvidas.
30

 sprint Planning Meeting: Reunio de planejamento.

sprint Review Meeting: Reunio de reviso.
sprint Backlog: Atividade desenvolvida em um Sprint de forma a produzir um
produto ou resultado que dever ser mostrado ao cliente.
dayling Scrum: Reunio diria.
Segundo Pereira (2007) o Scrum um processo imprevisvel, no descreve
como agir em todos os momentos, usado para projetos com alto nvel e
complexidade, onde invivel saber o que poder acontecer, usando um framework
que permite definir boas prticas para gesto de projetos. Ainda segundo Pereira
(2007) o Scrum se baseia em quatro atividades bsicas, que so:
planejamento: Estabelece
benefcios para sua realizao.

uma

perspectiva

do

projeto,

assegurando

stagging: Baseado em estimar o tamanho do projeto elaborando itens para o

Product Backlog.
desenvolvimento: Fundamenta-se na execuo de vrios Sprints para o
desenvolvimento da propagao de funcionalidade do produto.
releasing: Fundamenta-se na ao da entrega final ao cliente.
A Figura 4 apresenta de maneira simples o ciclo do Scrum.

Figura 4: Ciclo de vida do Scrum

Fonte: (PEREIRA, 2007).

De acordo com Pereira (2007), existe no Scrum uma diviso em trs grupos:
o Product Owner, o Scrum Master e o Scrum Team, cada grupo possui atividades
particulares porem todos esto envolvidos atuando mutuamente entre si.
O Product Owner (PO) representar os interesses de todos envolvidos no
projeto, o PO no necessita ter um conhecimento absoluto sobre a metodologia
Scrum, porm precisa compreender bem a atividade que ser desenvolvida.
31

 necessrio estar sempre acessvel para a equipe, sobretudo no perodo de

reunies de planejamento (Sprint Planning), e nas reunies de reviso (Sprint
Review), com a inteno de priorizar as atividades que sero feitas no Sprint.
O Product Owner (PO) tambm tem a responsabilidade de fragmentar as
atividades em partes menores e preservar o Product Backlog em ordem, tambm
so tarefas do PO:
responsvel pelo retorno financeiro do produto.
pode mudar os requisitos e prioridades a cada Sprint.
detalhar os requisitos do produto, definir a entrega da release e o que deve
conter nela.
decidir quais requisitos possuem maior importncia conforme o valor de
mercado que possuem.
aceita ou rejeita o concluso de cada Sprint.
O Scrum Master segundo Magnos (2008) tem um papel muito importante no
Scrum, este papel ocupado por uma pessoa que trabalha especificamente com a
equipe de desenvolvimento. O Scrum Master o responsvel por assegurar a
execuo dos procedimentos do Scrum no projeto, a equipe deve compreender que
esta pessoa tem entendimento pleno sobre o processo de Scrum e que seu
trabalho remover qualquer impedimento na utilizao das prticas do Scrum.
Segundo SOARES (2004), o mais conhecido entre os mtodos geis o
Extreme Programing.

10.7.2.

EXTREME PROGRAMMING (XP)

Conforme Wells (2012) Ward Cunningham e Kent Beck juntaram-se em 1996

para resolver a necessidade de uma metodologia para desenvolvimento de software
com abordagem mais simples, eficiente e direta. Com isso surgiu o Extreme
Programming (XP).
Beck (1999) define o Extreme Programming como: uma metodologia gil
para equipes pequenas e mdias que desenvolvem software baseado em histrias
de usurios e requisitos que se modificam rapidamente. Como o Scrum, o Extreme
Programming em relao s metodologias tradicionais possui caractersticas como
abordagem iterativa incremental, valorizao da comunicao face a face e
constante feedback6.
Segundo Beck (1999) O XP uma abordagem disciplinada e deliberada para
o desenvolvimento de software, e vem sendo mais adotada a cada dia, ele afirma
tambm que o XP est tomando espao que antes pertencia a outras metodologias,
metodologias tradicionais, como por exemplo, o RUP Rational Unified Process7 e o
CMMI8.

Feedback, segundo FIORELLI (2007), um processo de ajuda para mudanas de comportamento,

comunicao a uma pessoa, ou grupo, no sentido de fornecer-lhe informaes sobre como sua atuao est
afetando outras pessoas.
7
Segundo Kroll (2003) o RUP, abreviao de Rational Unified Process, um processo proprietrio de
Engenharia de software criado pela Rational Software Corporation que fornecendo tcnicas a serem seguidas

32

Conforme Beck (1999) o XP fortemente baseado em seus valores.

10.7.2.1.

VALORES BASE DO EXTREME PROGRAMMING

O XP, como outras metodologias geis, tem foco na garantia da satisfao do

cliente, ele estima que o desenvolvimento do projeto ocorra de forma gil para
garantir o cumprimento das estimativas deste. Conforme Beck (1999) quem utiliza
devem seguir basicamente quatro valores que sero explicados a seguir, estes so:

comunicao;
simplicidade;
feedback;
coragem.

Sobre comunicao, Beck (1999) ensina que o princpio da comunicao

busca em ter o melhor relacionamento possvel entre o cliente e desenvolvedores.
Beck (1999) mostra que isto deve ser feito de maneira direta, pessoal, sendo mais
explicito, ou seja, devem-se evitar contatos no diretos como telefone, e-mails, entre
outros. Conforme ele, isto se aplica tanto para o relacionamento quanto a clientes
externos bem como clientes internos, como gerentes e diretores. O valor da
simplicidade busca criar cdigos simples, ou seja, sem desenvolvimento
desnecessrio, um software com o menor nmero possvel de classes e mtodos.
(Beck, 1999)
O feedback constante auxilia os programadores a terem informaes
atualizadas, seja do cliente ou do prprio cdigo. Testes contnuos buscam apontar
erros tanto no mdulo que est sendo desenvolvido como outros mdulos que j
esto no software. Com as constantes entregas do software para o cliente
disponibilizado em um ambiente similar ao de produo estas novas verses para o
cliente homologar e acompanhar a evoluo, assim possvel ele solicitar melhorias
a serem feitas e novas funcionalidades. Neste ambiente integrado os erros so
identificados rapidamente pelos testes contnuos e corrigidos. Com o
acompanhamento constante do cliente o produto final tende a sempre atender suas
expectativas (Beck, 1999).
Referente coragem, para o XP, possuir coragem para adotar os trs valores
extremamente importante. Pois nem todos tm facilidade em se comunicar, ou
atitude para simplificar o cdigo sempre que ter oportunidade, ou at estar pronto
para dar e receber feedback.

10.7.2.2.

ATIVIDADES BSICAS DO EXTREME PROGRAMMING

Para Beck (1999): Voc codifica porque se voc no codificar voc no ter
nada. Voc testa porque se voc no testar voc no saber quando voc terminou
de codificar. Voc ouve porque se voc no ouvir voc no saber o que codificar ou
o que testar. E voc projeta para que voc possa codificar, testar e ouvir
indefinitivamente.
pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade
no processo de desenvolvimento.
8
Conforme o SEI (2010), CMMI um modelo de referncia baseado nas melhores prticas para
desenvolvimento e manuteno de produtos, ele procura estabelecer um modelo nico para o processo de
melhoria corporativo, integrando diferentes modelos e disciplinas.

33

Beck (1999) diz que o XP feito de quatro bsicas atividades:

codificar: Codificar escrever o cdigo efetivamente.
testar: Para todo trecho de cdigo, deve haver um trecho de teste unitrio
correspondente.
ouvir: Ouvir sempre o que o cliente tem a dizer, o que ele tem a mostrar e
aprender com ele sobre o seu negcio.
projetar: Criar uma estrutura que organiza a lgica de modo a diminuir a
complexidade do cdigo.
Conforme JEFFRIES (2012) estas quatro atividades so distribudas em treze
prticas conforme apresenta a Figura 5:

Figura 5: Prticas XP
Fonte: (JEFFRIES, 2012).
Conforme Jeffries (2012) as treze prticas podem ser descritas conforme
apresentado na tabela 1.

Jogo do planejamento

Pequenas Verses

Metforas

Design simples

Estime as tarefas, defina e priorize o escopo da verso

atual seguinte, se tiver algum problema, refaa o
planejamento.
Busque um prazo de entrega de uma a duas semanas
para cada nova entrega de verso do software e
trabalhando com a avaliao do cliente para evitar
surpresas nas entregas das verses.
Escreva historia com a necessidade do cliente e uma
descrio breve do comportamento da nova
funcionalidade do sistema, a equipe deve se encarregar
de projetar junto com cliente o que ele realmente
espera.
O cdigo deve ser o mais simples possvel,
basicamente somente para os testes passarem.
34

Testes Unitrios

Testes de Aceite

Refatorao

Programao em par

Propriedade coletiva
Integrao contnua
Ritmo sustentvel

Cliente e equipe em
constante
comunicao
Padres de cdigo

Os testes devem ser escritos antes do desenvolvimento

com o intuito garantir a qualidade e auxiliar o
desenvolvedor, a saber, quando a funcionalidade est
pronta, assim no gerando cdigo desnecessrio.
Testes de aceite devem sem desenvolvidos para
auxiliar na deciso de quando a funcionalidade est
pronta.
O cdigo deve ser o mais simples e objetivo possvel,
mas sem perder o padro e a qualidade, os testes
unitrios do mais segurana para o programador
durante a refatorao.
Toda codificao deve ser feita em dupla. Assim diminui
erros sintxicos do cdigo e aumenta a qualidade,
devido a que o cdigo sempre revisado. Deve-se
sempre alternar os papeis baseando se em sesses,
em uma sesso um revisa e o outro codifica, na outra
se inverte os papeis.
Todos os membros da equipe podem alterar qualquer
parte do cdigo.
Automatize o maior numero de tarefas possveis.
Busque trabalhar somente dentro da escala normal,
hora extra em demasia pode indicar um erro de
estimativa ou de planejamento.
Sempre que necessrio entre em contato com o cliente
para sanar as duvidas da equipe, o obvio deve ser dito.
Todos os cdigos devem estar de acordo com o padro
definido pela equipe.

Tabela 1: Treze prticas do XP.

Fonte: (JEFFRIES, 2012).

Wells (2012) cita que as treze prticas apresentadas anteriormente, formam a base
do processo gil Extreme Programming.

10.7.2.3.

CINCO REGRAS DO EXTREME PROGRAMMING

Segundo Wells (2012) o mais surpreendente aspecto do Extreme

Programming so suas simples regras. Este possui vrios pedaos pequenos e
individualmente suas peas podem fazer sentido algum, porem ao combina-las
forma-se uma imagem completa como pode ser visto na Figura 6.

35

Figura 6: Relacionamento das prticas do XP.

Fonte: (WELLS, 2012).
Conforme Wells (2012) as treze prticas podem ser divididas nas cinco
regras, que so: planejando, gerenciando, projetando, codificando e testando.
Para Wells (2012), o cliente escreve cartes de histrias, estes cartes so
utilizados na definio de prazos e nas reunies para planejamento de liberao.
Cada histria ter seu tempo de desenvolvimento estimado. O tempo de
desenvolvimento o tempo necessrio para transformar a histria em cdigo
incluindo os cdigos de teste.
Segundo Wells (2012), reunies de planejamento tm por objetivo estimar
cada histria em semanas de programao ideal e definir suas prioridades com o
cliente, definem-se tambm quantas histrias podem ser codificadas at uma
determinada data. A equipe de negcios juntamente com o cliente responsvel por
definir as prioridades, o escopo, as tarefas que compem as verses e as datas de
entrega, mas para essas decises necessrio informaes da rea tcnica
juntamente com as suas estimativas, consequncias previstas, cronograma e
processo.
Projetos so medidos por quatro variveis:
escopo: O que deve ser feito.
recursos: Pessoas envolvidas.
tempo: Qual o prazo para ser entregue.
qualidade: O software atende os requisitos acordado.
No gerenciando, conforme Wells (2012) deve ser definido um padro de
acompanhamento do projeto. Aconselham-se reunies dirias, aconselha-se
estruturar estas reunies com trs tpicos, o que foi finalizado no dia anterior, o que
est sendo feito no dia atual e se h impedimentos para o andamento das tarefas.

36

Sobre projetando, segundo Wells (2012), deve-se ter foco na simplicidade,

sempre que for encontrado um cdigo extenso ou complicado deve-se substituir por
outro mais simples. Desenvolva somente as funcionalidades solicitadas pelo cliente.
De acordo com Wells (2012) refatorar no ciclo de desenvolvimento do software
aumenta a qualidade e economiza tempo, deve ser executado impiedosamente para
manter o projeto simples, com baixa complexidade e evitar confuses
desnecessrias. Um cdigo simples e coerente facilmente compreendido,
estendido e modificado.
Em codificando, perante Wells (2012) desenvolver teste antes da codificao
da soluo facilita no entendimento do que tem que ser feito. A programao em par
traz mais qualidade para o sistema. Integrar o cdigo pronto com o resto do
desenvolvimento frequentemente evita conflitos de cdigos. Sempre trabalhar na
ultima verso dos cdigos fonte evita alterar cdigos obsoletos.
Referente a testando, para Wells (2012) todo cdigo deve ser testado. Ao
adicionar uma nova funcionalidade ao sistema rode todos os testes para garantir que
uma funcionalidade antiga no foi quebrada. Ao encontrar um erro no sistema, crie
um teste para garantir que o mesmo erro no volte a acontecer. O desenvolvimento
s est pronto quando todos passar em todos os testes de aceitao.
O desenvolvimento e aplicao das tcnicas geis de desenvolvimento
surgiram no XP. Segundo Beck (1999) as tcnicas geis de desenvolvimento so
base da metodologia XP e apoiam-se entre sim, uma fortalecendo a outra.

10.8. TCNICAS GEIS DE TESTE

Segundo Beck (1999), uma das primeiras tcnicas de desenvolvimento gil
apresentadas por foi o Test driven development (TDD).

10.8.1.

TEST DRIVEN DEVELOPMENT (TDD)

O conceito do desenvolvimento orientado a testes (Test driven development

ou TDD) surgiu no XP.

10.8.1.1.

CONCEITO DO TDD

O TDD uma tcnica que utiliza testes para ajudar no projeto de software,
forando o desenvolvimento a resultar de maneira incremental no decorrer da
implementao. A viso de se ter o desenvolvimento do teste antes da codificao e
na implementao, o cdigo deve ser escrito unicamente com o propsito de fazer o
teste resultar em sucesso (KOSKELA, 2007).
Conforme Koskela (2007), embora o nome sugira que Test driven
development (TDD) esteja associado somente a testes, TDD uma tcnica de
projeto de software. O primeiro passo a inverso da sequncia comum de planejar,
implementar e ento testar. O TDD traz os testes para o primeiro passo e divide o
ciclo em vrias pequenas iteraes. Essa mudana de ordem tem vrios impactos,
desde o nvel de projeto de software at o nvel de confiana do desenvolvedor no
produto sendo desenvolvido.

37

O TDD, tambm conhecido como Test first development (TFD), uma tcnica
de teste estrutural9:
TDD no a respeito de testes, na verdade como usar testes
para criar software de maneira compreensvel e incremental. Alm de
simplificar o processo de desenvolvimento, melhora qualitativamente o
projeto do software (Gold et al., 2004).

Koskela (2007) cita que em disparidade a forma habitual de desenvolvimento

de software, onde se inicia um projeto que ir conduzir a implementao, utilizando
TDD comea-se aplicando um teste que define como uma parte do sistema deve
funcionar. Construir os testes antes ajuda a entender o comportamento do sistema,
e contraria a prtica habitual de se realizar um projeto detalhado antes da
implementao. Maximilien e Williams (2003), aderentes de metodologias geis,
criticam essa forma de planejar o desenvolvimento de software por ser pouco
passvel a modificaes e por resultar em projetos irrelevantemente grandes ou
complexos.
Em todo processo, existem falhas. O sucesso de TDD pode ser
atribudo diminuio dessas falhas, medida que ciclos menores de
teste-ento-codifique retornam constantes feedbacks ao programador.
Um fato constante citado em engenharia de software que quanto mais
tempo uma falha permanece no sistema, mais caro e difcil resolv-la.
Aplicando TDD falhas so apontadas rapidamente e sua causa
facilmente identificada. (Maximilien e Williams, 2003).

Em estudos realizados pela IBM, aps a adoo de TDD, foi constatada uma
reduo de 50% na quantidade de defeitos encontrados. Os mesmos estudos feitos
pela Microsoft confirmam o aumento na qualidade do produto, entretanto apontam
que o desenvolvimento de testes seguindo a tcnica TDD leva 15% a mais de tempo
(NAGAPPAN, 2006).
Os primeiros registros de aplicao de TDD foram durante a dcada de 60,
quando foi utilizada pela NASA (Larman e Basili, 2003). Segundo Nagappan (2006)
o TDD uma tcnica que ganhou espao com o surgimento de metodologias geis,
como uma das prticas XP, porm vem ganhando destaque individualmente
medida que mais assuntos so divulgados especificamente sobre o assunto.
A reduo da quantidade de falhas no sistema que o uso de TDD traz
notvel para se ter um maior retorno de investimento, Return On Investment (ROI).
Com o custo da correo de defeitos aumentando exponencialmente com o passar
do tempo, corrigi-los na fase de especificao pode chegar a custar menos do que
1% do custo que teria a correo dessa mesma falha na fase de implantao
(VIEGA E MCMANUS, 2000).
George e Williams (2003) apresentaram uma pesquisa comparando um grupo
de profissionais desenvolvendo um software em Java utilizando TDD e o outro
utilizando a metodologia em cascata. Os resultados mostraram que os
desenvolvedores que aplicam TDD produziram cdigo de melhor qualidade, e
tiveram 18% a mais de sucesso em testes funcionais10. Entretanto, o grupo usando
TDD tambm gastou 16% mais tempo na codificao, mesmo com resultados

Conforme Myers (2004), tcnica de teste estrutural, conhecido tambm como caixa branca, uma tcnica
para avalia o comportamento interno do componente de software. Essa tcnica trabalha diretamente sobre o
cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de
dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados.
10
Segundo Myers (2004), teste funcionais, conhecido tambm como caixa preta, so testes que avalia o
comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo.

38

positivos, o TDD ainda dificultoso de ser implantado pelas equipes de

desenvolvimento (DUBINSKY E HAZZAN, 2007).
Para praticar TDD corretamente, no entanto, necessrio escrever testes de
uma forma diferente:
Para aprender usar TDD corretamente preciso, criar testes
adequados que possam ser utilizados para conduzir o desenvolvimento
do software. A grande maioria dos programadores entendem como
construir testes para testar cdigo que j foi codificado, porm escrever
testes antes do cdigo pode necessitar um tratamento diferente. Para
criar testes que conduzam o desenvolvimento do cdigo, necessrio se
concentrar em como testar a funcionalidade de um cdigo ao invs de
sua implementao. (Gold et al., 2004)

Essa diferena na forma de criar testes to importante que algumas

referncias utilizam um vocabulrio especial para os testes unitrios desenvolvidos
utilizando TDD.
Testes do programador so os testes criados com finalidade de orientar o
desenvolvimento do software, por outro lado testes de unidade tm a finalidade de
testar a implementao de uma unidade j codificada. So chamados de teste do
programador em disparidade aos testes do usurio, que so testes feitos pelo
usurio para mensurar o comportamento do sistema de um ponto de vista do dele
(ASTELS, 2010).
No desenvolvimento habitual, testes de unidade esto propenso a ser
utilizados para comprovar funcionalidades de somente um mdulo do sistema. No
entanto, no TDD, estes so utilizados para projetar-se um objeto que ainda no foi
codificado fases iniciais do desenvolvimento. Criando testes de unidade, os
programadores podem decidir as funcionalidades de uma classe e as interaes
com outras classes. Desta forma os teste ajudam a descrever o sistema. O teste de
unidade adota um papel no projeto do sistema (KIM et al., 2006).
Ainda sobre a diferena de criar-se testes de unidade para fins de teste e
para fins de projeto, segundo Astels (2010) necessrio existir as seguintes etapas:
cdigo somente entra em produo se houver um teste associado a ele.
mantm-se um conjunto exaustivo de testes do programador.
testes so escritos antes da implementao.
testes determinam o cdigo que ser escrito.
O desenvolvimento em TDD constitudo de iteraes. Cada iterao
corresponde implementao de uma funcionalidade e constituda dos seguintes
passos (BECK, 1999):
escrever o teste para a funcionalidade;
verificar se o teste falha;
implementar o cdigo;
executar todos os testes;
melhorar o cdigo.
Segundo Beck (1999), com a mudana primordial da ordem comum das
aes que so projetar, codificar e ento testar baseando-se em um perodo
39

pequeno de iteraes, inicialmente o programador escreve um teste que falhe, o

com isso considera-se que o cdigo possui erros, logo ele deve fazer o teste passar,
atribui-se novas entradas no teste e se executa ele novamente, observa-se uma
melhor compreenso da cobertura do cdigo, comea ento a depurao do cdigo,
inicia-se a execuo, refatorao do cdigo, novamente teste tudo. Este processo
apresentado na Figura 7.

Figura 7: Processo de TDD

Fonte: (KOSKELA, 2007).
Primeiramente deve-se escrever o teste, posteriormente implementar a
funcionalidade e logo aps melhorar a implementao, assim o projeto de software
molda-se de uma forma objetiva de forma que implementado o mnimo necessrio.
Esse fluxo de teste-codificao-refatorao" (Figura 7) o contrrio do costumeiro
projete-codifique-teste" (KOSKELA, 2007).
A mudana do teste-codificao-refatorao" o vermelho-verderefatorao", decorrente ao uso comum de framework xUnit 11 em TDD, que
costumam apresentar uma barra verde para os testes que passam e uma barra
vermelha para os testes que falham. Acompanhando o ciclo TDD, logo que o teste
11

Conforme Fowler (2000), XUnit o nome dado ao grupo de ferramentas para teste estrutural que se
tornaram amplamente conhecido entre os desenvolvedores de software. O nome uma derivao do JUnit o
primeiro destes a ser amplamente conhecido.

40

escrito ele deve falhar, apresentando uma barra vermelha, e aps o cdigo ter sido
implementado, ele dever passar, apresentando uma barra verde. Visto que o teste
esteja passando, o cdigo refatorado. (KOSKELA, 2007).
Pequenas mudanas tambm tornam fcil o raciocnio do programador, que
acaba lidando com menos complexidade, se atentando com pequenas partes do
sistema, resultando em menos variveis.
As repeties devem ser pequenas assim o sistema nunca se afasta muito de
um estado funcional em que sua utilizao no seja prejudicada devido quantidade
de falhas existentes. Pequenas alteraes tambm impedem projetos de software
muito grandes, tornando o projeto de software algo constante e progressivo,
executado a cada iterao. Isso permite tomar decises de projeto fundamentado
em conhecimento adquirido durante o desenvolvimento, ao invs de ideias iniciais e
antecipao (Koskela, 2007).

10.8.1.2.

MOCK OBJECT

Segundo Fowler (2000), a expresso mock object tornou-se uma ferramenta

popular para representar objetos de casos especficos que imitam objetos reais para
o teste. Vrios ambientes de linguagem nesta ocasio tem frameworks que facilitam
o processo para criar objetos simulados. O que na maioria da vezes tornasse
imperceptvel, porm, os objetos simulados somente uma maneira do objeto
especfico do caso de teste, que possibilita uma forma diferente de testes.
De acordo com Beck (1999), mock object um objeto falso que imita o
comportamento de um objeto real de maneira coordenada. Mock object so
normalmente usados em testes de unidade para coordenar o funcionamento dos
objetos reais. Nesta ocasio, um objeto a menor parte testvel de um aplicativo. A
interface do componente de cdigo que se deseja imitar usada pelo mock object
para os devidos testes.
Conforme Kim (2006), as vantagens de um mock object ao invs de um
objeto real que o objeto real produzido lentamente ou de maneira ineficaz em
ocasies prticas de teste, sucede esporadicamente e trabalhoso produzir
artificialmente, alm de fornecer resultados no definitivos ele ainda no existe em
um significado prtico, ou seja, no determinado de forma principal e exclusiva a
executar testes.
Beck (1999) incentiva cita que o uso de mock object aumenta potencialmente
as vantagens do uso de TDD devido a que eleva o numero de cenrios de testes
possvel j que possvel testar isoladamente os mtodos.

10.8.1.3.

VANTAGENS DO TDD

Conforme Beck (1999), entre os diversos benefcios que o TDD pode trazer
englobam: processo de implementao simplificado, cdigo automaticamente
testvel, construo de base para teste de regresso, melhor compreenso dos
requisitos de software, confiana dos programadores na aplicao e porcentagem
relevantes de cobertura da aplicao.
Com o TDD tambm possvel obter uma melhor compreenso dos
requisitos de software devido a que, ao escrever os testes de unidade, uma clareza
de como a unidade pode se comportar construda proporo que os critrios de
sucesso vo sendo estabelecidos e as afirmativas sero codificadas. Desta forma,
um teste de unidade define corretamente quais comportamentos a unidade deve

41

possuir, e em um nvel de descrio mais fundamentado do que eventualmente um

documento de requisitos (GOLD et al., 2004);
O programador melhora seu cdigo, visto que existe uma base de testes que
assegura o desempenho esperado do cdigo implementado (KOSKELA, 2007).
Devido a maior convico o programador possui menos temor em realizar
alteraes, tornando melhor a estrutura interna do sistema. Um sistema mais bem
estruturado, por fim, torna mais simples a atividade de escrever testes.
A maneira de implementao simplificada uma vez que, o programador
tenha concludo um teste de unidade, ele apenas precisa atentar-se em faz-lo
passar. Desta forma o desenvolvedor pode somente se concentrar em uma parte do
sistema. Com isso decises so prorrogadas e no necessita ser tomadas com
antecedncia, quando at ento no h nada implementado e eventualmente no h
informaes suficientes (GOLD et al., 2004)
Por meio do processo um grupo de testes de unidade produzido. Esse
grupo de testes pode ser aplicado aps a insero de novas funcionalidades ao
sistema para constatar se nenhuma falha foi inserida, servindo como testes de
regresso (KOSKELA, 2007).
Utilizando uma abordagem de testar primeiro em pequenas
etapa atesta-se que ocasionalmente sero utilizados depuradores. Tem
conhecimento exatamente que linhas foram inseridas que fazem o teste
falhar e capaz de chegar fonte do defeito de imediato, poupando
grandes trabalhos de depurao, ato comum entre programadores.
possvel consertar falhas mais cedo, diminuindo o custo do projeto.
(Koskela, 2007).

Visto que no incio apenas deve-se criar cdigo para fazer um teste passar,
os testes tendem a alcanar uma porcentagem muito elevada de cobertura (Astels,
2010). Isso diminui a quantidade de falhas:
Possivelmente a causa nmero um para um falha entrar em
produo que no houve teste que averiguasse se uma trajetria de
execuo especfica do cdigo na realidade funciona devidamente. TDD
auxilia esse cenrio garantindo que praticamente no existe cdigo no
sistema que no seja fundamental e consequentemente executado pelos
testes. (Koskela, 2007)

Existe uma diminuio da utilidade de depuradores, o cdigo feito

automaticamente testvel a camada de unidades porque o cdigo em TDD somente
criado para fazer passar algum teste de unidade. O que no assegura que ser
testvel em camadas mais altas, como testes de sistema (MAXIMILIEN E
WILLIAMS, 2003).
Beck (1999) afirma que atravs da total cobertura de teste unitrios de uma
classe o desenvolvedor pode refazer toda a classe e garantir que aps a refatorao
a mesma no perdeu suas funcionalidades assim trazendo uma maior segurana
para o desenvolvedor no momento de efetuar alguma manuteno no software.
Segundo Beck (1999), devido ao teste continuo do cdigo, tende a diminuir o
numero de defeitos colocados no sistema durante o desenvolvimento de uma nova
funcionalidade ou correo de uma antiga funcionalidade do sistema que possua
um defeito.
Dubinsky e Hazzan (2007) afirmam que o TDD tambm possui algumas
desvantagens comparadas com outros mtodos de desenvolvimento de software.

42

10.8.1.4.

DESVANTAGENS DO TDD

Comparado forma habitual de desenvolver software, o TDD cria uma base

de cdigo de testes de unidade muito grande. Em um estudo feito para comparar a
aceitao do TDD no meio acadmico e na indstria, foi visto em um teste que, para
19 funes implementadas, o dobro de linhas de teste eram codificadas (DUBINSKY
E HAZZAN, 2007).
Wasmus e Gross (2007) citam como uma desvantagem de uma base de
cdigo grande que esta apresenta em si um gasto de manuteno, o que pode
sobrecarregar o desenvolvimento. Exemplo, pequenas mudanas de requisitos no
sistema poderem fazer alguns testes falharem, tornando uma tarefa a princpio
simples, poder difcil. Outra desvantagem citada que dependendo da dimenso do
sistema, efetuar todos os testes pode ser exaustivo e exige grande recurso do
sistema computacional.
Em virtude do aspecto gil de TDD, no concebida documentao
detalhada como de prtica nas metodologias tradicionais (DEURSEN, 2001).
Porm, pesquisas feitas afirmam que a falta de documentao formal escrita
problema para novos desenvolvedores no projeto. Os testes concederam a
documentao necessria e as informaes arquiteturais foram complementadas
por reunies rpidas com programadores (WASMUS E GROSS, 2007).
Como os testes de unidade so feitos pelo prprio programador, provvel
que um requisito no desenvolvido ou mal compreendido na implementao tambm
seja refletido nos testes. Assim, contudo mesmo que os testes estejam cobrindo o
cdigo e sendo aprovado nos testes, os mesmos esto errados, tanto o cdigo
quanto o teste devido a no ir de encontro com os requisitos e necessidades do
cliente devido a uma falha de interpretao. Esse cenrio no aconteceria se testes
de unidade estivessem sido feitos por uma equipe parte.
Em outras circunstncias, estudos prticos exibem um aumento considervel
na quantidade de falhas nos testes de aceitao. Porm o benefcio de confiana
por parte do programador promove mudanas que aperfeioe a qualidade do cdigo,
uma confiana que uma grande base de testes de unidade traz ao programador, o
que desmotivaria a criao de outros testes, como testes de sistema ou de
integrao (SINIAALTO E ABRAHAMSSON, 2007).
Beck (1999) cita que a prtica TDD pode no ser cabvel a todos os domnios
de aplicao, nem a todas as situaes, como componentes distribudos, interfaces
grficas e banco de dados. Pode existir empecilho tambm ao usar TDD em
ambientes de desenvolvimentos multi-institucionais como, por exemplo, o caso de
licitaes para contratao de fbricas de software, onde o gestor muitas vezes no
tem um contato facilmente com o programador. Isso acontece inclusive quando se
trata de metodologias geis que fazem uso de TDD, como o caso do XP.
Restries tambm podem surgir ao trabalhar com uma base maior de
cdigo. Em sistemas muito grandes devido quantidade de testes de unidade
executados a execuo frequente de todos eles pode no ser vivel. Um modo de
contornar isso criar testes agrupando-os por funcionalidade. Assim quando uma
funcionalidade for adicionada ou alterada apenas um grupo especfico precisa ser
executado, exigindo menos tempo e recursos.
Um exemplo de teste pode ser visto em seguida demonstrando uma pequena
estrutura utilizando TDD (BECK, 1999).

43

Para a aplicao do TDD necessita de uma ferramenta especifica para este

fim.

10.8.1.5.

FERRAMENTA DE TDD

O framework de teste de unidade o Junit12, um framework de cdigo livre

desenvolvido em Java por Kent Beck e Erich Gamma (BECK, 1999). Foi inspirado
no SUnit13, uma implementao de framework para testes de unidade em SmallTalk
14
feito por Kent Beck em 1998 (BECK, 1999).
O JUnit contem integrao com vrios
desenvolvimento como NetBeans, IntelliJ e Eclipse15.

ambientes

integrados

de

Com a maturao das tcnicas de teste unitrio surgiu da necessidade de

levar o TDD ao nvel de testes de aceitao buscando assim ajuda a gerar mtricas
que validem o atendimento as funcionalidades dos clientes.

10.8.2.
(ATDD)

ACCEPTANCE

TEST

DRIVEN

DEVELOPMENT

Conforme Koskela (2007), o ATDD a tcnica que amplia o uso de TDD ao

nvel de testes de aceitao ATDD ajuda a gerar sistemas que atendam s
necessidades do cliente. medida que o TDD se refere qualidade dentro do
cdigo, estrutural, o ATDD se refere qualidade externa do cdigo, a qualidade
funcional.
Segundo Koskela (2007), o modo habitual de acrescentar funcionalidades ao
sistema primeiro escrever os requisitos, executar a implementao e ento depois
o usurio pode efetuar os testes de aceitao. O ATDD muda a fase de testes para
antes da implementao. necessrio que o requisito seja relatado de forma
explcita e sem deixar duvidas, pois ele ser o modo concreto de verificar se as
exigncias do cliente foram atendidas. um processo semelhante ao TDD, somente
tratado em um nvel diferente: medida que TDD trata de comportamento de
unidades, ATDD trata de comportamento de sistema.
Para a criao de testes de aceitao so usadas histrias de usurio 16, as
mesmas utilizadas no Scrum. Para Koskela, (2007), histrias de usurio encena uma
funcionalidade do sistema e normalmente so escritas em pequenos cartes,
possuindo poucas frases. Uma histria um requisito escrito normalmente em um
pargrafo que conta a necessidade de um usurio de modo simplificado usando uma
linguagem simples do negcio.
Deve-se compreender melhor o conceito do desenvolvimento orientado a
teste de aceite (ATDD) para entender seus benefcios.

12

JUnit segundo Beck (1999) um framework de testes unitrios para desenvolvimento na linguagem Java.
SUnit conforme Beck (1999) um framework de testes unitrios para desenvolvimento na linguagem
Smalltalk.
14
Smalltalk de acordo com Beck (1999) uma linguagem de programao orientada a objeto dinamicamente
tipada.
15
NetBeans, IntelliJ e Eclipse para Beck (1999), so ambientes de desenvolvimento integrado (IDE) que oferece
aos desenvolvedores ferramentas necessrias para criar aplicativos profissionais.
16
Segundo Astels (2010), uma histria de usurio basicamente narra o assunto, o comportamento e o ator de
uma funcionalidade do software na linguagem do negcio ou cliente.
13

44

10.8.2.1.

CONCEITO DO ATDD

Todo sistema tem um tempo de vida til e uma srie de fatores podem
contribuir para aumentar ou diminuir este tempo, tais como, por exemplo,
arquitetura, modelagem, tecnologia utilizada e aceitao do mercado. Neste tempo
ou ciclo de vida, o sistema sofre vrias alteraes (SOARES, 2004).
De acordo com Sommerville (2007), os negcios atualmente operam em um
ambiente global sujeito a rpidas mudanas. Eles tm de responder s novas
oportunidades e mercados, mudanas de condies econmicas e ao surgimento de
produtos e servios concorrentes.
Diante desse cenrio, pequenas e mdias organizaes que desenvolvem
software, e que no conseguem adotar nenhum processo tradicional devido ao custo
dos recursos e falta de sistematizao, desenvolvem software de baixa qualidade.
Esses aspectos tambm contriburam para os profissionais pensarem em
novas tcnicas para o desenvolvimento de software.
De acordo com Park e Frank (2010), Kent Beck apresentou em 2003, atravs
do seu livro Test Driven Development, uma tcnica para desenvolver sistemas
baseada em testes que visa garantir a qualidade e a funcionalidade do software
durante seu ciclo de vida. Beck relata que o desenvolvimento de software dirigido
por testes de aceitao (Acceptance Test Driven Development ATDD) uma
tcnica que surgiu recentemente.
O desenvolvimento de software dirigido por histrias de usurio
transformadas em teste de aceitao uma abordagem diferente das tradicionais
geralmente adotadas por algumas empresas, pois nela tm-se os testes de
aceitao presentes logo no incio das atividades de um projeto com o objetivo de
orientar o desenvolvimento do software afirma Park e Frank (2010).
Segundo Park e Frank (2010), na engenharia de software que determina a
adoo de mtodos e prticas da engenharia de software gil, a forma dominante de
representao inicial dos requisitos so relatos do usurio. Esses relatos, tambm
denominados de histrias de usurios, normalmente so frases escritas em uma
linguagem comum que descrevem uma funcionalidade do software, e que o cliente
usa no seu dia a dia. Em mtodos geis, essas histrias so utilizadas em
substituio aos casos de uso e das especificaes de requisitos de software das
metodologias clssicas atravs de ferramentas.
Conforme Park e Frank (2010) as histrias obrigam a definir quem e o que
das funcionalidades, por exemplo, O gestor pode no aceitar o relatrio de compras
novas compras. Dessas histrias so extrados os testes de aceitao, que so
automatizadas, normalmente com o auxlio de framework de automao de testes de
aceitao, onde os mais populares so o Selenium, o Fit e o FitNesse. O ATDD no
detalha como a codificao realmente deve ser realizada, porm sugere a utilizao
de TDD.

10.8.2.2.

FERRAMENTA DE ATDD

Ferramentas de ATDD como Fit podem ser facilmente utilizada pelos clientes
e Product Owner (PO) para definir as histrias de usurio de forma precisa, e
assegurar que os programadores iro implementar exatamente o que elas
significavam devido a ferramenta utilizar uma linguagem comum a equipe e ao
cliente. Os interessados tambm podem acompanhar o estado atual e a evoluo do

45

projeto por meio da execuo dos testes de aceite na ferramenta, pois podem ver
exatamente qual funcionalidade j est implementada.
Nesta fase o foco deve ser na descoberta de requisitos, mais do que sobre os
testes reais, ou seja, o propsito das questes deve ser atender os requisitos (PARK
E FRANK, 2010).
Park e Frank (2010) citam que devido necessidade de ampliar a viso do
atendimento de todos os requisitos funcionais do software de forma automatizada e
no mais apenas os cenrios dos testes de aceitao surgiu o Behaviour Driven
Development (BDD).

10.8.3.

BEHAVIOR DRIVEN DEVELOPMENT (BDD)

Segundo North (2006), Behaviour Driven Development (BDD) surgiu da

necessidade de se mudar o foco que o TDD possui em testes. Visto que o TDD no
sobre testes, sobre projeto, ento a descrio e o modo de trabalho com
framework de teste de unidade encaminham o programador sempre ao cenrio de
testes. Isso dificulta o entendimento dos conceitos de TDD e traz imprecises na
utilizao certa da tcnica.
Em ltima instncia, BDD considerado uma evoluo de TDD, com a
principal diferena sendo a mudana do foco: de teste para comportamento. Em vez
de criar testes, o programador ir criar documentaes, descrevendo
comportamentos que o sistema deve possuir. Essa alterao na linguagem
transforma o entendimento do programador, fazendo-o perceber que ele est
documentado comportamentos e no escrevendo testes (ASTELS, 2010).

10.8.3.1.
HISTRIAS
DE
USURIO
DESENVOLVIMENTO COM O BDD

PARA

Em Astels (2010), tem-se que grupos no qual adotam metodologias geis,

fazem uma reunio com o cliente e outros envolvidos para alinhar as histrias do
projeto. Mesmo que existam algumas variaes, uma histria basicamente narra o
assunto, o comportamento e o ator de uma funcionalidade do software na linguagem
do negcio ou cliente. Essa histria prescreve cenrios que ditam o comportamento
esperado do sistema segundo o usurio ou cliente.
De acordo Astels (2010) cada comportamento ficar relatado da maneira
Given/When/Then (Dado que / Quando ocorrer / Ento vai acontecer), que a forma
usada por parte das ferramentas BDD. Deste modo a descrio ir conter um
contexto introdutrio (Given), condies (When) e um resultado previsto (Then)
conforme apresentado na tabela 2.
Given
Dado que
Contexto introdutrio

When
Quando ocorrer
Condies

Then
Ento vai acontecer
Resultado previsto

Tabela 2: Estrutura da histria em BDD.

Fonte: (ASTELS, 2010).
Mais detalhes da estrutura da histria e contextualizao sero apresentados
nas Figuras 8 e 9.
Esse detalhamento em cenrios feito quando a histria for implementada.

46

Apenas quando no sistema de BDD for detalhando todos os cenrios

relatados pode se definir a histria como concluda.
Existem diversos frameworks para BDD. Um desses frameworks o
JBehave 17 , que possibilita gerar especificaes escritas em linguagem normal. O
JBehave um plugin 18 do JUnit, framework de testes de unidade, e as
especificaes geradas para eles devem ser mapeadas para testes de unidade
reais.
Por exemplo, usando o JBehave, a especificao dos caractersticas de
aprovao de um componente de segurana escrita em linguagem normal
conforme a Figura 8.

Figura 8: Exemplo de especificao no JBehave.

Fonte: (ASTELS, 2010).
Essa documentao diz que um usurio no autenticado, quando tentar
realizar autenticao com o usurio e senha vlidos, recebe uma determinada
mensagem. Essa documentao salva em um arquivo que depois ser
interpretado pelo JBehave segundo um mapeamento. O mapeamento ensina como
o JBehave deve ler o arquivo de documentao e como gerar um teste a partir dele.
A Figura 9 ilustra um exemplo.

Figura 9: Cdigo de exemplo JBehave.

Fonte: (ASTELS, 2010).

17

Conforme Astels (2010) o Jbehave um framework de BDD para a linguagem Java.

Segundo Astels (2010) plugin uma funcionalidade extra que pode ser adicionado ao software ou
framework.
18

47

No mapeamento, as anotaes sero conferidas com a especificao e as

palavras-chave, iniciadas com $, sero extradas e utilizadas como parmetros
para os mtodos.
E necessrio estender a classe Steps 19, uma classe especfica do framework
JBehave. BDD visto por alguns como TDD feito direito". Ele pode ser comparado
juno de ATDD e TDD, uma vez que a especificao serve de teste de unidade
para o desenvolvimento do software.
Segundo Astels (2010), para entender melhor os benefcios efetivos do BDD
deve-se analisar os conceitos envolvidos por traz dele.

10.8.3.2.

CONCEITO DO BDD

Para Santos (2010), no possvel ter sucesso no desenvolvimento de

software sem uma metodologia, as tentativas resultariam apenas em uma srie de
erros. Segundo o autor, o programador codificaria, testaria algumas situaes e iria
corrigir as falhas at que o sistema superficialmente se mostre estvel. Este ciclo se
repete at que o cliente solicite mais funcionalidades ou perceba problemas na
aplicao.
Santos (2010) afirma que o BDD uma metodologia que conduz a equipe a
colocar em prtica esses dois conceitos a qual pode ser entendida por todos os
envolvidos no projeto.
Conforme Santos (2010) esta prtica usada para mostrar o comportamento
do sistema e serve como base para a execuo de testes automatizados. De modo
simplificado como mostra a Figura 10, os passos do desenvolvimento com BDD :
descrever a histrias;
detalhar o comportamento esperado da histria atravs de cenrios;
mapear o cenrio em uma classe de teste automatizado;
escrever o cdigo para que o teste seja aprovado com sucesso.

19

Segundo Astels (2010) a classe Steps e a principal classe de testes do Jbehave.

48

Figura 10: Processo de BDD

Fonte: (SANTOS, 2010).
Utilizando BDD, os procedimentos relatados acompanham um forma
padronizada
de
implementao,
por
exemplo,
Given/When/Then
(Dado/Quando/Ento), e so usadas para testes de aceitao ou de integrao.
Santos (2010) descreve que para compreendermos o BDD devemos entender
suas motivaes.

10.8.3.3.

MOTIVAO DO BDD

Segundo North (2006), o BDD uma melhoria do TDD. O mesmo foi criado
com a finalidade de simplificar o entendimento de TDD para aqueles que esto
iniciando o desenvolvimento dirigido por testes e mais eficaz que a mtodo que a
originou devido a que o BDD uma prtica na qual o principio est em avaliar o
comportamento do sistema e no apenas em gerar testes. Sendo assim os testes
passam ser apenas uma consequncia bsica para garantir que o seu sistema
funcione de acordo com as histrias e com os critrios de avaliao levantados.
Para North (2006) uma das vantagens do BDD para o projeto gil orientar
os desenvolvedores na criao dos testes. No haver mais questes como:
Por qual perodo devo testar?
O que realmente devo testar?
Que nome atribuir ao teste criado?
O principal objetivo est em testar o que interessa para o usurio e comprova
que o sistema funciona de acordo com as suas expectativas. No haver mais
necessidade de encontrar o que deve ser testado, as histrias e os requisitos de
aprovao informaram isso para os programadores.
Em North (2006) cita-se como beneficio que os testes estaro centralizados
agregando valor no que importa para o usurio e, consequentemente, o tempo
usado na criao dos testes trar grandes benefcios e clareza no projeto. A
qualidade do sistema ter um avano e a experincia do usurio ser positiva. O
49

BDD vem de encontro a mapear e validar continuamente se os requisitos esto

sendo atingido e se um novo desenvolvimento no gerou impacto negativo em uma
funcionalidade que j existia no sistema.
O desenvolvimento de BDD se compara muito ao fluxo de TDD. Utiliza as
histrias, como mostra a Figura 11 e possibilita discernir a parte que desempenhar
uma funcionalidade a procura de um resultado.

Figura 11: Histria exemplificando um relatrio de vendas

Fonte: (Santos, 2010).
O processo de desenvolvimento usando BDD deve ser auxiliado por
frameworks como o JBehave. Utilizado para desenvolvimento de BDD em Java, ele
possibilita criar os testes fundamentado na descrio textual do que deve ser
testado.

10.8.3.4.

FERRAMENTA PARA BDD

Santos (2010) cita que o JBehave foi o primeiro framework BDD para
linguagem Java e afirma que um dos mais utilizados atualmente. Ele realiza a
leitura dos cenrios das histrias para executar testes automatizados que so
implementados em cdigo de linguagem Java. Como resultado, o JBehave cria um
relatrio com as histrias e indica as falhas que foram encontradas.
O contedo do arquivo igual aos cenrios descritos anteriormente, sendo as
nicas diferenas o formato do texto e a substituio de Dado/Quando/Ento para
Given/When/Then.
Ainda Santos (2010) cita que na linguagem Java, cada passo do arquivo texto
representado por intermdio de um mtodo que possui a annotation 20 @Given,
@When ou @Then e define o que o JBehave deve executar. A implementao
desse cdigo similar criao de testes unitrios com o JUnit.
20

A annotation, segundo Deitel (2005), um recurso da Plataforma Java, introduzido como padro de
linguagem na verso 1.5, fornece a opo do uso de metadata ao longo do cdigo que podem ser
posteriormente interpretadas por um compilador ou pr-compilador que ir realizar alguma tarefa prdefinida.

50

Para Santos (2010) o papel do JBehave ser um elo entre a descrio da

histria e o cdigo de testes. Por isso, para programar os testes automatizados so
necessrias outras ferramentas para validaes, automatizar operaes dos
navegadores 21, criar mock object, entre outros. (Santos, 2010)
Ainda o autor cita que devido dificuldade de automatizar testes de aceitao
em aplicaes web, muitas vezes os desenvolvedores focavam somente nos testes
unitrios e os testes de aceitao tinham que ser executados manualmente por uma
equipe de testes. O grande problema que o custo de executar esses testes
manualmente alto, e a equipe de testes poderia estar focada em outros fatores
essenciais, como testar a segurana e o desempenho do software.
Para Santos (2010), outro framework amplamente utilizado Cucumber,
segundo o autor, um framework de alto nvel para testes automatizados.
Utilizado o Cucumber para testes de aceitao, ele possibilita descrever uma
histria e implementar o cdigo de acordo com a mesma. O Cucumber
considerado um framework de alto nvel porque, diferentemente do Rspec 22 no
utiliza somente cdigo Ruby em sua descrio de funcionalidades, mas utiliza a
linguagem formal como, por exemplo, o ingls.
O framework Cucumber assim como o JBehave se preocupa em testar o
comportamento do sistema na viso do usurio. Existe uma grande diferena de
testar uma funcionalidade isolada com o TDD e testar a funcionalidade com o
Cucumber. Este ltimo faz algo muito parecido com o que antes era chamado de
teste de caixa preta, ou seja, testar o comportamento da aplicao, como ela reage
e qual sua resposta sem saber em certo qual o cdigo responsvel por este
comportamento.
Por ser especificaes em texto claro, criar uma funcionalidade no Cucumber
para algum que no conhece linguagem de programao algo possvel. A forma
como se pode organizar o pensamento de fcil entendimento para ambas as
partes. vlido lembrar que os testes com o framework no substituem os testes
unitrios.
A garantia de atendimento dos requisitos diretamente ligada qualidade do
software. A qualidade do software a um fator primordial para a sobrevivncia das
empresas de software no mercado. As empresas mais sensveis aceitao ou
negativao do mercado so as startups de software. Caso o mercado no responda
bem a este tipo de empresa ou se feche por um instante pode facilmente lev-la a
falncia.

10.9. STARTUP
Conforme Gitahy (2011) foi na dcada de 90 que o empreendedorismo
startup popularizou-se. No Brasil, passou a ser conhecido somente a partir de 2000,
no surgimento das empresas de software no mercado eletrnico.
Atualmente o termo startup muito utilizado pelos empreendedores, mas
poucos conhecem o real significado da palavra; start do ingls, que significa
iniciar em portugus, e up tambm do ingls, que significa para cima em
portugus (GITAHY, 2011).

21

De acordo com Santos (2010), o navegador um programa de computador que habilita seus usurios a
interagirem com documentos virtuais da Internet.
22
RSpec segundo Astels (2010), uma ferramenta de teste para a linguagem de programao Ruby.

51

A palavra startup hoje atrelada diretamente a inovao e ao

empreendedorismo, e recorda empresas como: Apple, Google Inc, Facebook,
Yahoo, e outras afins, que cresceram positivamente e se destacaram no mercado
em que atuam e hoje esto em posies de liderana.
Sobre o conceito de empreender, Johnson (2001) cita que a arte de
empreender requer dedicao e foco no que tange o seu negcio. preciso ter
iniciativa, assumir responsabilidade e fazer as coisas acontecerem por meio da
criatividade, da administrao dos riscos inerentes ao processo e da habilidade de
enxergar o futuro como uma oportunidade de negcios inovadores, at mesmo
quando se enfrenta obstculos e dificuldades. Assim, compreende-se que um
empreendedor startup v a empresa como algo que seu, a qual este dedica se
intensamente, sempre em busca do seu objetivo, sem colocar limites e barreiras no
processo de empreender efetivamente seu modelo de negcio.
De acordo com Dornelas (2008), o motivo de o empreendedorismo ter se
intensificado somente agora, foi o avano tecnolgico que necessita de um nmero
maior de empreendedores. Diante desta, este avano e essa fase de mutao, fora
as novas empresas e os novos empresrios a adotarem novos paradigmas, assim
atuando em novos mercados por via do empreendedorismo startup.
H diversas conceituaes para o que uma empresa startup.
Startup so as empresas de pequeno porte, recm-criadas ou
ainda em fase de constituio, com atividades ligadas pesquisa e
desenvolvimento de ideias inovadoras, cujos custos de manuteno
sejam baixos e ofeream a possibilidade de rpida e consistente gerao
de lucros. (HERMANSON, 2011).

Ainda Hermanson (2011), destaca que uma startup no obrigatoriamente

apenas empresas da rea tecnolgica, ao oposto, toda e qualquer empresa na
etapa de formao. Este tipo de empreendedorismo ocorre mais na rea da
tecnologia devido a que os custos so menores para criar uma empresa de software
do que para comear um comercio ou indstria.
Startup um modelo de empresa jovem ou embrionria em fase
de construo de seus projetos, que esta atrelada fortemente pesquisa,
investigao e desenvolvimento de ideias inovadoras (GITAHY, 2011).

Contudo GITAHY (2011) complementa:

Startup um grupo de pessoas procura de um modelo de
negcios repetvel e escalvel, trabalhando em condies de extrema
incerteza (GITAHY, 2011).

Baseando-se neste pensamento, o empreendimento ser denominado uma

startup, desde que seja comprovado que o modelo de negcios adotado seja
receptvel e escalvel, mesmo que esteja em um cenrio de incerteza; este cenrio
trabalha como se fosse uma taxa de juros do investimento, que torna atraente o
negcio aos investidores.
O termo receptvel e escalvel citado por Gitahy (2011) no significado de
ser capaz de produzir um igualitrio produto ou servio em grande escala, sem que
o mesmo sofra customizaes para cada tipo de cliente e que o negcio possa fazer
crescer sua receita, sem que os custos acompanhe esse crescimento, ou seja, os
custos da sua escalabilidade devem crescer lentamente.
Startup so pequenas empresas montadas em casa ou em
faculdades e que recebem pequenos aportes de capital. Elas exploram
reas inovadoras de determinado setor (mais comumente a de

52

tecnologia), possuindo uma acelerao de crescimento muito alta j nos

primeiros meses de existncia em virtude de investimentos feitos por
fundos de investimento especializados (LONGHI, 2011).

Startup segundo Longhi (2011) a definio mais prxima da situao atual,

a cada dia mais comum esse tipo de empreendimento inicie em casa, ou at na
garagem. Este um exemplo de empreendimento que inicia com custos reduzidos e
se mantm reduzidos mesmo que a empresa esteja consolidada no mercado.
Conforme Hermanson (2011), o empreendedorismo de startup se faz desigual
do empreendedorismo corporativo, pelo motivo que estes so negcios recmcriados, esta na etapa de desenvolvimento e pesquisa de mercado, tem alto risco
envolvido no negcio, to quanto serem negcios com baixos custos iniciais e
tambm ser altamente escalvel. Tal tipo de empreendedorismo se caracteriza pela
criao de riqueza, aquisio de investimento junto a capitalistas de risco,
elaborao de estratgias e culturas organizacionais, inexistncia de regras,
aplicao no horizonte de curto prazo e percepo na utilizao de estratgias
rpidas.
Para Dornelas (2008) o empreendedor de startup, como o empreendedor
corporativo tambm aficionado pelo o que faz porem ambos possuem o grau de
paixo diferente, segundo ele, exagero admitir que o empreendedor corporativo
enxergue a organizao como algo que dele, a no ser que, seja oferecida a
possibilidade de retornos pelos riscos assumidos. No entanto o empreendedor de
startup tem prazer em executar o acontecer, deslumbrado pela ideia e por isso
possui altos riscos ao defend-la.

53

11.

APLICAO DO TRABALHO

Para exemplificao da aplicao das tcnicas geis de teste sero

apresentados exemplos prticos do uso das mesmas. Estes exemplos tm por
finalidade mostrar como as ferramentas funcionam, seus processos de configurao
e estrutura para utilizao destes frameworks. Possui tambm como objetivo o
estudo e treinamento das equipes para o primeiro contato com as ferramentas e
deve ser evoludo para o tipo de soluo de cada empresa. Estes exemplos podem
mostrar como efetivamente a aplicao das tcnicas geis de teste de software
podem ser utilizadas no processo de desenvolvimento, manuteno e evoluo do
software das startups.
Para os exemplos deste desenvolvimento foram utilizados os seguintes
frameworks:

JUnit para o desenvolvimento com TDD.

Fitnesse para o desenvolvimento com ATDD.

Cucumber-jvm para o desenvolvimento com ATDD.

Foram escolhidos estes frameworks devido a que so os pioneiros em suas

reas de aplicao para a linguagem Java e consequentemente os mais conhecidos.
Seu uso amplamente incentivado pela comunidade.

11.1.

EXEMPLO DE TDD

Como exemplo prtico de TDD implementa-se um estudo de caso sobre um

estabelecimento denominado estacionamento privado.
As necessidades apresentadas pelo cliente para o funcionamento do
estacionamento so:
o estacionamento deve conter 300 vagas disponveis.
o estacionamento deve permitir a entrada de um carro no caso de existir ao
menos uma vaga disponvel no estacionamento.
o estacionamento deve atualizar a vaga que antes estava ocupada para
disponvel ao carro que lhe ocupava sair do estacionamento.
Como primeiro passo para implementao utilizando a IDE Eclipse e o
framework JUnit cria-se o projeto estacionamento privado e sua respectiva classe
em JUnit chamada EstacionamentoTest conforme a Figura 12.

54

Figura 12: Classe EstacionamentoTest

Fonte: (AUTORIA PRPRIA, 2013).
A classe EstacionamentoTest contm os as validaes que cada regra
colocada pelo cliente foi apresentada.
Como passo a passo do TDD cria-se os mtodos que deveram ser testados
posteriormente, ento criado o primeiro mtodo que define que o estacionamento
deve conter 300 vagas disponveis Figura 13.

Figura 13: Criao dos mtodos

Fonte: (AUTORIA PRPRIA, 2013).
55

O teste implementado devem ser executados com a informao de que eles

falharam, isso ocorre por que a classe Estacionamento ou seus mtodos ainda no
foram implementados Figura 14.

Figura 14: Teste falhando

Fonte: (AUTORIA PRPRIA, 2013).

Devido a falha dos testes executados o procedimento a ser seguido fazer o

teste ser aprovado para isso necessrio que a classe Estacionamento seja criada
e o mtodo getVagasDisponiveis Figura 15.

56

Figura 15: Criao da classe Estacionamento

Fonte: (AUTORIA PRPRIA, 2013).
Agora que a classe foi criada e esta sendo executada com sucesso feita a
ltima etapa do ciclo de que fazer a refatorao conforme apresentado na Figura
16.

Figura 16: Refatorao da classe Estacionamento

Fonte: (AUTORIA PRPRIA, 2013).

57

Na medida em que os problemas vo sendo guiados pelos testes e passo a

passo so resolvidos a complexidade vai aumentado, porm com a vantagem de
que os mtodos esto sendo cobertos por testes individuais que quando os testes
so aprovados em sua execuo garantem que a funcionalidade no possui
defeitos.
Na Figura 17 apresenta-se a classe EstacionamentoTest com as 3 regras
implementadas.

Figura 17:
implementadas.

Classe

EstacionamentoTest

com

as

Trs

regras

Fonte: (AUTORIA PRPRIA, 2013).

Na Figura
implementados.

18

classe

Estacionamento

com

seus

trs

mtodos

58

Figura 18: Classe Estacionamento com os mtodos implementados.

Fonte: (AUTORIA PRPRIA, 2013).

Por fim as classes sendo executadas e mostrando na IDE Eclipse atravs do

framework JUnit, o resultado na cor verde indicando que os testes passaram Figura
19.

Figura 19: JUnit informando que os testes passaram

Fonte: (AUTORIA PRPRIA, 2013).

59

11.2.

EXEMPLO DE ATDD

Como exemplo prtico de ATDD implementa-se um estudo de caso baseado

em um calculo simples de soma.
A histria descrita pelo cliente para funcionamento do calculo :
Como usurio do sistema devo apresentar dois nmeros e ter a soma destes
dois elementos.
Como primeiro passo para implementao utilizando a IDE Eclipse cria-se o
projeto que recebe o nome de Projeto ATDD, esse projeto tem que ser gerado
seguindo os seguintes passos:
1. Clicar em New.
2. Clicar em Dynamic Web Project.
3. Coloca-se o nome do projeto conforme a Figura 20.

Figura 20: Criao do projeto ProjetoATDD.

Fonte: (AUTORIA PRPRIA, 2013).

60

Criado o projeto a prxima etapa a criao da classe que conter a

implementao solicitada pelos stakeholders, a classe se chamar
CalculadoraSimples conforme a Figura 21.

Figura 21: Criao da classe CalculadoraSimples.

Fonte: (AUTORIA PRPRIA, 2013).

A implementao segue em uma codificao simples onde o objetivo que o

usurio possa fornecer dois nmeros e atravs de um mtodo o mesmo possa
informar o resultado da soma destes dois nmeros conforme apresentado na Figura
22.

Figura 22: Implementando a classe CalculadoraSimples

Fonte: (AUTORIA PRPRIA, 2013).

61

Com a implementao feita podemos validar se o desenvolvimento est de

acordo com o que foi solicitado pelo cliente utilizando o Framework Fitnesse. Para
inici-lo devemos abrir o prompt de comando e navegar at o diretrio onde se
encontra o jar da ferramenta, apresentado na Figura 23.

Figura 23: Inicializando o framework Fitnesse.

Fonte: (AUTORIA PRPRIA, 2013).

Feita a inicializao do Fitnesse basta acessar a URL localmente para

confirmao do servio rodando, conforme apresentado na Figura 24.

Figura 24: Servio do Fitnesse ativo.

Fonte: (AUTORIA PRPRIA, 2013).

62

Prxima etapa criar um teste para validao da regra, os critrios de aceite

para criao do teste so:
1. Declarar o import da classe a ser analisada pelo framework Fitnesse.
2. Declarar o caminho onde se encontra a classe.
3. Declarar na mesma sentena as variveis e posteriormente possveis
valores a serem testados.
4. Declarar o mtodo que ser executado os resultados esperados que
foram passados por parmetro no item 3. Passos apresentado na Figura 25.

Figura 25: Criando critrio de aceitao.

Fonte: (AUTORIA PRPRIA, 2013).

Tendo os critrios de aceitao definidos, clica-se em salvar uma forma de

tabela gerada. Apresentado na Figura 26.

63

Figura 26: Critrio de aceite salvo e visualizao da tabela.

Fonte: (AUTORIA PRPRIA, 2013).

Por fim iremos executar o teste clicando no boto Test e aguardar o feedback
do Fitnesse, ele busca a classe especificada e ir realizar os teste utilizando como
paramento os valores informados na tabela e tambm valida os resultados baseados
nos valores esperados inseridos no mtodo que ir ser testado. Dados apresentado
na Figura 27.

Figura 27: Execuo dos testes e feedback do framework.

Fonte: (AUTORIA PRPRIA, 2013).

11.3.

EXEMPLO DE BDD

Como exemplo prtico de BDD implementa-se um estudo de caso baseado

no exemplo anterior do Estacionamento Privado.
64

A histria descrita pelo cliente como funcionamento do Estacionamento :

Como gerente do estacionamento eu devo cadastrar veculos para que tenha
controle de nmeros de vagas disponveis no estacionamento.
Como primeiro passo para implementao utilizando a IDE Eclipse e o
framework Cucumber criar a feature que recebe o nome de
gerencia_estacionamento com a extenso .features. Esse arquivo tem que ser
gerado seguindo os seguintes passos:
4. Clicar em New.
5. Clicar em File.
6. Coloca-se o nome do arquivo com sua extenso conforme a Figura 28.

Figura 28: Criao da funcionalidade.

Fonte: (AUTORIA PRPRIA, 2013).

Posteriormente
deve-se
escrever
a
histria
no
arquivo
gerencia_estacionamento.feature criada, transformando-os em cenrios do BDD,
cada cenrio sempre iniciados pelas palavras chave: Dado, Quando, Ento
reconhecidas pelo framework, essas palavras so escritas como mostra a Figura 29.

65

Figura 29: Escrevendo o cenrio

Fonte: (AUTORIA PRPRIA, 2013).

Criado o cenrio com os critrios de aceitao definidos pelos stakeholders

preciso criar uma classe que ir fazer o framework ler esse e executar estes
cenrios, a classe que vai executar o teste se chama ExecutaTestes.java conforme
mostra a Figura 30.

Figura 30: Criao da classe ExecutaTestes.java

Fonte: (AUTORIA PRPRIA, 2013).
A classe executada, devido a validao ainda no estar implementado o
teste falha, o framework informa o motivo da falha conduzindo o programador a
implentar as validaes nos mtodos segundo o cenrio descrito prviamente
conforme apresenta a Figura 31.
66

Figura 31: Classe falha e a informao e exibida no console

Fonte: (AUTORIA PRPRIA, 2013).

Com a instruo do status atual das validaes e as histrias escritas em

linguagem comum deve ser criada a classe contendo o cdigo que far o
desenvolvimento da funcionalidade do software que atenda a necessidade da
histria, esta etapa direciona o desenvolvedor com conhecimento da regra de
negocio criar funcionalidade que realmente agregam valor ao cliente tornando a
tarefa mais clara, objetiva e testvel, com uma documentao funcional.
Essa classe pode se chamar EstacionamentoSteps e dentro do conceito da
utilizao da classe Steps, que conforme descrito, serve como a principal no
desenvolvimento do BDD, faz com que os passo que so apresentado no BDD se
tornem validados no desenvolvimento. Apresenta-se um exemplo na Figura 32.

67

Figura 32: Criao da classe steps.

Fonte: (AUTORIA PRPRIA, 2013).

Aps a execuo do teste pode-se visualizar no console, o resultado do teste

informando quais cenrios foram escritos, quantos cenrios foram executados,
quantos passos (Steps) foram aprovados ou ficaram pendentes nas validaes,
conforme apresentado na Figura 33.

Figura 33: Classe executada com sucesso.

Fonte: (AUTORIA PRPRIA, 2013).

11.4.
APLICAO DE PRTICAS GEIS DE
DESENVOLVIMENTO DE SOFTWARE EM STARTUP

TESTE

Percebe-se que conceitualmente a utilizao de metodologias geis de

desenvolvimento vem ser uma estratgia para reduo de custo, ganho de
68

produtividade, e foco em resultado, comparando as metodologias tradicionais como,

por exemplo, o CMMI, com metodologias geis, como o XP, percebe se que as
metodologias geis utilizam-se de equipes reduzidas, formadas de profissionais
multifuncionais, no sendo necessria uma pessoa para cada papel do processo.
Por exemplo, no XP o desenvolvedor tambm a pessoa que escreve os testes e
testa os sistemas, no havendo a necessidade de uma pessoa somente para testes.
Outro item relacionado documentao, o XP impulsiona a documentar somente o
necessrio, enquanto que no RUP h uma lista extensa de modelos documentos,
um para cada atividade especifica do processo.
Avaliando os benefcios da adoo das tcnicas geis de teste,
principalmente a questo sobre a reduo de custos para as empresas que aplicam
as tcnicas de teste antecipado (TDD) e garantia de efetiva codificao dos
requisitos (ATDD e BDD), em que por meio do TDD se trabalha de forma preventiva
no tratamento de possveis defeitos que poderiam ir para a produo, tanto nas
novas funcionalidades, quanto em correes ou alteraes de funcionalidades j
existentes no sistema, no que diz respeito ao BDD, este traz a garantia que
nenhuma funcionalidade j anteriormente entregue ao cliente parou de funcionar
durante a implantao de uma nova funcionalidade ou correo do sistema. J que
para cada funcionalidade deve-se ter um teste de aceite. Conforme Myers (2004),
quaisquer dos defeitos do software teriam seu custo de correo aumentado
exponencialmente caso fossem identificados somente no ambiente de produo.
No se deve ignorar o fato de que h outros fatores que influenciam para o
sucesso de uma empresa startup de software, porm, prevenir custos de retrabalho,
reduzir o custo do desenvolvimento e aumentar a qualidade do produto final so
alguns passos que tende a levar a empresa ao sucesso.
As tcnicas geis de teste de software afirmam-se como alternativas para
trilhar o caminho do sucesso tratando em termos de qualidade, atendimento aos
requisitos e documentao funcional pois oferecem uma srie de prticas que
convergem para este fim.

69

12.

ESTUDO DE CASO

Nesta seo ser detalhado o estudo de caso tal como suas consideraes
cientificas, aspectos tcnicos e os resultados obtidos.

12.1.

PROBLEMATIZAO

No cenrio predecessor a aplicao das tcnicas geis de teste a etapa de

definio dos critrio de aceite das tarefas e a aplicao dos testes em si
executada apenas no final do processo, quando o sistema j est pronto, a
documentao dos requisitos do sistema elaborada na etapa de anteprojeto, e no
alterada depois daquele momento durante todo o processo de desenvolvimento do
software, os requisitos so armazenados de forma esttica, e no possuem nenhum
vinculo ou rastreabilidade com o cdigo fonte. O conceito de teste de unidade
inexistente, devido a que a viso dentro do processo de que o menor entregvel
valido uma funcionalidade e no um item menor, como um modulo por exemplo.
Conforme relatos da empresa, este cenrio acarretava em um maior custo de
produo devido principalmente as falhas que eram reportadas na etapa final do
processo e seu processo de engenharia reversa para correo e reteste. Outro
problema reportado era sobre o desalinhamento entre o solicitado nos requisitos e o
que foi codificado efetivamente.Identificava se que os termos de aceite no eram de
uma linguagem comum a todo os stakeholders.
A ideia de utilizar-se de algumas metodologias e tcnicas geis surge devido
que estas mais alinhadas ao cenrios atual da empresa startup estudada, que
possui recursos financeiros finitos e uma equipe tcnica reduzida.
Conforme expectativa da diretoria a aplicao de testes geis de software
vem de encontro reduo de custo do processo de desenvolvimento, manuteno
e evoluo do software como tambm o aumento de produtividade efetiva da equipe.
Foi definido a adequao do processo atual de desenvolvimento da empresa para
ser possvel aplicar as tcnicas geis de teste e ser validar se o resultado vem de
encontro com a expectativa da diretoria.

12.2.

ABORDAGEM TCNICA

Com a definio da implantao das tcnicas de teste geis, foi definido um

novo processo de trabalho com a aplicao das praticas geis de teste. A parte
inicial do processo apresentado na Figura 34 definindo em que parte do processo
as estrias, testes de aceite e testes funcionais sero cadastrados nas ferramentas
de ATDD e BDD.

70

Figura 34: Processo de planejamento da Sprint arquitetado pela equipe.

Fonte: (AUTORIA PRPRIA, 2013).

De acordo com o novo fluxo do processo de planejamento da Sprint

apresentado na figura 37, as ideias so recebidas pelos clientes e filtradas pelo
mercado. As mesmas so analisadas pelo product owner em par com a diretoria
estratgica, caso a ideia no seja aprovada para o produto, a mesma armazena
em uma em um arquivo de ideias, caso ela for aprovada para codificao, ela
comparada com as outras atividades j existentes no backlog do produto para ento
ser definido sua prioridade com as outras tarefas, depois de definido a prioridade a
ideia definido sua histria de usurio, seus critrios de aceite e cenrios de teste
durante a sua elaborao e validao. Posteriormente a ideia cadastrada em
forma de tarefa na ferramenta Jira que o BPMN utilizado pela empresa e
qualificada com sua devida prioridade. Por ultimo a histria e seus critrios de aceite
so cadastrados na ferramenta de BDD e seus cenrios de testes bsicos so
cadastrados na ferramenta de ATDD.
Com a adoo de tcnicas geis de teste foi necessrio tambm adequar o
processo de desenvolvimento de software. Na figura 36 apresentado o antigo
processo de desenvolvimento da empresa e na figura 37 apresentado o processo
j com as adequaes necessrias.
No processo de desenvolvimento j utilizado pela empresa apresentado nas
figuras 36 e 35, ao iniciar a Sprint as tarefas era colocadas na coluna TO DO do
Kambam da equipe de acordo com sua prioridade, de cima para baixo, o
programador ficava encarregado de movimentar a tarefa para o DOING sinalizando
que ela estava em execuo por ele, neste momento a ferramenta de BPMN
71

executa a criao do branch de desenvolvimento da tarefa de forma automtica

atravs de um servidor de integrao continua. Ao finalizar a tarefa, deve executar o
Commit o cdigo fonte da tarefa e movimentar l para o DONE sinalizando que a
tarefa j est pronta para ser testado, neste momento o servidor de integrao
continua identifica qual o branch foi enviado para teste e j efetua a publicao
isoladamente para teste.
O testador fica designado a movimentar a tarefa para TEST e executar os
cenrios de teste pr-definidos escritos na tarefa durante o passo de planejamento e
reviso da tarefa, caso o teste reprove, a tarefa deve voltar para o TO DO para que
o programador possa efetuar as correes necessrias. No cenrio do teste ser
aprovado, a testador deve movimentar a tarefa para o deploy, assim disparando a
rotina que executa automaticamente o merge do cdigo fonte desta tarefa com o
cdigo fonte do resto do sistema, no final do processo de merge, o servidor de
integrao continua publica a tarefa no ambiente de homologao, ao prximo do
final da Sprint, no momento em que todas as tarefas j estiverem publicadas para
homologao, o testador deve executar um teste de regresso, assim executando
todos os cenrios de testes existentes para o produto, validando todas as
funcionalidades do produto e analisando se nenhuma funcionalidade foi impactada
com um dos novos desenvolvimentos, caso acontecer de houver impactos, dever ser
cadastradas tarefas dentro da Sprint para efetuar as correes necessrias, estas
tarefas devem seguir todo o processo de desenvolvimento de software. Ao finalizar
todas as tarefas e o sistema ser aprovado no teste de regresso, deve ser gerado o
rotulo da nova verso do sistema, mapeado ao release notes, assim identificando
quais defeitos no software foram corrigidos e quais novas funcionalidades foram
agregadas e posteriormente deve ser publicado o sistema em produo.

72

Figura 35: Kambam do antigo processo de desenvolvimento Flexy.

Fonte: (AUTORIA PRPRIA, 2013).
73

Figura 36: Antigo processo de desenvolvimento.

Fonte: (AUTORIA PRPRIA, 2013).

74

Figura 37: Novo processo de desenvolvimento.

Fonte: (AUTORIA PRPRIA, 2013).

75

Conforme a figura 37 visvel que no se fez necessrio reestruturar todo o

processo de desenvolvimento utilizado pela empresa, apenas adequ-lo para a
aplicao das tcnicas geis de teste. Durante o processo de execuo da
codificao da tarefa (DOING) o programador agregou a atividade de elaborar o
TDD da tarefa executada como tambm a codificao da vinculao dos testes
criados aos critrios de aceite da tarefa ATDD e histria de usurio BDD, por ultimo
deve efetuar o Commit dos testes juntamente com o cdigo fonte da tarefa. Ao
programador movimentar a tarefa para o DONE executado de forma automtica
os testes unitrio e de aceite da tarefa especifica. Caso algum destes testes falhar, o
programador ser notificado via e-mail. No momento em que a tarefa for aprovada
pelo testador, prosseguido do merge do cdigo fonte da tarefa com o cdigo fonte do
sistema, executado de forma automtica todos os testes vinculado, ao sistema,
sejam unitrio, de aceite ou de negcio. Caso algum destes falhar, a equipe
receber um e-mail notificando sobre o impacto do merge da tarefa no sistema.
Ao final da Sprint, aps a publicao das novas funcionalidades para
homologao, todos os testes, sejam unitrios, de integrao, de aceite ou de
negcio so executados de forma automtica pelo servidor de integrao continua
para validar se no houve nenhum impacto referente o ambiente no sistema.
Defino a reestruturao do processo, se faz necessrio ampliar a gama de
maquinas e ferramentas utilizado pela empresa como tambm orar os custos
envolvidos na implantao das tcnicas de teste geis.

12.3.
DEFINIO DOS PARAMETROS QUALITATIVOS DOS
DADOS
Os dados analisados foram coletados atravs entrevistas com a diretoria em
um primeiro momento. No segundo momento questionrios objetivos
disponibilizados de forma online aplicados a diretoria, desenvolvedores, PO, analista
de teste e clientes. Em uma terceira e ultima etapa, a coleta das mtricas do projeto
e processo.
Para obter-se a concluso foi filtrado os resultados utilizando estatstica de
soma direta dos resultados de respostas obtidos atravs dos questionrios aplicados
e analise comparativa do histrico de entregas realizadas.
De acordo com um estudo de mercado efetuado pela equipe da Flexy, foi
definido as ferramentas que sero agregadas ao processo para complementarem a
adoo das tcnicas geis de teste conforme apresentadas na tabela 3. Esto fora
do escopo de analise as ferramentas j utilizadas pela empresa como Jira Atlassian,
Jenkins CI, Sonarqube e Git SCM.

76

Quantidade

Aplicao

Tipo

Fonte

Custo

Servidor para
testes

Estrutura
ECM
amazon aws
On Demand

https://aws.amazon.com/pt/ec2/ USD
~40,00
Mensais

Gerenciamento
e execuo do
ATDD

Ferramenta
Fitnesse

http://www.fitnesse.org/

USD 0,00

Gerenciamento
e execuo do
TDD

Ferramenta
Junit

http://junit.org/

USD 0,00

Rodas os testes
codificados em
Selenium

Ferramenta
Driver
Selenium

http://docs.seleniumhq.org/

USD 0,00

Gerenciamento
e execuo do
BDD

Ferramenta
Cucumber

http://cukes.info/

USD 0,00

Tabela 3: Ferramentas que sero agregadas ao processo para

complementarem a adoo das tcnicas geis de teste.
Fonte: (AUTORIA PRPRIA, 2013).
A tabela 4 apresenta o custo bruto da mo de obra Flexy. Foi repassado pela
diretoria da empresa para ser usada como base no calculo dos custos envolvidos na
implantao das tcnicas de testes geis.
Funo

Valor Hora (custo total)

Programador

R$ 250,00

Testador

R$ 250,00

Arquiteto de Infraestrutura

R$ 250,00

Tabela 4: Custo de mo de obra Flexy.

Fonte: (AUTORIA PRPRIA, 2013).
Com as ferramentas e novos fluxos de trabalho definidos, se faz necessrio
estimar o tempo e custo direto da adequao ao processo da Flexy como apresenta
a tabela 5.

77

Tarefa

Pessoa

Horas estimadas

Total

para adequao
Configurao e

Programador

12 horas

R$3.000,00

implementao da
arquitetura.
Tabela 5: Estimativa de tempo e custo direto da adequao ao processo
da Flexy.
Fonte: (AUTORIA PRPRIA, 2013).
Com o custo de adequao da arquitetura definido, se faz necessrio definir o
custo de manuteno mensal da arquitetura como apresenta a tabela 6.
Tarefa
Mensalidade

Custo Mensal
arquitetura R$ 80,00

Total
R$ 80,00

Cloud AWS (EC2 medium)

Tabela 6: Custo de manuteno mensal da arquitetura.
Fonte: (AUTORIA PRPRIA, 2013).
Com todos os custos pr-definidos, se faz necessrio a definio do
cronograma de planejamento da implantao das tcnicas geis de teste para
acompanhamento e analise do andamento do processo como tambm dos
resultados apresentados conforme apresentado na tabela 7.
Atividade

Data inicio

Definio

dos

indicadores

que

Data fim

Horas previstas

02/06/2013

02/06/2013

8 hrs

14/06/2013

15/06/2013

16 hrs

novo

16/06/2013

17/06/2013

16 hrs

da

17/06/2013

18/06/2013

16 hrs

da

19/06/2013

20/06/2013

16 hrs

Codificar piloto TDD

21/06/2013

22/06/2013

16 hrs

sero analisados
Coleta de mtricas
do processo atual
Definio

do

processo
Definio
arquitetura
Implementao
arquitetura

78

para treinamento
Codificar piloto ATDD

23/06/2013

24/06/2013

16 hrs

25/06/2013

26/06/2013

16 hrs

27/06/2013

01/07/2013

24 hrs

02/07/2013

02/12/2013

5 meses

03/12/2013

04/12/2013

16 hrs

05/12/2013

05/12/2013

4 hrs

06/12/2013

06/12/2013

8 hrs

07/12/2013

07/12/2013

4 hrs

para treinamento
Codificar piloto BDD
para treinamento
Repasse

de

conhecimento
treinamento

e
da

equipe
Acompanhamento da
equipe na utilizao
tcnicas
Coleta de mtricas
do novo processo no
sistema
Coleta de mtricas
do novo processo na
equipe
Analise
comparao

e
dos

resultados
Apresentar parecer a
equipe e a gerncia
Tabela 7: Cronograma de implantao e avaliao das tcnicas geis de
teste.
Fonte: (AUTORIA PRPRIA, 2013).

Com o cronograma definido, se faz necessrio definir os critrios que sero

utilizados na analise dos resultados anteriormente e posteriormente a implantao
das tcnicas geis de teste. Atravs de consulta de mercado os critrios de
avaliao foram firmados em:
- produo em pontos de funo por Sprint, j que um indicador chave para
medir a produtividade da equipe.

79

- numero de tarefas de suporte a produo cadastradas ao ms, que

considera-se um indicador muito eficaz para medir se os produtos tem sado da
fabrica de software com extrema qualidade.
- tempo mdio do ciclo de vida de tarefas de suporte a problemas de
produo, para medir se a implantao das tcnicas geis de teste efetivamente
auxiliaram em um ganho de produtividade.
- numero de rejeies reportadas na Sprint atravs das ferramentas de teste
gil, para validar se as tcnicas de teste gil efetivamente esto cumprindo seu
papel de manter uma qualidade plena no produto atravs de uma larga cobertura
com testes automatizados.
- satisfao dos clientes com os produtos e servios Flexy, com o intuito de
validar se o investimento em tcnicas de teste gil auxilia no aumento da satisfao
dos clientes com os produtos e servios da Flexy.

12.4.

OBTENO E ANALISE DOS DADOS/INFORMAO

Com todos os indicadores pr-definidos, se faz necessrio a execuo da

coleta de mtricas com os cliente anteriormente das tcnicas geis de teste
conforme apresentado na figura 38.

80

Figura 38: Resultado da pesquisa de satisfao aplicada em alguns

clientes antes da implantao das tcnicas geis de teste.
Fonte: (AUTORIA PRPRIA, 2013).
Conforme repassado pela empresa foi definido e aplicado um cronograma
para contextualizao e treinamento para os colaboradores da empresa Flexy
Negcios Digitais sobre as tcnicas geis de teste conforme apresentado na tabela
8.
Assunto

Data

Durao

Instrutor

Teste geis de software

27/06/2013

4Hrs

William M. Jablonski

Prtica TDD I

28/06/2013

4Hrs

Daniel Ribeiro

Prtica TDD II

29/06/2013

4Hrs

Daniel Ribeiro

Prtica ATDD

30/06/2013

4Hrs

Daniel Ribeiro

Prtica BDD I

31/06/2013

4Hrs

Daniel Ribeiro

Prtica BDD II

01/07/2013

4Hrs

Daniel Ribeiro

Tabela 8: Cronograma treinamento de Tcnicas geis de teste.

Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado um aumento
de 30% no tempo utilizado pelo Product Owner para analisar, entender e especificar
a tarefa juntamente com seus cenrios de aceite e teste nas ferramentas de BPMN,
ATDD e BDD conforme apresentado na figura 39. Segundo informado pelo Product
Owner este aumento se justifica devido que para o cadastro nas ferramentas, as
tarefas e validaes esto mais bem definidas e exploradas, assim fechando
visivelmente para todos o escopo e entendimento das tarefas.

81

Figura 39: Aumento de 30% do tempo de analise do Product Ower.

Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado uma reduo
de 30% no tempo utilizado pelo programador para entender a funcionalidade do
modulo que apresentou defeito durante analise de impacto das falhas em mdulos j
cobertos com testes automatizados e BDD conforme apresentado pela figura 40.
Segundo os programadores, est reduo deve-se ao fato de que a funcionalidade e
suas caractersticas de aceite ficam escrita em BDD (linguagem comum a todos
envolvidos) na ferramenta de teste gil. Antes da utilizao das tcnicas de testes
geis, era necessrio questionar diversas vezes o Product Owner, o testador e em
alguns casos at o cliente sobre o correto funcionamento da funcionalidade.

Figura 40: Reduo de 30% do tempo de analise do programador para

codificao.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado um aumento
mdio de 20% no tempo de codificao de cada tarefa da Sprint como mostra a
figura 41. Segundo os programadores este aumento justifica-se devido a que nesta
etapa do processo foi agregado a atividade efetivamente codificar e executar
manualmente as tcnicas de testes geis TDD, ATDD e BDD de forma a assegurar
sua execuo, completude e efetividade.

82

Figura 41: Aumento de 20% do tempo codificao da tarefa pelo

programador.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado uma reduo
de 50% no tempo de execuo dos testes da funcionalidade codificada conforme
apresentado na figura 42. A equipe atribuiu esta reduo ao processo de que
durante a codificao da tarefas e tcnicas geis de teste, o programador deve
obrigatoriamente executar o cdigo implementado e seus devidos testes, de modo
que assim ele valida a funcionalidade e corrigi as anomalias reportadas antes de
encaminhar o cdigo para o teste da equipe de testes.

Figura 42: Reduo de 50% do tempo execuo de testes da tarefa pelo

testador.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado uma reduo
de 80% no tempo de execuo dos testes de regresso conforme apresentado na
figura 43. De acordo com a equipe, est reduo se d devido automatizao do
processo de teste de regresso gerado pelas tcnicas de testes geis. No novo
processo as ferramentas de TDD, ATDD e BDD ficam encarregadas de executarem
estes testes de forma automtica e de abrangncia linear, respeitando todas as
necessidades especificadas para o sistema.

83

Figura 43: Reduo de 50% do tempo execuo de testes da tarefa pelo

testador.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado um aumento
de 40% nos bugs reportados durante a execuo dos testes de regresso conforme
apresentado na figura 44. De acordo com a equipe, este aumento se d devido
automatizao do processo de execuo dos testes de regresso atravs das
tcnicas geis de testes, de forma que sem um alto custo possvel validar 100%
das funcionalidade do sistema j implementadas. Sem contar que atravs da
automao dos testes isolados os fatores humanos que podem influenciar nos
resultados dos testes conforme Myers (2004).

Figura 44: Aumento de 40% no numero mdio de defeitos reportados

durante o teste de regresso por Sprint.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado um aumento
de 50% na produtividade mdia da equipe conforme apresentado na figura 45. De
acordo com a equipe, este aumento atribui-se como efeito cascata dos benefcios
gerados ao longo do processo motivados pela implantao das tcnicas geis de
teste como o maior detalhamento das tarefas pelo Produt Owner, a reduo do
tempo de analise do desenvolvedor para codificao e a reduo do tempo de
execuo de testes da funcionalidade e de regresso.

84

Figura 45: Ganho de 50% na produtividade mdia por Sprint.

Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise do material de apoio ao sistema foi observado um
aumento de 70% no ndice de documentao do sistema conforme apresentado na
figura 46. Conforme a equipe, este aumento atribui-se parcialmente ao maior
detalhamento das tarefas por parte do Product Owner, mas principalmente ao intuito
de que na adoo das tcnicas geis de testes como ATDD e BDD a equipe
forada a manter uma documentao mais funcional e efetiva durante o processo de
manuteno das validaes automatizadas.

Figura 46: Aumento de 70% na documentao do sistema.

Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado uma reduo
de 60% no tempo do ciclo de vida de uma tarefa de suporte ao cliente conforme
apresentado na figura 47. De acordo com a equipe, esta reduo se d pelo motivo
que 30% das tarefas de suporte esto ligado diretamente a duvidas tcnicas do
sistema, com o aumento da cobertura da documentao funcional do sistema,
consequncia da adoo das tcnicas geis de teste, fica mais rpido para o tcnico
de suporte resolver estas tarefas, j que este conhecimento est arquivado em
lugares especficos e no mais apenas espalhados entre os membros da equipe. A
equipe ainda afirma que antes da adoo das tcnicas geis de teste, o tcnico de
suporte tinha que ir de membro a membro da equipe questionamento sobre o seu
conhecimento sobre a tarefa em questo, at adquirir e agrupar todo o
conhecimento necessrio para resolv-la. Do restante das tarefas de suporte, est
reduo ainda atribuda por parte documentao funcional do sistema que auxilia
na resoluo direta da questo e por fim aos testes de regresso j codificados e
validados, que reduzem diretamente o tempo de teste no processo de suporte.

85

Figura 47: Reduo de 60% no tempo de resoluo das tarefas de

suporte.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado uma reduo
de 50% no numero de tarefas de suporte ao cliente geradas ao ms conforme
apresentado na figura 48. De acordo com a equipe, esta reduo se d pelo motivo
que a adoo das tcnicas geis de teste trouxe por consequncia o aumento da
qualidade do sistema que por consequncia direta gerou uma reduo significativa
no numero de falhas de sistema disponibilizados na produo assim de forma
cascata reduzindo o numero de problemas reportados por clientes em produo.

Figura 48: Reduo de 50% no numero de tarefas de suporte ao ms.

Fonte: (AUTORIA PRPRIA, 2013).
A partir da reunio realizada com a equipe no dia 05/12/2013 com o objetivo
de avaliar os impactos, benefcios e malefcios da utilizao de prticas geis de
teste na empresa Flexy Negcios Digitais conclui-se de forma geral que a utilizao
de tcnicas geis de teste durante o processo de engenharia de software, d maior
segurana para a equipe alterar o software, maior entendimento do que deve ser
feito em termo de funcionalidades, uma viso mais clara dos objetivos da entrega,
uma viso mais clara dos critrios de aceite da tarefa, assume-se que o tempo de
desenvolvimento da tarefa maior porem validado que h uma reduo drstica
no tempo absoluto do ciclo de desenvolvimento da tarefa, por fim conclui-se que
efetivamente a qualidade do software aumenta e consequentemente a satisfao do
cliente com a empresa devido aos diversos benefcios das tcnicas de testes geis.
Pessoas participantes da reunio: Fred Dubiel (Scrum Master), Rafaela Gonalves
(estagiaria de teste), William Jablonski (Coordenador de qualidade), Eduardo
Parucker (Programador), Daniel Ribeiro (Coordenador de desenvolvimento), Cristian
Muller (Programador), Ricardo Simas (Programador), Marlon Hemkemaier (Product
Owner).
Durante o acompanhamento dos resultados gerados pela adoo das
tcnicas geis de teste, motivado pelas redues dos tempos dentro de algumas
atividades especificas no ciclo de desenvolvimento e outros ganhos gerados com a
86

adoo das tcnicas conforme citados acima, foi executado pela empresa a reduo
do tempo da Sprint de 2 semanas para 1 semana com a meta de se manter a
produtividade gerada de 60 pontos por Sprint. O resultado conclui-se satisfatrio
conforme previsto assim conforme apresentado na figura 49 foi possvel ter um
ganho real de 200% na produtividade efetiva da Sprint no mesmo espao de tempo
sem a necessidade de alterao na equipe.

Figura 49: Ganho de 200% em produtividade atravs da adoo das

tcnicas geis de teste no perodo de um ms.
Fonte: (AUTORIA PRPRIA, 2013).
Tratando-se do custo versus produtividade, atravs dos resultados obtidos
com a adoo das tcnicas geis de teste houve uma economia de R$64.800,00
para atingir o mesmo ndice de produo caso utilizado o antigo processo de
desenvolvimento da Flexy conforme apresenta a figura 50. O valor obtido se baseia
de modo que para atingir o mesmo ndice de produtividade a empresa deveria mais
que triplicar a equipe de desenvolvimento, testes e suporte ao cliente.

Figura 50: Ganho acumulado em economia financeira atravs da adoo

das tcnicas geis de teste no perodo de um ms.
Fonte: (AUTORIA PRPRIA, 2013).
Considerando o perodo de um ano, est economia chega ao valor de R$
777.600,00 mil reais conforme apresentado pela figura 51.

87

Figura 51: Ganho acumulado em economia financeira atravs da adoo

das tcnicas geis de teste no perodo de um ano
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado um aumento
de 20% na satisfao dos clientes com os produtos e servios da Flexy conforme
apresentado na figura 52. Considera-se que este aumento motivado pelos
resultados gerados atravs da implantao das tcnicas geis de teste, resultados
que foram apresentados anteriormente.

Figura 52: Resultado da pesquisa de satisfao aplicada em alguns

clientes aps da implantao das tcnicas de testes geis.
Fonte: (AUTORIA PRPRIA, 2013).
Atravs da analise dos resultados dos indicadores foi observado um aumento
de 5% na ingresso de novos clientes atravs de indicao clientes. possvel
observar uma mudana do parecer de alguns clientes sobre os produtos e servios
da Flexy conforme apresentado na figura 52. Considera-se que este mudana de
parecer motivada pelos resultados obtidos atravs da adoo das tcnicas geis
de teste.

12.5.

RESULTADO DO ESTUDO DE CASO

Consolidando os resultados, aferiu-se que em termos de qualidade dos

produtos e servios da empresa houve um aumento gradativo e significativo nos
indicadores de qualidade, um dos carros chefe desse movimento pode se considerar
a reduo de erros reportados no sistema em testes de final de processo tal como
erros reportados pelos clientes em ambiente de produo, por fator motivador
observa-se a execuo de forma automatizada das validaes tal como a medio
do ndice de cobertura destes testes e efetividade dos mesmo. Outro fator
extremamente decisivo foi o alinhamento e automao dos termos de aceite em uma
linguagem comum a todos, reduzindo a possibilidade de duplo entendimento destes
fatores.
Atravs destes, conclui-se que neste cenrio, a aplicao destas tcnicas de
teste geis em um formato a utiliz-las de forma consolidada, acarretou nos
benefcios anteriormente firmados como expectativas da diretoria na empresa alvo
88

do estudo de caso. Diversos autores citam benefcios da utilizao de forma

individual, mas os resultados do formato consolidado apresentaram que uma pode
complementar a outra gerando assim um melhor resultado final.

89

13.

CONSIDERAES FINAIS

Esta pesquisa teve como objetivo apresentar conceitos, exemplo de

ferramental, benefcios da implantao de testes geis tal como o estudo de caso da
aplicao de prticas geis de teste de software na empresa startup Flexy Negcios
Digitais, um startup catarinense de e-commerce, e validar seus resultados.
O processo de migrao de tcnicas de trabalho em ambiente de software
um processo delicado e complexo, devido a que deve gerar o menor impacto
possvel pois qualquer erro que seja impeditivo a equipe de software potencialmente
vem a gerar impactos negativos ao oramento da empresa, como por exemplo em
uma falha de processo que impea o programador de disponibilizar seu cdigo para
testes, atrasando a entrega.
O resultado desta pesquisa, neste cenrio, a partir do consolidado de
resultados obtidos no estudo de caso, aponta que efetivamente foi gerado um
aumento da qualidade dos produtos e servios da empresa, como tambm reduo
de custos no processo de software, ainda fez-se mapear de forma automatizada o
atendimento dos requisitos acordados com o cliente como tambm gerar uma maior
produtividade na equipe. possvel concluir tambm que a aplicao das tcnicas
geis de teste de software atua de forma preventiva incentivando o processo de
reviso esttica e identificao antecipada dos defeitos seja de especificao,
entendimento ou do software efetivamente, evitando que os defeitos inseridos no
software sejam disponibilizados para o cliente Outra atuao identificada sua ao
de forma reativa, notificando de forma antecipada os impactos causados no sistema
devido a erros de negcio reportados.
A aplicao de prticas geis de teste influncia diretamente no resultado
final do software e seus aspectos arquiteturais como o caso do TDD, tambm
influencia em todo o processo de aquisio e modelagem do conhecimento
necessrio para especificao do software antes de sua codificao, ferramentas de
ATDD e BDD obrigam a equipe a ter uma definio solida da necessidade do cliente
e dos termos de aceite da funcionalidade, todos estes dados sero escritos em
linguagem comum a todos interessados do processo, assim mantendo uma viso
clara para todos do que deve ser feito e entregue.
Uma questo importante sobre a implementao que em caso de falha, seja
falha humana por falta de treinamento, falha de processo por definio incorreta ou
falha em ferramental por configurao indevida ou qualquer outra falha seja de
carter fsico ou no, potencialmente pode gerar resultados negativos a empresa
atravs do atraso da entrega ou at uma entrega defeituosa.
As ferramentas de ATDD e BDD auxiliam no acompanhamento do status do
projeto, um status sobre o que j foi codificado e o que ainda est pendente. Estas
ferramentas ainda contribuem para um acompanhamento da sade do projeto, j
que possvel atravs delas validar se as funcionalidades j existentes no projeto
esto funcionando efetivamente, desde que cobertas pelas validaes destas
ferramentas.

90

14.

TRABALHOS FUTUROS

Como trabalhos futuros sugere-se explorar o estudo dos benefcios da

aplicao das tcnicas geis de testes em ambientes de integrao continua
(Continuous Integration) e publicao continua (Continuous Deployment).

91

15.

BIBLIOGRAFIA

ASEE. American Society for Engineering Education. Disponvel em:

<http://www.asee.org>. 2000. Acesso em: 08 abril 2013.
ASTELS, Dave, David Chelimsky, Bryan Helmkamp and Dan North. The
RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and
Friends (The Facets of Ruby Series. 2010
BASTOS, Anderson et al. Base de conhecimento em teste de software. 2
Ed. Niteri. Martins Fontes, 2007.
BAUER, F. L. Scientific Affairs Division. NATO SCIENCE COMMITTEE,
Garmisch, Germany, 1969.
BECK, K., Extreme Programming Explained: Embrace Change, 1st Edition,
Addison-Wesley, 1999.
BECK, Kent et al. Manifesto gil., 2001.Disponvel em:
<http://manifestoagil.com.br/> Acesso em: 16 mai. 2013.
BISSI, Wilson. Scrum - Metodologia de desenvolvimento gil. Campo
Digital, Campo Mouro, V. 2, n. 1. 2007.
BOSSI P., Extreme Programming Applied: a case study in the private
banking domain, January 2003, OOP2003 Conference, Munich (Germany),
Disponvel
em:
<http://www.quinary.com/pagine/downloads/files/Resources/OOP2003Paper.pdf>.
Acesso em: 08 abril 2013.
BURNSTEIN, I. Practical software testing: a process-oriented approach.
New York: Springer, 2003.
CRESPO, Adalberto; SILVA, Odair; BORGES Carlos; SALVIANO Clnio;
JINO Mario. Uma Metodologia para Teste de Software no Contexto da Melhoria
de Processo. CenPRA - Centro de Pesquisa Renato Archer. In: Simpsio Brasileiro
de Qualidade de Software, 2004. Disponvel em <www.sbc.org.br/ >. Acesso em: 16
mai. 2013.
CRESWELL, J. W. Research design: qualitative, quantitative and mixed
methods approaches. California/USA: Sage Publications, Inc., 2003.
DEEK, F. P.; MCHUGH, J. A.; ELJABIRI, O. M. Strategic software
engineering: an interdisciplinary approach. Auerbach, 2005.
DELAMARO, M. E. ; MALDONADO, J. C. ; JINO, M. . Conceitos bsicos. In:
Delamaro, Marcio; Maldonado, Jos Carlos; Jino, Mario. (Org.). Introduo ao teste
de software. v. 1 Rio de Janeiro: Campus, 2007.
DEITEL, Harvey M. Java: Como Programar. 6 ed. So Paulo: Pearson
education do Brasil, 2005.
DEURSEN, A. van. L. Moonen, and T. Kuipers. Extreme Programming
Examined. Addison-Wesley, 2001.
DORNELAS, Jos Carlos Assis, 1971. Empreendedorismo: Transformando
ideias em negcios / Jos Carlos Assis Dornelas. 3.ed. Rio de Janeiro:
Elsevier, 2008.
92

DUBINKSY, Y. and Hazzan, O. Measured test-driven development: Using

measures to monitor and control the unit development, Journal of Computer,
2007.
FERREIRA, Sueli Mara S. P. Estudos de necessidades de informao:
dos paradigmas tradicionais abordagem Sense-Making. Disponvel em:
<www.eca.usp.br/nucleos/sense/index.htm>. Acesso em: 01 nov. 2013.
FIORELLI, Jos Osmir. Psicologia para administradores: integrando
teoria e prtica. 5 ed. So Paulo: Atlas, 2007.
FOWLER, Martin. "To Be Explicit." IEEE Software, November/December
2000.
GEORGE, B., Williams, L., An Initial Investigation of Test- Driven
Development in Industry. ACM Symposium on Applied Computing. Melbourne,
Florida, USA, 2003.
GOLD, R., Hammell, T., and Snyder, T.. Test-Driven Develop-ment: A J2EE
Example (Experts Voice). Apress. 2004.
GONALVES, Andr Silva. Gesto de Projetos em Pequenas e Mdias
Empresas:
Principais
dificuldades.
2008.
Disponvel
em:
<http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/677>. Acesso em 08
abril 2013.
GITAHY, Yuri. O que uma start up?. Empreendedor Online
Empreendedorismo na Internet e negcios online, 2011 . Disponvel
em:<http://www.empreendedoronline.net.br/o-que-e-uma-startup/>
Acessado
em23/05/2013.
HERBERT, J.S. Teste cooperativo de software. Porto Alegre: UFRGS,
1999.
HERMANSON, Boris. O que uma startup? So Paulo: Mundo Sebrae,
2011. Volume 1/2011.
HIGHSMITH, Jim, Agile Project Management, Creating innovative products,
Addison Wesley, 2004.
IBGE. Instituto brasileiro de geografia e estatstica. Disponvel em:
<http://www.ibge.gov.br>. 2010. Acesso em: 08 abril 2013.
IEEE, Institute of Electrical and Eletronic Engineers. IEEE 829 Standard for
Software Test Documentation. IEEE Standards Boards, New York: IEEE Computer
Society, Sep. 1990.
IEEE, Institute of Electrical and Eletronic Engineers. IEEE 829 Standard for
Software Test Documentation. V2. IEEE Standards Boards, New York: IEEE
Computer Society, Jul. 2012.
JEFFRIES, Ron, et al.What is Extreme Programming?, 2012.Disponvel em:
<http://xprogramming.com/book/whatisxp/>Acessoem: 16 mai. 2013.
JOHNSON, D. What is innovation and entrepreneurship? Lessons for
larger Organizations. Industrial and Commercial Training. Press, v. 33, n. 4, 2001.
JURAN, Joseph M.. A Qualidade desde o Projeto. Cengage Learning, 1992.
KOSCIANSKI, Andr. Qualidade de Software. Novatec. 2007.

93

KOSKELA, L. Test Driven: TDD and Acceptance TDD for JavaDevelopers.

Manning Publications. 2007.
KROLL, P. e Kruchten P. The Rational Unified Process Made Easy: A
Practitioner ' s Guide to the RUP , Addison Wesley. 2003.
KIM, T., Park, C., and Wu, C. Mock object models for test driven
development. In SERA 06: Proceedings of the Fourth International Conference
on Software Engineering Research, Management and Applications. Washington,
DC, USA. IEEE Computer Society. 2006.
LARMAN, C. and Basili, V. R. Iterative and incrementaldevelopment: A
brief history. Computer, 36(6). 2003
LONGHI, Flvio. A histria da revoluo das startups, Ed. Rio de Janeiro:
Alta Books, 2011.
MAGNOS, Alexandre. Revista Viso gil Scrum Master por Ele Mesmo.
Edio 4 2008.
MAGELA, R. Engenharia de software aplicada: fundamentos. 1 edio.
Ed. Rio deJaneiro: Alta Books, 2006.
MARAL, Ana Sofia. Estendendo o SCRUM segundo as reas de
processo de gerenciamento de projetos do CMMI. 2007
MARCONI, M. A.; LAKATOS, E.M. Fundamentos de metodologia cientfica.
So Paulo/SP: Editora Atlas, 2003.
MAXIMILIEN, E. M. and L. Williams. Assessing test-driven development at
IBM. IEEE 25th International Conference on Software Engineering, Portland,
Orlando, USA, IEEE Computer Society, 2003.
MENEZES, Estera Muszkat; SILVA, Edna Lcia da. Metodologia da
pesquisa e elaborao de dissertao. 4. ed. ver. atual. Florianpolis: UFSC,
2005.
MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2,
Nova Jrsei: 2004.
MOLINARI, E. Testes de Software: Produzindo Sistemas melhores e mais
Confiveis. So Paulo: rica, 2003.
MLLER, M. M., Hagner, O. Experiment about test-first programming. IEE
Proceedings 149(5). 2007.
NAGAPPAN, N., Bhat, T. Evaluating the efficacy of test- driven
development: industrial case studies. Proceedings of the 2006 ACM/IEEE
international symposium on Empirical software engineering.
NORTH,
D.
Introducing
bdd.
2006.
Disponvel
http://blog.dannorth.net/introducing-bdd/. Acesso em: 01/11/2013.

em:

PARK, Shelly; FRANK, Maurer. An Extended Review on Story Test Driven

Development. Universidade de Calgary, Calgary, 2010. Disponvel em:
<http://dspace.ucalgary.ca/bitstream/1880/47762/1/2010-953-02.pdf > Acesso em:
01 junho. 2013.

94

PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prtica.

Rio de Janeiro: Campus, 2001.
PEREIRA, Paulo. Entendendo o Scrum para Gerenciar Projetos de Forma
gil.
Mundo
PM.
2007.
Disponvel:
<http://www.lapjor.cce.ufsc.br/elgg/html/pg/file/benhur/read/349/entendendo-scrumpara-gerenciar-projetos-de-forma-gil>. Acesso em: 07 abril 2013.
PETERS, J., F.; WITOLD, P. Engenharia de software. Rio de Janeiro:
Campus, 2001.
PFLEEGER, SHARI L. Engenharia de software Teoria e Prtica. Pearson
Prentice-Hall, 2 Ed 2004.
PRESSMAN, ROGER S., Engenharia de Software, So Paulo, Ed.
McGrawHill, 6 Ed, 2006.
RSPEC, Info. 2010. Disponvel em: <http://rspec.info/>. Acesso em: 07 abril
2013.
SANTOS, J,. M., S. Um Framework para definio de processos de testes
de softwareque atenda ao nvel 3 do TMM-e. Recife: s.n., 2006.
SCOTT, Michael L. Programming Language Pragmatics. San Francisco,
CA: Morgam Kaufmann/Academic Press, 2006.
SEI, Software Engeneering Institute. 2010. Disponvel em:
<www.sei.cmu.edu>. Acesso em: 16 maio. 2013.
SINIAALTO, M. and Abrahamsson, P. A comparative case study on the
impact of test-driven development on program design and test coverage. In
Proceedings of the rst international symposium on empirical software
engineering and measurement, ESEM 07, Washington, DC, USA. IEEE Computer
Society. 2007.
SOMERVILLE, I. Engenharia de Software. 6ed. So Paulo: Prentice Hall,
2003.
SOARES, M. S. Comparao entre Metodologias geis e Tradicionais
para Desenvolvimento de Software. INFOCOMP Journal of Computer Science,
Vol. 3, n. 2, p. 8-13, 2004.
STEFFEN, Juliana Berossa. O que so essas tais de metodologias geis?.
[S.l.]:
IBM,
2012.
Disponvel
em:
<https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_q
ue_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en>. Acesso em: 16
maio. 2013.
SWEBOK 2004. Guide to the Software Engineering Body of
Knowlegment. 2004. Disponvel em http://www.swebok.org/htmlformat.html. Acesso
em: 30/09/2013.
TASSEY, Gregory.The Economic Impacts of Inadequate Infrastruture for
Software
Testing.NIST,
2002.Disponvel
em:
<http://www.nist.gov/director/planning/upload/report02-3.pdf>, Acesso em: 08 abril
2013.
THOMAS, Jerry R.; NELSON, Jack K., SILVERMAN, Stephen J. Mtodos de
Pesquisa em Atividade Fsica. 5 ed. Porto Alegre: Artmed, 2007.

95

TOSETTO, M. Ambiente Organizacional para Teste de Software. 2004.

Disponvel
em:
<http://www.unisinos.br/inf/images/stories/Inf/32tc_mauro_tosetto.pdf.>
Acessado
em 01/11/2013.
TONSIG, Srgio L. Engenharia de Software - Anlise e Projeto de
Sistema. CIENCIA MODERNA. 2008
VASCONCELOS, Alexandre Marcos Lins, ROUILLER, Ana Cristina,
MACHADO,Cristina ngela Filipak Machado, MEDEIROS, Teresa Maria Maciel.
Introduo Engenharia de Software e Qualidade de Software. Editora FAEPE
- UFLA, 2006.
VIEGA, J. and McManus, J. (2000).The importance of software testing.
Disponvel em: http://www.cutter.com/research/2000/crb000111.html, Acesso em 15
maio 2013.
VILAS BOAS, A. L. de C. Qualidade e Avaliao de Produto de Software.
Ed. Lavras. 2007.
WASMUS, H. and Gross, H.-G. Evaluation of test-driven development.
Delft University of Technology. 2007.
WELLS, D., Extreme Programming: A gentle introduction. 2012, Disponvel
em: <http://www.extremeprogramming.org>, Acesso em: 08 abril 2013.

96