A Relação Entre Desenvolvimento Orientado a Testes e Qualidade de Software

Transcrição

1 A Relação Entre Desenvolvimento Orientado a Testes e Qualidade de Software Cássio L. Ribeiro 1 1 Instituto de Informática Pontifícia Universidade Católica de Goiás (PUC Goiás) Goiânia GO Brasil cassio.landim@gmail.com Abstract. This paper shows how the consequences of the use of test-driven development affect the quality of software. It lists some situations that negatively affect the quality of software, such as the lack of unit testing and presence of disorganized code. It demonstrates how the use of test-driven development mitigates or eliminates the occurrence of these situations. Finally, it highlights other important quality factors that the test-driven development does not resolve properly. Resumo. O presente artigo evidencia de que maneira as consequências do emprego do desenvolvimento orientado a testes afetam a qualidade de um software. São listadas algumas situações que afetam negativamente a qualidade de um software, como a ausência de testes unitários e a presença de código desorganizado. Demonstramos como o emprego do desenvolvimento orientado a testes ameniza ou elimina a ocorrência dessas situações. Ao final, evidencia outros fatores importantes para a qualidade, que o desenvolvimento orientado a testes deixa a desejar. 1. Introdução A natureza ubíqua da computação moderna, software e infraestrutura de informação e, ainda, a demanda crescente por automação e conveniência pela sociedade moderna tem gerado constante aumento de tamanho e complexidade dos sistemas de software modernos. Este incremento em tamanho e complexidade acaba por causar consequências nãointencionais em termos de gerar problemas de qualidade [Tian 2005]. A alta complexidade e o amplo escopo dificultam a prevenção ou eliminação de problemas de software e seus impactos negativos relacionados; consequentemente, várias atividades de garantia da qualidade são realizadas para prevenir e/ou eliminar certas classes de problemas, ou ainda, para reduzir a probabilidade ou severidade de tais impactos quando não se pode evitá-los [Tian 2005]. As metodologias ágeis emergiram da necessidade de se minimizar os riscos do desenvolvimento de softwares. Essas metodologias evoluíram como parte de uma reação contrária aos processos de desenvolvimento utilizados na época, caracterizados como pesados, burocráticos, micro-gerenciados e com uma alta tendência a se produzir documentos formais [Langr 2005]. Como o desenvolvimento orientado a testes (Test-Driven Development - TDD) é uma prática fundamental da Programação Extrema (extreme Programming - XP), que está

2 começando a ganhar uma ampla aceitação entre as entidades desenvolvedoras de software, este estudo visa evidenciar de que maneira o emprego do TDD afeta a qualidade de um software. 2. Conceitos de Qualidade de Software e TDD 2.1. Qualidade de Software [Tian 2005] coloca a qualidade sob a perspectiva das expectativas dos usuários de software. Em geral, o que as pessoas esperam como qualidade em um sistema de software é que eles façam o que foram programados para fazer. Em outras palavras, eles devem fazer a coisa certa, ou seja, eles devem executar suas tarefas específicas corretamente ou satisfatoriamente. Comportamentos inesperados se manifestando na forma de defeitos, podem afetar profundamente a qualidade de um software, porém, este não é o único fator que determina a qualidade. Segundo [Friedman 2009], as metodologias ágeis tratam o processo de incremento da qualidade como um exercício de eliminação do desperdício onde o conceito de desperdício assume o mesmo significado no contexto da manufatura lean 1 [James P. Womack 1990], onde um produto de alta qualidade é aquele que previne o desperdício do esforço investido pelo usuário no processo de produzir algo de valor. [Friedman 2009] identifica três fatores principais de desperdício que reduzem a qualidade de um software. O primeiro e mais comum são os defeitos. Estes podem ser categorizados como ocorrências onde o sistema se comporta de forma inesperada. Enquanto o desenvolvedor espera que o sistema se comporte de certa maneira, o comportamento exibido é diferente devido a defeitos inseridos na fase de codificação. O problema é que quando um defeito afeta o usuário, em casos menos graves, pode forçar o usuário a repetir alguma ação, enquanto que em casos extremos pode causar uma perda substancial de dados que irá requerer um esforço significativo para serem reproduzidos (quando possível). O segundo fator está ligado a problemas de usabilidade, onde um produto de difícil uso causa um desperdício de esforço. Em casos extremos, os usuários fazem uso de caminhos alternativos para atingirem seus objetivos; entretanto, em vários casos, os usuários empregam a forma incorreta de execução ao invés de perceber que a qualidade atual do sistema é insuficiente para atender seus propósitos. O terceiro fator, funcionalidades do sistema que não são utilizadas, também representam um fator de desperdício. Além de inúteis, retardam e dificultam o uso do sistema. Esta é a forma de desperdício que mais despende esforços para ser localizada e eliminada Verificação versus Validação Verificação é provar que o produto atende corretamente os requisitos especificados em atividades prévias durante o ciclo de vida de desenvolvimento, já a validação checa que o 1 O termo lean foi cunhado ao final da década de 80 em um projeto de pesquisa do Massachusetts Institute of Technology (MIT) sobre a indústria automobilística mundial. A pesquisa revelou que a Toyota havia desenvolvido um novo e superior paradigma de gestão nas principais dimensões dos negócios (manufatura, desenvolvimento de produtos e relacionamento com os clientes e fornecedores).

3 sistema atende os requisitos do cliente ao final do ciclo de vida. Tradicionalmente, teste de software tem sido considerado um processo de validação, isto é, uma fase do ciclo de vida [Lewis 2004] Qualidade Externa e Interna Qualidade externa é a qualidade medida pelo cliente, e qualidade interna é a qualidade medida pelas pessoas que possuem acesso ao código, como é o caso dos programadores e arquitetos. As metodologias ágeis pregam que a qualidade interna de um software não é negociável, ela deve ser fixada como ótima durante todo o ciclo de vida do software. Algumas equipes, na esperança de reduzir o prazo de entrega, sacrificam temporariamente a qualidade interna na esperança de que a qualidade externa não sofrerá um grande impacto. Esta estratégia é muito tentadora em um cenário em curto prazo. Porém, eventualmente problemas de qualidade interna o alcançarão e tornarão aquele software proibitivamente caro de manter ou mesmo incapaz de alcançar um nível competitível de qualidade externa [Beck 1999]. Este fenômeno é conhecido como débito tecnológico. Segundo [Friedman 2009], tentar trocar a qualidade por velocidade é uma das estratégias mais errôneas existentes Testes Unitários De acordo com [Lewis 2004], teste unitário é a escala mais micro de testes para testar funções particulares ou módulos de códigos. Tipicamente são feitos pelo programador e não por testadores, já que requerem um conhecimento detalhado do código e do design interno do software. Nem sempre são fáceis de se implementar a não ser que a aplicação tenha uma arquitetura muito bem desenhada com código organizado. [Bellware 2009] acredita que quando testes são escritos após o código de produção já estar pronto, na realidade o que se está fazendo é um tipo de engenharia reversa, que é uma forma de engenharia de que exige uma grande quantidade de esforço. Exige muito esforço porque ao se escrever os testes neste momento, o programador precisará ler todo o código, entender o que ele faz e adivinhar como escrever um teste para este código. Os testes produzidos desta maneira acabarão, provavelmente, não servindo para cobrir o mínimo necessário dos caminhos alternativos de execução do código Desenvolvimento Orientado a Testes As metodologias ágeis já se tornaram populares na área de desenvolvimento de software. A cada dia, mais empresas as adotam para amenizar problemas de qualidade e de entrega de produtos que agreguem o valor real aos seus clientes. Algumas metodologias ágeis como Scrum tem foco em práticas gerenciais e organizacionais, enquanto XP tem foco maior em práticas de programação. O TDD é uma das práticas que fazem parte do núcleo do XP [Beck 1999] que entra em cena durante as fases de desenho e codificação de um software. XP é uma metodologia ágil e leve para equipes de desenvolvimento de software de tamanho pequeno à médio que lidam com requisitos vagos ou que mudam rapidamente

4 [Beck 1999]. XP procura melhorar um projeto de software através da comunicação, simplicidade, feedback, respeito e coragem. Dá ênfase no trabalho em equipe, permitindo que os desenvolvedores respondam com confiança às mudanças de requisitos dos clientes, até mesmo tardiamente no ciclo de vida do projeto. Scrum é um processo ágil para o desenvolvimento de projetos, sendo mais adequado para projetos onde os requisitos estão mudando ou emergindo rapidamente. É mais focado nas pessoas e na forma como elas deverão interagir entre si para atingir um objetivo comum. [Schwaber 2004] afirma que o Scrum baseia todas as suas práticas em uma estrutura de processo incremental e iterativo. Esta estrutura é formada por iterações de atividades de desenvolvimento que ocorrem uma após a outra, sendo que a saída de cada iteração é um incremento do produto. Dentro desta iteração ocorrem várias iterações mais curtas (inspeções diárias), onde os indivíduos membros do time se encontram para inspecionar as atividades dos outros membros e fazerem as adaptações necessárias. Uma lista de requisitos guia a iteração. Este ciclo se repete até que o projeto termine. Ao início de cada iteração, o time analisa o que deve ser feito. Ele então escolhe o que acredita que possa se tornar um incremento de funcionalidade potencialmente entregável ao final da iteração. O time é deixado a sós para fazer seu melhor esforço pelo resto da iteração. Ao final da iteração, o time apresenta o incremento de funcionalidade que construiu para que os patrocinadores do projeto possam inspecioná-lo e fazer ajustes para as próximas iterações do projeto. O processo criativo durante as iterações é o coração da produtividade do Scrum. Já o TDD é uma prática que visa aumentar a velocidade da entrega de produtos através da simplificação das atividades de desenho de software. [Koskela 2008] resume a filosofia do TDD em uma frase somente escreva código para fazer um teste falho passar. [Astels 2003] define o TDD como sendo um estilo de desenvolvimento onde: Uma suíte exaustiva de testes de programadores é mantida; Nenhum código entra em produção a não ser que tenha testes associados; Os testes são escritos antes; Os testes determinam que código precise ser escrito Ciclo Teste-Codificação-Refatoração TDD é uma técnica de desenho e desenvolvimento que nos ajuda a construir um sistema de forma incremental, com a consciência de que nunca nos afastamos de uma baseline funcional e entregável. O ciclo Teste-Codificação-Refatoração é quem dita o ritmo do desenvolvimento através de pequenos e controlados passos. A sequência clássica que nos foi ensinada, onde primeiramente produzimos o desenho, implementamos o desenho, e só então testamos o software em busca dos defeitos, é totalmente invertida quando comparada ao ciclo Teste-Codificação-Refatoração. Primeiramente escrevemos o teste, depois escrevemos o código para fazer este teste passar e então passamos para a fase de desenho. Esta fase de desenho é diferente da fase de desenho tradicional. No TDD ela é chamada de refatoração, onde o desenho atual do código é transformado em um desenho melhor.

5 O ciclo Teste-Codificação-Refatoração também pode ser chamado de ciclo Vermelho-Verde-Refatoração [Astels 2003]. O vermelho simboliza a fase inicial do ciclo TDD onde o teste escrito falha. Ele falha porque o sistema não está funcional; ele não possui as funcionalidades que desejamos que ele tenha. Em alguns ambientes de desenvolvimento, essa falha é evidenciada através da exibição de uma barra vermelha. Na segunda fase implementamos as funcionalidades que faltavam para fazer todos os testes passarem, ou seja, os testes que já existiam e o novo teste recém-introduzido. Neste momento, a barra visual deve se tornar verde. Somente se passa para a próxima etapa quando nenhum teste estiver falho. Na última parte do ciclo é feita a refatoração. Refinamos o desenho do código sem alterarmos seu comportamento externo, mantendo todos os testes passando e a com a barra visual exibindo a cor verde. 3. A Relação entre TDD e Qualidade Qualidade não pode ser alcançada através da avaliação de um produto já feito. O objetivo, portanto, é prevenir defeitos de qualidade ou deficiências em primeiro lugar, tornando os produtos avaliáveis através de medidas de garantia de qualidade [Lewis 2004]. [Beck 1999] cita alguns exemplos de riscos relacionados ao desenvolvimento de software. Dos riscos citados, dois estão diretamente ligados a qualidade de software e podem ser tratados através da utilização de TDD: Taxa de defeitos o software é colocado em produção mas a taxa de defeitos é tão alta que ele acaba não sendo utilizado. TDD eleva a validação de um software a um patamar superior, testando-o função por função; Deterioração do sistema o software é colocado em produção com sucesso, porém após algum tempo o custo de se fazer modificações ou a taxa de defeitos aumenta tanto que o sistema precisa ser substituído. TDD mantém o programador focado na solução, de forma que o software não fica carregado de códigos desnecessários, duplicados ou de difícil manutenção, impedindo a deterioração do sistema. Nesta mesma obra, [Beck 1999] elaborou três frases de impacto, que servem como um ponto de partida para entendermos como o TDD afeta a qualidade de um software: Toda vez que alguém toma uma decisão e não a testa, existe uma grande probabilidade de que esta decisão esteja errada; Funcionalidades de software que não podem ser demonstradas através de testes automatizados simplesmente não existem; Testes nos dão à chance de pensar sobre o que queremos, independente da forma como a solução será implementada. Ao utilizar TDD, devemos escrever testes para cada solução implementada. Dessa forma, diminuímos a probabilidade de tomarmos uma decisão errada. Ao mesmo tempo, temos a oportunidade de experimentar várias implementações diferentes para o mesmo problema e escolher aquela mais limpa, elegante e que apresente o melhor desempenho. Na época em que [Beck 2002] publicou sua obra, afirmou que ainda não haviam estudos que demonstrassem científicamente as diferenças na qualidade, produtividade ou diversão entre a utilização de TDD e quaisquer outras alternativas. Atualmente já existem

6 publicados alguns estudos objetivos sobre o impacto da utilização de TDD com relação à qualidade e produtividade, frente à maneira tradicional de desenvolvimento. Em seu blog, [Hawley 2004] publicou os resultados de uma pesquisa que ele mesmo realizou com a ajuda de seu colega de trabalho. Nesta pesquisa ele constatou que 92% dos desenvolvedores perceberam que TDD os forçaram a produzir código de alta qualidade. Constatou também, através dos códigos produzidos pelos participantes, que houve um incremento na qualidade do código, uma vez que eles tiveram 18% mais de sucesso nos testes de caixa-preta em comparação com os códigos produzidos da maneira tradicional Desenho Simplificado e Evolucionário Escrevendo somente o necessário para os testes e removendo toda a duplicação, você automaticamente obtém um desenho que é perfeitamente adaptado para os requisitos atuais e igualmente preparado para todas as futuras funcionalidades [Beck 2002]. Design simplificado reduz os custos porque ao escrever menos código para atender os requisitos, menos código existirá para ser mantido no futuro. Design simplificado é mais fácil de se construir, manter e entender Refatoração Os testes lhe dão a confiança de que grandes refatorações não mudarão o comportamento do sistema, o que se conclui que, quanto maior a confiança, mais agressivamente você poderá conduzir refatorações em larga escala que estenderão a vida de seu sistema. A refatoração torna a elaboração dos próximos testes muito mais fácil [Beck 2002]. Custos são reduzidos porque a refatoração contínua evita que o desenho se degrade com o passar do tempo, assegurando que o código continue fácil de ser entendido, mantido e modificado Feedback Constante [Beck 2002], no último capítulo de sua publicação, afirma que TDD o ajuda a dar atenção aos problemas certos na hora certa, de forma que o desenho do software fica mais limpo e com muito menos defeitos. O TDD faz com que o programador ganhe confiança sobre seu código com o passar do tempo, isto é, à medida que os testes vão se acumulando (e melhorando), ele ganha confiança no comportamento do sistema. E ainda, à medida que o desenho é refinado, mais e mais mudanças se tornam possíveis. Outra vantagem do TDD que [Beck 2002] acredita poder explicar seus efeitos positivos, é a forma como ele encurta o ciclo de feedback sobre as decisões de desenho. Ele dura apenas segundos ou minutos, e é seguido pela reexecução dos testes dezenas ou centenas de vezes por dia. Ao invés de se projetar um desenho e então esperar semanas ou meses para outra pessoa sentir as dores ou glórias de sua consequência, o feedback emerge em segundos ou minutos, enquanto você tenta traduzir suas idéias em interfaces plausíveis Suíte de Testes (Regressão) Usando TDD, os testes unitários são criados num momento onde a funcionalidade a ser implementada está mais bem definida na mente do programador, e depois podem e devem

7 ser utilizados para fazer testes de regressão. Uma suíte de testes automáticos feita por programadores reduz os custos de um software funcionando como uma rede de segurança de testes que capturam defeitos, problemas de comunicação e ambigüidades antes e permitem que o desenho possa ser modificado de forma incremental. Esta suíte de testes gerada pelo TDD é fundamental para viabilizar procedimentos de Integração Contínua Documentação Para Programadores A suíte de testes serve como uma documentação voltada para o programador que tem um entendimento mais rápido e facilitado do que uma parte do código faz através do código que o testa. Cada teste unitário especifica o uso apropriado de uma classe de produção [Langr 2005]. 4. Conclusões Esta técnica de desenvolvimento produz desenhos menos acoplados que são mais fáceis de manter, reduz altamente a quantidade de defeitos, e reforça a construção e manutenção apenas do que é realmente necessário. Finalmente, testes bem escrito atuam como um tipo de requisitos executáveis que ajudam a manter o entendimento compartilhado da equipe de desenvolvimento, sobre como o sistema de software representa os problemas do mundo real. Por outro lado, o fato de se ter um grande número de testes unitários passando com sucesso, pode passar uma falsa sensação de segurança, resultando na implementação de menos atividades de garantia de qualidade, como testes de integração e testes de conformidade. É importante ressaltar também que, esta técnica não garante a obtenção de níveis aceitáveis em certos aspectos do software final, como usabilidade e desempenho. Além disso, TDD não consegue mitigar riscos relacionados com a falta de requisitos ou com requisitos erroneamente definidos. Referências Astels, D. (2003). Test-Driven Development: A Practical Guide. Prentice Hall PTR. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison Wesley. Beck, K. (2002). Test-Driven Development By Example. Addison Wesley. Bellware, S. (2009). Good Test, Better Code - From Unit Testing to Behavior-Driven Development (10:40). Fowler, M. (2006). Continuous integration. Friedman, L. (2009). Quality - an agile point of view. TE: Testing Experience, Setembro: Segundo [Fowler 2006], integração contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente, podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva um software coeso mais rapidamente.

8 Hawley, M. (2004). TDD Research Findings. James P. Womack, Daniel T. Jones, D. R. (1990). The machine that changed the world. Koskela, L. (2008). Test Driven: Pratical TDD and Acceptance TDD for Java Developers. Manning. Langr, J. (2005). Agile Java Crafting Code with Test-Driven Development. Prentice Hall PTR. Lewis, W. E. (2004). Software Testing and Continuous Quality Improvement. Auerbach, 2 edition. Schwaber, K. (2004). Agile Project Management with Scrum. Microsoft Press. Tian, J. (2005). Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement. John Wiley & Sons.