Você está na página 1de 55

UNIVERSIDADE FEDERAL DA BAHIA

INSTITUTO DE MATEMTICA
DEPARTAMENTO DE CINCIA DA COMPUTAO

Daniela Soares Feitosa

Um estudo sobre o impacto do uso de


desenvolvimento orientado por testes na melhoria
da qualidade de software

Salvador
2007
Daniela Soares Feitosa

Monografia apresentada ao Curso de


graduao em Cincia da Computao,
Departamento de Cincia da Computao,
Instituto de Matemtica, Universidade Fed-
eral da Bahia, como requisito parcial para
obteno do grau de Bacharel em Cincia da
Computao.
Orientador:
Antonio Soares de Azevedo Terceiro

Salvador
2007
A Deus, pela minha vida.
A todos que contriburam direta ou indiretamente para a realizao deste projeto.
Agradecimentos

Em primeiro lugar, Deus por todas as coisas que aconteceram na minha vida e que me
permitiram ser o que sou hoje.

Aos meus pais Vilma e Fernando, pela motivao, suporte e exemplo que me deram.

minha irm Fernanda, pela amizade e carinho que me demonstra sempre.

Ao meu namorado Helder, pelo incentivo, pacincia e companhia em todos os momentos.

A Terceiro, por toda ajuda e orientao que me deu durante esse semestre.

A todos os meus amigos que sempre me do apoio.


RESUMO

O desenvolvimento de software orientado por testes (TDD - Test Driven Development)


uma das tcnicas utilizadas no modelo de programao XP - eXtreme Programming, cujo uso
tem aumentado bastante. Esta tcnica tem como um de seus objetivos antecipar a identificao
de defeitos durante o desenvolvimento do software e, para isso, os testes so feitos antes da
implementao do cdigo. Esse tipo de desenvolvimento ajuda os desenvolvedores a focar na
funcionalidade das aplicaes e a disponibilidade de testes antes do desenvolvimento permite
um rpido retorno aps qualquer alterao. Este trabalho uma reviso sistemtica que tem
como objetivo analisar se a utilizao desta tcnica diminui a quantidade de defeitos numa
aplicao, melhorando sua qualidade e confiana.
Palavras-chave: engenharia de software, desenvolvimento orientado por testes, reviso
sistemtica.
ABSTRACT

Test Driven Development is one of the techniques used in the practices of XP - eXtreme
Programming, whose use has increased significantly. This technique has as one of its goals
to previously identify defects during software development and, therefore, the tests are written
prior to implementation of the code. This type of development help developers to focus on
the functionality of applications and the availability of tests before the development allows a
rapid feedback. This work is a systematic review that aims to examine whether the use of this
technique reduces the amount of defects in an application, improving its quality and reliability.
Keywords: software engineering, test-driven development, systematic review.
LISTA DE FIGURAS

2.1 Test Driven Development (BHAT; NAGAPPAN, 2006, p.357) . . . . . . . . . 18

2.2 Executando todos os testes do programa exemplo. . . . . . . . . . . . . . . . . 19

2.3 Executando todos os testes do programa exemplo pela segunda vez. . . . . . . 19

4.1 Grfico dos resultados obtidos a partir do estudo na Microsoft - (BHAT; NA-
GAPPAN, 2006, p.361) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Densidade dos defeitos encontrados no estudo na IBM - (VOUK, 17-20 Nov.
2003, p.7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
LISTA DE ABREVIATURAS E SIGLAS

CASE Computer-Aided Software Engineering, p. 12


TDD Test-Driven Development, p. 17
XP eXtreme Programming, p. 19
SUMRIO

1 Introduo 10

2 Conceitos 12

2.1 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Fases de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Testes automatizados de software . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Prticas de desenvolvimento de software . . . . . . . . . . . . . . . . . . . . . 15

2.5 Test-Driven Development (TDD) . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.1 Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . . 19

3 Metodologia 22

3.1 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Descrio do problema . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.3 Questes da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.4 Palavras-chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.5 Mtodo utilizado para pesquisa de fontes primrias . . . . . . . . . . . 24

3.1.6 Critrio de seleo dos estudos . . . . . . . . . . . . . . . . . . . . . . 24

3.1.7 Critrio de qualidade dos estudos . . . . . . . . . . . . . . . . . . . . 25

3.1.8 Mtodo de avaliao dos estudos . . . . . . . . . . . . . . . . . . . . . 25

3.1.9 Mtodo de extrao dos dados . . . . . . . . . . . . . . . . . . . . . . 26


3.1.10 Mtodo de sntese dos dados . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Execuo da Reviso Sistemtica . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Resultados 28

4.1 Discusso dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Concluso 32

5.1 Uso de reviso sistemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 TDD X Quantidade de defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Contribuies do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Apndice A -- Formulrio de conduo da reviso 34

Apndice B -- Formulrio de seleo de estudos 36

Apndice C -- Formulrio de extrao de dados 51

Referncias Bibliogrficas 54
10

1 INTRODUO

O processo de desenvolvimento de um software uma atividade complexa que envolve


diferentes questes. Entre elas, destaca-se uma das mais difceis de ser respondida, que como
garantir a qualidade do software. Testes sistemticos e tecnicamente completos so utilizados
para garantir essa qualidade. Alguns dos fatores que afetam a qualidade de software podem ser
medidos diretamente, como defeitos por quantidade de linhas de cdigo e por unidade de tempo,
enquanto outros podem ser medidos apenas indiretamente, como usabilidade e manutenibili-
dade. Estes fatores devem ser calculados e as medidas encontradas indicaro a qualidade do
software (PRESSMAN, 2005).

Segundo Ian Sommerville (SOMMERVILLE, 2003), a Engenharia de Software enfrenta


trs desafios principais neste sculo:

Sistemas legados: A maioria dos grandes softwares utilizados atualmente foi desen-
volvido h muitos anos. O desafio manter e atualizar estes sistemas legados de uma
forma economicamente vivel e garantindo a entrega dos servios prestados por estes
sistemas;

Heterogeneidade: O software desenvolvido deve ser confivel e flexvel o bastante para


ser bem-sucedido em diferentes combinaes de hardware e software;

Entrega: O aumento da complexidade do software e diminuio dos prazos de entrega


comprometem a qualidade do software;

A importncia da qualidade do software se mostra ainda mais evidente ao tentar solucionar


este ltimo ponto. Se a complexidade do software aumenta e o prazo de entrega diminui, deve-
se encontrar uma forma de garantir a qualidade do software apesar dos desafios. Test Driven
Development (TDD) surgiu como uma possvel soluo para este problema.

TDD j usada informalmente por bons programadores a muito tempo, mas as primeiras
tentativas de defin-la como uma prtica de desenvolvimento comearam no final de 2002, com
11

as publicaes de Kent Beck (BECK, 2003) e David Astels (ASTELS, 2003). Esta tcnica
consiste em implementar testes para cada nova funcionalidade do software antes mesmo de
implement-la. Os testes devero ser executados regularmente para verificar se o cdigo imple-
mentado aps cada teste est correto. Essa forma de desenvolver ajuda os desenvolvedores a
focar na funcionalidade das aplicaes e, caso os testes passem, o desenvolvedor saber que o
cdigo foi bem implementado, garantindo a qualidade da aplicao.

TDD ajuda os desenvolvedores a focar na funcionalidade das aplicaes e a disponibilidade


de testes antes do desenvolvimento permite um rpido feedback. Entretanto, no garantido
que a quantidade de defeitos diminuir.

Neste trabalho, foi conduzida uma reviso sistemtica com o objetivo de analisar se a uti-
lizao de TDD diminui a quantidade de defeitos no software, comparando com outras tcnicas
de desenvolvimento. Para isso, alguns estudos que obtiveram resultados experimentais foram
identificados, analisados e avaliados como proposto em (KITCHENHAM, 2004).

Em funo do nmero reduzido de estudos especficos sobre o impacto de TDD na quanti-


dade de defeitos no software, no possvel estatisticamente afirmar que h uma diminuio na
quantidade de defeitos, apesar dessa ser uma tendncia apontada por esses mesmos estudos.

Este trabalho encontra-se dividido em 5 captulos. O captulo 2 far uma introduo sobre
os principais conceitos envolvendo TDD. O captulo 3 descreve a metodologia utilizada, apre-
sentando detalhadamente o protocolo e a conduo da reviso. O captulo 4 apresenta os resul-
tados obtidos da reviso. O captulo 5 apresenta as concluses. E, finalmente, os formulrios
utilizados na conduo da reviso so apresentados nos apndices A, B e C.
12

2 CONCEITOS

Neste captulo sero apresentados os resumos dos conceitos necessrios para o entendi-
mento deste trabalho: Engenharia de Software, Testes de software e Test Driven Development.

2.1 ENGENHARIA DE SOFTWARE

Uma primeira definio de engenharia de software foi proposta por Fritz Baur na primeira
conferncia dedicada ao assunto (NAUR; RANDELL, 1969 apud PRESSMAN, 2005): Engen-
haria de software a criao e a utilizao de slidos princpios de engenharia a fim de obter
software de maneira econmica, que seja confivel e que trabalhe eficientemente em mquinas
reais. A criao da engenharia de software surgiu numa tentativa de contornar a crise do soft-
ware e dar um tratamento mais sistemtico e controlado ao desenvolvimento de sistemas de
software complexos.

A engenharia de software a rea da computao que se preocupa com todos os aspectos da


produo de software e procura garantir a qualidade do software desenvolvido. Segundo Press-
man (PRESSMAN, 2005), ela composta por um conjunto de trs elementos fundamentais:
mtodos, ferramentas e processos, que possibilita o controle do processo de desenvolvimento
do software.

Os mtodos provm os detalhes de como fazer a implementao do software e incluem


os modelos, a especificao do software, guia do processo e um conjunto de critrios para
qualidade do software.

As ferramentas tem como objetivo proporcionar apoio automatizado ou semi-automatizado


para as atividades do processos. um sistema de suporte ao desenvolvimento de software que
abrange toda ferramenta baseada em computadores que auxiliam atividades de engenharia de
software, desde anlise de requisitos e modelagem at programao e testes.

Os processos constituem a interao dos mtodos, ferramentas e pessoas. Eles definem a


sequncia de prticas que ser utilizada para o desenvolvimento, garantia de qualidade e entrega
13

dos produtos (documentos, relatrios, formulrios etc). Estas prticas englobam as atividades
de especificao, desenvolvimento, validao e evoluo.

2.2 TESTES DE SOFTWARE

Teste de software o processo de executar um software de uma maneira controlada com o


objetivo de avaliar se o mesmo se comporta conforme o especificado. Envolve aes que vo
do levantamento de requisitos at a execuo do teste propriamente dito. Segundo Sommerville
(SOMMERVILLE, 2003), teste de software uma tcnica de verificao e validao.

Verificao e validao so processos de checagem e anlise de software. O objetivo da


verificao mostrar se um programa est de acordo com a especificao e a validao mostra
se um programa faz o que o cliente/usurio deseja.

Um erro de software um erro de implementao no cdigo e um defeito de software a


manifestao de um ou mais erros, fazendo com que o software no execute da forma esperada.
Testes de software revelam a presena de defeitos.

O teste considerado bom se revela um ou mais defeitos. Teste de software no pode


provar a ausncia de defeitos, pode apenas mostrar a presena de defeitos, por isso seu objetivo
executar um programa com a inteno de revelar a presena de defeitos, e no a sua ausncia.
Aps a realizao de um teste, o resultado deve ser avaliado e comparado ao resultado esperado.
Caso os resultados sejam diferentes, chega-se concluso que h defeitos e que deve ser feita a
depurao.

A maioria dos softwares possuem defeitos, ento, para promover um ambiente mais estvel
para o usurio final, importante que a maioria desses defeitos no sejam crticos. Os testes de
software tentam garantir que a qualidade, o custo, a segurana e a confiabilidade do software
no sejam prejudicados pela presena desses defeitos.

2.2.1 FASES DE TESTE

Ian Sommerville (SOMMERVILLE, 2003) declara que os testes devem ser feitos em duas
fases. Na primeira fase, so feitos os testes de componentes e na segunda fase, os testes de
integrao.

Durante a fase de testes de componentes duas tcnicas de testes so muito utilizadas:

Teste da caixa-preta: Dados de entrada so fornecidos, o teste executado e o resultado


14

obtido comparado a um resultado esperado previamente conhecido. chamado de


caixa-preta porque o comportamento interno do componente no considerado, apenas
as entradas e sadas fornecidas pelo componente so conhecidas.

Teste da caixa-branca: Tambm chamado de teste estrutural, pois avalia a estrutura e


implementao do software.

Depois de testar todos os componentes do software individualmente e verificar que fun-


cionam, eles devem ser integrados para criar o software completo. Para garantir que o software
resultante da interao dos componentes no apresenta problemas so feitos os testes de inte-
grao. Estes testes so aplicados na construo da estrutura do programa, realizando testes
para descobrir defeitos associados s interfaces entre os componentes, verificando se todos os
componentes funcionaro corretamente quando estiverem integrados.

A integrao dos componentes podem ser feitas na forma no-incremental ou incremental.

Na integrao no-incremental, todos os mdulos do software so combinados ao mesmo


tempo e o software resultante testado. Neste caso, muitos defeitos podem ser encontrados e a
correo pode se tornar complicada, pois ser mais difcil encontrar a origem do defeito.

Na integrao incremental, o software construdo e testado em pequenos segmentos, per-


mitindo que os erros sejam mais fceis de ser isolados e corrigidos e as interfaces tm maior
probabilidade de serem testadas completamente.

2.3 TESTES AUTOMATIZADOS DE SOFTWARE

Para facilitar a execuo dos testes, foram criadas ferramentas que ajudam na criao de
cdigo para a automao de testes, como o JUnit. Com essas ferramentas, o desenvolvedor
escreve um teste pensando na interface do cdigo, ao invs de se preocupar em como ser im-
plementado, verificando se os mtodos e classes funcionam da forma esperada. Utilizando es-
tas ferramentas, executar testes passou a ser to fcil quanto compilar um software (FOWLER,
2001). Por ser fcil de executar automaticamente, os desenvolvedores podem executar os testes
automticos vrias vezes por dia, permitindo que os defeitos sejam encontrados mais rapida-
mente. Por exemplo, se aps a execuo de todos os testes, um bug for inserido no software, o
desenvolvedor saber que o defeito foi causado pelas linhas de cdigo inseridas entre a ltima
execuo dos testes e a revelao do bug.

Para exemplificar, ser assumido que existe um programa escrito na linguagem Ruby e
utilizando o framework Rails que armazena dados de vrias pessoas num banco de dados. Neste
15

programa h uma classe chamada Pessoa com um campo nome, que deve ser obrigatrio. Ento,
o programa no deve permitir que um objeto da classe Pessoa seja salvo no banco de dados sem
ter o campo nome preenchido. Os testes unitrios dessa classe so escritos numa classe chamada
PessoaTest. No teste para validar o campo obrigatrio, um objeto da classe criado e deve ser
verificado se ele ser salvo no banco sem o campo nome preenchido. Para verificar em Ruby
utilizado o mtodo assert, que retorna true se o que est sendo testado for verdadeiro e false
caso contrrio.

Um exemplo de teste unitrio automatizado para essa situao mostrado na listagem 2.1.
Nele, o primeiro assert verifica se o objeto p no pde ser salvo e o segundo verifica se foi
salvo. O primeiro dever retornar o valor true, j que um objeto sem o campo nome no dever
ser salvo. O segundo tambm dever retornar o valor true, j que o campo nome foi preenchido.
Outros casos de testes unitrios para essa mesma classe devem ser preenchidas no mesmo ar-
quivo.

Listagem 2.1: Teste unitrio da classe Pessoa


c l a s s PessoaTest < Test : : Unit : : TestCase

def t e s t _ c a m p o s _ o b r i g a t o r i o s
p = P e s s o a . new
a s s e r t ! p . save
p . nome = M a r i a
a s s e r t p . save
end

end

2.4 PRTICAS DE DESENVOLVIMENTO DE SOFTWARE

Kent Beck (BECK, 2000) descreveu as 12 melhores prticas de engenharia de software para
aumentar a produtividade e qualidade, que esto listadas abaixo:

O processo de planejamento: Esta prtica permite que o cliente defina as funcionali-


dades que sero prioritrias no desenvolvimento, a partir dos custos estimados fornecidos
pelos desenvolvedores.
16

Pequenas verses: Consiste em colocar um sistema simples em produo rapidamente e


atualiz-lo frequentemente, um ciclos curtos.

Metfora: Compartilhar um sistema de nomes e uma descrio do sistema para guiar


o desenvolvimento e a comunicao.

Design simples: O programa desenvolvido deve ser o programa mais simples possvel
que contemple os requisitos do momento. Nada que ainda no tenha sido descrito como
uma funcionalidade deve ser implementado.

Testes: A validao do software deve ser feita em todos os momentos. Os programadores


devem escrever os testes primeiro e, depois, o cdigo que contemple os requisitos refleti-
dos nos testes (TDD).

Refatorao: Esta prtica utilizada para reestruturar o sistema sem mudar seu compor-
tamento. utilizado para eliminar duplicaes, melhorar a comunicao, simplicidade
ou adicionar mais flexibilidade.

Programao em pares: Todo o cdigo produzido em pares: dois desenvolvedores


trabalhando juntos em uma mquina. Dessa forma, os desenvolvedores se ajudam. En-
quanto um escreve o cdigo, o outro pode analisar a necessidade de reviso do cdigo
e/ou refatorao.

Propriedade coletiva: Todo o cdigo produzido pertence todos os desenvolvedores.


Isto permite que um grupo produza mais rpido. Se algo precisa ser mudado, ele ser
mudado sem demora, pois qualquer desenvolvedor poder modificar qualquer parte do
cdigo.

Integrao contnua: Os grupos de desenvolvedores integram e produzem software


vrias vezes por dia, permitindo que o progresso do desenvolvimento seja mais rpido.

40 horas por semana: Desenvolvedores cansados cometem mais erros. Ento, nenhum
desenvolvedor deve trabalhar mais de 40h por semana.

Cliente sempre presente: Um cliente/usurio deve estar sempre presente no desenvolvi-


mento, determinando requisitos, estabelecendo prioridade e respondendo s questes que
os desenvolvedores fizerem.

Padres de codificao: Para um grupo trabalhar efetivamente em pares e compartilhar


a propriedade do cdigo, todos os desenvolvedores devem produzir cdigo da mesma
forma, com regras que garantem que auxiliem a comunicao atravs do cdigo.
17

2.5 TEST-DRIVEN DEVELOPMENT (TDD)

Desenvolvimento Orientado por Testes (TDD) uma tcnica utilizada na fase de implemen-
tao do software. Ela consiste de pequenas iteraes onde novos casos de testes so escritos
contemplando uma nova funcionalidade ou melhoria e, depois, o cdigo necessrio e suficiente
para passar esses teste implementado. Ento, o software refatorado para contemplar as
mudanas de forma que os testes continuem passando.

Cada pequena iterao possui um micro objetivo, que ser uma funcionalidade ou melhoria
que dever ser implementada. Este micro objetivo ter sido alcanado quando os testes criados
antes da implementao do cdigo passarem. Essa forma de implementar reduz o escopo do que
o desenvolvedor deve focar, j que ele pensar apenas no micro objetivo, ao invs de se preocu-
par com todo o software. Esta tcnica tambm permite que o desenvolvedor escreva os testes
se preocupando apenas com a comportamento desejado da nova funcionalidade, ignorando sua
implementao e garante que os testes cobrem todo o cdigo.

Uma consequncia desta tcnica a reduo na quantidade de cdigo desnecessrio, pois se


o desenvolvedor pensou em todos os testes necessrios para o software e todos os testes passam,
mostra que o software j est terminado.

TDD pode ser aplicada em combinao com outras tcnicas e utilizada em qualquer metodolo-
gia de desenvolvimento de software.

Segundo Kent Beck (BECK, 2003), os seguinte passos so necessrios para a utilizao
dessa tcnica:

Adicionar um novo teste;

Executar todos os testes;

Implementar o cdigo necessrio para passar no teste;

Executar todos os testes;

Refatorar o cdigo.

Como todas as funcionalidades e melhorias do cdigo comeam com um teste, o desen-


volvedor precisa conhecer os casos de uso e estrias que contemplem todos os requisitos e
excees do sistema. Essa tcnica obriga o desenvolvedor a focar no requisito para escrever
bons testes.
18

Cada teste adicionado deve cobrir uma funcionalidade ou melhoria que ainda no foi im-
plementada, ento esse teste dever falhar na sua primeira execuo. Isso garante que o teste
no passar sem a necessidade de alterar o cdigo.

Com a falha no teste, o desenvolvedor deve implementar o cdigo necessrio e suficiente


para passar no novo teste, sem se preocupar com a elegncia do cdigo.

Aps implementado a nova funcionalidade/melhoria, os testes devem ser executados nova-


mente e, se todos os testes passarem, o desenvolvedor tem a garantia que o cdigo cumpre todos
os requisitos testados. Se algum no passar, o cdigo referente ao teste que falhou dever ser
corrigido.

Antes de adicionar um novo teste no software, o desevolvedor deve refatorar o cdigo, para
evitar duplicao.

Bhat e Nagappan (BHAT; NAGAPPAN, 2006), resumiram os passos na Figura 2.1.

Figura 2.1: Test Driven Development (BHAT; NAGAPPAN, 2006, p.357)

Ser utilizado como exemplo, o mesmo programa apresentado na seo 2.3. O micro-
objetivo da iterao ser garantir que um objeto da classe no seja salvo no banco de dados sem
o preenchimento do campo nome. Primeiro, o desenvolvedor dever escrever o teste (listagem
2.1). Depois, todos os testes devero ser executados para v-los falharem (figura 2.2). Neste
exemplo, h apenas um teste escrito.

O terceiro passo implementar o cdigo necessrio para o novo teste passar (listagem 2.2).
19

Figura 2.2: Executando todos os testes do programa exemplo.

Neste exemplo, basta inserir uma linha com a validao que verifica se o atributo especificado
est em branco.

Listagem 2.2: Classe Pessoa


c l a s s P e s s o a < A c t i v e R e c o r d : : Base

v a l i d a t e s _ p r e s e n c e _ o f : nome

end

Para saber se o cdigo escrito funciona como o esperado, os testes so executados nova-
mente (figura 2.3).

Figura 2.3: Executando todos os testes do programa exemplo pela segunda vez.

Como os testes passaram, o ltimo passo refatorar, que desnecessrio neste caso.

2.5.1 EXTREME PROGRAMMING (XP)

Extreme Programming (ou XP) uma metodologia de programao gil composta por um
conjunto de valores, princpios e prticas que visa desenvolver softwares de alta qualidade de
forma gil, econmica e flexvel (JEFFRIES, 2007).
20

Como o objetivo do XP desenvolver em pequenos ciclos, TDD se torna essencial para


ter a garantia que o cdigo que foi produzido atende s necessidades do cliente. E, se o cliente
sugerir alteraes, os desenvolvedores se sentiro seguros em fazer as mudanas, j que os testes
j produzidos possibilitaro indicar eventuais defeitos introduzidos pela alterao.

Os cinco valores que guiam o desenvolvimento XP so:

Comunicao: A comunicao entre os desenvolvedores e clientes importante para


que os desenvolvedores entendam as necessidades do cliente e estes acompanhem o de-
senvolvimento do projeto de perto. Tambm essencial que haja comunicao entre os
desenvolvedores, para garantir que todos entendam o software da mesma forma. A co-
municao verbal e presencial priorizada para garantir que todas as partes envolvidas
tenham a chance de se compreender da melhor maneira possvel.

Simplicidade: A equipe de desenvolvedores deve se concentrar em codificar primeiro


tudo que claramente importante para o software, evitando desenvolver o que ainda no
essencial. Este valor est relacionado com a comunicao, pois a simplicidade do cdigo
permite que ele seja entendido mais facilmente por todos os desenvolvedores do projeto.

Feedback: No desenvolvimento de software quanto mais cedo um defeito encontrado,


mais barata sua correo. A metodologia XP propes ciclos de desenvolvimento curtos
(1 a 4 semanas). Em cada ciclo ocorrem todas as fases de desenvolvimento (planejamento,
anlise de requisitos, codificao, teste e documentao), que so entregues ao cliente.
Este, ento, analisa se tudo o que pediu est contido na verso entregue e informa aos
desenvolvedores suas sugestes, crticas e dvidas.

Coragem: Os desenvolvedores que utilizam XP tm conscincia que os clientes podem


querer mudanas no software. Ento, tm coragem de permitir que essas mudanas sejam
feitas, pois confiam nas protees que o software possui quando desenvolvido utilizando
as prticas do XP, como desenvolvimento orientado por testes, programao em par e
integrao contnua.

Os princpios (BEEDLE et al., 2001) seguidos pelos desenvolvedores so:

A maior prioridade a satisfao do cliente atravs da entrega rpida e contnua de soft-


ware til.

As mudanas de requisito sero bem recebidas em qualquer momento, mesmo que o


desenvolvimento j esteja adiantado.
21

A entrega do software dever ser frequente, devendo ser em poucas semanas ou meses,
dando preferncia menor escala.

As pessoas que entendem de negcios e os desenvolvedores devem trabalhar juntos diari-


amente durante o projeto.

Desenvolva projetos com pessoas motivadas. Dem todo o ambiente e suporte que as
pessoas precisarem e confie que elas produziro.

o mtodo mais eficiente e eficaz de transmitir informaes em uma equipe de desenvolvi-


mento a conversa frente-a-frente.

Um software que funciona a primeira medida de progresso.

Processos geis promovem desenvolvimento sustentvel. Os clientes, desenvolvedores e


usurios devem ser capazes de manter um ritmo constante indefinidamente.

Ateno contnua excelncia tcnica e um bom projeto aumentam a agilidade.

Simplicidade a arte de maximizar a quantidade de trabalho a no ser feito essencial.

As melhores arquiteturas, requisitos e projetos emergem de grupos auto-organizveis.

Em intervalos regulares, o grupo deve refletir sobre como se tornar mais eficaz, ento
devem ajustar seu comportamento de acordo com isso.

A metodologia XP baseada nas 12 melhores prticas de engenharia de software citadas


na seo 2.4, com nfase em testes via TDD.
22

3 METODOLOGIA

A metodologia utilizada neste trabalho a Reviso Sistemtica. A maior parte das pesquisas
comea com uma reviso de literatura, no entanto, segundo Kitchenham (KITCHENHAM,
2004), para ter valor cientfico necessrio que essa reviso seja feita de forma abrangente, no
tendenciosa, aberta e objetiva. Esse a principal razo de uma reviso sistemtica, que deve
identificar, avaliar e interpretar todas as pesquisas disponveis e relevantes sobre uma questo
e, para isso, precisa ser executada seguindo um protocolo pr-definido e rigoroso. Obrigato-
riamente, nesse protocolo deve conter todas as informaes que permitam que a reviso seja
repetida por outros pesquisadores interessados. A reviso sistemtica deve reunir informaes
sobre uma determinada questo ou fenmeno, identificar lacunas na pesquisa atual e indicar um
direcionamento para pesquisas futuras.

Uma reviso sistemtica envolve trs fases: planejamento, execuo e anlise dos resulta-
dos.

Na fase de planejamento, o protocolo que dever orientar toda a reviso sistemtica con-
strudo. Nele deve conter as informaes sobre o objetivo, a descrio do problema, as questes
da pesquisa e os mtodos e critrios utilizados para a busca, seleo, avaliao e extrao de
dados.

Na fase de execuo, os mtodos descritos no protocolo so aplicados e documentados nos


formulrios de conduo da reviso e de seleo dos estudos. O objetivo do formulrio de
conduo da reviso documentar o processo de busca. Possui campos para a armazenagem
de informaes sobre a fonte onde a busca foi realizada, o endereo virtual da fonte, a data de
realizao da busca, as combinaes de palavras-chave que proporcionaram a busca dos artigos,
a quantidade de artigos encontrados e a quantidade de arquivos pr-selecionados. O formulrio
de seleo de estudos documenta a busca e possui campos informando o nome do artigo, a lista
de autores, data de sua publicao, veculo de publicao do artigo, fonte de onde foi obtido,
situao do artigo (pendente, includo e excludo) e informaes sobre se os critrios foram
atendidos.
23

Na fase de anlise dos resultados os dados dos estudos so extrados e sintetizados e os


resultados so analisados. A extrao documentada no formulrio de extrao de dados, que
possui campos informando o ttulo, abstract, objetivo do estudo, descrio do estudo experi-
mental, resultados do estudo, alm de comentrios adicionais do pesquisador que extraiu os
dados.

Na seo seguinte ser apresentado o protocolo utilizado para esta reviso sistemtica.

3.1 PROTOCOLO

O protocolo da reviso especifica os mtodos que sero utilizados para a reviso sistemtica.
Segundo Kitchenham, um protocolo pr-definido necessrio para reduzir a possibilidade de
uma pesquisa tendenciosa, j que sem um protocolo, um pesquisador poderia selecionar estudos
de acordo com suas expectativas.

3.1.1 DESCRIO DO PROBLEMA

Na maioria dos projetos de desenvolvimento de software, quanto mais se distancia das


fases iniciais do desenvolvimento mais custosa fica sua correo. Ento, a utilizao da tcnica
de desenvolvimento orientado por testes passa a ser uma boa opo, pois esta tem como um de
seus objetivos antecipar a identificao de defeitos durante o desenvolvimento do software. Esta
tcnica faz parte do modelo de programao XP, cuja utilizao tem aumentado bastante nos
ltimos anos. Para permitir que os defeitos sejam identificados previamente, os testes so feitos
antes da implementao do cdigo. Esse tipo de desenvolvimento ajuda os desenvolvedores a
focar na funcionalidade das aplicaes e a disponibilidade de testes antes do desenvolvimento
permite um rpido feedback. Entretanto, no garantido que a quantidade de defeitos diminuir.

3.1.2 OBJETIVO

O foco desta reviso sistemtica analisar se a utilizao da tcnica de desenvolvimento


de software orientado por testes diminui a quantidade de defeitos numa aplicao. Caso seja
verificado que a quantidade de defeitos menor, esta reviso tambm verificar o impacto da
utilizao da tcnica TDD na quantidade de defeitos do software.
24

3.1.3 QUESTES DA PESQUISA

Essas questes devero ser respondidas ao final da reviso sistemtica.

Questo Primria: O uso da metodologia TDD no desenvolvimento de software diminui


a quantidade de defeitos no software?

Populao: Projetos de desenvolvimento

Interveno: Test Driven Development

Resultado: Diminuio da quantidade de defeitos

Questo Secundria: Qual o impacto da utilizao de TDD na quantidade de defeitos em


um software?

3.1.4 PALAVRAS-CHAVE

Essas palavras sero utilizadas para fazer as buscas de estudos.

Populao

software development, software process, software project

Interveno:

development test, test, tests, software test, tdd, test driven development

Resultado:

errors, error, error detection, error identification, failure, defect

3.1.5 MTODO UTILIZADO PARA PESQUISA DE FONTES PRIMRIAS

As fontes sero pesquisada pela web nas bases eletrnicas de dados IEEE Xplore e ACM
Digital Library. As strings de busca utilizadas sero formada pela interseo das palavras que
formam a populao, a interveno e o resultado listados na subseo 3.1.4. A busca ser
documentada e apresentada no apndice A.

3.1.6 CRITRIO DE SELEO DOS ESTUDOS

Sero includos na reviso todos os artigos encontrados com a utilizao do mtodo descrito
na subseo 3.1.5 que satisfaam todos os seguintes critrios:
25

Os artigos devem ter sido publicados entre 1990 e 2007

Os artigos devem estar escritos em ingls. A escolha do ingls como idioma padro deve-
se sua universalidade.

Os artigos devem estar disponveis na web

Os artigos devem contemplar a execuo de estudos experimentais.

Os artigos devem abordar o uso da metodologia TDD no desenvolvimento de softwares e


a quantidade de defeitos ao final do desenvolvimento.

A seleo dos estudos ser documentada e apresentada no apndice B.

3.1.7 CRITRIO DE QUALIDADE DOS ESTUDOS

Os artigos que atenderem aos critrios descritos na subseo 3.1.6 sero avaliados baseado
nos critrios para avaliao de estudos experimentais em engenharia de software definidos por
Barbara Kitchenham e ilustrados na tabela 3.1 (KITCHENHAM, 2004). Apenas os estudos
com nvel 5 sero excludos da reviso sistemtica.

1 Evidence obtained from at least one properly-designed randomised controlled trial.


2 Evidence obtained from well-designed pseudo-randomised controlled trials (i.e.
non-random allocation to treatment).
3-1 Evidence obtained from comparative studies with concurrent controls and allocation
not randomised, cohort studies, case-control studies or interrupted time series with
a control group.
3-2 Evidence obtained from comparative studies with historical control, two or more
single arm studies, or interrupted time series without a parallel control group.
4-1 Evidence obtained from a randomised experiment performed in an artificial setting.
4-2 Evidence obtained from case series, either post-test or pre-test/post-test.
4-3 Evidence obtained from a quasi-random experiment performed in an artificial setting.
5 Evidence obtained from expert opinion based on theory or consensus.
Tabela 3.1: Hierarquia dos estudos para Engenharia de Software (KITCHENHAM, 2004, p.13)

3.1.8 MTODO DE AVALIAO DOS ESTUDOS

Cada artigo que atender aos critrios listados na subseo 3.1.6 ser lido e os estudos
selecionados sero avaliados de acordo com os critrios de qualidade estabelecidos na sub-
seo 3.1.7.Os artigos que se enquadrarem nesses critrios sero utilizados para a finalidade
deste estudo.
26

3.1.9 MTODO DE EXTRAO DOS DADOS

Para cada artigo que atender aos critrios listados na subseo 3.1.7 ser preenchido uma
cpia do formulrio de extrao de dados que ser apresentado no apndice C.

3.1.10 MTODO DE SNTESE DOS DADOS

Os dados dos estudos selecionados sero comparados, com a finalidade de realar as simi-
laridades e diferenas entre os estudos de acordo com as questes da pesquisa (ver apndice C)
. Foi considerada a idia de realizar meta-anlise sobre os dados quantitativos dos estudos, mas
como a quantidade de artigos encontrados foi muito baixa, a idia foi desconsiderada.

3.2 EXECUO DA REVISO SISTEMTICA

O processo de busca foi executado utilizando as combinaes de palavras-chave seguindo


o mtodo de pesquisa de fontes primrias do protocolo (subseo 3.1.5) e restringindo a busca
aos anos entre 1990 e 2007. Foram listados 489 artigos somando o material encontrados nas
duas bases eletrnicas de dados. Devido ao grande nmero de artigos encontrados, primeiro foi
feita uma pr-seleo a partir da leitura do resumo dos estudos. Os artigos que claramente eram
irrelevantes para a reviso foram descartados. Foram pr-selecionados 43 estudos, todos eles
abordavam estudos experimentais, testes, metodologias geis ou XP. Os formulrios de busca
podem ser vistos no apndice A.

Todos os artigos pr-selecionados estavam descritos em ingls e estavam disponveis na


WEB, atendendo trs dos critrios citados na subseo 3.1.6 (recentes, em ingls e disponveis
na WEB). Os artigos pr selecionados, ento, foram lidos e verificados atravs dos critrios
ainda no atendidos de incluso e excluso estabelecidos. A seleo foi documentada no for-
mulrio de seleo de estudos, juntamente com os critrios e se estes foram atendidos ou no
(apndice B). Dos 43 artigos pr-selecionados, 2 estavam de acordo com os critrios previstos
no protocolo de reviso e tiveram seus dados extrados e analisados (apndice C).

Relatrio sobre os artigos encontrados (ver critrios na subseo 3.1.6):

Estudos que no contemplavam estudos experimentais: 19

Estudos que contemplavam estudos experimentais, mas no utilizavam a metodologia


TDD: 19
27

2 abordavam testes contnuos;

3 abordam programao em par e inspeo de software;

1 adaptou a metodologia TDD para suas necessidades;

1 avaliava tcnicas de reduo de defeitos;

1 abordava a tcnica de desenvolvimento orientado a modelos;

1 focava na utilizao de prticas XP para ensinar programao orientada a objetos.

1 relacionava a qualidade de um software com a qualidade dos seu requisitos;

9 no tinham nenhum relao com o tema do trabalho;

Estudos experimentais que abordavam TDD: 5

2 foram includos na pesquisa;

1 foi excludo por relatar a mesma pesquisa que um arquivo j includo;

2 foram excludos porque analisavam a melhora na performance dos desenvolvedores


e o aumento da quantidade de testes, no os defeitos do software
28

4 RESULTADOS

Apenas dois artigos contemplaram todos os critrios de incluso e tiveram seus dados sin-
tetizados.

Os dois artigos, Evaluating the Efficacy of Test-Driven Development: Industrial Case


Studies e Test-Driven Development as a Defect-Reduction Practice tm em comum a inter-
veno utilizada (TDD), a populao avaliada (projetos de software) e o resultado (diminuio
na quantidade de defeitos). O primeiro artigo recebeu uma avaliao 3-1 e o segundo, 3-2 (ver
figura ??). Os contextos dos dois estudos foram diferentes. O primeiro envolvia grupos de de-
senvolvedores de 2 divises da Microsoft desenvolvendo projetos similares no mesmo perodo e
com diferentes tcnicas, enquanto que no segundo um grupo de desenvolvedores da IBM desen-
volveu utilizando TDD e o software resultante foi comparado com uma outra verso j existente
desenvolvida com outra tcnica. Em relao ao impacto na quantidade de defeitos, no primeiro
artigo a quantidade de defeitos utilizando TDD em uma das divises foi 2,6 vezes menor e na
outra diviso, 4,2 vezes menor. No segundo artigo, houve uma reduo de 40% na quantidade
de defeitos, comparando as duas verses.

4.1 DISCUSSO DOS RESULTADOS

O estudo Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies


(BHAT; NAGAPPAN, 2006) foi realizado em duas diferentes divises da Microsoft: Windows
e MSN. Em cada diviso, dois projetos foram selecionados e desenvolvidos por gerentes com
nveis semelhantes de responsabilidades que reportavam para um mesmo gerente com nvel
superior de responsabilidade. Em cada diviso, um dos projetos foi desenvolvido utilizando
TDD e o outro no. Os projetos foram analisados aps sua finalizao e os desenvolvedores
no sabiam que o trabalho deles seria avaliado. Isso foi feito para minimizar a influncia na
performance do desenvolvedor.

Como resultado, foi verificado que na diviso Windows, a quantidade de defeitos encontra-
29

dos no cdigo da equipe que no utilizou TDD foi 2.6 vezes superior outra equipe. Na diviso
MSN, o cdigo da equipe que no utilizou TDD apresentou quantidade de defeitos 4.2 vezes
superior equipe que utilizou a metodologia.

Para fazer avaliar os softwares produzidos, o estudo definiu defeito como sendo a ocorrncia
de uma anomalia externa visvel. As falhas foram normalizadas por milhares de linha de cdigo
(KLOC).

Os projetos foram realizados com programadores profissionais em diferentes plataformas e


ambientes. A figura 4.1 mostra que nas duas divises onde ocorreram o estudo, a qualidade do
cdigo nos dois sistemas desenvolvidos com TDD foi pelo menos duas vezes superior qual-
idade do sistemas desenvolvidos com outra tcnica. Tambm ilustra o acrscimo no tempo de
desenvolvimento do software. Isto sugere que ao utilizar o TDD, o desenvolvedor perceber um
aumento de qualidade do cdigo e um acrscimo no tempo de desenvolvimento, provavelmente
aumentando os custos do software.

Figura 4.1: Grfico dos resultados obtidos a partir do estudo na Microsoft - (BHAT; NAGAP-
PAN, 2006, p.361)

O estudo Test-Driven Development as a Defect-Reduction Practice (VOUK, 17-20 Nov.


2003) relata que um grupo de desenvolvedores da IBM desenvolve drivers de dispositivos h
mais de uma dcada e um dos produtos produzidos por esse grupo, que j teve sete lanamentos
desde 1998 foi usado como base para o estudo. Em 2002, uma parte do grupo desenvolveu
drivers de dispositivos em uma nova plataforma utilizando TDD. O estudo compara o stimo
lanamento desse driver na antiga plataforma com o primeiro lanamento na nova plataforma.

Como resultado, foi verificado que o driver desenvolvido com a metodologia TDD apresen-
tou uma reduo de 40% na taxa de defeito comparado ao driver de dispositivo desenvolvido
com outra metodologia.
30

Para verificar os defeitos, foi executado um teste de Verificao Funcional (FVT) por um
grupo de testes depois da produo do cdigo. Os testes de verificao funcional analisa os
componentes do software e os testam para observar se elas operam como uma unidade e se
executam todas as funes que deveriam. Os defeitos tambm foram normalizadas por milhares
de linha de cdigo (KLOC).

Alguns detalhes devem ser considerados na avaliao dos resultados deste estudo.

Os dispositivos no produto antigo deveriam funcionar em duas plataformas (Windows e


Linux), mas o driver novo precisa funcionar apenas no Linux.

Como o driver antigo funcionava em mais plataformas de hardware que o novo, os casos
de teste foram executados em cada plataforma.

O driver antigo suporta mais dispositivos.

A figura 4.2 ilustra a densidade das falhas observadas no estudo. Ela mostra que a densidade
das falhas encontradas no novo driver significativamente menor que o driver antigo (legado).

Figura 4.2: Densidade dos defeitos encontrados no estudo na IBM - (VOUK, 17-20 Nov. 2003,
p.7)

Como a quantidade de estudos encontrados foram poucos, no possvel afirmar que a


utilizao da tcnica de desenvolvimento TDD diminui a quantidade de defeitos na aplicao
mas sugerem que a utilizao dessa tcnica resultar num software com maior qualidade.

Analisando os artigos que foram descartados (apndice B) e a pequena quantidade de arti-


gos selecionados, essa reviso sistemtica indica que h pesquisas sobre XP, mtodos geis e
TDD, mas h uma carncia de estudos experimentais que indiquem o impacto no uso de TDD
na quantidade de defeitos encontrados em aplicaes. Algumas pesquisas focam na quantidade
31

de testes e na produtividade do desenvolvedor e no na quantidade de defeitos, objetivo desta


reviso sistemtica.
32

5 CONCLUSO

5.1 USO DE REVISO SISTEMTICA

Esta reviso sistemtica foi conduzida a partir de um protocolo que especificou os mtodos
que foram utilizados para a conduo do trabalho. A definio do protocolo foi essencial para
permitir a conduo da pesquisa. Como todos os detalhes da conduo da pesquisa foram
definidos no incio da reviso, isso impediu que o foco fosse desviado da reviso sistemtica, j
que apenas foram lidos e estudados os artigos relevantes pesquisa.

Os critrios definidos no protocolo e utilizados para a seleo dos estudos foram necessrios
e suficientes para obter apenas os estudos que podiam responder s questes da pesquisa. A
utilizao de formulrios foi importante para documentar a reviso e permitir que os dados dos
estudos fossem sintetizados e analisados mais facilmente. Houve dificuldade para adaptar as
strings de busca, j que as bases eletrnicas de dados no permitem que as buscas sejam feitas
da mesma forma.

5.2 TDD X QUANTIDADE DE DEFEITOS

Como foi encontrado um nmero reduzido de estudos, esta reviso sistemtica no teve
dados suficientes para analisar o impacto da utilizao da tcnica TDD na quantidade de defeitos
no software final. Os poucos estudos encontrados obtiveram os mesmos resultados, revelando
que h uma tendncia diminuio da quantidade de defeitos com a utilizao de TDD no
desenvolvimento.

Em um dos estudos analisados foi verificado que o tempo de desenvolvimento utilizando


a tcnica TDD foi maior que quando no utilizada. E em alguns estudos que no foram sele-
cionados para essa reviso foi verificado que houve um aumento na produtividade dos desen-
volvedores e na quantidade de testes executados.
33

5.3 CONTRIBUIES DO TRABALHO

A reviso sistemtica prov os meios para executar revises de literatura abrangentes e no


tendenciosas, mas ainda muito pouco difundido na rea da computao. Este trabalho mostra
que podem ser feitas revises sistemticas na rea de engenharia de software, reunindo de forma
sistemtica e passvel de reproduo evidncias existentes sobre um fenmeno e identificando
lacunas nas pesquisas atuais.

A quantidade de artigos selecionados nesta reviso sistemtica mostra que, apesar de TDD
ser uma tcnica utilizada por muitos desenvolvedores, necessrio que haja mais pesquisas
sobre o impacto da utilizao desta tcnica em projetos de desenvolvimento.
34

APNDICE A -- FORMULRIO DE
CONDUO DA REVISO

Fonte da busca Portal ACM


Endereo virtual http://portal.acm.org/
Data da busca 22/10/2007
String de busca ("software development", "software process", "software
project") +("development test", "test", "tests", "software
test", "tdd", "test driven development", "test-driven devel-
opment", "test driven-development, "tfd", "test first devel-
opment", "test first design") +("errors", "error", "error de-
tection", "error identification", failure", "defect")
Perodo dos artigos 1990 a 2007
Quantidade encontrada 15636 artigos. Destes, os 200 mais relevantes (critrio do
portal) foram listados.
Quantidade de arquivos 12
pr-selecionados
Fonte da busca IEEE Xplore
Endereo virtual http://ieeexplore.ieee.org/
Data da busca 22/10/2007
String de busca (software development<or>software process<or>software
project) <and> (development test <or> test <or> tests
<or> software test <or> tdd <or> test driven development
<or> test-driven development <or> test driven-development
<or>tfd <or> test first development <or> test first design)
<and> (errors <or> error <or> error detection <or> error
identification <or> failure <or> defect)
Perodo dos artigos 1990 a 2007
35

Quantidade encontrada 289 artigos


Quantidade de arquivos 31
pr-selecionados
36

APNDICE B -- FORMULRIO DE SELEO


DE ESTUDOS

OBS:

Critrio 4: Contempla a execuo de estudos experimentais.

Critrio 5: Aborda o uso da metodologia TDD no desenvolvimento de softwares e a


quantidade de defeitos ao final do desenvolvimento.

Nome do artigo Evaluating Advantages of Test Driven Development: a


Controlled Experiment with Professionals
Lista de autores Gerardo Canfora, Aniello Cimitile, Felix Garcia, Mario Pi-
attini, Corrado Aaron Visaggio
Data de publicao Setembro, 2006
Veculo de publicao ACM Press
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 O artigo aborda o uso da metodologia TDD, mas no a
quantidade de erros do software e sim a produtividade
dos desenvolvedores e a quantidade e qualidade dos testes
unitrios.
Nome do artigo Assessing Undergraduate Experience of Continuous Inte-
gration and Test-Driven Development
Lista de autores Jon Bowyer, Janet Hughes
Data de publicao Maio, 2006
Veculo de publicao ACM Press
37

Fonte Portal ACM


Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 O artigo avalia a participao e performance dos alunos ao
desenvolver utilizando uma metodologia gil, e no a quan-
tidade de erros do software.
Nome do artigo An Experimental Evaluation of Continuous Testing During
Development
Lista de autores David Saff, Michael D. Ernst
Data de publicao Julho, 2004
Veculo de publicao ACM Press
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. Os desenvolvedores precisavam testar continuamente,
mas no necessariamente testar antes de codificar (TDD).
Nome do artigo Adopting XP Practices for Teaching Object Oriented Pro-
gramming
Lista de autores Karen Keefe, Judithe Sheard, Martin Dick
Data de publicao Janeiro, 2006
Veculo de publicao Australian Computer Society, Inc
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 O foco do artigo a utilizao de prticas XP para ensinar
programao orientada a objetos.
Nome do artigo Software Testing Research: Achievements, Challenges,
Dreams
Lista de autores Antonia Bertolino
Data de publicao Maio, 2007
Veculo de publicao ICSE 2007: Future of Software Engineering
38

Fonte Portal ACM


Situao do artigo (includo excludo
ou excludo)
Critrio 4 No, um artigo terico.
Critrio 5 No. O artigo apresentas os desafios atuais e futuros dos
testes de software.
Nome do artigo On the Economic Evaluation of XP Projects
Lista de autores Matthias M. Muller, Frank Padberg
Data de publicao Setembro, 2003
Veculo de publicao ACM Press
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No, um artigo terico.
Critrio 5 No. O artigo apresenta um modelo para estudar o impacto
das prticas XP.
Nome do artigo Unit Testing: Test Early, Test Often
Lista de autores Michael Olan
Data de publicao Dezembro, 2003
Veculo de publicao Consortium for Computing Sciences in Colleges
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No, um artigo terico.
Critrio 5 No. O artigo apresenta a necessidade de testes unitrios
em todo o desenvolvimento do processo.
Nome do artigo Rethinking Computer Science Education from a Test-first
Perspective
Lista de autores Stephen H. Edwards
Data de publicao Outubro, 2003
Veculo de publicao ACM Press
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
39

Critrio 4 No. O artigo mostra uma nova viso para a cincia da


computao, centrada no uso de TDD.
Critrio 5 No. O artigo no desenvolve um estudo de caso com TDD.
Nome do artigo Experiences Using Test-Driven Development With An Au-
tomated Grader
Lista de autores Stephen H. Edwards, Manuel A. Prez-Quiones
Data de publicao Janeiro, 2007
Veculo de publicao Consortium for Computing Sciences in Colleges
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No.
Critrio 5 No. O artigo relata a experincia de testes em uma sala de
aula.
Nome do artigo An Empirical Comparison Between Pair Development and
Software Inspection in Thailand
Lista de autores Monvorath Phongpaibul, Barry Boehm
Data de publicao Setembro, 2006
Veculo de publicao ACM Press
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo apresenta experimentos para comparar pro-
gramao em par e inspeo de software como tcnicas de
diminuio de erros.
Nome do artigo Assessing Test-Driven Development at IBM
Lista de autores E. Michael Maximilien and Laurie Williams
Data de publicao Maio, 2003
Veculo de publicao Proceedings of the 25th International Conference on Soft-
ware Engineering
Fonte Portal ACM
Situao do artigo (includo excludo
ou excludo)
40

Critrio 4 Sim.
Critrio 5 Sim. Foi excludo, pois o artigo aborda o mesmo estudo
de caso relatado noartigo "Test-Driven Development as a
Defect-Reduction Practice".
Nome do artigo Evaluating the Efficacy of Test-Driven Development: In-
dustrial Case Studies
Lista de autores Thirumalesh Bhat, Nachiappan Nagappan
Data de publicao Setembro, 2006
Veculo de publicao Proceedings of the 2006 ACM/IEEE international sympo-
sium on International symposium on empirical software en-
gineering
Fonte Portal ACM
Situao do artigo (includo includo
ou excludo)
Critrio 4 Sim.
Critrio 5 Sim.
Nome do artigo Improving the Software Development Process Using Testa-
bility Research
Lista de autores Jeffrey M. Voas and Keith W. Miller
Data de publicao Outubro, 1992
Veculo de publicao Proceedings on Third International Symposium on Soft-
ware Reliability Engineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Attitude Towards Testing: A Key Contributor to Software
Quality
Lista de autores S. Murugesan
Data de publicao Dezembro, 1994
Veculo de publicao Conference Proceedings on First International Conference
on Software Testing, Reliability and Quality Assurance
Fonte IEEE Xplore
41

Situao do artigo (includo excludo


ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Towards A Zero-Defect Product - The End-To-End Test
Process
Lista de autores Rathna K. Prasad
Data de publicao Dezembro, 1994
Veculo de publicao Conference Proceedings on First International Conference
on Software Testing, Reliability and Quality Assurance
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Controlling Software Reliability EDuring Development
Lista de autores Gerald W. Baumann
Data de publicao Novembro, 1993
Veculo de publicao Proceedings on Fourth International Symposium on Soft-
ware Reliability Engineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no aborda o uso da tcnica TDD
Nome do artigo Test Case Design Based on Z and the Classification-Tree
Method
Lista de autores Harbhajan Singh, Mirko Conrad, Sadegh Sadeghipour
Data de publicao Novembro, 1997
Veculo de publicao Proceedings on First IEEE International Conference on For-
mal Engineering Methods
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
42

Critrio 4 No. O artigo possui uma abordagem terica.


Critrio 5 No.
Nome do artigo "Continuous Verification"in Mission Critical Software De-
velopment
Lista de autores Tien-fu Chang, Alejandro Danylyzsn, So Norimatsu,Jose
Rivera, David Shepard, Anthony Lattanze, Dr. James
Tomayko
Data de publicao Janeiro, 1997
Veculo de publicao Proceedings of the Thirtieth Hawaii International Confer-
ence on System Sciences
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no aborda o uso da tcnica TDD.
Nome do artigo Improving Defect Removal Effectiveness for Software De-
velopment
Lista de autores Hareton K. N. Leung
Data de publicao Maro, 1998
Veculo de publicao Proceedings of the Second Euromicro Conference on Soft-
ware Maintenance and Reengineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Managing Cyclical Software Development
Lista de autores Anthony J Lattanze, Manuel Rosso-Llopart
Data de publicao Outubro, 1998
Veculo de publicao Proceedings of Pioneering New Technologies: Manage-
ment Issues and Challenges in the Third Millennium on
International Conference on Engineering and Technology
Management
Fonte IEEE Xplore
43

Situao do artigo (includo excludo


ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Studying the Effects of Code Inspection and Structural Test-
ing on Software Quality
Lista de autores Oliver Laitenberger
Data de publicao Novembro, 1998
Veculo de publicao Proceedings of The Ninth International Symposium on
Software Reliability Engineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no aborda o uso da tcnica TDD.
Nome do artigo Integrating Pair Programming into a Software Development
Process
Lista de autores Laurie Williams
Data de publicao Fevereiro, 2001
Veculo de publicao Proceedings of 14th Conference on Software Engineering
Education and Training
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo A Formal Model of the Software Test Process
Lista de autores Joao W. Cangussu, Raymond A. DeCarlo and Aditya P.
Mathur
Data de publicao Agosto, 2002
Veculo de publicao IEEE Computer Society
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
44

Critrio 4 No. O artigo possui uma abordagem terica.


Critrio 5 No.
Nome do artigo Test and Development Process Retrospective - a Case Study
using ODC Triggers
Lista de autores Ram Chillarege, Kothanda Ram Prasad
Data de publicao Junho, 2002
Veculo de publicao Proceedings of International Conference Dependable Sys-
tems and Networks
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no utiliza a tcnica TDD.
Nome do artigo Hypothesis Testing for Module Test in Software Develop-
ment
Lista de autores Tsuneo Yamaura, Akira K. Onoma
Data de publicao Setembro, 2006
Veculo de publicao Annual India Conference
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo On Estimating Testing Effort Needed to Assure Field Qual-
ity in Software Development
Lista de autores Osamu Mizuno, Eijiro Shigematsu, Yasunari Takagi and
Tohru Kikuno
Data de publicao Novembro, 2002
Veculo de publicao Proceedings of 13th International Symposium on Software
Reliability Engineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
45

Critrio 5 No.O artigo no utiliza a tcnica TDD.


Nome do artigo An Investigation of the Applicability of Design of Experi-
ments to Software Testing
Lista de autores D. Richard Kuhn, Michael J. Reilly
Data de publicao Dezembro, 2002
Veculo de publicao Proceedings of 27th Annual NASA Goddard/IEEE Soft-
ware Engineering Workshop
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Reducing wasted development time via continuous testing
Lista de autores David Saff, Michael D. Ernst
Data de publicao Novembro, 2003
Veculo de publicao 14th International Symposium on Software Reliability En-
gineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Breeding Software Test Cases for Complex Systems
Lista de autores A. Watkins, D. Berndt, K. Aebischer, J. Fisher and L. John-
son
Data de publicao Janeiro, 2004
Veculo de publicao Proceedings of the 37th Annual Hawaii International Con-
ference on System Sciences
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no utiliza a tcnica TDD.
46

Nome do artigo The Importance of Life Cycle Modeling to Defect Detection


and Prevention
Lista de autores A. Watkins, D. Berndt, K. Aebischer, J. Fisher and L. John-
son
Data de publicao Janeiro, 2004
Veculo de publicao Proceedings of 10th International Workshop on Software
Technology and Engineering Practice
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no utiliza a tcnica TDD.
Nome do artigo Establishment of Automated Regression Testing at ABB:
Industrial Experience Report on "Avoiding the Pitfalls"
Lista de autores Christer Persson, Nur Yilmaztrk
Data de publicao Setembro, 2004
Veculo de publicao Proceedings of 19th International Conference on Auto-
mated Software Engineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no utiliza a tcnica TDD.
Nome do artigo Using the Information: Incorporating Positive Feedback In-
formation into the Testing Process
Lista de autores Kwok Ping Chan, Dave Towey, Tsong Yueh Chen, Fei-
Ching Kuo
Data de publicao Setembro, 2003
Veculo de publicao Eleventh Annual International Workshop on Software Tech-
nology and Engineering Practice
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
47

Critrio 5 No.
Nome do artigo A Control Approach for Agile Processes
Lista de autores Joo W. Cangussu, Richard M. Karcich
Data de publicao Julho, 2005
Veculo de publicao 29th Annual International Computer Software and Applica-
tions Conference
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo possui uma abordagem terica.
Critrio 5 No.
Nome do artigo Studying the Fault-Detection Effectiveness of GUI Test
Cases for Rapidly Evolving Software
Lista de autores Atif M. Memon, Qing Xie
Data de publicao Outubro, 2005
Veculo de publicao IEEE Transactions on Software Engineering
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no utiliza a tcnica TDD.
Nome do artigo Model-based Testing Considering Cost, Reliability and
Software Quality
Lista de autores Chaw Yupar Htoon, Ni Lar Thein
Data de publicao Novembro, 2005
Veculo de publicao Proceedings of 6th Asia-Pacific Symposium on Information
and Telecommunication Technologies
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no utiliza a tcnica TDD.
48

Nome do artigo Optimize Defect Detection Techiniques through Empirical


Software Engineering Method
Lista de autores Hai Tao Sun
Data de publicao Novembro, 2005
Veculo de publicao IEEE International Conference on Electro Information
Technology
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo analisa as tcnicas de deteco de erros.
Nome do artigo Agile Software Testing in a Large-Scale Project
Lista de autores David Talby, Arie Keren, Orit Hazzan, Yael Dubinsky
Data de publicao Julho/Agosto, 2006
Veculo de publicao IEEE Computer Society
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo foca no estudo com mtodos geis e adap-
taram o TDD para suas necessidades.
Nome do artigo Test-Driven Development in Large Projects
Lista de autores Raghvinder S. Sangwan, Phillip A. Laplante
Data de publicao Setembro/Outubro, 2006
Veculo de publicao IT Professional
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 No. O artigo apresenta um estudo terico.
Critrio 5 No.
Nome do artigo Test Case Prioritization Using Relevant Slices
Lista de autores Dennis Jeffrey, Neelam Gupta
Data de publicao Setembro, 2006
49

Veculo de publicao 30th Annual International Computer Software and Applica-


tions Conference
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo no aborda o uso da metodologia TDD.
Nome do artigo An Empirical Study on the Relationship between Defective
Requirements and Test Failures
Lista de autores Robert W. Ferguson, Giuseppe Lami
Data de publicao Abril, 2006
Veculo de publicao 30th Annual IEEE/NASA Software Engineering Workshop
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo faz uma anlise sobre a relao entre a quali-
dade dos softwares e a qualidade dos requisitos usados para
criar os softwares.
Nome do artigo Using Model-Driven Development in Time-Constrained
Course Projects
Lista de autores Wilson Pdua
Data de publicao Julho, 2007
Veculo de publicao 20th Conference on Software Engineering Education and
Training
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 No. O artigo utiliza a tcnica Model-Driven Development.
Nome do artigo Experiences of Using Pair Programming in an Agile Project
Lista de autores Jari Vanhanen and Harri Korpi
Data de publicao Janeiro, 2007
50

Veculo de publicao 40th Annual Hawaii International Conference on System


Sciences
Fonte IEEE Xplore
Situao do artigo (includo excludo
ou excludo)
Critrio 4 Sim.
Critrio 5 Apesar de alguns utilizarem TDD, o estudo foca na progra-
mao em par, por isso, esse artigo foi excludo.
Nome do artigo Test-Driven Development as a Defect-Reduction Practice
Lista de autores Williams, L. and Maximilien and E.M., Vouk, M.
Data de publicao Novembro, 2003
Veculo de publicao 14th International Symposium on Software Reliability En-
gineering
Fonte IEEE Xplore
Situao do artigo (includo includo
ou excludo)
Critrio 4 Sim.
Critrio 5 Sim.
51

APNDICE C -- FORMULRIO DE EXTRAO


DE DADOS

Ttulo Evaluating the Efficacy of Test-Driven Development: In-


dustrial Case Studies
Lista de autores Thirumalesh Bhat, Nachiappan Nagappan
Data de publicao Setembro, 2006
Veculo de publicao Proceedings of the 2006 ACM/IEEE international sympo-
sium on International symposium on empirical software en-
gineering
Fonte Portal ACM
Abstract do artigo This paper discusses software development using the Test
Driven Development (TDD) methodology in two different
environments (Windows and MSN divisions) at Microsoft.
In both these case studies we measure the various context,
product and outcome measures to compare and evaluate the
efficacy of TDD. We observed a significant increase in qual-
ity of the code (greater than two times) for projects devel-
oped using TDD compared to similar projects developed in
the same organization in a non-TDD fashion. The projects
also took at least 15extra upfront time for writing the tests.
Additionally, the unit tests have served as auto documenta-
tion for the code when libraries/APIs had to be used as well
as for code maintenance.
Objetivo do estudo Discutir o desenvolvimento de software utilizando a
metodologia TDD em dois ambientes diferentes na Mi-
crosoft (divises do Windows e MSN).
52

Descrio do estudo experi- O estudo de caso foi realizado em duas diferentes divises
mental da Microsoft, Windows e MSN. Em cada diviso, dois pro-
jetos foram selecionados e desenvolvidos por gerentes com
nveis semelhantes de responsabilidades que reportavam
para um mesmo gerente com nvel superior de responsabil-
idade. Em cada diviso, um dos projetos foi desenvolvido
utilizando TDD e o outro no. Os projetos foram analisados
aps sua finalizao e os desenvolvedores no sabiam que o
trabalho deles seria avaliado. Isso foi feito para minimizar
a influncia na performance do desenvolvedor.
Resultados Na diviso Windows, a quantidade de defeitos encontrados
no cdigo da equipe que no utilizou TDD foi 2.6 vezes su-
perior outra equipe. Na diviso MSN, o cdigo da equipe
que no utilizou TDD apresentou quantidade de defeitos 4.2
vezes superior equipe que utilizou a metodologia.
Comentrios Para fazer a avaliao, o estudo definiu defeito como sendo
a ocorrncia de uma anomalia externa visvel. As fal-
has foram normalizadas por milhares de linha de cdigo
(KLOC).
Ttulo Test-Driven Development as a Defect-Reduction Practice
Lista de autores Williams, L. and Maximilien and E.M., Vouk, M.
Data de publicao Novembro, 2003
Veculo de publicao 14th International Symposium on Software Reliability En-
gineering
Fonte IEEE Xplore
53

Abstract do artigo Test-driven development is a software development practice


that has been used sporadically for decades. With this prac-
tice, test cases (preferably automated) are incrementally
written before production code is implemented. Test-driven
development has recently re-emerged as a critical enabling
practice of the Extreme Programming software develop-
ment methodology. We ran a case study of this practice
at IBM. In the process, a thorough suite of automated test
cases was produced after UML design. In this case study,
we found that the code developed using a test-driven devel-
opment practice showed, during functional verification and
regression tests, approximately 40traditional fashion. The
productivity of the team was not impacted by the additional
focus on producing automated test cases. This test suite will
aid in future enhancements and maintenance of this code.
The case study and the results are discussed in detail.
Objetivo do estudo Examinar a eficcia de TDD como uma forma de diminuir
a quantidade de erros num software.
Descrio do estudo experi- Um grupo de desenvolvedores da IBM desenvolve drivers
mental de dispositivos h mais de uma dcada e um dos produ-
tos produzidos por esse grupo, que j teve sete lanamentos
desde 1998 foi usado como base para o estudo. Em 2002,
uma parte do grupo desenvolveu drivers de dispositivos em
uma nova plataforma. O estudo compara o stimo lana-
mento desse driver na antiga plataforma com o primeiro
lanamento na nova plataforma.
Resultados Utilizando a metodologia TDD, houve uma reduo de 40na
taxa de erro comparado ao driver de dispositivo desen-
volvido com outra metodologia.
Comentrios Para verificar os erros, foi executado um teste de Verificao
Funcional (FVT) por um grupo de testes depois da produo
do cdigo. Os erros foram normalizadas por milhares de
linha de cdigo (KLOC).
54

REFERNCIAS BIBLIOGRFICAS

ASTELS, D. Test Driven Development: A Practical Guide. [S.l.]: Pearson, 2003.

BECK, K. EXtreme Programming Explained. [S.l.]: Addison-Wesley Professional, 2000.

BECK, K. Test Driven Development: By Example. [S.l.]: Addison-Wesley Professional, 2003.

BEEDLE, M. et al. Manifesto for Agile Software Development. 2001. Disponivel em


http://agilemanifesto.org/principles.html. ltimo acesso em 12/12/2007.

BHAT, T.; NAGAPPAN, N. Evaluating the efficacy of test-driven development: industrial case
studies. ACM, New York, NY, USA, p. 356363, 2006. Disponvel em http://portal.acm.org.
ltimo acesso em 12/12/2007.

FOWLER, M. Refactoring: Improving the Design of Existing Code. [S.l.]: Addison-Wesley,


2001.

JEFFRIES, R. XProgramming.com: an Agile Software Development Resource. 2007.


Disponvel em http://www.xprogramming.com/. ltimo acesso em 12/12/2007.

KITCHENHAM, B. Procedures for performing systematic reviews. Keele University, UK,


Technical Report, p. 13537776, 2004. Disponvel em http://portal.acm.org. ltimo acesso em
12/12/2007.

NAUR, P.; RANDELL, B. Software Engineering: A report on a Conference Sponsored by the


NATO Science Committee. [S.l.], 1969.

PRESSMAN, R. S. Engenharia de Software. [S.l.]: MAKRON Books, 2005.

SOMMERVILLE, I. Software Engineering. [S.l.]: Addison Wesley Professional, 2003.

VOUK, L. W. E. M. M. Test-driven development as a defect-reduction practice. Software


Reliability Engineering, 2003. ISSRE 2003. 14th International Symposium on, p. 3445, 1720
Nov. 2003. ISSN 1071-9458. Disponvel em http://ieeexplore.ieee.org. ltimo acesso em
12/12/2007.