UNIVERSIDADE FEDERAL DA BAHIA Um estudo sobre o impacto

Transcrição

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) . . . . . . . . .
3.1
Hierarquia dos estudos para Engenharia de Software (KITCHENHAM, 2004,
p.13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
21
Gráfico dos resultados obtidos a partir do estudo na Microsoft - (BHAT; NAGAPPAN, 2006, p.361) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
14
25
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
14
3
Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . .
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
4
5
Execução da Revisão Sistemática . . . . . . . . . . . . . . . . . . . . . . . . .
22
Resultados
24
4.1
24
Discussão dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 IEEE Xplore e ACM
Digital Library. As strings de busca utilizadas serão formada pela interseção das palavras que
formam a população, a intervenção e o resultado listados na subseção 3.1.4. A busca será
documentada e apresentada no apêndice A.
3.1.6
CRITÉRIO DE SELEÇÃO DOS ESTUDOS
Serão incluídos na revisão todos os artigos encontrados com a utilização do método descrito
na subseção 3.1.5 que satisfaçam todos os seguintes critérios:
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
23
no protocolo de revisão e tiveram seus dados extraídos e analisados (apêndice C).
Relatório sobre os artigos encontrados (ver critérios na subseção 3.1.6):
• Estudos que não contemplavam estudos experimentais: 19
• Estudos que contemplavam estudos experimentais, mas não utilizavam a metodologia
TDD: 19
2 abordavam testes contínuos;
3 abordam programação em par e inspeção de software;
1 adaptou a metodologia TDD para suas necessidades;
1 avaliava técnicas de redução de defeitos;
1 abordava a técnica de desenvolvimento orientado a modelos;
1 focava na utilização de práticas XP para ensinar programação orientada a objetos.
1 relacionava a qualidade de um software com a qualidade dos seu requisitos;
9 não tinham nenhum relação com o tema do trabalho;
• Estudos experimentais que abordavam TDD: 5
2 foram incluídos na pesquisa;
1 foi excluído por relatar a mesma pesquisa que um arquivo já incluído;
2 foram excluídos porque analisavam a melhora na performance dos desenvolvedores
e o aumento da quantidade de testes, não os defeitos do software
24
4
RESULTADOS
Apenas dois artigos contemplaram todos os critérios de inclusão e tiveram seus dados sintetizados.
Os dois artigos, “Evaluating the Efficacy of Test-Driven Development: Industrial Case
Studies” e “Test-Driven Development as a Defect-Reduction Practice” têm em comum a intervenção utilizada (TDD), a população avaliada (projetos de software) e o resultado (diminuição
na quantidade de defeitos). O primeiro artigo recebeu uma avaliação 3-1 e o segundo, 3-2 (ver
figura 3.1). Os contextos dos dois estudos foram diferentes. O primeiro envolvia grupos de desenvolvedores de 2 divisões da Microsoft desenvolvendo projetos similares no mesmo período e
com diferentes técnicas, enquanto que no segundo um grupo de desenvolvedores da IBM desenvolveu utilizando TDD e o software resultante foi comparado com uma outra versão já existente
desenvolvida com outra técnica. Em relação ao impacto na quantidade de defeitos, no primeiro
artigo a quantidade de defeitos utilizando TDD em uma das divisões foi 2,6 vezes menor e na
outra divisão, 4,2 vezes menor. No segundo artigo, houve uma redução de 40% na quantidade
de defeitos, comparando as duas versões.
4.1
DISCUSSÃO DOS RESULTADOS
O estudo “Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies”
(BHAT; NAGAPPAN, 2006) foi realizado em duas diferentes divisões da Microsoft: Windows
e MSN. Em cada divisão, dois projetos foram selecionados e desenvolvidos por gerentes com
níveis semelhantes de responsabilidades que reportavam para um mesmo gerente com nível
superior de responsabilidade. Em cada divisão, um dos projetos foi desenvolvido utilizando
TDD e o outro não. Os projetos foram analisados após sua finalização e os desenvolvedores
não sabiam que o trabalho deles seria avaliado. Isso foi feito para minimizar a influência na
performance do desenvolvedor.
Como resultado, foi verificado que na divisão Windows, a quantidade de defeitos encontra-
25
dos no código da equipe que não utilizou TDD foi 2.6 vezes superior à outra equipe. Na divisão
MSN, o código da equipe que não utilizou TDD apresentou quantidade de defeitos 4.2 vezes
superior à equipe que utilizou a metodologia.
Para fazer avaliar os softwares produzidos, o estudo definiu defeito como sendo a ocorrência
de uma anomalia externa visível. As falhas foram normalizadas por milhares de linha de código
(KLOC).
Os projetos foram realizados com programadores profissionais em diferentes plataformas e
ambientes. A figura 4.1 mostra que nas duas divisões onde ocorreram o estudo, a qualidade do
código nos dois sistemas desenvolvidos com TDD foi pelo menos duas vezes superior à qualidade do sistemas desenvolvidos com outra técnica. Também ilustra o acréscimo no tempo de
desenvolvimento do software. Isto sugere que ao utilizar o TDD, o desenvolvedor perceberá um
aumento de qualidade do código e um acréscimo no tempo de desenvolvimento, provavelmente
aumentando os custos do software.
Figura 4.1: Gráfico dos resultados obtidos a partir do estudo na Microsoft - (BHAT; 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 década e um dos produtos produzidos por esse grupo, que já teve sete lançamentos
desde 1998 foi usado como base para o estudo. Em 2002, uma parte do grupo desenvolveu
drivers de dispositivos em uma nova plataforma utilizando TDD. O estudo compara o sétimo
lançamento desse driver na antiga plataforma com o primeiro lançamento na nova plataforma.
Como resultado, foi verificado que o driver desenvolvido com a metodologia TDD apresentou uma redução de 40% na taxa de defeito comparado ao driver de dispositivo desenvolvido
com outra metodologia.
26
Para verificar os defeitos, foi executado um teste de Verificação Funcional (FVT) por um
grupo de testes depois da produção do código. Os testes de verificação funcional analisa os
componentes do software e os testam para observar se elas operam como uma unidade e se
executam todas as funções que deveriam. Os defeitos também foram normalizadas por milhares
de linha de código (KLOC).
Alguns detalhes devem ser considerados na avaliação dos resultados deste estudo.
• Os dispositivos no produto antigo deveria funcionar em duas plataformas (Windows e
Linux), mas o driver novo precisa funcionar apenas no Linux.
• Como o driver antigo funcionava em mais plataformas de hardware que o novo, os casos
de teste foram executados em cada plataforma.
• O driver antigo suporta mais dispositivos.
A figura 4.2 ilustra a densidade das falhas observadas no estudo. Ela mostra que a densidade
das falhas encontradas no novo driver é significativamente menor que o driver antigo (legado).
Figura 4.2: Densidade dos defeitos encontrados no estudo na IBM - (VOUK, 17-20 Nov. 2003,
p.7)
Como a quantidade de estudos encontrados foram poucos, não é possível afirmar que a
utilização da técnica de desenvolvimento TDD diminui a quantidade de defeitos na aplicação
mas sugerem que a utilização dessa técnica resultará num software com maior qualidade.
Analisando os artigos que foram descartados (apêndice B) e a pequena quantidade de artigos selecionados, essa revisão sistemática indica que há pesquisas sobre XP, métodos ágeis e
TDD, mas há uma carência de estudos experimentais que indiquem o impacto no uso de TDD
na quantidade de defeitos encontrados em aplicações. Algumas pesquisas focam na quantidade
27
de testes e na produtividade do desenvolvedor e não na quantidade de defeitos, objetivo desta
revisão sistemática.
28
5
CONCLUSÃO
5.1
USO DE REVISÃO SISTEMÁTICA
Esta revisão sistemática foi conduzida a partir de um protocolo que especificou os métodos
que foram utilizadas para a condução do trabalho. A definição do protocolo foi essencial para
permitir a condução da pesquisa. Como todos os detalhes da condução da pesquisa foi definido
no início da revisão, isso impediu que o foco fosse desviado da revisão sistemática, já que
apenas foram lidos e estudados os artigos relevantes à pesquisa.
Os critérios definidos no protocolo e utilizados para a seleção dos estudos foram necessários
e suficientes para obter apenas os estudos que podiam responder às questões da pesquisa. A
utilização de formulários foi importante para documentar a revisão e permitir que os dados dos
estudos fossem sintetizados e analisados mais facilmente. Houve dificuldade para adaptar as
strings de busca, já que as bases eletrônicas de dados não permitem que as buscas sejam feitas
da mesma forma.
5.2
TDD X QUANTIDADE DE DEFEITOS
Como foi encontrado um número reduzido de estudos, esta revisão sistemática não teve
dados suficientes para analisar o impacto da utilização da técnica TDD na quantidade de defeitos
no software final. Os poucos estudos encontrados obtiveram os mesmos resultados, revelando
que há uma tendência à diminuição da quantidade de defeitos com a utilização de TDD no
desenvolvimento.
Em um dos estudos analisados foi verificado que o tempo de desenvolvimento utilizando
a técnica TDD foi maior que quando não utilizada. E em alguns estudos que não foram selecionados para essa revisão foi verificado que houve um aumento na produtividade dos desenvolvedores e na quantidade de testes executados.
29
5.3
CONTRIBUIÇÕES DO TRABALHO
A revisão sistemática provê os meios para executar revisões de literatura abrangentes e não
tendenciosas, mas ainda é muito pouco difundido na área da computação. Este trabalho mostra
que podem ser feitas revisões sistemáticas na área de engenharia de software, reunindo de forma
sistemática e passível de reprodução evidências existentes sobre um fenômeno e identificando
lacunas nas pesquisas atuais.
A quantidade de artigos selecionados nesta revisão sistemática mostra que, apesar de TDD
ser uma técnica utilizada por muitos desenvolvedores, é necessário que haja mais pesquisas
sobre o impacto da utilização desta técnica em projetos de desenvolvimento.
30
APÊNDICE A -- FORMULÁRIO DE
CONDUÇÃO DA REVISÃO
Fonte da busca
Portal ACM
Endereço virtual
http://portal.acm.org/
Data da busca
22/10/2007
String de busca
("software development", "software process", "software
project") +("development test", "test", "tests", "software
test", "tdd", "test driven development", "test-driven development", "test driven-development’, "tfd", "test first development", "test first design") +("errors", "error", "error detection", "error identification", failure", "defect")
Período dos artigos
1990 a 2007
Quantidade encontrada
15636 artigos. Destes, os 200 mais relevantes (critério do
portal) foram listados.
Quantidade
de
arquivos
12
pré-selecionados
Fonte da busca
IEEE Xplore
Endereço virtual
http://ieeexplore.ieee.org/
Data da busca
22/10/2007
String de busca
(software development<or>software process<or>software
project) <and> (development test <or> test <or> tests
<or> software test <or> tdd <or> test driven development
<or> test-driven development <or> test driven-development
<or>tfd <or> test first development <or> test first design)
<and> (errors <or> error <or> error detection <or> error
identification <or> failure <or> defect)
Período dos artigos
1990 a 2007
31
Quantidade encontrada
289 artigos
Quantidade
31
de
pré-selecionados
arquivos
32
APÊNDICE B -- FORMULÁRIO DE SELEÇÃO
DE ESTUDOS
OBS:
• Critério 4: Contempla a execução de estudos experimentais.
• Critério 5: Aborda o uso da metodologia TDD no desenvolvimento de softwares e a
quantidade de defeitos ao final do desenvolvimento.
Nome do artigo
Evaluating Advantages of Test Driven Development: a
Controlled Experiment with Professionals
Lista de autores
Gerardo Canfora, Aniello Cimitile, Felix Garcia, Mario Piattini, Corrado Aaron Visaggio
Data de publicação
Setembro, 2006
Veículo de publicação
ACM Press
Fonte
Portal ACM
Situação do artigo (incluído
excluído
ou excluído)
Critério 4
Sim.
Critério 5
O artigo aborda o uso da metodologia TDD, mas não a
quantidade de erros do software e sim a produtividade
dos desenvolvedores e a quantidade e qualidade dos testes
unitários.
Nome do artigo
Assessing Undergraduate Experience of Continuous Integration and Test-Driven Development
Lista de autores
Jon Bowyer, Janet Hughes
Maio, 2006
ACM Press
33
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Sim.
Critério 5
O artigo avalia a participação e performance dos alunos ao
desenvolver utilizando uma metodologia ágil, e não a quantidade de erros do software.
Nome do artigo
An Experimental Evaluation of Continuous Testing During
Development
Lista de autores
David Saff, Michael D. Ernst
Julho, 2004
ACM Press
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. Os desenvolvedores precisavam testar continuamente,
mas não necessariamente testar antes de codificar (TDD).
Nome do artigo
Adopting XP Practices for Teaching Object Oriented Programming
Lista de autores
Karen Keefe, Judithe Sheard, Martin Dick
Janeiro, 2006
Australian Computer Society, Inc
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Sim.
Critério 5
O foco do artigo é a utilização de práticas XP para ensinar
programação orientada a objetos.
Nome do artigo
Software Testing Research: Achievements, Challenges,
Dreams
Lista de autores
Antonia Bertolino
Maio, 2007
ICSE 2007: Future of Software Engineering
34
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Não, é um artigo teórico.
Critério 5
Não. O artigo apresentas os desafios atuais e futuros dos
testes de software.
Nome do artigo
On the Economic Evaluation of XP Projects
Lista de autores
Matthias M. Muller, Frank Padberg
Setembro, 2003
ACM Press
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Critério 5
Não. O artigo apresenta um modelo para estudar o impacto
das práticas XP.
Nome do artigo
Unit Testing: Test Early, Test Often
Lista de autores
Michael Olan
Dezembro, 2003
Consortium for Computing Sciences in Colleges
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Critério 5
Não. O artigo apresenta a necessidade de testes unitários
em todo o desenvolvimento do processo.
Nome do artigo
Rethinking Computer Science Education from a Test-first
Perspective
Lista de autores
Stephen H. Edwards
Outubro, 2003
ACM Press
Fonte
Portal ACM
excluído
ou excluído)
35
Critério 4
Não. O artigo mostra uma nova visão para a ciência da
computação, centrada no uso de TDD.
Critério 5
Não. O artigo não desenvolve um estudo de caso com TDD.
Nome do artigo
Experiences Using Test-Driven Development With An Automated Grader
Lista de autores
Stephen H. Edwards, Manuel A. Pérez-Quiñones
Janeiro, 2007
Consortium for Computing Sciences in Colleges
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Não.
Critério 5
Não. O artigo relata a experiência de testes em uma sala de
aula.
Nome do artigo
An Empirical Comparison Between Pair Development and
Software Inspection in Thailand
Lista de autores
Monvorath Phongpaibul, Barry Boehm
Setembro, 2006
ACM Press
Fonte
Portal ACM
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo apresenta experimentos para comparar programação em par e inspeção de software como técnicas de
diminuição de erros.
Nome do artigo
Assessing Test-Driven Development at IBM
Lista de autores
E. Michael Maximilien and Laurie Williams
Maio, 2003
Proceedings of the 25th International Conference on Software Engineering
Fonte
Portal ACM
excluído
ou excluído)
36
Critério 4
Sim.
Critério 5
Sim. Foi excluído, pois o artigo aborda o mesmo estudo
de caso relatado noartigo "Test-Driven Development as a
Defect-Reduction Practice".
Nome do artigo
Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies
Lista de autores
Thirumalesh Bhat, Nachiappan Nagappan
Setembro, 2006
Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering
Fonte
Portal ACM
incluído
ou excluído)
Critério 4
Sim.
Critério 5
Sim.
Nome do artigo
Improving the Software Development Process Using Testability Research
Lista de autores
Jeffrey M. Voas and Keith W. Miller
Outubro, 1992
Proceedings on Third International Symposium on Software Reliability Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Não. O artigo possui uma abordagem teórica.
Critério 5
Não.
Nome do artigo
Attitude Towards Testing: A Key Contributor to Software
Quality
Lista de autores
S. Murugesan
Dezembro, 1994
Conference Proceedings on First International Conference
on Software Testing, Reliability and Quality Assurance
Fonte
IEEE Xplore
37
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Towards A Zero-Defect Product - The End-To-End Test
Process
Lista de autores
Rathna K. Prasad
Dezembro, 1994
Conference Proceedings on First International Conference
on Software Testing, Reliability and Quality Assurance
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Controlling Software Reliability EDuring Development
Lista de autores
Gerald W. Baumann
Novembro, 1993
Proceedings on Fourth International Symposium on Software Reliability Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo não aborda o uso da técnica TDD
Nome do artigo
Test Case Design Based on Z and the Classification-Tree
Method
Lista de autores
Harbhajan Singh, Mirko Conrad, Sadegh Sadeghipour
Novembro, 1997
Proceedings on First IEEE International Conference on Formal Engineering Methods
Fonte
IEEE Xplore
excluído
ou excluído)
38
Critério 4
Critério 5
Não.
Nome do artigo
"Continuous Verification"in Mission Critical Software Development
Lista de autores
Tien-fu Chang, Alejandro Danylyzsn, So Norimatsu,Jose
Rivera, David Shepard, Anthony Lattanze, Dr.
James
Tomayko
Janeiro, 1997
Proceedings of the Thirtieth Hawaii International Conference on System Sciences
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo não aborda o uso da técnica TDD.
Nome do artigo
Improving Defect Removal Effectiveness for Software Development
Lista de autores
Hareton K. N. Leung
Março, 1998
Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Managing Cyclical Software Development
Lista de autores
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
39
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Studying the Effects of Code Inspection and Structural Testing on Software Quality
Lista de autores
Oliver Laitenberger
Novembro, 1998
Proceedings of The Ninth International Symposium on
Software Reliability Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo não aborda o uso da técnica TDD.
Nome do artigo
Integrating Pair Programming into a Software Development
Process
Lista de autores
Laurie Williams
Fevereiro, 2001
Proceedings of 14th Conference on Software Engineering
Education and Training
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
A Formal Model of the Software Test Process
Lista de autores
Joao W. Cangussu, Raymond A. DeCarlo and Aditya P.
Mathur
Agosto, 2002
IEEE Computer Society
Fonte
IEEE Xplore
excluído
ou excluído)
40
Critério 4
Critério 5
Não.
Nome do artigo
Test and Development Process Retrospective - a Case Study
using ODC Triggers
Lista de autores
Ram Chillarege, Kothanda Ram Prasad
Junho, 2002
Proceedings of International Conference Dependable Systems and Networks
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo não utiliza a técnica TDD.
Nome do artigo
Hypothesis Testing for Module Test in Software Development
Lista de autores
Tsuneo Yamaura, Akira K. Onoma
Setembro, 2006
Annual India Conference
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
On Estimating Testing Effort Needed to Assure Field Quality in Software Development
Lista de autores
Osamu Mizuno, Eijiro Shigematsu, Yasunari Takagi and
Tohru Kikuno
Novembro, 2002
Proceedings of 13th International Symposium on Software
Reliability Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
41
Critério 5
Não.O artigo não utiliza a técnica TDD.
Nome do artigo
An Investigation of the Applicability of Design of Experiments to Software Testing
Lista de autores
D. Richard Kuhn, Michael J. Reilly
Dezembro, 2002
Proceedings of 27th Annual NASA Goddard/IEEE Software Engineering Workshop
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Reducing wasted development time via continuous testing
Lista de autores
David Saff, Michael D. Ernst
Novembro, 2003
14th International Symposium on Software Reliability Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Breeding Software Test Cases for Complex Systems
Lista de autores
A. Watkins, D. Berndt, K. Aebischer, J. Fisher and L. Johnson
Janeiro, 2004
Proceedings of the 37th Annual Hawaii International Conference on System Sciences
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
42
Nome do artigo
The Importance of Life Cycle Modeling to Defect Detection
and Prevention
Lista de autores
A. Watkins, D. Berndt, K. Aebischer, J. Fisher and L. Johnson
Janeiro, 2004
Proceedings of 10th International Workshop on Software
Technology and Engineering Practice
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Nome do artigo
Establishment of Automated Regression Testing at ABB:
Industrial Experience Report on "Avoiding the Pitfalls"
Lista de autores
Christer Persson, Nur Yilmaztürk
Setembro, 2004
Proceedings of 19th International Conference on Automated Software Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Nome do artigo
Using the Information: Incorporating Positive Feedback Information into the Testing Process
Lista de autores
Kwok Ping Chan, Dave Towey, Tsong Yueh Chen, FeiChing Kuo
Setembro, 2003
Eleventh Annual International Workshop on Software Technology and Engineering Practice
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
43
Critério 5
Não.
Nome do artigo
A Control Approach for Agile Processes
Lista de autores
João W. Cangussu, Richard M. Karcich
Julho, 2005
29th Annual International Computer Software and Applications Conference
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Critério 5
Não.
Nome do artigo
Studying the Fault-Detection Effectiveness of GUI Test
Cases for Rapidly Evolving Software
Lista de autores
Atif M. Memon, Qing Xie
Outubro, 2005
IEEE Transactions on Software Engineering
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Nome do artigo
Model-based Testing Considering Cost, Reliability and
Software Quality
Lista de autores
Chaw Yupar Htoon, Ni Lar Thein
Novembro, 2005
Proceedings of 6th Asia-Pacific Symposium on Information
and Telecommunication Technologies
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
44
Nome do artigo
Optimize Defect Detection Techiniques through Empirical
Software Engineering Method
Lista de autores
Hai Tao Sun
Novembro, 2005
IEEE International Conference on Electro Information
Technology
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo analisa as técnicas de detecção de erros.
Nome do artigo
Agile Software Testing in a Large-Scale Project
Lista de autores
David Talby, Arie Keren, Orit Hazzan, Yael Dubinsky
Julho/Agosto, 2006
IEEE Computer Society
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo foca no estudo com métodos Ágeis e adaptaram o TDD para suas necessidades.
Nome do artigo
Test-Driven Development in Large Projects
Lista de autores
Raghvinder S. Sangwan, Phillip A. Laplante
Setembro/Outubro, 2006
IT Professional
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Não. O artigo apresenta um estudo teórico.
Critério 5
Não.
Nome do artigo
Test Case Prioritization Using Relevant Slices
Lista de autores
Dennis Jeffrey, Neelam Gupta
Setembro, 2006
45
30th Annual International Computer Software and Applications Conference
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo não aborda o uso da metodologia TDD.
Nome do artigo
An Empirical Study on the Relationship between Defective
Requirements and Test Failures
Lista de autores
Robert W. Ferguson, Giuseppe Lami
Abril, 2006
30th Annual IEEE/NASA Software Engineering Workshop
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo faz uma análise sobre a relação entre a qualidade dos softwares e a qualidade dos requisitos usados para
criar os softwares.
Nome do artigo
Using Model-Driven Development in Time-Constrained
Course Projects
Lista de autores
Wilson Pádua
Julho, 2007
20th Conference on Software Engineering Education and
Training
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Não. O artigo utiliza a técnica Model-Driven Development.
Nome do artigo
Experiences of Using Pair Programming in an Agile Project
Lista de autores
Jari Vanhanen and Harri Korpi
Janeiro, 2007
46
40th Annual Hawaii International Conference on System
Sciences
Fonte
IEEE Xplore
excluído
ou excluído)
Critério 4
Sim.
Critério 5
Apesar de alguns utilizarem TDD, o estudo foca na programação em par, por isso, esse artigo foi excluído.
Nome do artigo
Test-Driven Development as a Defect-Reduction Practice
Lista de autores
Williams, L. and Maximilien and E.M., Vouk, M.
Novembro, 2003
Fonte
IEEE Xplore
incluído
ou excluído)
Critério 4
Sim.
Critério 5
Sim.
47
APÊNDICE C -- FORMULÁRIO DE EXTRAÇÃO
DE DADOS
Título
Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies
Lista de autores
Thirumalesh Bhat, Nachiappan Nagappan
Setembro, 2006
Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering
Fonte
Portal ACM
Abstract do artigo
This paper discusses software development using the Test
Driven Development (TDD) methodology in two different
environments (Windows and MSN divisions) at Microsoft.
In both these case studies we measure the various context,
product and outcome measures to compare and evaluate the
efficacy of TDD. We observed a significant increase in 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 (divisões do Windows e MSN).
48
Descrição do estudo experi-
O estudo de caso foi realizado em duas diferentes divisões
mental
da Microsoft, Windows e MSN. Em cada divisão, dois projetos foram selecionados e desenvolvidos por gerentes com
níveis semelhantes de responsabilidades que reportavam
para um mesmo gerente com nível superior de responsabilidade. Em cada divisão, um dos projetos foi desenvolvido
utilizando TDD e o outro não. Os projetos foram analisados
após sua finalização e os desenvolvedores não sabiam que o
trabalho deles seria avaliado. Isso foi feito para minimizar
a influência na performance do desenvolvedor.
Resultados
Na divisão Windows, a quantidade de defeitos encontrados
no código da equipe que não utilizou TDD foi 2.6 vezes superior à outra equipe. Na divisão MSN, o código da equipe
que não utilizou TDD apresentou quantidade de defeitos 4.2
vezes superior à equipe que utilizou a metodologia.
Comentários
Para fazer a avaliação, o estudo definiu defeito como sendo
a ocorrência de uma anomalia externa visível.
As fal-
has foram normalizadas por milhares de linha de código
(KLOC).
Título
Test-Driven Development as a Defect-Reduction Practice
Lista de autores
Williams, L. and Maximilien and E.M., Vouk, M.
Novembro, 2003
Fonte
IEEE Xplore
49
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 verification and
regression tests, approximately 40traditional fashion. The
productivity of the team was not impacted by the additional
focus on producing automated test cases. This test suite will
aid in future enhancements and maintenance of this code.
The case study and the results are discussed in detail.
Objetivo do estudo
Examinar a eficácia de TDD como uma forma de diminuir
a quantidade de erros num software.
Descrição do estudo experi-
Um grupo de desenvolvedores da IBM desenvolve drivers
mental
de dispositivos há mais de uma década e um dos produtos produzidos por esse grupo, que já teve sete lançamentos
desde 1998 foi usado como base para o estudo. Em 2002,
uma parte do grupo desenvolveu drivers de dispositivos em
uma nova plataforma. O estudo compara o sétimo lançamento desse driver na antiga plataforma com o primeiro
lançamento na nova plataforma.
Resultados
Utilizando a metodologia TDD, houve uma redução de 40na
taxa de erro comparado ao driver de dispositivo desenvolvido com outra metodologia.
Comentários
Para verificar os erros, foi executado um teste de Verificação
Funcional (FVT) por um grupo de testes depois da produção
do código. Os erros foram normalizadas por milhares de
linha de código (KLOC).
50
REFERÊNCIAS BIBLIOGRÁFICAS
ASTELS, D. Test Driven Development: A Practical Guide. [S.l.]: Pearson, 2003.
BECK, K. EXtreme Programming Explained. [S.l.]: Addison-Wesley Professional, 2000.
BECK, K. Test Driven Development: By Example. [S.l.]: Addison-Wesley Professional, 2003.
BEEDLE, M. et al. Manifesto for Agile Software Development. 2001. Disponivel em
http://agilemanifesto.org/principles.html. Último acesso em 12/12/2007.
BHAT, T.; NAGAPPAN, N. Evaluating the efficacy of test-driven development: industrial case
studies. ACM, New York, NY, USA, p. 356–363, 2006. Disponível em http://portal.acm.org.
Último acesso em 12/12/2007.
FOWLER, M. Refactoring: Improving the Design of Existing Code. [S.l.]: Addison-Wesley,
2001.
JEFFRIES, R. XProgramming.com: an Agile Software Development Resource. 2007.
Disponível em http://www.xprogramming.com/. Último acesso em 12/12/2007.
KITCHENHAM, B. Procedures for performing systematic reviews. Keele University, UK,
Technical Report, p. 1353–7776, 2004. Disponível em http://portal.acm.org. Último acesso 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. 34–45, 17–20
Nov. 2003. ISSN 1071-9458. Disponível em http://ieeexplore.ieee.org. Último acesso em
12/12/2007.

UNIVERSIDADE FEDERAL DA BAHIA Um estudo sobre o impacto

Transcrição

Documentos relacionados

Ata do Pregão Presencial n.º 63/2015 Objeto: MATERIAL

Que tipo de garantia têm os produtos AV200 da Corinex?

Iniciando a Sua Pesquisa

Declaração de garantia do nível de bolha

Escarola - Hortiescolha

Marcelo Morandi

tantos cruzeiros, tudo incluído

071 - Cabo do Exército foi excluído das Forças Armadas sem direito

RIU NEGRIL 5* RIU OCHO RIOS 5* Últimos

Super-económico e sem problemas