1

UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA

A QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE

A STUDY ABOUT APPROACHES OF TEST AND THEIR CONTRIBU TIONS TO

QUALITY ON SOFTWARE DEVELOPMENT

Fábio PIO¹

Rogério ROCHA²

¹Faculdade de Minas, Faminas-BH, Curso de Bacharelado em Sistemas de Informação.

E-mail: fabioleandropio@oi.com.br

²Mestre e professor do curso de Bacharelado de Sistemas de Informação

E-mail: rogerio.rocha@faminasbh.edu.br

Resumo

Este artigo teve como finalidade discutir na perspectiva da qualidade do software em processos ágeis, como o desenvolvimento dirigido a testes, pode contribuir para a criação de software de qualidade. Para este fim, foi utilizada a metodologia de pesquisa qualitativa por meio de revisões bibliográficas, bem como, artigos e periódicos relacionados ao tema. Houve ainda pesquisa quantitativa por meio de um estudo de caso com aplicação de questionário junto aos desenvolvedores de uma empresa do ramo de desenvolvimento de software, a fim de coletar na prática, suas impressões a respeito dos assuntos abordados. O resultado da pesquisa permitiu tecer considerações baseadas no estudo, coleta de dados e na análise comparativa feita com abordagens já existentes, proporcionando uma fonte para aqueles que buscam conhecer sobre a utilização de técnicas de testes nos ciclos do desenvolvimento de software, visando obter produtos de maior qualidade. Palavras-chave: Qualidade. Software. Testes. Processo Ágil.

Abstract

This article aimed to discuss, from the perspective of software quality in agile process, how the test driven development, can contribute to creation quality software. With this objective, it was used qualitative research methodology through literature reviews, as well as articles and journals related to the topic. There were also quantitative researches through case study with questionnaire together developers of a software development company in order to collect their impressions in practice concerning the matters addressed. The result of the research allowed to make considerations based on research, data collection and benchmarking with techniques already existing, providing a source for those seeking to meet about the techniques used during testing cycles of software development, in order to obtain higher quality products. Keywords: Quality. Software. Tests. Agile Process.

2

1 Introdução

Segundo Sommerville (2007) os negócios operam em um ambiente global de rápidas

mudanças e devem atender ao mesmo tempo as novas oportunidades e mercados, mudanças

de condições econômicas e ao surgimento de produtos e serviços concorrentes. O software é

parte de quase todas as operações de negócio, integrando ainda, centenas de tarefas no dia-a-

dia de milhares de empresas.

Estão presentes nos mais diversos dispositivos capazes de processar centenas de

informações por segundo, o que os torna familiares a grande parte da sociedade. O

desenvolvimento de software tem a finalidade de contribuir com as novas oportunidades e

responder as pressões competitivas, é comumente relacionado como fonte de auxílio à tomada

de decisão nas empresas. Estes são alguns dos fatores que caracterizam, há décadas, a

importância do software e a necessidade da preocupação em se estabelecer boas práticas que

remetam a um desenvolvimento de qualidade.

Para Pressman (2002), no início a programação e os processos de desenvolvimento de

softwares, eram vistos como uma “forma de arte”. Existiam poucos métodos formais e poucas

pessoas os utilizavam. O programador frequentemente aprendia seu ofício por meio de

tentativa e erro. Tempos depois, profissionais e técnicos começavam a ter preocupações

relativas ao software e a maneira como ele era desenvolvido. Uma das indagações e que muito

atormentavam os profissionais das décadas passadas era: “Por que não descobrimos todos os

erros antes de entregarmos o software aos nossos clientes?”.

Pressman (2002) salienta ainda que, um conceito que levaria os desenvolvedores de

software a uma grande reflexão e, consequentemente, a um maior comprometimento em

relação aos anseios do mercado seria o estabelecimento e uso de sólidos princípios de

engenharia, para que se possa obter economicamente um software que seja confiável e que

funcione eficientemente em máquinas reais. O alcance destes princípios viria a ocorrer por

meio de três elementos fundamentais: Métodos, ferramentas e procedimentos.

Diante das muitas buscas e estudos de melhoria do processo de desenvolvimento de

software, em 2001, no chamado “Manifesto Ágil1”, a união de dezessete especialistas em

processos de desenvolvimento de software representando os métodos Scrum, Extreme

Programming (XP) e outros, culminaram na criação da aliança ágil.

1 Encontro realizado em 2001 por um conjunto de pensadores independentes abordando assuntos relacionados ao

desenvolvimento de software. Disponível em: <http://agilemanifesto.org/> Acessado em: 10/10/2012.

3

Segundo Beck (2002) as metodologias ágeis aplicam uma coleção de práticas bem

definidas e guiadas por princípios e valores que podem ser aplicados por profissionais de

software no dia-a-dia. Uma destas práticas é o desenvolvimento dirigido por testes, objetivo

geral de estudo deste artigo em comparação às abordagens tradicionais.

A proposta foi analisar na perspectiva da qualidade do software em processos ágeis,

como o desenvolvimento dirigido por testes, pode contribuir para a criação de software de

qualidade? Para isso, alguns objetivos específicos foram definidos, como os de realizar uma

análise comparativa entre técnicas e práticas existentes, além do estudo de caso junto a

desenvolvedores de uma empresa de desenvolvimento de software. Estes foram alguns passos

seguidos para a busca do objetivo geral definido.

Assim, a metodologia utilizada para criação deste trabalho consistiu em grande parte

pelo embasamento por meio de pesquisa bibliográfica, revisões de materiais como artigos,

periódicos e sites para uma abordagem qualitativa das informações. Foi realizado também um

estudo de caso por meio da aplicação de questionário aos profissionais da área de

desenvolvimento em uma empresa do ramo de softwares, observando os níveis de

conhecimento e experiência para uma análise quantitativa sobre as opiniões a respeito da

temática abordada.

Por fim, foram tecidas algumas considerações baseadas no estudo, coleta de dados e

análise comparativa de abordagens a fim de oferecer subsídios para aqueles que buscam

conhecer sobre a utilização de técnicas de testes durante os ciclos do desenvolvimento de

software, visando obter produtos de maior qualidade.

2 Garantia da qualidade de software

Segundo Sommerville (2007), “garantia de qualidade é o processo de definição de

como a qualidade de software pode ser atingida e como a organização de desenvolvimento

sabe que o software possui o nível de qualidade necessário”. Desta forma, o processo de

Quality Assurance (QA) está principalmente relacionado à definição e seleção de padrões que

devem ser aplicados aos processos de desenvolvimento de software ou ao produto de

software. Vale ressaltar que assim como os serviços que ele fornece, os produtos de software

possuem outros atributos associados e que juntos são capazes de demonstrar a qualidade do

software.

A norma internacional ISO/IEC 9126, publicada em 1991, e que na versão brasileira de agosto de 1996 recebeu o número NBR 13596, define qualidade de software como “A totalidade de características de um produto de software que lhe confere a

4

capacidade de satisfazer necessidades explicitas e implícitas”. Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. [...] As necessidades implícitas são subjetivas aos usuários (inclusive operadores, destinatários dos resultados do software e mantenedores do produto), são também chamadas de fatores externos e podem ser percebidas tanto pelos desenvolvedores quanto pelos usuários. (MOLINARI, 2003, p. 24)

Ainda segundo Sommerville (2007), como parte do processo de QA, naturalmente os

envolvidos podem selecionar e adquirir ferramentas e métodos para apoiar os padrões

estipulados para o processo de desenvolvimento. Os dois tipos de padrões que podem ser

estabelecidos como partes do processo de QA seriam: “padrões de produto” e “padrões de

processo”.

Segundo o autor, os padrões de produto se aplicam ao produto de software em

desenvolvimento, bem como, padrões de documentos, padrões de codificação, definição de

como uma linguagem de programação pode ser usada, etc. Já os padrões de processo definem

os processos que devem ser seguidos durante o ciclo de desenvolvimento de software. Neste

caso, podem incluir definições de processos de especificação, projeto e validação, e uma

descrição dos documentos que devem ser escritos ao longo dos processos (também

conhecidos como artefatos).

Ainda conforme Sommerville (2007) há uma estreita ligação entre os padrões de

produtos e de processos. Os padrões de produto aplicam-se a saída do processo de software e

em muitos casos, os padrões de processo incluem atividades de processo específicas que

asseguram que padrões de produto sejam seguidos.

2.1 Processo tradicional de testes de software

Para Rios e Moreira (2003) o processo de testes deve basear-se em uma metodologia

aderente ao processo de desenvolvimento, com pessoal técnico qualificado, em ambiente e

ferramentas adequadas. A metodologia de testes deve ser o documento básico para organizar a

atividade de testar aplicações no contexto da empresa. Para o autor, assim como é indesejável

o desenvolvimento de sistemas que não possuam uma metodologia adequada, também

acontece o mesmo com a atividade de testes.

Segundo Pressman (2002) existe ainda a estratégia de teste de software, que integra

métodos de projeto de casos de teste numa série bem planejada de passos, que resultam na

construção de software bem sucedida. A estratégia fornece um roteiro que descreve tais

5

passos a serem conduzidos como parte do teste. Define quando serão planejados e executados,

o cálculo de esforço, tempo e recursos necessários para tais tarefas.

Assim, conforme Pressman (2002) tem-se que qualquer estratégia de teste deve

incorporar planejamento de teste, projeto de casos de teste, execução de teste e a resultante

coleta e avaliação de dados. Uma estratégia de testes de software deve ser suficientemente

flexível para promover uma abordagem de teste sob medida ao objeto de teste. Ao mesmo

tempo, deve ser suficientemente rígida para promover planejamento razoável e

acompanhamento gerencial, à medida que o projeto progride.

2.1.2 Ciclo tradicional dos testes de software

“O ciclo de vida de testes e de desenvolvimento são totalmente interdependentes, mas

o ciclo de testes é dependente da conclusão dos produtos e da atividade do ciclo de

desenvolvimento”. (BASTOS et al., 2007, p. 40).

Segundo Bastos et al. (2007) apud Rios (2003), na figura 1, a parte de “Procedimentos

iniciais” é uma fase curta, no qual é traçado em linhas gerais, um pequeno esboço do processo

de teste e assinado um acordo de nível de serviço. “Planejamento” e “Preparação” são etapas

que acompanham todo o processo de teste. Trata-se de atividades complementares e de

suporte ao processo. O cerne de todo o processo de teste está em “Especificação, Execução e

Entrega”, que consomem em torno de 80% a 85% de todo processo.

Figura 1 – Modelo 3P x 3E do ciclo de vida do processo de teste

Fonte: RIOS e MOREIRA (2003, p.9)

Segundo Bastos et al. (2007), no chamado “conceito V” de testes tem-se que as ações

de ver e conferir são realizados do início ao fim no ciclo de vida do desenvolvimento de

software. São realizadas desde atividades voltadas a verificação em um processo inicial do

desenvolvimento do software (uma vez que ainda não se pode ter o produto completo para

6

examinar), envolvendo itens como requisitos, análise, arquitetura e codificação, e por fim, até

as atividades de validação (onde tem-se que é algo mais maduro e já funcional), oferecendo

condições de aplicar os testes unitários, testes de integração, testes de sistema e os testes de

aceite.

2.2 A prática do desenvolvimento dirigido a testes

“O test driven development (TDD) é uma forma de gerir o medo durante a

programação”. (BECK, 2002, p. 7, tradução nossa).

Beck (2002) discorre que o sentido da palavra medo não quer dizer que seja

prejudicial ao desenvolvedor, mas que este deve arriscar o bastante ao ponto de planejar testes

que levem ao conhecimento profundo de seu código e os efeitos por ele provocados. O autor

ressalta ainda que uma das principais vantagens do test driven development ou

desenvolvimento dirigido a testes, é que o código desenvolvido já pode ser testado contra os

casos de teste criados pelo próprio desenvolvedor na fase conhecida como de “testes

unitários” ou “teste de componentes”.

Segundo Nicolas (2006), o TDD consiste em iterações de desenvolvimento curtas,

onde os casos de teste para cobrir uma nova funcionalidade (feature) são criados em primeiro

lugar frente à implementação propriamente dita. A ideia principal é que cada desenvolvedor

tenha a concepção de que não é possível desenvolver algo que ele mesmo não saiba como

testar ou validar frente aos objetivos do sistema (requisitos).

Ambler (2011) complementa que no TDD existe um aumento da sua confiança sobre o

que funciona no sistema e maior atenção aos requisitos definidos. Além do mais, pode-se ter

100% de cobertura (cada linha de código é testada), algo que com os testes tradicionais ainda

não é possível.

Diante das diversas definições e características do TDD, pode-se dizer que é uma

prática que se relaciona aos processos de desenvolvimento de software modernos. Propõe uma

nova abordagem no tocante ao código desenvolvido versus a qualidade empregada. É

originada de metodologias ágeis, bem como a programação extrema ou extreme programimg

(XP) 2 presente também no Scrum3, visando sempre uma maior qualidade, com o dispêndio

cada vez menor de recursos.

2“” Extreme programing enfatiza a satisfação do cliente como um dos seus principais impulsionadores, a metodologia “” pretende entregar o software que o cliente precisa, quando precisa (WATKINS, 2009, p. 21, tradução nossa). 3“” Scrum é um método de gerenciamento de projetos para o desenvolvimento ágil de softwares e testes de forma a permitir à “” auto-organização das equipes. (WATKINS, 2009, p. 23, tradução nossa).

7

2.2.1 Ciclo de vida do desenvolvimento dirigido a testes

Beck (2002) como propulsor do TDD e sua aplicação nos processos de

desenvolvimento, criou o conhecido “ciclo do TDD”, que consiste nos seguintes passos (vide

figura 2):

Figura 2 – Ciclo do TDD

Fonte: GASPARETO (2006, p. 2)

Segundo Beck (2002), deve-se criar um teste de forma genérica, pensar em como

gostaria que a operação aparecesse no código, este é o momento propício para inventar a

interface que se deseja e incluir todos os elementos da história imaginada; será necessário

calcular as respostas certas para saber identificar as falhas geradas. Executar o programa e

fazê-lo funcionar. Rapidamente fazer ficar verde o sinalizador da maioria dos utilitários para a

criação deste tipo de teste (XUnit). Se a solução é simples, será fácil fazer o teste passar, o

que torna fácil também fazer com que falhe. Depois de ver “passar” e “falhar”, deve-se agora

fazer a coisa certa. Retirar a duplicação gerada, fazer o que chamam de refatoração

(refactoring). Rodar novamente e ver como o sistema está se comportando.

8

Fowler (2004) salienta a importância do refactoring, como forma de encontrar o ponto

de equilíbrio do trabalho. Permite, sobretudo, descobrir que o projeto, em vez de acontecer

todo no início, ocorre continuamente durante o desenvolvimento. Há um processo de

aprendizado com a construção dos sistemas e como melhorar o projeto. A interação resultante

leva a um programa que permanece bom na medida em que o desenvolvimento continua.

Assim, a fase de refactoring é uma das mais importantes para o TDD, uma vez que é neste

passo em que o código assume sua forma mais madura.

Além do refactoring visto como um ponto positivo no TDD, os principais teóricos da

comunidade ágil, dentre eles Nicolas (2006) citam vantagens de se seguir o ciclo do TDD,

dentre elas que os desenvolvedores teriam quase um retorno imediato sobre os componentes

que desenvolvem e testados contra os casos de teste. O tempo de resposta para a resolução de

defeitos é mais curto do que o que se tem na metodologia cascata tradicional, onde o código é

testado dias ou semanas após a implementação e o desenvolvedor já pode ter se direcionado a

outros contextos. Outro fator citado pelo autor, seria que os casos de teste são facilmente

gerados a partir dos casos de uso e refletem as especificações funcionais com precisão, o que

evita a criação desnecessária de código.

Por fim, o autor afirma que o TDD se encaixa muito bem no processo ágil como

Scrum. Durante um Sprint4 por exemplo, pode ser definido que a aplicação irá executar contra

um conjunto pré-definido de casos de teste, enquanto se codifica outras coisas. Assim, a

prática vai sempre requerer que o desenvolvedor de software pense em termos de pequenas

unidades que podem ser escritas e testadas de forma independente e integrados em conjunto

posteriormente.

2.3 Testes unitários e a prática do TDD

Martin (2011) afirma que em 1997 não se ouvia falar TDD, os testes de unidade eram

um pequeno pedaço de código descartável que eram escritos para se certificar que os

programas funcionavam. Tipicamente, envolvia a criação de um programa simples de controle

que permitisse interagir manualmente com o programa que havia acabado de desenvolver.

Para Johansen (2011) escrever testes é um investimento que geralmente remente a uma

objeção comum de que consome muito tempo, embora naturalmente, testar aplicações leva

tempo. Os testes unitários servem ainda como boa documentação, pois, permite que os

desenvolvedores (novatos e veteranos) entendam rapidamente o sistema baseado nos testes 4 Consiste em curtas fases de desenvolvimento que o Scrum denomina “Sprints”. (Cockburn, 2000, p. 179, tradução nossa).

9

criados. Isso tudo contribui para a criação de códigos limpos (clean code) e de fácil

compreensão.

Na visão ágil segundo Crispin e Gregory (2009), quando um desenvolvedor começa a

codificar uma tarefa de testes, ele escreve rotinas que capturam o comportamento de parte do

código, que progressivamente são incrementados até que se possa capturar o comportamento

de todo o código. Assim, o desenvolvedor tem a chance de pensar melhor no que esta sendo

desenvolvido e sua funcionalidade frente à necessidade do cliente. Um fato interessante é que

pode inclusive, envolver o testador, pois assim tem ajuda para garantir que todos os aspectos

daquele fragmento de código e sua integração com outras unidades serão testados.

Larman (2005) diz que com o TDD irão surgir eventualmente centenas ou milhares de

testes de unidade e uma classe de teste para cada classe de produção. Quando um

desenvolvedor precisa modificar o código existente (escrito por ele mesmo ou outros), já

existirá um conjunto de testes de unidade que poderão ser executados, fornecendo

realimentação imediata se a modificação causar algum erro.

Assim, já existem ferramentas e recursos que auxiliam desenvolvedores na criação e

manutenção do TDD como o caso dos XUnit, Mock objects e ferramentas de integração

contínua que serão melhor detalhadas nos tópicos a seguir.

2.3.1 Ferramentas (XUnit)

Segundo Shoren e Warden (2008) o framework mais popular de teste de unidade é a

família XUnit (para muitas linguagens). Para Java a versão popular é o JUnit5, existe também

um NUnit6 para .NET, etc. O JUnit está integrado a muitas Interactive Development

Environment (IDE) populares de Java, tal como o Eclipse7 e é conhecido pela maioria dos

desenvolvedores.

Segundo Beck (2002) com a utilização de ferramentas XUnit, é possível se descobrir

diferenças entre as afirmações de falha (asserts) de outros tipos de erros durante a execução

de testes, o que permite uma detecção eficaz levando rapidamente a causa do erro.

5 JUnit é um framework de testes unitários para a linguagem de programação Java. Disponível em: <http://www.junit.org/> “” Acessado em: 15/10/2012. 6 NUnit é um framework de testes unitários para a linguagem de programação .NET. Disponível em: <http://www.nunit.org/> “ Acessado em: 15/10/2012. 7 Eclipse é um ambiente de desenvolvimento que suporta linguagens como Java. Disponível em: <http://www.eclipse.org/> “” Acessado em: 15/10/2012.

10

Assim, tais ferramentas oferecem aos desenvolvedores melhores condições para

alcance da eficácia na criação dos testes e menor perda de tempo, o que costuma ser um fator

de grande importância durante as rápidas iterações de desenvolvimento.

2.3.2 Objetos simulados (Mock objects)

Segundo Shone e Warden (2008) o teste com mock objects é uma técnica popular,

originada no Extreme Program (XP) para isolar classes para teste de unidade. Ao usar objetos

simulados, os testes podem substituir o próprio objeto por um "objeto fictício".

Ainda segundo os autores, o objeto de simulação confere se ele é chamado

corretamente e fornece uma resposta pré-definida. Ao fazer isso, evita-se a demora da

comunicação com um banco de dados, socket de rede, ou entidades de fora ou mesmo que

estejam sobre responsabilidade de outro desenvolvedor para implementação.

Watkins (2009) propõe que a sequencia normal de testes de unidade com mock objects

durante os testes unitários conforme ilustrado (figura 3):

Figura 3- Ciclo do teste com Mock Objects

Fonte: Adaptado de CASSIDY, Colin. E-university, 2012.

Segundo Watkins (2009), o teste de unidade inicia o framework mocks objects que

solicita uma simulação dinâmica de objetos para cada dependência do código em teste; são

11

criados os mock objects dinâmicos. O teste de unitário cria um conjunto de "expectativas" de

como ele espera que o código em teste interaja com os objetos e suas respostas. Logo, o teste

de unitário invoca o código em teste, evitando o risco de usar o código que está fora do

escopo do teste. O código em teste executa, chamando o mock test em vez da situação real. O

mock test verifica se ele foi chamado corretamente. Se assim for, ele retorna o resultado que

foi gerado. Senão, ele gera um erro mostrando que o teste de unidade falhou.

2.3.3 Testes automatizados e a integração contínua

Segundo Beck (2002), outro ponto que deve ser considerado nos testes unitários,

principalmente quando se lembram de processos ágeis são os testes automatizados. Crispin e

Gregory (2009) complementam que qualquer tarefa tediosa ou repetitiva e que esteja

envolvida no desenvolvimento de software é um forte candidato para automação.

Por este motivo, muitas equipes de desenvolvimento, principalmente as ágeis, já

pensam sobre a importância de uma compilação automatizada e a integração contínua durante

o processo de desenvolvimento. Na linha de estudo proposta por Crispin e Gregory (2009) é

praticamente inviável construir uma série de testes automatizados sem pensar na automação

das rotinas para geração das versões e execução dos testes.

Ainda segundo as autoras Crispin e Gregory (2009), geralmente a equipe precisa do

retorno imediato dos testes para permanecerem seguros sobre alguma mudança. Receber e-

mails automáticos de construção listando todas as mudanças verificadas já é de grande ajuda

aos testadores e envolvidos no processo de QA, porque eles sabem quando uma compilação

está pronta para testar sem ter que incomodar os programadores.

Uma das ferramentas de integração contínua bastante difundida e conhecida pela

comunidade, permitindo dentre outras coisas a geração de versões e testes é o Jenkins8,

ferramenta também citada por Martin (2011) em seu livro The Clean Coder: "Ultimamente eu

tenho usado Jenkins como o meu mecanismo de desenvolvimento contínuo. É leve, simples, e

não precisa de quase nenhuma curva de aprendizagem. Você o baixa, executa, realiza algumas

configurações rápidas e simples, logo já estará pronto e funcionando". (MARTIN, 2011, p.

197, tradução nossa).

8 Jenkins é um aplicativo que monitora as execuções de trabalhos que se repetem, como a construção de um projeto de “” software. Disponível em: <http://jenkins-ci.org/> Acessado em: 18/10/2012.

12

2.4 Dos testes tradicionais ao TDD

Os principais entusiastas envolvidos nos estudos de processos de desenvolvimento de

software ágeis detêm opiniões muito particulares sobre a prática do TDD e das abordagens

tradicionais, algumas foram coletadas e serão apresentadas no decorrer deste tópico.

Crispin e Gregory (2009) discorrem que o sistema é mais susceptível a satisfazer os

requisitos do cliente com o TDD. Segundo as autoras, em processos tradicionais onde

primeiro se cria o programa de computador e depois se testa, o tempo de teste é ocupado em

encontrar e corrigir falhas (bugs) que poderiam ter sido detectados por testes unitários. Isso é

um grande problema para os desenvolvedores, pois, há o risco de não ter tempo para encontrar

as situações graves, ou quando encontradas, podem não se ter o tempo de corrigi-las, o que

pode afetar negativamente o negócio. Assim, quando times de desenvolvimento praticam o

TDD, acabam por minimizar a quantidade de bugs que podem ser encontrados

posteriormente, uma vez que grande parte dos erros é evitada pelo ato de escrever o teste

antes de codificar.

Para Ambler (2011), tal como acontece com os testes tradicionais, quanto maior o

perfil de risco do sistema, mais completos os testes precisam ser, ressaltando ainda que em

ambos os testes, tradicionais ou TDD, não se está buscando a perfeição, em vez disso, está

testando a importância do sistema.

Watkins (2009) discorre a respeito do feedback dos desenvolvedores adeptos ao TDD,

mostrando que a técnica é recebida como uma abordagem muito valiosa. Complementa ainda

que, é grande a necessidade de compreensão dos requisitos em nível de detalhe suficiente para

capacidade de projetar um teste que mostre que o código atende ao requisito.

Assim, antes de escrever o código, significa que os desenvolvedores ganharam a

compreensão completa da intenção do requisito antes de codificá-lo. Diferente do que ocorre

em processos tradicionais que contam com os testes unitários criados após o desenvolvimento

de código ou mesmo aqueles em que qualquer tipo de teste é feito somente após a liberação

do software em fase específica aos profissionais de teste.

Ainda segundo o autor Watkins (2009), alguns desenvolvedores manifestaram a

opinião de que TDD iria atrasá-los e reduzir sua produtividade, porém na prática, não houve

redução significativa na produtividade do desenvolvedor, mas sim uma melhoria mensurável

da qualidade do código e consequentemente, nas ações por ele realizadas.

13

3 Análise e discussão dos dados obtidos

Conforme previsto na metodologia, para uma análise envolvendo o desenvolvimento

dirigido a testes e abordagem tradicional, foi realizado um estudo de caso por meio da

aplicação de questionário com profissionais de desenvolvimento. Foi submetido um

formulário de 13 questões (múltipla escolha) para preenchimento a 20 desenvolvedores, dos

quais 13 enviaram suas respostas. A pesquisa ocorreu numa empresa do ramo do

desenvolvimento de softwares, fornecedora de aplicações para ambiente web e adepta à

metodologia de desenvolvimento ágil Scrum.

Foram solicitadas informações como idade e nível de escolaridade a fim de conhecer

um pouco mais do perfil dos respondentes, onde do total 77% afirmaram ter de 25 a 32 anos

de idade e 23% afirmaram ter idade de 18 a 24 anos. A escolaridade apresentou que 69% do

total de respondentes são de nível superior completo e 31% com pós-graduação (stricto ou

lato sensu) em áreas relacionadas à tecnologia.

Sobre o TDD, 69% do total dos respondentes afirmaram o conhecer contra 31% que

não o conhecem. Daqueles que afirmaram conhecer o TDD, foi perguntado se atuam ou já

atuaram utilizando a técnica, a resposta foi de que 67% nunca atuaram com a técnica (mesmo

a conhecendo) e que somente 33% atuam ou já atuaram com o TDD (vide gráfico 1).

Gráfico 1 - Popularidade do TDD

Fonte: Autoria própria

0%

10%

20%

30%

40%

50%

60%

70%

80%

Conhecem o

TDD

Não

conhecem o

TDD

Atua/atuou

com TDD

Nunca atuou

com TDD

14

Foi perguntado aos que disseram conhecer o TDD o que imaginariam ser mais

importante testar. A maioria respondeu que seriam os testes de integração (67%), conferência

de valores por asserts9 (11%) e testes simples na lógica aplicada (22%).

Outra questão foi que opinassem em que seria uma das maiores dificuldades ao aplicar

o TDD. As respostas evidenciaram que seria o tempo de criação dos testes (67%), outro ponto

que demonstrou maior dificuldade pelos respondentes seria definir o que testar e/ou não testar

(33%). Nesta mesma questão estavam disponíveis ainda as opções de “definir até onde testar”

e “entender porque um teste falhou” que não foram assinaladas por nenhum respondente.

Nas perguntas voltadas a comparação entre o TDD e o teste tradicional, as respostas

pareceram favoráveis ao TDD, onde 89% afirmaram que o TDD compensa em virtude da

diminuição da criticidade ou na prevenção de bugs nas fases posteriores, contra 11% que

responderam não. A resposta a este questionamento confirma a tese apontada por Crispin e

Gregory (2009) e também por Nicolas (2006), onde, através do TDD, tem-se a detecção de

falhas de forma mais prematura, o que implica ainda na diminuição da criticidade de defeitos

que se estendem nas demais fases de desenvolvimento.

Em pergunta comparativa ao tempo do TDD e os testes unitários tradicionais, a opção

TDD demonstrou que segundo opinião da maioria dos desenvolvedores gastaria maior tempo

(56%). Esta questão ilustra o apontado por Johansen (2011), onde de fato, a ideia de escrever

testes geralmente remete a objeção de que consome muito tempo, embora teoricamente,

conforme aponta Watkins (2009), não há uma queda significativa na produtividade do

desenvolvedor.

Sobre a qualidade do código, 67% dos que conhecem o TDD, afirmaram que existe

uma diferença positiva no código em relação ao desenvolvido e depois testado contra os 33%

que responderam não, defendendo a qualidade do código também por meio dos testes

tradicionais. Esta questão teve como objetivo resgatar o valor da refatoração que faz parte do

TDD, ao qual segundo Fowler (2004) é a fase onde se atribui maior qualidade ao código

criado.

A pergunta final buscou saber na visão dos desenvolvedores, se acaso tivessem a

proposta de um novo projeto com foco em qualidade, o que lhes viria primeiro a cabeça,

pensar no desenvolvimento e depois testar, ou pensar nos testes e depois desenvolver? As

respostas apresentadas mostraram que 54% ainda preferem pensar no desenvolvimento e

9 Para checar que os testes funcionam corretamente, escreve-se expressões de código do tipo booleanas. O estado dos

booleanos pode ser checado pelo computador chamando variáveis de um método "assert()". Ex.: “assertTrue(rectangle.area() == 50)”. (Beck, 2002, tradução nossa).

15

42%

44%

46%

48%

50%

52%

54%

56%

TDD Tradicionais

depois testar do que os 46% que afirmaram que pensariam primeiro nos testes e depois

desenvolveriam (vide gráfico 2).

Gráfico 2 - Pensar nos testes e depois desenvolver ou desenvolver e depois testar?

Fonte: Autoria própria

4 Considerações finais

Com base nos estudos, foi possível observar que a qualidade de software tem se

aprimorado significativamente desde a década de 80. É perceptível que no atual cenário de

desenvolvimento tem havido uma maior conscientização da importância do gerenciamento de

qualidade de software e da adoção de técnicas de garantia de qualidade; estas foram algumas

das melhorias alcançadas ao longo da evolução dos modelos de desenvolvimento.

As empresas têm visto a cada dia mais a importância do software para o sucesso de

seus negócios. As técnicas buscam se adequar as necessidades dos softwares que a cada vez

mais tendem a ser complexos e aptos a atenderem uma grande gama de dispositivos do mundo

real. Assim percebe-se que tanto nos testes tradicionais ou no TDD, quanto maior o perfil de

risco do sistema, consequentemente mais completos os testes precisam ser. Lembrando que,

nenhuma destas abordagens, muda a opinião de inúmeros autores que discorrem sobre a

impossibilidade de se conceber um software completamente imune aos erros ou falhas.

De uma forma ou outra, as duas abordagens, TDD e testes tradicionais são

reconhecidos pela comunidade de desenvolvimento por serem formas de se impor o

cumprimento de requisitos, prevenção de erros e falhas. A grande diferença está no momento

16

e precisão com que isso é feito; o que faz todo sentido nos processos de desenvolvimento por

questões óbvias como prazos, orçamento, etc.

Os diversos estudos mostraram que para se aproximar ao máximo da meta de

“qualidade total", não há outro caminho, senão as equipes de desenvolvimento trabalharem

em sintonia com a equipe de qualidade e testes ou garantia de qualidade, também denominada

como equipe de QA. O objetivo é que desde o início do desenvolvimento a começar com

testes de unidade até os testes de sistema e aceitação, seja possível o alcance de um estado em

que casos e cenários possibilitem o fornecimento máximo de feedbacks ao longo do ciclo de

desenvolvimento, para assegurar que o sistema permanece estável continuamente. Por isso, a

utilização de ferramentas de testes unitários, automatizados e integração contínua demonstram

ganhar cada vez mais popularidade nos processos de desenvolvimento de software.

Com este estudo, observou-se que não há uma tendência que prevaleça, mas o TDD

está ganhando espaço. Como sugerem os dados obtidos através do estudo de caso, o TDD é

uma prática nova, ainda não amplamente utilizada ou sequer conhecida, o que não o torna um

padrão nos processos de desenvolvimento; porém, tende a crescer à medida que os processos

ágeis evoluam e se estabeleçam nas empresas de desenvolvimento de software.

Rapidamente novas práticas e técnicas são elaboradas com a finalidade de que se

adequem as necessidades das empresas de forma a contribuir para um desenvolvimento de

qualidade. Durante o desenvolvimento deste, outras técnicas e práticas foram encontradas

como o caso do Behavior driven development (BDD), CrowdTest e alguns conceitos que

surgem como o continuous deploy, assuntos que fomentam o anseio por estudos futuros,

abordando variáveis diferentes, porém, dentro do contexto da qualidade de software.

5 Referências

AMBLER, Scott and associates: Agile Data. Introduction to Test Driven Development (TDD), 2011 . Disponível em: <http://www.agiledata.org/essays/tdd.html#WhatIsTDD> Acessado em: 10/10/2012 BASTOS, Anderson et al. Base de conhecimento em teste de software. Ed. Martins Fontes, 2. ed. São Paulo, 2007. BECK, Kent. Test Driven Development By Example. Three Rivers Institute, Copyrigth© 2002. CASSIDY, Colin. E-university. Agile Testing with Mock Objects: A CAST-Based Approach, 2012.Disponível em: <http://e-university.wisdomjobs.com/agile-testing/chapter-417-284/agile-testing-with-mock-objects-a-cast-based-approach.html> Acessado em: 04/02/2012. CRISPIN, Lisa; GREGORY, Janet. Agile testing – A practical guide for testers and Agile Teams. United States: Addison-Wesley, 2009.

17

FOWLER, Martin. Refatoração: Aperfeiçoando o projeto do código existente. Porto Alegre: Bookman, 2004. Disponível em: <http://books.google.com.br/books?id=zPdb4QJKBtkC&printsec=frontcover&dq=refatora%C3%A7%C3%A3o&source=bl&ots=e2u8vhoqe-&sig=HLNLvtbch2ip0eTaxjG5PLq8-gc&hl=en&sa=X&ei=1jRHUJivGYSE8ASK9ICwCQ&ved=0CCwQ6AEwAA#v=onepage&q=refatora%C3%A7%C3%A3o&f=false> Acessado em: 05/09/2012. GASPARETO, Otávio. Test Driven Development. Universidade Federal de do Rio Grande do Sul – Instituto de informática, 2006. Disponível em: <http://www.inf.ufrgs.br/~cesantin/TDD-Otavio.pdf> Acessado em: 21/10/2012. JOHANSEN, Christian. Test-Driven Java Script Development – Developers Library. Boston: Pearson Education, 2011. Disponível em: <http://books.google.com.br/books?id=W218yMY2MhcC&pg=SA1-PA41&lpg=SA1-PA41&dq=xunit+tests&source=bl&ots=diS0oZhqO0&sig=7Ohnz65eJ3uulxitnsnMjgS_Bx8&hl=en#v=onepage&q=xunit%20tests&f=false> Acessado em: 17/09/2012. LARMAN, Graig. Utilizando UML e padrões - Uma introdução à análise e ao projeto orientado a objetos e ao desenvolvimento iterativo. 3º. ed. Porto Alegre RS: Bookman, 2005. Disponivel em: <http://books.google.com.br/books?id=ZHtcynS03DIC&pg=PA397&lpg=PA397&dq=Ferramentas+(XUnit)&source=bl&ots=JAb3vF08hg&sig=AQQE57CnTiLlK321BQ7JJMXV38k&hl=en#v=onepage&q=Ferramentas%20(XUnit)&f=false> Acessado em: 17/09/2012. MARTIN, Robert C. Código Limpo: Habilidades práticas do Agile Software. Rio de Janeiro: Alta Books, 2011. MOLINARI, Leonardo. Testes de Software – Produzindo sistemas melhores e mais confiáveis. São Paulo: Érica Ltda, 2003. NICOLAS, Patrick. Introduction to Test Driven Development Methodology, 2006. Disponível em: <http://www.pnexpert.com/files/Test_Driven_Development.pdf> Acessado em: 05/10/2012. PRESSMAN, Roger S. Engenharia de Software. 5º. ed. Rio de Janeiro: Mcgraw – Hill, 2002. cap.1, p. 3-52. RIOS, Emerson; MOREIRA, Crayahú. Teste de Software. 2º.ed. Rio de Janeiro: Alta Books, 2003. SHORE, James; WARDEN Shane. The art of agile development. United States of America: O’Really Media, 2008. p. 285 -302 SOMMERVILLE, Ian. Engenharia de Software. 8º ed. São Paulo: Pearson Addison-Wesley, 2007. p. 423 – 453. WATKINS, John. Agile Testing – How to success in an Extreme Testing Enviroment. Cambridge: Cambridge University Press, 2009.