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

Monograa apresentada ao Curso de graduao em Cincia da Computao, Departamento de Cincia da Computao, Instituto de Matemtica, Universidade Federal 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 identicao 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 conana. 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 signicantly. 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 2.2 2.3 4.1 Test Driven Development (BHAT; NAGAPPAN, 2006, p.357) . . . . . . . . . Executando todos os testes do programa exemplo. . . . . . . . . . . . . . . . . Executando todos os testes do programa exemplo pela segunda vez. . . . . . . Grco dos resultados obtidos a partir do estudo na Microsoft - (BHAT; NAGAPPAN, 2006, p.361) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Densidade dos defeitos encontrados no estudo na IBM - (VOUK, 17-20 Nov. 2003, p.7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 29 18 19 19

LISTA DE ABREVIATURAS E SIGLAS

CASE TDD XP Computer-Aided Software Engineering, Test-Driven Development, eXtreme Programming, p. 12 p. 17 p. 19

SUMRIO

1 2

Introduo Conceitos 2.1 2.2 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.3 2.4 2.5 Fases de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 12 12 13 13 14 15 17 19 22 23 23 23 24 24 24 24 25 25 26

Testes automatizados de software . . . . . . . . . . . . . . . . . . . . . . . . . Prticas de desenvolvimento de software . . . . . . . . . . . . . . . . . . . . . Test-Driven Development (TDD) . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . .

Metodologia 3.1 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 Descrio do problema . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Questes da pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . Palavras-chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mtodo utilizado para pesquisa de fontes primrias . . . . . . . . . . . Critrio de seleo dos estudos . . . . . . . . . . . . . . . . . . . . . . Critrio de qualidade dos estudos . . . . . . . . . . . . . . . . . . . . Mtodo de avaliao dos estudos . . . . . . . . . . . . . . . . . . . . . Mtodo de extrao dos dados . . . . . . . . . . . . . . . . . . . . . .

3.1.10 Mtodo de sntese dos dados . . . . . . . . . . . . . . . . . . . . . . . 3.2 4 Execuo da Reviso Sistemtica . . . . . . . . . . . . . . . . . . . . . . . . .

26 26 28 28 32 32 32 33 34 36 51 54

Resultados 4.1 Discusso dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Concluso 5.1 5.2 5.3 Uso de reviso sistemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . TDD X Quantidade de defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . Contribuies do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Apndice A -- Formulrio de conduo da reviso Apndice B -- Formulrio de seleo de estudos Apndice C -- Formulrio de extrao de dados Referncias Bibliogrcas

10

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 manutenibilidade. 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 desaos principais neste sculo: Sistemas legados: A maioria dos grandes softwares utilizados atualmente foi desenvolvido h muitos anos. O desao 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 convel e exvel 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, devese encontrar uma forma de garantir a qualidade do software apesar dos desaos. 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 den-la como uma prtica de desenvolvimento comearam no nal 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 vericar se o cdigo implementado 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 utilizao de TDD diminui a quantidade de defeitos no software, comparando com outras tcnicas de desenvolvimento. Para isso, alguns estudos que obtiveram resultados experimentais foram identicados, analisados e avaliados como proposto em (KITCHENHAM, 2004). Em funo do nmero reduzido de estudos especcos sobre o impacto de TDD na quantidade de defeitos no software, no possvel estatisticamente armar 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, apresentando detalhadamente o protocolo e a conduo da reviso. O captulo 4 apresenta os resultados obtidos da reviso. O captulo 5 apresenta as concluses. E, nalmente, os formulrios utilizados na conduo da reviso so apresentados nos apndices A, B e C.

12

CONCEITOS

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

2.1

ENGENHARIA DE SOFTWARE

Uma primeira denio de engenharia de software foi proposta por Fritz Baur na primeira conferncia dedicada ao assunto (NAUR; RANDELL, 1969 apud PRESSMAN, 2005): Engenharia de software a criao e a utilizao de slidos princpios de engenharia a m de obter software de maneira econmica, que seja convel e que trabalhe ecientemente em mquinas reais. A criao da engenharia de software surgiu numa tentativa de contornar a crise do software 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 Pressman (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 especicao 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 denem 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 especicao, 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 especicado. 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 vericao e validao. Vericao e validao so processos de checagem e anlise de software. O objetivo da vericao mostrar se um programa est de acordo com a especicao 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 nal, importante que a maioria desses defeitos no sejam crticos. Os testes de software tentam garantir que a qualidade, o custo, a segurana e a conabilidade 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 vericar que funcionam, 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 integrao. Estes testes so aplicados na construo da estrutura do programa, realizando testes para descobrir defeitos associados s interfaces entre os componentes, vericando 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, permitindo 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 implementado, vericando se os mtodos e classes funcionam da forma esperada. Utilizando estas 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 rapidamente. 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 exemplicar, 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 vericado se ele ser salvo no banco sem o campo nome preenchido. Para vericar 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 verica se o objeto p no pde ser salvo e o segundo verica 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 arquivo. 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 dena as funcionalidades 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 reetidos nos testes (TDD). Refatorao: Esta prtica utilizada para reestruturar o sistema sem mudar seu comportamento. utilizado para eliminar duplicaes, melhorar a comunicao, simplicidade ou adicionar mais exibilidade. Programao em pares: Todo o cdigo produzido em pares: dois desenvolvedores trabalhando juntos em uma mquina. Dessa forma, os desenvolvedores se ajudam. Enquanto 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 modicar 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 desenvolvimento, determinando requisitos, estabelecendo prioridade e respondendo s questes que os desenvolvedores zerem. Padres de codicao: 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 implementao 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 suciente 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 preocupar 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 metodologia 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 desenvolvedor 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 implementada, 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 suciente para passar no novo teste, sem se preocupar com a elegncia do cdigo. Aps implementado a nova funcionalidade/melhoria, os testes devem ser executados novamente 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 microobjetivo 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 (gura 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 verica se o atributo especicado 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 novamente (gura 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 exvel (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 desenvolvimento do projeto de perto. Tambm essencial que haja comunicao entre os desenvolvedores, para garantir que todos entendam o software da mesma forma. A comunicao 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 codicar 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, codicao, 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 conam 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 software 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 diariamente durante o projeto. Desenvolva projetos com pessoas motivadas. Dem todo o ambiente e suporte que as pessoas precisarem e cone que elas produziro. o mtodo mais eciente e ecaz de transmitir informaes em uma equipe de desenvolvimento 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 indenidamente. 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 reetir sobre como se tornar mais ecaz, 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

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 cientco necessrio que essa reviso seja feita de forma abrangente, no tendenciosa, aberta e objetiva. Esse a principal razo de uma reviso sistemtica, que deve identicar, avaliar e interpretar todas as pesquisas disponveis e relevantes sobre uma questo e, para isso, precisa ser executada seguindo um protocolo pr-denido e rigoroso. Obrigatoriamente, 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, identicar lacunas na pesquisa atual e indicar um direcionamento para pesquisas futuras. Uma reviso sistemtica envolve trs fases: planejamento, execuo e anlise dos resultados. Na fase de planejamento, o protocolo que dever orientar toda a reviso sistemtica construdo. 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 experimental, 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 especica os mtodos que sero utilizados para a reviso sistemtica. Segundo Kitchenham, um protocolo pr-denido 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 ca 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 identicao 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 identicados 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 vericado que a quantidade de defeitos menor, esta reviso tambm vericar 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 nal 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 identication, 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 devese 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 nal 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 denidos por Barbara Kitchenham e ilustrados na tabela 3.1 (KITCHENHAM, 2004). Apenas os estudos com nvel 5 sero excludos da reviso sistemtica. 1 2 3-1 Evidence obtained from at least one properly-designed randomised controlled trial. Evidence obtained from well-designed pseudo-randomised controlled trials (i.e. non-random allocation to treatment). 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. Evidence obtained from comparative studies with historical control, two or more single arm studies, or interrupted time series without a parallel control group. Evidence obtained from a randomised experiment performed in an articial setting. Evidence obtained from case series, either post-test or pre-test/post-test. Evidence obtained from a quasi-random experiment performed in an articial setting. Evidence obtained from expert opinion based on theory or consensus.

3-2 4-1 4-2 4-3 5

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 subseo 3.1.7.Os artigos que se enquadrarem nesses critrios sero utilizados para a nalidade 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 nalidade de realar as similaridades 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 vericados atravs dos critrios ainda no atendidos de incluso e excluso estabelecidos. A seleo foi documentada no formulrio 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

RESULTADOS

Apenas dois artigos contemplaram todos os critrios de incluso e tiveram seus dados sintetizados. Os dois artigos, Evaluating the Efcacy of Test-Driven Development: Industrial Case Studies e Test-Driven Development as a Defect-Reduction Practice tm em comum a interveno 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 gura ??). Os contextos dos dois estudos foram diferentes. O primeiro envolvia grupos de desenvolvedores 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 desenvolveu 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 Efcacy 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 nalizao e os desenvolvedores no sabiam que o trabalho deles seria avaliado. Isso foi feito para minimizar a inuncia na performance do desenvolvedor. Como resultado, foi vericado 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 deniu 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 prossionais em diferentes plataformas e ambientes. A gura 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 qualidade 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: Grco dos resultados obtidos a partir do estudo na Microsoft - (BHAT; NAGAPPAN, 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 vericado que o driver desenvolvido com a metodologia TDD apresentou uma reduo de 40% na taxa de defeito comparado ao driver de dispositivo desenvolvido com outra metodologia.

30

Para vericar os defeitos, foi executado um teste de Vericao Funcional (FVT) por um grupo de testes depois da produo do cdigo. Os testes de vericao 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 gura 4.2 ilustra a densidade das falhas observadas no estudo. Ela mostra que a densidade das falhas encontradas no novo driver signicativamente 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 armar 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 artigos 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

CONCLUSO

5.1

USO DE REVISO SISTEMTICA

Esta reviso sistemtica foi conduzida a partir de um protocolo que especicou os mtodos que foram utilizados para a conduo do trabalho. A denio do protocolo foi essencial para permitir a conduo da pesquisa. Como todos os detalhes da conduo da pesquisa foram denidos 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 denidos no protocolo e utilizados para a seleo dos estudos foram necessrios e sucientes 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 diculdade 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 sucientes para analisar o impacto da utilizao da tcnica TDD na quantidade de defeitos no software nal. 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 vericado que o tempo de desenvolvimento utilizando a tcnica TDD foi maior que quando no utilizada. E em alguns estudos que no foram selecionados para essa reviso foi vericado que houve um aumento na produtividade dos desenvolvedores 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 identicando 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 Endereo virtual Data da busca String de busca

Portal ACM http://portal.acm.org/ 22/10/2007 ("software development", "software process", "software project") +("development test", "test", "tests", "software test", "tdd", "test driven development", "test-driven development", "test driven-development, "tfd", "test rst development", "test rst design") +("errors", "error", "error detection", "error identication", failure", "defect")

Perodo dos artigos Quantidade encontrada Quantidade de arquivos

1990 a 2007 15636 artigos. Destes, os 200 mais relevantes (critrio do portal) foram listados. 12

pr-selecionados Fonte da busca Endereo virtual Data da busca String de busca IEEE Xplore http://ieeexplore.ieee.org/ 22/10/2007 (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 rst development <or> test rst design) <and> (errors <or> error <or> error detection <or> error identication <or> failure <or> defect) Perodo dos artigos 1990 a 2007

35

Quantidade encontrada Quantidade de arquivos pr-selecionados

289 artigos 31

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 nal do desenvolvimento. Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Sim. 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 Lista de autores Data de publicao Veculo de publicao Assessing Undergraduate Experience of Continuous Integration and Test-Driven Development Jon Bowyer, Janet Hughes Maio, 2006 ACM Press Evaluating Advantages of Test Driven Development: a Controlled Experiment with Professionals Gerardo Canfora, Aniello Cimitile, Felix Garcia, Mario Piattini, Corrado Aaron Visaggio Setembro, 2006 ACM Press Portal ACM excludo

37

Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

Portal ACM excludo Sim. O artigo avalia a participao e performance dos alunos ao desenvolver utilizando uma metodologia gil, e no a quantidade de erros do software.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

An Experimental Evaluation of Continuous Testing During Development David Saff, Michael D. Ernst Julho, 2004 ACM Press Portal ACM excludo Sim. No. Os desenvolvedores precisavam testar continuamente, mas no necessariamente testar antes de codicar (TDD).

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

Adopting XP Practices for Teaching Object Oriented Programming Karen Keefe, Judithe Sheard, Martin Dick Janeiro, 2006 Australian Computer Society, Inc Portal ACM excludo Sim. O foco do artigo a utilizao de prticas XP para ensinar programao orientada a objetos.

Nome do artigo Lista de autores Data de publicao Veculo de publicao

Software Testing Research: Achievements, Challenges, Dreams Antonia Bertolino Maio, 2007 ICSE 2007: Future of Software Engineering

38

Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

Portal ACM excludo No, um artigo terico. No. O artigo apresentas os desaos atuais e futuros dos testes de software.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

On the Economic Evaluation of XP Projects Matthias M. Muller, Frank Padberg Setembro, 2003 ACM Press Portal ACM excludo No, um artigo terico. No. O artigo apresenta um modelo para estudar o impacto das prticas XP.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

Unit Testing: Test Early, Test Often Michael Olan Dezembro, 2003 Consortium for Computing Sciences in Colleges Portal ACM excludo No, um artigo terico. No. O artigo apresenta a necessidade de testes unitrios em todo o desenvolvimento do processo.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo)

Rethinking Computer Science Education from a Test-rst Perspective Stephen H. Edwards Outubro, 2003 ACM Press Portal ACM excludo

39

Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

No. O artigo mostra uma nova viso para a cincia da computao, centrada no uso de TDD. No. O artigo no desenvolve um estudo de caso com TDD. Experiences Using Test-Driven Development With An Automated Grader Stephen H. Edwards, Manuel A. Prez-Quiones Janeiro, 2007 Consortium for Computing Sciences in Colleges Portal ACM excludo No. No. O artigo relata a experincia de testes em uma sala de aula.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

An Empirical Comparison Between Pair Development and Software Inspection in Thailand Monvorath Phongpaibul, Barry Boehm Setembro, 2006 ACM Press Portal ACM excludo Sim. No. O artigo apresenta experimentos para comparar programao em par e inspeo de software como tcnicas de diminuio de erros.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo)

Assessing Test-Driven Development at IBM E. Michael Maximilien and Laurie Williams Maio, 2003 Proceedings of the 25th International Conference on Software Engineering Portal ACM excludo

40

Critrio 4 Critrio 5

Sim. 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 Lista de autores Data de publicao Veculo de publicao

Evaluating the Efcacy of Test-Driven Development: Industrial Case Studies Thirumalesh Bhat, Nachiappan Nagappan Setembro, 2006 Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering

Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte

Portal ACM includo Sim. Sim. Improving the Software Development Process Using Testability Research Jeffrey M. Voas and Keith W. Miller Outubro, 1992 Proceedings on Third International Symposium on Software Reliability Engineering IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. Attitude Towards Testing: A Key Contributor to Software Quality S. Murugesan Dezembro, 1994 Conference Proceedings on First International Conference on Software Testing, Reliability and Quality Assurance IEEE Xplore

41

Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo)

excludo No. O artigo possui uma abordagem terica. No. Towards A Zero-Defect Product - The End-To-End Test Process Rathna K. Prasad Dezembro, 1994 Conference Proceedings on First International Conference on Software Testing, Reliability and Quality Assurance IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. Controlling Software Reliability EDuring Development Gerald W. Baumann Novembro, 1993 Proceedings on Fourth International Symposium on Software Reliability Engineering IEEE Xplore excludo Sim. No. O artigo no aborda o uso da tcnica TDD Test Case Design Based on Z and the Classication-Tree Method Harbhajan Singh, Mirko Conrad, Sadegh Sadeghipour Novembro, 1997 Proceedings on First IEEE International Conference on Formal Engineering Methods IEEE Xplore excludo

42

Critrio 4 Critrio 5 Nome do artigo Lista de autores

No. O artigo possui uma abordagem terica. No. "Continuous Verication"in Mission Critical Software Development Tien-fu Chang, Alejandro Danylyzsn, So Norimatsu,Jose Rivera, David Shepard, Anthony Lattanze, Dr. Tomayko James

Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao

Janeiro, 1997 Proceedings of the Thirtieth Hawaii International Conference on System Sciences IEEE Xplore excludo Sim. No. O artigo no aborda o uso da tcnica TDD. Improving Defect Removal Effectiveness for Software Development Hareton K. N. Leung Maro, 1998 Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. Managing Cyclical Software Development Anthony J Lattanze, Manuel Rosso-Llopart Outubro, 1998 Proceedings of Pioneering New Technologies: Management Issues and Challenges in the Third Millennium on International Conference on Engineering and Technology Management

Fonte

IEEE Xplore

43

Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo)

excludo No. O artigo possui uma abordagem terica. No. Studying the Effects of Code Inspection and Structural Testing on Software Quality Oliver Laitenberger Novembro, 1998 Proceedings of The Ninth International Symposium on Software Reliability Engineering IEEE Xplore excludo Sim. No. O artigo no aborda o uso da tcnica TDD. Integrating Pair Programming into a Software Development Process Laurie Williams Fevereiro, 2001 Proceedings of 14th Conference on Software Engineering Education and Training IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. A Formal Model of the Software Test Process Joao W. Cangussu, Raymond A. DeCarlo and Aditya P. Mathur Agosto, 2002 IEEE Computer Society IEEE Xplore excludo

44

Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4

No. O artigo possui uma abordagem terica. No. Test and Development Process Retrospective - a Case Study using ODC Triggers Ram Chillarege, Kothanda Ram Prasad Junho, 2002 Proceedings of International Conference Dependable Systems and Networks IEEE Xplore excludo Sim. No. O artigo no utiliza a tcnica TDD. Hypothesis Testing for Module Test in Software Development Tsuneo Yamaura, Akira K. Onoma Setembro, 2006 Annual India Conference IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. On Estimating Testing Effort Needed to Assure Field Quality in Software Development Osamu Mizuno, Eijiro Shigematsu, Yasunari Takagi and Tohru Kikuno Novembro, 2002 Proceedings of 13th International Symposium on Software Reliability Engineering IEEE Xplore excludo Sim.

45

Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

No.O artigo no utiliza a tcnica TDD. An Investigation of the Applicability of Design of Experiments to Software Testing D. Richard Kuhn, Michael J. Reilly Dezembro, 2002 Proceedings of 27th Annual NASA Goddard/IEEE Software Engineering Workshop IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. Reducing wasted development time via continuous testing David Saff, Michael D. Ernst Novembro, 2003 14th International Symposium on Software Reliability Engineering IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. Breeding Software Test Cases for Complex Systems A. Watkins, D. Berndt, K. Aebischer, J. Fisher and L. Johnson Janeiro, 2004 Proceedings of the 37th Annual Hawaii International Conference on System Sciences IEEE Xplore excludo Sim. No. O artigo no utiliza a tcnica TDD.

46

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4

The Importance of Life Cycle Modeling to Defect Detection and Prevention A. Watkins, D. Berndt, K. Aebischer, J. Fisher and L. Johnson Janeiro, 2004 Proceedings of 10th International Workshop on Software Technology and Engineering Practice IEEE Xplore excludo Sim. No. O artigo no utiliza a tcnica TDD. Establishment of Automated Regression Testing at ABB: Industrial Experience Report on "Avoiding the Pitfalls" Christer Persson, Nur Yilmaztrk Setembro, 2004 Proceedings of 19th International Conference on Automated Software Engineering IEEE Xplore excludo Sim. No. O artigo no utiliza a tcnica TDD. Using the Information: Incorporating Positive Feedback Information into the Testing Process Kwok Ping Chan, Dave Towey, Tsong Yueh Chen, FeiChing Kuo Setembro, 2003 Eleventh Annual International Workshop on Software Technology and Engineering Practice IEEE Xplore excludo No. O artigo possui uma abordagem terica.

47

Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

No. A Control Approach for Agile Processes Joo W. Cangussu, Richard M. Karcich Julho, 2005 29th Annual International Computer Software and Applications Conference IEEE Xplore excludo No. O artigo possui uma abordagem terica. No. Studying the Fault-Detection Effectiveness of GUI Test Cases for Rapidly Evolving Software Atif M. Memon, Qing Xie Outubro, 2005 IEEE Transactions on Software Engineering IEEE Xplore excludo Sim. No. O artigo no utiliza a tcnica TDD. Model-based Testing Considering Cost, Reliability and Software Quality Chaw Yupar Htoon, Ni Lar Thein Novembro, 2005 Proceedings of 6th Asia-Pacic Symposium on Information and Telecommunication Technologies IEEE Xplore excludo Sim. No. O artigo no utiliza a tcnica TDD.

48

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

Optimize Defect Detection Techiniques through Empirical Software Engineering Method Hai Tao Sun Novembro, 2005 IEEE International Conference on Electro Information Technology IEEE Xplore excludo Sim. No. O artigo analisa as tcnicas de deteco de erros. Agile Software Testing in a Large-Scale Project David Talby, Arie Keren, Orit Hazzan, Yael Dubinsky Julho/Agosto, 2006 IEEE Computer Society IEEE Xplore excludo Sim. No. O artigo foca no estudo com mtodos geis e adaptaram o TDD para suas necessidades.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao

Test-Driven Development in Large Projects Raghvinder S. Sangwan, Phillip A. Laplante Setembro/Outubro, 2006 IT Professional IEEE Xplore excludo No. O artigo apresenta um estudo terico. No. Test Case Prioritization Using Relevant Slices Dennis Jeffrey, Neelam Gupta Setembro, 2006

49

Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

30th Annual International Computer Software and Applications Conference IEEE Xplore excludo Sim. No. O artigo no aborda o uso da metodologia TDD. An Empirical Study on the Relationship between Defective Requirements and Test Failures Robert W. Ferguson, Giuseppe Lami Abril, 2006 30th Annual IEEE/NASA Software Engineering Workshop IEEE Xplore excludo Sim. No. O artigo faz uma anlise sobre a relao entre a qualidade dos softwares e a qualidade dos requisitos usados para criar os softwares.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5 Nome do artigo Lista de autores Data de publicao

Using Model-Driven Development in Time-Constrained Course Projects Wilson Pdua Julho, 2007 20th Conference on Software Engineering Education and Training IEEE Xplore excludo Sim. No. O artigo utiliza a tcnica Model-Driven Development. Experiences of Using Pair Programming in an Agile Project Jari Vanhanen and Harri Korpi Janeiro, 2007

50

Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

40th Annual Hawaii International Conference on System Sciences IEEE Xplore excludo Sim. Apesar de alguns utilizarem TDD, o estudo foca na programao em par, por isso, esse artigo foi excludo.

Nome do artigo Lista de autores Data de publicao Veculo de publicao Fonte Situao do artigo (includo ou excludo) Critrio 4 Critrio 5

Test-Driven Development as a Defect-Reduction Practice Williams, L. and Maximilien and E.M., Vouk, M. Novembro, 2003 14th International Symposium on Software Reliability Engineering IEEE Xplore includo Sim. Sim.

51

APNDICE C -- FORMULRIO DE EXTRAO DE DADOS

Ttulo Lista de autores Data de publicao Veculo de publicao

Evaluating the Efcacy of Test-Driven Development: Industrial Case Studies Thirumalesh Bhat, Nachiappan Nagappan Setembro, 2006 Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering

Fonte Abstract do artigo

Portal ACM 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 efcacy of TDD. We observed a signicant increase in quality of the code (greater than two times) for projects developed 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 documentation 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 Microsoft (divises do Windows e MSN).

52

Descrio do estudo experimental

O estudo de caso 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 nalizao e os desenvolvedores no sabiam que o trabalho deles seria avaliado. Isso foi feito para minimizar a inuncia 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 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.

Comentrios

Para fazer a avaliao, o estudo deniu defeito como sendo a ocorrncia de uma anomalia externa visvel. (KLOC). As falhas foram normalizadas por milhares de linha de cdigo

Ttulo Lista de autores Data de publicao Veculo de publicao Fonte

Test-Driven Development as a Defect-Reduction Practice Williams, L. and Maximilien and E.M., Vouk, M. Novembro, 2003 14th International Symposium on Software Reliability Engineering IEEE Xplore

53

Abstract do artigo

Test-driven development is a software development practice that has been used sporadically for decades. With this practice, 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 development 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 development practice showed, during functional verication 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 Descrio do estudo experimental

Examinar a eccia de TDD como uma forma de diminuir a quantidade de erros num software. 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. O estudo compara o stimo lanamento 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 desenvolvido com outra metodologia.

Comentrios

Para vericar os erros, foi executado um teste de Vericao 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 efcacy 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.