Slides

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

Description
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…
Categories
Published
of 17
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
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 f
  • Search
    Similar documents
    View more...
    Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks