Professional Documents
Culture Documents
GRANDE FLORIANPOLIS
Curso de Cincia da Computao
Campus So Jos
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.
6.2.
7. HIPTESES ................................................................................................................................. 11
8. METODOLOGIA DE PESQUISA .............................................................................................. 12
9. OBJETIVOS .................................................................................................................................. 13
9.1.
9.2.
ENGENHARIA DE SOFTWARE..................................................................................... 13
10.2.
10.3.
10.3.1.
10.3.2.
10.3.3.
10.4.
10.5.
10.5.1.
10.6.
10.7.
10.7.1.
SCRUM .................................................................................................................... 30
10.7.2.
10.7.2.1.
10.7.2.2.
10.7.2.3.
10.8.
10.8.1.
10.8.1.1.
10.8.1.2.
10.8.1.3.
10.8.1.4.
10.8.1.5.
10.8.2.
10.8.2.1.
10.8.2.2.
10.8.3.
10.8.3.1.
10.8.3.2.
10.8.3.3.
10.8.3.4.
STARTUP ........................................................................................................................... 51
10.9.
11.
11.1.
EXEMPLO DE TDD.................................................................................................... 54
11.2.
11.3.
11.4.
APLICAO DE PRTICAS GEIS DE TESTE DESENVOLVIMENTO DE
SOFTWARE EM STARTUP ..................................................................................................... 68
12.
12.1.
PROBLEMATIZAO ...................................................................................................... 70
12.2.
12.3.
12.4.
12.5.
13.
14.
15.
BIBLIOGRAFIA ....................................................................................................................... 92
1.
LISTA DE SIGLAS
2.
LISTA DE FIGURAS
3.
LISTA DE TABELAS
4.
RESUMO
5.
INTRODUO
6.
TEMA
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
7.
HIPTESES
11
8.
METODOLOGIA DE PESQUISA
test
driven
development
(ATDD),
ou
12
9.
OBJETIVOS
9.1.
9.2.
OBJETIVOS ESPECFICOS
10.
FUNDAMENTAO TERICA
15
existente
no
cdigo-fonte de um
17
18
19
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.
23
10.5.1.
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
25
26
27
10.7.1.
SCRUM
uma
perspectiva
do
projeto,
assegurando
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
10.7.2.
32
10.7.2.1.
comunicao;
simplicidade;
feedback;
coragem.
10.7.2.2.
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
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
Testes Unitrios
Testes de Aceite
Refatorao
Programao em par
Propriedade coletiva
Integrao contnua
Ritmo sustentvel
Cliente e equipe em
constante
comunicao
Padres de cdigo
Wells (2012) cita que as treze prticas apresentadas anteriormente, formam a base
do processo gil Extreme Programming.
10.7.2.3.
35
36
10.8.1.
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).
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
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
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
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)
42
10.8.1.4.
DESVANTAGENS DO TDD
43
10.8.1.5.
FERRAMENTA DE TDD
ambientes
integrados
de
10.8.2.
(ATDD)
ACCEPTANCE
TEST
DRIVEN
DEVELOPMENT
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.
10.8.3.1.
HISTRIAS
DE
USURIO
DESENVOLVIMENTO COM O BDD
PARA
When
Quando ocorrer
Condies
Then
Ento vai acontecer
Resultado previsto
46
17
47
10.8.3.2.
CONCEITO DO BDD
19
48
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
10.8.3.4.
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
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
52
53
11.
APLICAO DO TRABALHO
11.1.
EXEMPLO DE TDD
54
56
57
Figura 17:
implementadas.
Classe
EstacionamentoTest
com
as
Trs
regras
Na Figura
implementados.
18
classe
Estacionamento
com
seus
trs
mtodos
58
59
11.2.
EXEMPLO DE ATDD
60
61
62
63
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.
11.3.
EXEMPLO DE BDD
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
67
11.4.
APLICAO DE PRTICAS GEIS DE
DESENVOLVIMENTO DE SOFTWARE EM STARTUP
TESTE
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
12.2.
ABORDAGEM TCNICA
70
72
74
75
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
Programador
R$ 250,00
Testador
R$ 250,00
Arquiteto de Infraestrutura
R$ 250,00
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
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
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).
79
12.4.
80
Data
Durao
Instrutor
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
81
82
83
84
85
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.
87
12.5.
89
13.
CONSIDERAES FINAIS
90
14.
TRABALHOS FUTUROS
91
15.
BIBLIOGRAFIA
93
em:
94
95
96