UNIVERSIDADE FEDERAL DA BAHIA

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

Daniela Soares Feitosa Monografia apresentada ao Curso de graduação em Ciência da Computação, Departamento de Ciência da Computação, Instituto de Matemática, Universidade Federal da Bahia, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação. Orientador: Antonio Soares de Azevedo Terceiro Salvador 2007

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 uso tem aumentado bastante. Esta técnica tem como um de seus objetivos antecipar a identificação de defeitos durante o desenvolvimento do software e, para isso, 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. Este trabalho é uma revisão sistemática que tem como objetivo analisar se a utilização desta técnica diminui a quantidade de defeitos numa aplicação, melhorando sua qualidade e confiança. Palavras-chave: engenharia de software, desenvolvimento orientado por testes, revisão sistemática.

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

LISTA DE FIGURAS 2.1 Test Driven Development (BHAT; NAGAPPAN, 2006, p.357)......... 14 3.1 Hierarquia dos estudos para Engenharia de Software (KITCHENHAM, 2004, p.13)........................................ 21 4.1 Gráfico dos resultados obtidos a partir do estudo na Microsoft - (BHAT; NA- GAPPAN, 2006, p.361).............................. 25 4.2 Densidade dos defeitos encontrados no estudo na IBM - (VOUK, 17-20 Nov. 2003, p.7)..................................... 26

LISTA DE ABREVIATURAS E SIGLAS CASE Computer-Aided Software Engineering, p. 10 TDD Test-Driven Development, p. 13 XP extreme Programming, p. 14

SUMÁRIO 1 Introdução 8 2 Conceitos 10 2.1 Engenharia de Software.............................. 10 2.2 Testes de Software................................ 11 2.2.1 Fases de teste............................... 11 2.3 Testes automatizados de software......................... 12 2.4 Test-Driven Development (TDD)......................... 13 2.4.1 Extreme Programming (XP)....................... 14 3 Metodologia 18 3.1 Protocolo..................................... 19 3.1.1 Descrição do problema.......................... 19 3.1.2 Objetivo.................................. 19 3.1.3 Questões da pesquisa........................... 20 3.1.4 Palavras-chave.............................. 20 3.1.5 Método utilizado para pesquisa de fontes primárias........... 20 3.1.6 Critério de seleção dos estudos...................... 20 3.1.7 Critério de qualidade dos estudos.................... 21 3.1.8 Método de avaliação dos estudos..................... 22 3.1.9 Método de extração dos dados...................... 22 3.1.10 Método de síntese dos dados....................... 22

3.2 Execução da Revisão Sistemática......................... 22 4 Resultados 24 4.1 Discussão dos resultados............................. 24 5 Conclusão 28 5.1 Uso de revisão sistemática............................ 28 5.2 TDD X Quantidade de defeitos.......................... 28 5.3 Contribuições do trabalho............................. 29 Apêndice A -- Formulário de condução da revisão 30 Apêndice B -- Formulário de seleção de estudos 32 Apêndice C -- Formulário de extração de dados 47 Referências Bibliográficas 50

8 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 é sobre 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 manutenibilidade. 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 desenvolvido 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, devese 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

9 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 foi bem implementado. 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 utilizaçã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 quantidade 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 6 capítulos. O capítulo 2 fará uma introdução sobre os principais conceitos envolvendo TDD. O capítulo 3 descreve a metodologia utilizada, apresentando detalhadamente o protocolo e a condução da revisão. O capítulo 4 apresenta os resultados 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.

10 2 CONCEITOS Neste capítulo serão apresentados os resumos dos conceitos necessários para o entendimento 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): Engenharia 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 software 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 Pressman (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

11 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. Todos os 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

12 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 funcionam, 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 integraçã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, permitindo 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á implementado, verificando se os métodos e classes funcionam da forma esperada. Utilizando estas 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 rapidamente. 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.

13 2.4 TEST-DRIVEN DEVELOPMENT (TDD) Desenvolvimento Orientado por Testes (TDD) é uma técnica que 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. 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 desenvolvedor 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. Cada teste adicionado deve cobrir uma funcionalidade ou melhoria que ainda não foi implementada, 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 novamente 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.

14 Figura 2.1: Test Driven Development (BHAT; NAGAPPAN, 2006, p.357) 2.4.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). 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 desenvolvimento 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 comunicaçã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 facilmenet 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

15 (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 software útil As mudanças de requisito serão bem recebidas em qualquer momento, mesmo que o desenvolvimento já esteja adiantado. A entrega do software deverá ser frequente, em poucas semanas ou meses, dando preferência à menor escala. As pessoas que entendem de negócios e os desenvolvedores devem trabalhar juntos diariamente 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 desenvolvimento é 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.

16 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 para aumentar a produtividade e qualidade, com ênfase em testes via TDD. Essas práticas foram descritas por Kent Beck (BECK, 2000) e estão listadas abaixo: O processo de planejamento: Esta prática permite que o cliente defina as funcionalidades que serão prioritárias no desenvolvimento, a partir dos custos estimados fornecidos pelos desenvolvedores. 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 refletidos nos testes (TDD). Refatoração: Esta prática é utilizada para reestruturar o sistema sem mudar seu comportamento. É 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. Enquanto 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.

17 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 desenvolvimento, 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. 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.

18 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. Obrigatoriamente, 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 resultados. Na fase de planejamento, o protocolo que deverá orientar toda a revisão sistemática é construí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.

19 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 experimental, 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.

20 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 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:

21 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 devese à 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 figura 3.1 (KITCHENHAM, 2004). Apenas os estudos com nível 5 serão excluídos da revisão sistemática. Figura 3.1: Hierarquia dos estudos para Engenharia de Software (KITCHENHAM, 2004, p.13)

22 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 subseção 3.1.7.Os artigos que se enquadrarem nesses critérios serão utilizados para a finalidade deste estudo. 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 similaridades 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 formulá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