• Like
UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

UM ESTUDO SOBRE ABORDAGENS DE TESTE E SUAS CONTRIBUIÇÕES PARA A QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE

  • 203 views
Published

Uma análise sobre os processos de testes em relação com o TDD para obtenção da qualidade nos processos de desenvolvimento de software.

Uma análise sobre os processos de testes em relação com o TDD para obtenção da qualidade nos processos de desenvolvimento de software.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
203
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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.