Este artigo discute como o desenvolvimento dirigido a testes, uma prática ágil, pode contribuir para a criação de software de qualidade. O artigo faz uma revisão bibliográfica sobre garantia da qualidade, ciclos de teste tradicionais e desenvolvimento dirigido a testes. Também apresenta um estudo de caso aplicando questionários a desenvolvedores para avaliar suas percepções sobre as abordagens.

1. 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 CONTRIBUTIONS 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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=refator
a%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.