55
UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Daniela Soares Feitosa Um estudo sobre o impacto do uso de desenvolvimento orientado por testes na melhoria da qualidade de software Salvador 2007

Monografia TDD

Embed Size (px)

Citation preview

Page 1: Monografia TDD

UNIVERSIDADE FEDERAL DA BAHIAINSTITUTO DE MATEMÁTICA

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO

Daniela Soares Feitosa

Um estudo sobre o impacto do uso de

desenvolvimento orientado por testes na melhoria

da qualidade de software

Salvador

2007

Page 2: Monografia TDD

Daniela Soares Feitosa

Monografia apresentada ao Curso degraduação em Ciência da Computação,Departamento de Ciência da Computação,Instituto de Matemática, Universidade Fed-eral da Bahia, como requisito parcial paraobtenção do grau de Bacharel em Ciência daComputação.

Orientador:Antonio Soares de Azevedo Terceiro

Salvador

2007

Page 3: Monografia TDD

A Deus, pela minha vida.

A todos que contribuíram direta ou indiretamente para a realização deste projeto.

Page 4: Monografia TDD

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 motivação, suporte e exemplo que me deram.

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

Ao meu namorado Helder, pelo incentivo, paciência e companhia em todos os momentos.

A Terceiro, por toda ajuda e orientação que me deu durante esse semestre.

A todos os meus amigos que sempre me dão apoio.

Page 5: Monografia TDD

RESUMO

O desenvolvimento de software orientado por testes (TDD - Test Driven Development) éuma das técnicas utilizadas no modelo de programação XP - eXtreme Programming, cujo usotem aumentado bastante. Esta técnica tem como um de seus objetivos antecipar a identificaçãode defeitos durante o desenvolvimento do software e, para isso, os testes são feitos antes daimplementação do código. Esse tipo de desenvolvimento ajuda os desenvolvedores a focar nafuncionalidade das aplicações e a disponibilidade de testes antes do desenvolvimento permiteum rápido retorno após qualquer alteração. Este trabalho é uma revisão sistemática que temcomo objetivo analisar se a utilização desta técnica diminui a quantidade de defeitos numaaplicação, melhorando sua qualidade e confiança.

Palavras-chave: engenharia de software, desenvolvimento orientado por testes, revisãosistemática.

Page 6: Monografia TDD

ABSTRACT

Test Driven Development is one of the techniques used in the practices of XP - eXtremeProgramming, whose use has increased significantly. This technique has as one of its goalsto previously identify defects during software development and, therefore, the tests are writtenprior to implementation of the code. This type of development help developers to focus onthe functionality of applications and the availability of tests before the development allows arapid feedback. This work is a systematic review that aims to examine whether the use of thistechnique reduces the amount of defects in an application, improving its quality and reliability.

Keywords: software engineering, test-driven development, systematic review.

Page 7: Monografia TDD

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 Gráfico 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

Page 8: Monografia TDD

LISTA DE ABREVIATURAS E SIGLAS

CASE Computer-Aided Software Engineering, p. 12

TDD Test-Driven Development, p. 17

XP eXtreme Programming, p. 19

Page 9: Monografia TDD

SUMÁRIO

1 Introdução 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 Práticas 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 Descrição do problema . . . . . . . . . . . . . . . . . . . . . . . . . . 23

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

3.1.3 Questões da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

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

3.1.5 Método utilizado para pesquisa de fontes primárias . . . . . . . . . . . 24

3.1.6 Critério de seleção dos estudos . . . . . . . . . . . . . . . . . . . . . . 24

3.1.7 Critério de qualidade dos estudos . . . . . . . . . . . . . . . . . . . . 25

3.1.8 Método de avaliação dos estudos . . . . . . . . . . . . . . . . . . . . . 25

3.1.9 Método de extração dos dados . . . . . . . . . . . . . . . . . . . . . . 26

Page 10: Monografia TDD

3.1.10 Método de síntese dos dados . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Execução da Revisão Sistemática . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Resultados 28

4.1 Discussão dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Conclusão 32

5.1 Uso de revisão sistemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

5.3 Contribuições do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Apêndice A -- Formulário de condução da revisão 34

Apêndice B -- Formulário de seleção de estudos 36

Apêndice C -- Formulário de extração de dados 51

Referências Bibliográficas 54

Page 11: Monografia TDD

10

1 INTRODUÇÃO

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

diferentes questões. Entre elas, destaca-se uma das mais difíceis de ser respondida, que é como

garantir a qualidade do software. Testes sistemáticos e tecnicamente completos são 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 código 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 indicarão a qualidade do

software (PRESSMAN, 2005).

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

três desafios principais neste século:

• 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 viável e garantindo a entrega dos serviços prestados por estes

sistemas;

• Heterogeneidade: O software desenvolvido deve ser confiável e flexível o bastante para

ser bem-sucedido em diferentes combinações de hardware e software;

• Entrega: O aumento da complexidade do software e diminuição dos prazos de entrega

comprometem a qualidade do software;

A importância 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 possível solução para este problema.

TDD já é usada informalmente por bons programadores a muito tempo, mas as primeiras

tentativas de definí-la como uma prática de desenvolvimento começaram no final de 2002, com

Page 12: Monografia TDD

11

as publicações de Kent Beck (BECK, 2003) e David Astels (ASTELS, 2003). Esta técnica

consiste em implementar testes para cada nova funcionalidade do software antes mesmo de

implementá-la. Os testes deverão ser executados regularmente para verificar se o código imple-

mentado após cada teste está correto. Essa forma de desenvolver ajuda os desenvolvedores a

focar na funcionalidade das aplicações e, caso os testes passem, o desenvolvedor saberá que o

código foi bem implementado, garantindo a qualidade da aplicação.

TDD ajuda os desenvolvedores a focar na funcionalidade das aplicações e a disponibilidade

de testes antes do desenvolvimento permite um rápido feedback. Entretanto, não é garantido

que a quantidade de defeitos diminuirá.

Neste trabalho, foi conduzida uma revisão sistemática com o objetivo de analisar se a uti-

lização de TDD diminui a quantidade de defeitos no software, comparando com outras técnicas

de desenvolvimento. Para isso, alguns estudos que obtiveram resultados experimentais foram

identificados, analisados e avaliados como proposto em (KITCHENHAM, 2004).

Em função do número reduzido de estudos específicos sobre o impacto de TDD na quanti-

dade de defeitos no software, não é possível estatisticamente afirmar que há uma diminuição na

quantidade de defeitos, apesar dessa ser uma tendência apontada por esses mesmos estudos.

Este trabalho encontra-se dividido em 5 capítulos. O capítulo 2 fará uma introdução sobre

os principais conceitos envolvendo TDD. O capítulo 3 descreve a metodologia utilizada, apre-

sentando detalhadamente o protocolo e a condução da revisão. O capítulo 4 apresenta os resul-

tados obtidos da revisão. O capítulo 5 apresenta as conclusões. E, finalmente, os formulários

utilizados na condução da revisão são apresentados nos apêndices A, B e C.

Page 13: Monografia TDD

12

2 CONCEITOS

Neste capítulo serão apresentados os resumos dos conceitos necessários para o entendi-

mento deste trabalho: Engenharia de Software, Testes de software e Test Driven Development.

2.1 ENGENHARIA DE SOFTWARE

Uma primeira definição de engenharia de software foi proposta por Fritz Baur na primeira

conferência dedicada ao assunto (NAUR; RANDELL, 1969 apud PRESSMAN, 2005): “Engen-

haria de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter

software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas

reais”. A criação da engenharia de software surgiu numa tentativa de contornar a crise do soft-

ware e dar um tratamento mais sistemático e controlado ao desenvolvimento de sistemas de

software complexos.

A engenharia de software é a área da computação que se preocupa com todos os aspectos da

produção de software e procura garantir a qualidade do software desenvolvido. Segundo Press-

man (PRESSMAN, 2005), ela é composta por um conjunto de três elementos fundamentais:

métodos, ferramentas e processos, que possibilita o controle do processo de desenvolvimento

do software.

Os métodos provêm os detalhes de como fazer a implementação do software e incluem

os modelos, a especificação do software, guia do processo e um conjunto de critérios 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 análise de requisitos e modelagem até programação e testes.

Os processos constituem a interação dos métodos, ferramentas e pessoas. Eles definem a

sequência de práticas que será utilizada para o desenvolvimento, garantia de qualidade e entrega

Page 14: Monografia TDD

13

dos produtos (documentos, relatórios, formulários etc). Estas práticas englobam as atividades

de especificação, desenvolvimento, validação e evolução.

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 ações que vão

do levantamento de requisitos até a execução do teste propriamente dito. Segundo Sommerville

(SOMMERVILLE, 2003), teste de software é uma técnica de verificação e validação.

Verificação e validação são processos de checagem e análise de software. O objetivo da

verificação é mostrar se um programa está de acordo com a especificação e a validação mostra

se um programa faz o que o cliente/usuário deseja.

Um erro de software é um erro de implementação no código e um defeito de software é a

manifestação de um ou mais erros, fazendo com que o software não execute da forma esperada.

Testes de software revelam a presença de defeitos.

O teste é considerado bom se revela um ou mais defeitos. Teste de software não pode

provar a ausência de defeitos, pode apenas mostrar a presença de defeitos, por isso seu objetivo

é executar um programa com a intenção de revelar a presença de defeitos, e não a sua ausência.

Após a realização de um teste, o resultado deve ser avaliado e comparado ao resultado esperado.

Caso os resultados sejam diferentes, chega-se à conclusão que há defeitos e que deve ser feita a

depuração.

A maioria dos softwares possuem defeitos, então, para promover um ambiente mais estável

para o usuário final, é importante que a maioria desses defeitos não sejam críticos. Os testes de

software tentam garantir que a qualidade, o custo, a segurança e a confiabilidade do software

não sejam prejudicados pela presença 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, são feitos os testes de componentes e na segunda fase, os testes de

integração.

Durante a fase de testes de componentes duas técnicas de testes são muito utilizadas:

• Teste da caixa-preta: Dados de entrada são fornecidos, o teste é executado e o resultado

Page 15: Monografia TDD

14

obtido é comparado a um resultado esperado previamente conhecido. É chamado de

caixa-preta porque o comportamento interno do componente não é considerado, apenas

as entradas e saídas fornecidas pelo componente são conhecidas.

• Teste da caixa-branca: Também é chamado de teste estrutural, pois avalia a estrutura e

implementação 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 interação dos componentes não apresenta problemas são feitos os testes de inte-

gração. Estes testes são aplicados na construção da estrutura do programa, realizando testes

para descobrir defeitos associados às interfaces entre os componentes, verificando se todos os

componentes funcionarão corretamente quando estiverem integrados.

A integração dos componentes podem ser feitas na forma não-incremental ou incremental.

Na integração não-incremental, todos os módulos do software são combinados ao mesmo

tempo e o software resultante é testado. Neste caso, muitos defeitos podem ser encontrados e a

correção pode se tornar complicada, pois será mais difícil encontrar a origem do defeito.

Na integração incremental, o software é construído e testado em pequenos segmentos, per-

mitindo que os erros sejam mais fáceis de ser isolados e corrigidos e as interfaces têm maior

probabilidade de serem testadas completamente.

2.3 TESTES AUTOMATIZADOS DE SOFTWARE

Para facilitar a execução dos testes, foram criadas ferramentas que ajudam na criação de

código para a automação de testes, como o JUnit. Com essas ferramentas, o desenvolvedor

escreve um teste pensando na interface do código, ao invés de se preocupar em como será im-

plementado, verificando se os métodos e classes funcionam da forma esperada. Utilizando es-

tas ferramentas, executar testes passou a ser tão fácil quanto compilar um software (FOWLER,

2001). Por ser fácil de executar automaticamente, os desenvolvedores podem executar os testes

automáticos várias vezes por dia, permitindo que os defeitos sejam encontrados mais rapida-

mente. Por exemplo, se após a execução de todos os testes, um bug for inserido no software, o

desenvolvedor saberá que o defeito foi causado pelas linhas de código inseridas entre a última

execução dos testes e a revelação do bug.

Para exemplificar, será assumido que existe um programa escrito na linguagem Ruby e

utilizando o framework Rails que armazena dados de várias pessoas num banco de dados. Neste

Page 16: Monografia TDD

15

programa há uma classe chamada Pessoa com um campo nome, que deve ser obrigatório. Então,

o programa não deve permitir que um objeto da classe Pessoa seja salvo no banco de dados sem

ter o campo nome preenchido. Os testes unitários dessa classe são escritos numa classe chamada

PessoaTest. No teste para validar o campo obrigatório, 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 método assert, que retorna true se o que está sendo testado for verdadeiro e false

caso contrário.

Um exemplo de teste unitário automatizado para essa situação é mostrado na listagem 2.1.

Nele, o primeiro assert verifica se o objeto p não pôde ser salvo e o segundo verifica se foi

salvo. O primeiro deverá retornar o valor true, já que um objeto sem o campo nome não deverá

ser salvo. O segundo também deverá retornar o valor true, já que o campo nome foi preenchido.

Outros casos de testes unitários para essa mesma classe devem ser preenchidas no mesmo ar-

quivo.

Listagem 2.1: Teste unitário da classe Pessoa

c l a s s P e s s o a T e s t < T e s t : : Un i t : : T e s t C a s e

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 es so a . new

a s s e r t ! p . s ave

p . nome = ’ Maria ’

a s s e r t p . s ave

end

end

2.4 PRÁTICAS DE DESENVOLVIMENTO DE SOFTWARE

Kent Beck (BECK, 2000) descreveu as 12 melhores práticas de engenharia de software para

aumentar a produtividade e qualidade, que estão listadas abaixo:

• O processo de planejamento: Esta prática permite que o cliente defina as funcionali-

dades que serão prioritárias no desenvolvimento, a partir dos custos estimados fornecidos

pelos desenvolvedores.

Page 17: Monografia TDD

16

• Pequenas versões: Consiste em colocar um sistema simples em produção rapidamente e

atualizá-lo frequentemente, um ciclos curtos.

• Metáfora: Compartilhar um “sistema de nomes” e uma descrição do sistema para guiar

o desenvolvimento e a comunicação.

• Design simples: O programa desenvolvido deve ser o programa mais simples possível

que contemple os requisitos do momento. Nada que ainda não tenha sido descrito como

uma funcionalidade deve ser implementado.

• Testes: A validação do software deve ser feita em todos os momentos. Os programadores

devem escrever os testes primeiro e, depois, o código que contemple os requisitos refleti-

dos nos testes (TDD).

• Refatoração: Esta prática é utilizada para reestruturar o sistema sem mudar seu compor-

tamento. É utilizado para eliminar duplicações, melhorar a comunicação, simplicidade

ou adicionar mais flexibilidade.

• Programação em pares: Todo o código é produzido em pares: dois desenvolvedores

trabalhando juntos em uma máquina. Dessa forma, os desenvolvedores se ajudam. En-

quanto um escreve o código, o outro pode analisar a necessidade de revisão do código

e/ou refatoração.

• Propriedade coletiva: Todo o código produzido pertence à todos os desenvolvedores.

Isto permite que um grupo produza mais rápido. Se algo precisa ser mudado, ele será

mudado sem demora, pois qualquer desenvolvedor poderá modificar qualquer parte do

código.

• Integração contínua: Os grupos de desenvolvedores integram e produzem software

várias vezes por dia, permitindo que o progresso do desenvolvimento seja mais rápido.

• 40 horas por semana: Desenvolvedores cansados cometem mais erros. Então, nenhum

desenvolvedor deve trabalhar mais de 40h por semana.

• Cliente sempre presente: Um cliente/usuário deve estar sempre presente no desenvolvi-

mento, determinando requisitos, estabelecendo prioridade e respondendo às questões que

os desenvolvedores fizerem.

• Padrões de codificação: Para um grupo trabalhar efetivamente em pares e compartilhar

a propriedade do código, todos os desenvolvedores devem produzir código da mesma

forma, com regras que garantem que auxiliem a comunicação através do código.

Page 18: Monografia TDD

17

2.5 TEST-DRIVEN DEVELOPMENT (TDD)

Desenvolvimento Orientado por Testes (TDD) é uma técnica utilizada na fase de implemen-

tação do software. Ela consiste de pequenas iterações onde novos casos de testes são escritos

contemplando uma nova funcionalidade ou melhoria e, depois, o código necessário e suficiente

para passar esses teste é implementado. Então, o software é refatorado para contemplar as

mudanças de forma que os testes continuem passando.

Cada pequena iteração possui um micro objetivo, que será uma funcionalidade ou melhoria

que deverá ser implementada. Este micro objetivo terá sido alcançado quando os testes criados

antes da implementação do código passarem. Essa forma de implementar reduz o escopo do que

o desenvolvedor deve focar, já que ele pensará apenas no micro objetivo, ao invés de se preocu-

par com todo o software. Esta técnica também permite que o desenvolvedor escreva os testes

se preocupando apenas com a comportamento desejado da nova funcionalidade, ignorando sua

implementação e garante que os testes cobrem todo o código.

Uma consequência desta técnica é a redução na quantidade de código desnecessário, pois se

o desenvolvedor pensou em todos os testes necessários para o software e todos os testes passam,

mostra que o software já está terminado.

TDD pode ser aplicada em combinação com outras técnicas e utilizada em qualquer metodolo-

gia de desenvolvimento de software.

Segundo Kent Beck (BECK, 2003), os seguinte passos são necessários para a utilização

dessa técnica:

• Adicionar um novo teste;

• Executar todos os testes;

• Implementar o código necessário para passar no teste;

• Executar todos os testes;

• Refatorar o código.

Como todas as funcionalidades e melhorias do código começam com um teste, o desen-

volvedor precisa conhecer os casos de uso e estórias que contemplem todos os requisitos e

exceções do sistema. Essa técnica obriga o desenvolvedor a focar no requisito para escrever

bons testes.

Page 19: Monografia TDD

18

Cada teste adicionado deve cobrir uma funcionalidade ou melhoria que ainda não foi im-

plementada, então esse teste deverá falhar na sua primeira execução. Isso garante que o teste

não passará sem a necessidade de alterar o código.

Com a falha no teste, o desenvolvedor deve implementar o código necessário e suficiente

para passar no novo teste, sem se preocupar com a elegância do código.

Após 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 código cumpre todos

os requisitos testados. Se algum não passar, o código referente ao teste que falhou deverá ser

corrigido.

Antes de adicionar um novo teste no software, o desevolvedor deve refatorar o código, para

evitar duplicação.

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 seção 2.3. O micro-

objetivo da iteração será garantir que um objeto da classe não 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 deverão ser executados para vê-los falharem (figura 2.2). Neste

exemplo, há apenas um teste escrito.

O terceiro passo é implementar o código necessário para o novo teste passar (listagem 2.2).

Page 20: Monografia TDD

19

Figura 2.2: Executando todos os testes do programa exemplo.

Neste exemplo, basta inserir uma linha com a validação que verifica se o atributo especificado

está em branco.

Listagem 2.2: Classe Pessoa

c l a s s Pe ss oa < 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 código escrito funciona como o esperado, os testes são 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 é desnecessário neste caso.

2.5.1 EXTREME PROGRAMMING (XP)

Extreme Programming (ou XP) é uma metodologia de programação ágil composta por um

conjunto de valores, princípios e práticas que visa desenvolver softwares de alta qualidade de

forma ágil, econômica e flexível (JEFFRIES, 2007).

Page 21: Monografia TDD

20

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

ter a garantia que o código que foi produzido atende às necessidades do cliente. E, se o cliente

sugerir alterações, os desenvolvedores se sentirão seguros em fazer as mudanças, já que os testes

já produzidos possibilitarão indicar eventuais defeitos introduzidos pela alteração.

Os cinco valores que guiam o desenvolvimento XP são:

• Comunicação: A comunicação 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. Também é essencial que haja comunicação entre os

desenvolvedores, para garantir que todos entendam o software da mesma forma. A co-

municação verbal e presencial é priorizada para garantir que todas as partes envolvidas

tenham a chance de se compreender da melhor maneira possível.

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

tudo que é claramente importante para o software, evitando desenvolver o que ainda não é

essencial. Este valor está relacionado com a comunicação, pois a simplicidade do código

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 correção. A metodologia XP propões ciclos de desenvolvimento curtos

(1 a 4 semanas). Em cada ciclo ocorrem todas as fases de desenvolvimento (planejamento,

análise de requisitos, codificação, teste e documentação), que são entregues ao cliente.

Este, então, analisa se tudo o que pediu está contido na versão entregue e informa aos

desenvolvedores suas sugestões, críticas e dúvidas.

• Coragem: Os desenvolvedores que utilizam XP têm consciência que os clientes podem

querer mudanças no software. Então, têm coragem de permitir que essas mudanças sejam

feitas, pois confiam nas proteções que o software possui quando é desenvolvido utilizando

as práticas do XP, como desenvolvimento orientado por testes, programação em par e

integração contínua.

Os princípios (BEEDLE et al., 2001) seguidos pelos desenvolvedores são:

• A maior prioridade é a satisfação do cliente através da entrega rápida e contínua de soft-

ware útil.

• As mudanças de requisito serão bem recebidas em qualquer momento, mesmo que o

desenvolvimento já esteja adiantado.

Page 22: Monografia TDD

21

• A entrega do software deverá ser frequente, devendo ser em poucas semanas ou meses,

dando preferência à menor escala.

• As pessoas que entendem de negócios e os desenvolvedores devem trabalhar juntos diari-

amente durante o projeto.

• Desenvolva projetos com pessoas motivadas. Dêem todo o ambiente e suporte que as

pessoas precisarem e confie que elas produzirão.

• o método mais eficiente e eficaz de transmitir informações em uma equipe de desenvolvi-

mento é a conversa frente-a-frente.

• Um software que funciona é a primeira medida de progresso.

• Processos ágeis promovem desenvolvimento sustentável. Os clientes, desenvolvedores e

usuários devem ser capazes de manter um ritmo constante indefinidamente.

• Atenção contínua à excelência técnica e um bom projeto aumentam a agilidade.

• Simplicidade – a arte de maximizar a quantidade de trabalho a não ser feito – é essencial.

• As melhores arquiteturas, requisitos e projetos emergem de grupos auto-organizáveis.

• Em intervalos regulares, o grupo deve refletir sobre como se tornar mais eficaz, então

devem ajustar seu comportamento de acordo com isso.

A metodologia XP é baseada nas 12 melhores práticas de engenharia de software citadas

na seção 2.4, com ênfase em testes via TDD.

Page 23: Monografia TDD

22

3 METODOLOGIA

A metodologia utilizada neste trabalho é a Revisão Sistemática. A maior parte das pesquisas

começa com uma revisão de literatura, no entanto, segundo Kitchenham (KITCHENHAM,

2004), para ter valor científico é necessário que essa revisão seja feita de forma abrangente, não

tendenciosa, aberta e objetiva. Esse é a principal razão de uma revisão sistemática, que deve

identificar, avaliar e interpretar todas as pesquisas disponíveis e relevantes sobre uma questão

e, para isso, precisa ser executada seguindo um protocolo pré-definido e rigoroso. Obrigato-

riamente, nesse protocolo deve conter todas as informações que permitam que a revisão seja

repetida por outros pesquisadores interessados. A revisão sistemática deve reunir informações

sobre uma determinada questão ou fenômeno, identificar lacunas na pesquisa atual e indicar um

direcionamento para pesquisas futuras.

Uma revisão sistemática envolve três fases: planejamento, execução e análise dos resulta-

dos.

Na fase de planejamento, o protocolo que deverá orientar toda a revisão sistemática é con-

struído. Nele deve conter as informações sobre o objetivo, a descrição do problema, as questões

da pesquisa e os métodos e critérios utilizados para a busca, seleção, avaliação e extração de

dados.

Na fase de execução, os métodos descritos no protocolo são aplicados e documentados nos

formulários de condução da revisão e de seleção dos estudos. O objetivo do formulário de

condução da revisão é documentar o processo de busca. Possui campos para a armazenagem

de informações sobre a fonte onde a busca foi realizada, o endereço virtual da fonte, a data de

realização da busca, as combinações de palavras-chave que proporcionaram a busca dos artigos,

a quantidade de artigos encontrados e a quantidade de arquivos pré-selecionados. O formulário

de seleção de estudos documenta a busca e possui campos informando o nome do artigo, a lista

de autores, data de sua publicação, veículo de publicação do artigo, fonte de onde foi obtido,

situação do artigo (pendente, incluído e excluído) e informações sobre se os critérios foram

atendidos.

Page 24: Monografia TDD

23

Na fase de análise dos resultados os dados dos estudos são extraídos e sintetizados e os

resultados são analisados. A extração é documentada no formulário de extração de dados, que

possui campos informando o título, abstract, objetivo do estudo, descrição do estudo experi-

mental, resultados do estudo, além de comentários adicionais do pesquisador que extraiu os

dados.

Na seção seguinte será apresentado o protocolo utilizado para esta revisão sistemática.

3.1 PROTOCOLO

O protocolo da revisão especifica os métodos que serão utilizados para a revisão sistemática.

Segundo Kitchenham, um protocolo pré-definido é necessário 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 DESCRIÇÃO DO PROBLEMA

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

fases iniciais do desenvolvimento mais custosa fica sua correção. Então, a utilização da técnica

de desenvolvimento orientado por testes passa a ser uma boa opção, pois esta tem como um de

seus objetivos antecipar a identificação de defeitos durante o desenvolvimento do software. Esta

técnica faz parte do modelo de programação XP, cuja utilização tem aumentado bastante nos

últimos anos. Para permitir que os defeitos sejam identificados previamente, os testes são feitos

antes da implementação do código. Esse tipo de desenvolvimento ajuda os desenvolvedores a

focar na funcionalidade das aplicações e a disponibilidade de testes antes do desenvolvimento

permite um rápido feedback. Entretanto, não é garantido que a quantidade de defeitos diminuirá.

3.1.2 OBJETIVO

O foco desta revisão sistemática é analisar se a utilização da técnica de desenvolvimento

de software orientado por testes diminui a quantidade de defeitos numa aplicação. Caso seja

verificado que a quantidade de defeitos é menor, esta revisão também verificará o impacto da

utilização da técnica TDD na quantidade de defeitos do software.

Page 25: Monografia TDD

24

3.1.3 QUESTÕES DA PESQUISA

Essas questões deverão ser respondidas ao final da revisão sistemática.

• Questão Primária: O uso da metodologia TDD no desenvolvimento de software diminui

a quantidade de defeitos no software?

População: Projetos de desenvolvimento

Intervenção: Test Driven Development

Resultado: Diminuição da quantidade de defeitos

• Questão Secundária: Qual o impacto da utilização de TDD na quantidade de defeitos em

um software?

3.1.4 PALAVRAS-CHAVE

Essas palavras serão utilizadas para fazer as buscas de estudos.

• População

software development, software process, software project

• Intervenção:

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

• Resultado:

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

3.1.5 MÉTODO UTILIZADO PARA PESQUISA DE FONTES PRIMÁRIAS

As fontes serão pesquisada pela web nas bases eletrônicas de dados IEEE Xplore e ACM

Digital Library. As strings de busca utilizadas serão formada pela interseção das palavras que

formam a população, a intervenção e o resultado listados na subseção 3.1.4. A busca será

documentada e apresentada no apêndice A.

3.1.6 CRITÉRIO DE SELEÇÃO DOS ESTUDOS

Serão incluídos na revisão todos os artigos encontrados com a utilização do método descrito

na subseção 3.1.5 que satisfaçam todos os seguintes critérios:

Page 26: Monografia TDD

25

• Os artigos devem ter sido publicados entre 1990 e 2007

• Os artigos devem estar escritos em inglês. A escolha do inglês como idioma padrão deve-

se à sua universalidade.

• Os artigos devem estar disponíveis na web

• Os artigos devem contemplar a execução 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 seleção dos estudos será documentada e apresentada no apêndice B.

3.1.7 CRITÉRIO DE QUALIDADE DOS ESTUDOS

Os artigos que atenderem aos critérios descritos na subseção 3.1.6 serão avaliados baseado

nos critérios para avaliação de estudos experimentais em engenharia de software definidos por

Barbara Kitchenham e ilustrados na tabela 3.1 (KITCHENHAM, 2004). Apenas os estudos

com nível 5 serão excluídos da revisão sistemática.

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 witha control group.

3-2 Evidence obtained from comparative studies with historical control, two or moresingle 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 MÉTODO DE AVALIAÇÃO DOS ESTUDOS

Cada artigo que atender aos critérios listados na subseção 3.1.6 será lido e os estudos

selecionados serão avaliados de acordo com os critérios de qualidade estabelecidos na sub-

seção 3.1.7.Os artigos que se enquadrarem nesses critérios serão utilizados para a finalidade

deste estudo.

Page 27: Monografia TDD

26

3.1.9 MÉTODO DE EXTRAÇÃO DOS DADOS

Para cada artigo que atender aos critérios listados na subseção 3.1.7 será preenchido uma

cópia do formulário de extração de dados que será apresentado no apêndice C.

3.1.10 MÉTODO DE SÍNTESE DOS DADOS

Os dados dos estudos selecionados serão comparados, com a finalidade de realçar as simi-

laridades e diferenças entre os estudos de acordo com as questões da pesquisa (ver apêndice C)

. Foi considerada a idéia de realizar meta-análise sobre os dados quantitativos dos estudos, mas

como a quantidade de artigos encontrados foi muito baixa, a idéia foi desconsiderada.

3.2 EXECUÇÃO DA REVISÃO SISTEMÁTICA

O processo de busca foi executado utilizando as combinações de palavras-chave seguindo

o método de pesquisa de fontes primárias do protocolo (subseção 3.1.5) e restringindo a busca

aos anos entre 1990 e 2007. Foram listados 489 artigos somando o material encontrados nas

duas bases eletrônicas de dados. Devido ao grande número de artigos encontrados, primeiro foi

feita uma pré-seleção a partir da leitura do resumo dos estudos. Os artigos que claramente eram

irrelevantes para a revisão foram descartados. Foram pré-selecionados 43 estudos, todos eles

abordavam estudos experimentais, testes, metodologias ágeis ou XP. Os formulários de busca

podem ser vistos no apêndice A.

Todos os artigos pré-selecionados estavam descritos em inglês e estavam disponíveis na

WEB, atendendo três dos critérios citados na subseção 3.1.6 (recentes, em inglês e disponíveis

na WEB). Os artigos pré selecionados, então, foram lidos e verificados através dos critérios

ainda não atendidos de inclusão e exclusão estabelecidos. A seleção foi documentada no for-

mulário de seleção de estudos, juntamente com os critérios e se estes foram atendidos ou não

(apêndice B). Dos 43 artigos pré-selecionados, 2 estavam de acordo com os critérios previstos

no protocolo de revisão e tiveram seus dados extraídos e analisados (apêndice C).

Relatório sobre os artigos encontrados (ver critérios na subseção 3.1.6):

• Estudos que não contemplavam estudos experimentais: 19

• Estudos que contemplavam estudos experimentais, mas não utilizavam a metodologia

TDD: 19

Page 28: Monografia TDD

27

2 abordavam testes contínuos;

3 abordam programação em par e inspeção de software;

1 adaptou a metodologia TDD para suas necessidades;

1 avaliava técnicas de redução de defeitos;

1 abordava a técnica de desenvolvimento orientado a modelos;

1 focava na utilização de práticas XP para ensinar programação orientada a objetos.

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

9 não tinham nenhum relação com o tema do trabalho;

• Estudos experimentais que abordavam TDD: 5

2 foram incluídos na pesquisa;

1 foi excluído por relatar a mesma pesquisa que um arquivo já incluído;

2 foram excluídos porque analisavam a melhora na performance dos desenvolvedores

e o aumento da quantidade de testes, não os defeitos do software

Page 29: Monografia TDD

28

4 RESULTADOS

Apenas dois artigos contemplaram todos os critérios de inclusão 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” têm em comum a inter-

venção utilizada (TDD), a população avaliada (projetos de software) e o resultado (diminuição

na quantidade de defeitos). O primeiro artigo recebeu uma avaliação 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 divisões da Microsoft desenvolvendo projetos similares no mesmo período e

com diferentes técnicas, enquanto que no segundo um grupo de desenvolvedores da IBM desen-

volveu utilizando TDD e o software resultante foi comparado com uma outra versão já existente

desenvolvida com outra técnica. Em relação ao impacto na quantidade de defeitos, no primeiro

artigo a quantidade de defeitos utilizando TDD em uma das divisões foi 2,6 vezes menor e na

outra divisão, 4,2 vezes menor. No segundo artigo, houve uma redução de 40% na quantidade

de defeitos, comparando as duas versões.

4.1 DISCUSSÃO DOS RESULTADOS

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

(BHAT; NAGAPPAN, 2006) foi realizado em duas diferentes divisões da Microsoft: Windows

e MSN. Em cada divisão, dois projetos foram selecionados e desenvolvidos por gerentes com

níveis semelhantes de responsabilidades que reportavam para um mesmo gerente com nível

superior de responsabilidade. Em cada divisão, um dos projetos foi desenvolvido utilizando

TDD e o outro não. Os projetos foram analisados após sua finalização e os desenvolvedores

não sabiam que o trabalho deles seria avaliado. Isso foi feito para minimizar a influência na

performance do desenvolvedor.

Como resultado, foi verificado que na divisão Windows, a quantidade de defeitos encontra-

Page 30: Monografia TDD

29

dos no código da equipe que não utilizou TDD foi 2.6 vezes superior à outra equipe. Na divisão

MSN, o código da equipe que não 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 ocorrência

de uma anomalia externa visível. As falhas foram normalizadas por milhares de linha de código

(KLOC).

Os projetos foram realizados com programadores profissionais em diferentes plataformas e

ambientes. A figura 4.1 mostra que nas duas divisões onde ocorreram o estudo, a qualidade do

código nos dois sistemas desenvolvidos com TDD foi pelo menos duas vezes superior à qual-

idade do sistemas desenvolvidos com outra técnica. Também ilustra o acréscimo no tempo de

desenvolvimento do software. Isto sugere que ao utilizar o TDD, o desenvolvedor perceberá um

aumento de qualidade do código e um acréscimo no tempo de desenvolvimento, provavelmente

aumentando os custos do software.

Figura 4.1: Gráfico 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 década e um dos produtos produzidos por esse grupo, que já teve sete lançamentos

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 sétimo

lançamento desse driver na antiga plataforma com o primeiro lançamento na nova plataforma.

Como resultado, foi verificado que o driver desenvolvido com a metodologia TDD apresen-

tou uma redução de 40% na taxa de defeito comparado ao driver de dispositivo desenvolvido

com outra metodologia.

Page 31: Monografia TDD

30

Para verificar os defeitos, foi executado um teste de Verificação Funcional (FVT) por um

grupo de testes depois da produção do código. Os testes de verificação funcional analisa os

componentes do software e os testam para observar se elas operam como uma unidade e se

executam todas as funções que deveriam. Os defeitos também foram normalizadas por milhares

de linha de código (KLOC).

Alguns detalhes devem ser considerados na avaliação 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, não é possível afirmar que a

utilização da técnica de desenvolvimento TDD diminui a quantidade de defeitos na aplicação

mas sugerem que a utilização dessa técnica resultará num software com maior qualidade.

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

gos selecionados, essa revisão sistemática indica que há pesquisas sobre XP, métodos ágeis e

TDD, mas há uma carência de estudos experimentais que indiquem o impacto no uso de TDD

na quantidade de defeitos encontrados em aplicações. Algumas pesquisas focam na quantidade

Page 32: Monografia TDD

31

de testes e na produtividade do desenvolvedor e não na quantidade de defeitos, objetivo desta

revisão sistemática.

Page 33: Monografia TDD

32

5 CONCLUSÃO

5.1 USO DE REVISÃO SISTEMÁTICA

Esta revisão sistemática foi conduzida a partir de um protocolo que especificou os métodos

que foram utilizados para a condução do trabalho. A definição do protocolo foi essencial para

permitir a condução da pesquisa. Como todos os detalhes da condução da pesquisa foram

definidos no início da revisão, isso impediu que o foco fosse desviado da revisão sistemática, já

que apenas foram lidos e estudados os artigos relevantes à pesquisa.

Os critérios definidos no protocolo e utilizados para a seleção dos estudos foram necessários

e suficientes para obter apenas os estudos que podiam responder às questões da pesquisa. A

utilização de formulários foi importante para documentar a revisão 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 eletrônicas de dados não permitem que as buscas sejam feitas

da mesma forma.

5.2 TDD X QUANTIDADE DE DEFEITOS

Como foi encontrado um número reduzido de estudos, esta revisão sistemática não teve

dados suficientes para analisar o impacto da utilização da técnica TDD na quantidade de defeitos

no software final. Os poucos estudos encontrados obtiveram os mesmos resultados, revelando

que há uma tendência à diminuição da quantidade de defeitos com a utilização de TDD no

desenvolvimento.

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

a técnica TDD foi maior que quando não utilizada. E em alguns estudos que não foram sele-

cionados para essa revisão foi verificado que houve um aumento na produtividade dos desen-

volvedores e na quantidade de testes executados.

Page 34: Monografia TDD

33

5.3 CONTRIBUIÇÕES DO TRABALHO

A revisão sistemática provê os meios para executar revisões de literatura abrangentes e não

tendenciosas, mas ainda é muito pouco difundido na área da computação. Este trabalho mostra

que podem ser feitas revisões sistemáticas na área de engenharia de software, reunindo de forma

sistemática e passível de reprodução evidências existentes sobre um fenômeno e identificando

lacunas nas pesquisas atuais.

A quantidade de artigos selecionados nesta revisão sistemática mostra que, apesar de TDD

ser uma técnica utilizada por muitos desenvolvedores, é necessário que haja mais pesquisas

sobre o impacto da utilização desta técnica em projetos de desenvolvimento.

Page 35: Monografia TDD

34

APÊNDICE A -- FORMULÁRIO DECONDUÇÃO DA REVISÃO

Fonte da busca Portal ACM

Endereço 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")

Período dos artigos 1990 a 2007

Quantidade encontrada 15636 artigos. Destes, os 200 mais relevantes (critério do

portal) foram listados.

Quantidade de arquivos

pré-selecionados

12

Fonte da busca IEEE Xplore

Endereço 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)

Período dos artigos 1990 a 2007

Page 36: Monografia TDD

35

Quantidade encontrada 289 artigos

Quantidade de arquivos

pré-selecionados

31

Page 37: Monografia TDD

36

APÊNDICE B -- FORMULÁRIO DE SELEÇÃODE ESTUDOS

OBS:

• Critério 4: Contempla a execução de estudos experimentais.

• Critério 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 publicação Setembro, 2006

Veículo de publicação ACM Press

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 O artigo aborda o uso da metodologia TDD, mas não a

quantidade de erros do software e sim a produtividade

dos desenvolvedores e a quantidade e qualidade dos testes

unitários.

Nome do artigo Assessing Undergraduate Experience of Continuous Inte-

gration and Test-Driven Development

Lista de autores Jon Bowyer, Janet Hughes

Data de publicação Maio, 2006

Veículo de publicação ACM Press

Page 38: Monografia TDD

37

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 O artigo avalia a participação e performance dos alunos ao

desenvolver utilizando uma metodologia ágil, e não 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 publicação Julho, 2004

Veículo de publicação ACM Press

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. Os desenvolvedores precisavam testar continuamente,

mas não 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 publicação Janeiro, 2006

Veículo de publicação Australian Computer Society, Inc

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 O foco do artigo é a utilização de práticas XP para ensinar

programação orientada a objetos.

Nome do artigo Software Testing Research: Achievements, Challenges,

Dreams

Lista de autores Antonia Bertolino

Data de publicação Maio, 2007

Veículo de publicação ICSE 2007: Future of Software Engineering

Page 39: Monografia TDD

38

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não, é um artigo teórico.

Critério 5 Não. 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 publicação Setembro, 2003

Veículo de publicação ACM Press

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não, é um artigo teórico.

Critério 5 Não. O artigo apresenta um modelo para estudar o impacto

das práticas XP.

Nome do artigo Unit Testing: Test Early, Test Often

Lista de autores Michael Olan

Data de publicação Dezembro, 2003

Veículo de publicação Consortium for Computing Sciences in Colleges

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não, é um artigo teórico.

Critério 5 Não. O artigo apresenta a necessidade de testes unitários

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 publicação Outubro, 2003

Veículo de publicação ACM Press

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Page 40: Monografia TDD

39

Critério 4 Não. O artigo mostra uma nova visão para a ciência da

computação, centrada no uso de TDD.

Critério 5 Não. O artigo não 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. Pérez-Quiñones

Data de publicação Janeiro, 2007

Veículo de publicação Consortium for Computing Sciences in Colleges

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não.

Critério 5 Não. O artigo relata a experiência 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 publicação Setembro, 2006

Veículo de publicação ACM Press

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo apresenta experimentos para comparar pro-

gramação em par e inspeção de software como técnicas de

diminuição de erros.

Nome do artigo Assessing Test-Driven Development at IBM

Lista de autores E. Michael Maximilien and Laurie Williams

Data de publicação Maio, 2003

Veículo de publicação Proceedings of the 25th International Conference on Soft-

ware Engineering

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

excluído

Page 41: Monografia TDD

40

Critério 4 Sim.

Critério 5 Sim. Foi excluído, 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 publicação Setembro, 2006

Veículo de publicação Proceedings of the 2006 ACM/IEEE international sympo-

sium on International symposium on empirical software en-

gineering

Fonte Portal ACM

Situação do artigo (incluído

ou excluído)

incluído

Critério 4 Sim.

Critério 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 publicação Outubro, 1992

Veículo de publicação Proceedings on Third International Symposium on Soft-

ware Reliability Engineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Attitude Towards Testing: A Key Contributor to Software

Quality

Lista de autores S. Murugesan

Data de publicação Dezembro, 1994

Veículo de publicação Conference Proceedings on First International Conference

on Software Testing, Reliability and Quality Assurance

Fonte IEEE Xplore

Page 42: Monografia TDD

41

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Towards A Zero-Defect Product - The End-To-End Test

Process

Lista de autores Rathna K. Prasad

Data de publicação Dezembro, 1994

Veículo de publicação Conference Proceedings on First International Conference

on Software Testing, Reliability and Quality Assurance

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Controlling Software Reliability EDuring Development

Lista de autores Gerald W. Baumann

Data de publicação Novembro, 1993

Veículo de publicação Proceedings on Fourth International Symposium on Soft-

ware Reliability Engineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não aborda o uso da técnica 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 publicação Novembro, 1997

Veículo de publicação Proceedings on First IEEE International Conference on For-

mal Engineering Methods

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Page 43: Monografia TDD

42

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

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 publicação Janeiro, 1997

Veículo de publicação Proceedings of the Thirtieth Hawaii International Confer-

ence on System Sciences

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não aborda o uso da técnica TDD.

Nome do artigo Improving Defect Removal Effectiveness for Software De-

velopment

Lista de autores Hareton K. N. Leung

Data de publicação Março, 1998

Veículo de publicação Proceedings of the Second Euromicro Conference on Soft-

ware Maintenance and Reengineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Managing Cyclical Software Development

Lista de autores Anthony J Lattanze, Manuel Rosso-Llopart

Data de publicação Outubro, 1998

Veículo de publicação 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

Page 44: Monografia TDD

43

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Studying the Effects of Code Inspection and Structural Test-

ing on Software Quality

Lista de autores Oliver Laitenberger

Data de publicação Novembro, 1998

Veículo de publicação Proceedings of The Ninth International Symposium on

Software Reliability Engineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não aborda o uso da técnica TDD.

Nome do artigo Integrating Pair Programming into a Software Development

Process

Lista de autores Laurie Williams

Data de publicação Fevereiro, 2001

Veículo de publicação Proceedings of 14th Conference on Software Engineering

Education and Training

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

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 publicação Agosto, 2002

Veículo de publicação IEEE Computer Society

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Page 45: Monografia TDD

44

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Test and Development Process Retrospective - a Case Study

using ODC Triggers

Lista de autores Ram Chillarege, Kothanda Ram Prasad

Data de publicação Junho, 2002

Veículo de publicação Proceedings of International Conference Dependable Sys-

tems and Networks

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não utiliza a técnica TDD.

Nome do artigo Hypothesis Testing for Module Test in Software Develop-

ment

Lista de autores Tsuneo Yamaura, Akira K. Onoma

Data de publicação Setembro, 2006

Veículo de publicação Annual India Conference

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

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 publicação Novembro, 2002

Veículo de publicação Proceedings of 13th International Symposium on Software

Reliability Engineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Page 46: Monografia TDD

45

Critério 5 Não.O artigo não utiliza a técnica 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 publicação Dezembro, 2002

Veículo de publicação Proceedings of 27th Annual NASA Goddard/IEEE Soft-

ware Engineering Workshop

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

Nome do artigo Reducing wasted development time via continuous testing

Lista de autores David Saff, Michael D. Ernst

Data de publicação Novembro, 2003

Veículo de publicação 14th International Symposium on Software Reliability En-

gineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

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 publicação Janeiro, 2004

Veículo de publicação Proceedings of the 37th Annual Hawaii International Con-

ference on System Sciences

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não utiliza a técnica TDD.

Page 47: Monografia 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 publicação Janeiro, 2004

Veículo de publicação Proceedings of 10th International Workshop on Software

Technology and Engineering Practice

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não utiliza a técnica TDD.

Nome do artigo Establishment of Automated Regression Testing at ABB:

Industrial Experience Report on "Avoiding the Pitfalls"

Lista de autores Christer Persson, Nur Yilmaztürk

Data de publicação Setembro, 2004

Veículo de publicação Proceedings of 19th International Conference on Auto-

mated Software Engineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não utiliza a técnica 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 publicação Setembro, 2003

Veículo de publicação Eleventh Annual International Workshop on Software Tech-

nology and Engineering Practice

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Page 48: Monografia TDD

47

Critério 5 Não.

Nome do artigo A Control Approach for Agile Processes

Lista de autores João W. Cangussu, Richard M. Karcich

Data de publicação Julho, 2005

Veículo de publicação 29th Annual International Computer Software and Applica-

tions Conference

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo possui uma abordagem teórica.

Critério 5 Não.

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 publicação Outubro, 2005

Veículo de publicação IEEE Transactions on Software Engineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não utiliza a técnica TDD.

Nome do artigo Model-based Testing Considering Cost, Reliability and

Software Quality

Lista de autores Chaw Yupar Htoon, Ni Lar Thein

Data de publicação Novembro, 2005

Veículo de publicação Proceedings of 6th Asia-Pacific Symposium on Information

and Telecommunication Technologies

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não utiliza a técnica TDD.

Page 49: Monografia TDD

48

Nome do artigo Optimize Defect Detection Techiniques through Empirical

Software Engineering Method

Lista de autores Hai Tao Sun

Data de publicação Novembro, 2005

Veículo de publicação IEEE International Conference on Electro Information

Technology

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo analisa as técnicas de detecção 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 publicação Julho/Agosto, 2006

Veículo de publicação IEEE Computer Society

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo foca no estudo com métodos Á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 publicação Setembro/Outubro, 2006

Veículo de publicação IT Professional

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Não. O artigo apresenta um estudo teórico.

Critério 5 Não.

Nome do artigo Test Case Prioritization Using Relevant Slices

Lista de autores Dennis Jeffrey, Neelam Gupta

Data de publicação Setembro, 2006

Page 50: Monografia TDD

49

Veículo de publicação 30th Annual International Computer Software and Applica-

tions Conference

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo não 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 publicação Abril, 2006

Veículo de publicação 30th Annual IEEE/NASA Software Engineering Workshop

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo faz uma análise sobre a relação 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 Pádua

Data de publicação Julho, 2007

Veículo de publicação 20th Conference on Software Engineering Education and

Training

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Não. O artigo utiliza a técnica 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 publicação Janeiro, 2007

Page 51: Monografia TDD

50

Veículo de publicação 40th Annual Hawaii International Conference on System

Sciences

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

excluído

Critério 4 Sim.

Critério 5 Apesar de alguns utilizarem TDD, o estudo foca na progra-

mação em par, por isso, esse artigo foi excluído.

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 publicação Novembro, 2003

Veículo de publicação 14th International Symposium on Software Reliability En-

gineering

Fonte IEEE Xplore

Situação do artigo (incluído

ou excluído)

incluído

Critério 4 Sim.

Critério 5 Sim.

Page 52: Monografia TDD

51

APÊNDICE C -- FORMULÁRIO DE EXTRAÇÃODE DADOS

Título Evaluating the Efficacy of Test-Driven Development: In-

dustrial Case Studies

Lista de autores Thirumalesh Bhat, Nachiappan Nagappan

Data de publicação Setembro, 2006

Veículo de publicação 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 (divisões do Windows e MSN).

Page 53: Monografia TDD

52

Descrição do estudo experi-

mental

O estudo de caso foi realizado em duas diferentes divisões

da Microsoft, Windows e MSN. Em cada divisão, dois pro-

jetos foram selecionados e desenvolvidos por gerentes com

níveis semelhantes de responsabilidades que reportavam

para um mesmo gerente com nível superior de responsabil-

idade. Em cada divisão, um dos projetos foi desenvolvido

utilizando TDD e o outro não. Os projetos foram analisados

após sua finalização e os desenvolvedores não sabiam que o

trabalho deles seria avaliado. Isso foi feito para minimizar

a influência na performance do desenvolvedor.

Resultados Na divisão Windows, a quantidade de defeitos encontrados

no código da equipe que não utilizou TDD foi 2.6 vezes su-

perior à outra equipe. Na divisão MSN, o código da equipe

que não utilizou TDD apresentou quantidade de defeitos 4.2

vezes superior à equipe que utilizou a metodologia.

Comentários Para fazer a avaliação, o estudo definiu defeito como sendo

a ocorrência de uma anomalia externa visível. As fal-

has foram normalizadas por milhares de linha de código

(KLOC).

Título Test-Driven Development as a Defect-Reduction Practice

Lista de autores Williams, L. and Maximilien and E.M., Vouk, M.

Data de publicação Novembro, 2003

Veículo de publicação 14th International Symposium on Software Reliability En-

gineering

Fonte IEEE Xplore

Page 54: Monografia TDD

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 eficácia de TDD como uma forma de diminuir

a quantidade de erros num software.

Descrição do estudo experi-

mental

Um grupo de desenvolvedores da IBM desenvolve drivers

de dispositivos há mais de uma década e um dos produ-

tos produzidos por esse grupo, que já teve sete lançamentos

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 sétimo lança-

mento desse driver na antiga plataforma com o primeiro

lançamento na nova plataforma.

Resultados Utilizando a metodologia TDD, houve uma redução de 40na

taxa de erro comparado ao driver de dispositivo desen-

volvido com outra metodologia.

Comentários Para verificar os erros, foi executado um teste de Verificação

Funcional (FVT) por um grupo de testes depois da produção

do código. Os erros foram normalizadas por milhares de

linha de código (KLOC).

Page 55: Monografia TDD

54

REFERÊNCIAS BIBLIOGRÁFICAS

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 emhttp://agilemanifesto.org/principles.html. Último acesso em 12/12/2007.

BHAT, T.; NAGAPPAN, N. Evaluating the efficacy of test-driven development: industrial casestudies. ACM, New York, NY, USA, p. 356–363, 2006. Disponível 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.Disponível em http://www.xprogramming.com/. Último acesso em 12/12/2007.

KITCHENHAM, B. Procedures for performing systematic reviews. Keele University, UK,Technical Report, p. 1353–7776, 2004. Disponível em http://portal.acm.org. Último acesso em12/12/2007.

NAUR, P.; RANDELL, B. Software Engineering: A report on a Conference Sponsored by theNATO 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. SoftwareReliability Engineering, 2003. ISSRE 2003. 14th International Symposium on, p. 34–45, 17–20Nov. 2003. ISSN 1071-9458. Disponível em http://ieeexplore.ieee.org. Último acesso em12/12/2007.