SIPTEST System Intelligent Process Testing. Abordagens de teste para metodologias de desenvolvimento específicas.

SIPTEST System Intelligent Process Testing. Abordagens de teste para metodologias de desenvolvimento específicas. SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 8

Índice 1 Introdução... 2 1.1 Objetivo do documento... 2 1.2 Contexto... 2 1.3 Estrutura do documento... 2 2 Processos de desenvolvimento de testes... 3 2.1 Modelo Cascata... 3 2.2 Modelo Espiral... 3 2.3 V-model... 4 2.4 Modelo Ágil... 4 2.4.1 Test-Driven Development... 5 2.4.2 Rapid Application Development... 5 2.4.3 Scrum... 5 3 Referências... 7 Link Consulting,SA Pág. 1 de 8

1 Introdução 1.1 Objetivo do documento Este documento apresenta o resultado da pesquisa efetuada sobre abordagens de teste para metodologias de desenvolvimento específicas, no âmbito do projeto SIPTEST. Descrevem-se diferentes metodologias de desenvolvimento de software e processos de desenvolvimento de testes e relacionam-se com os processos de desenvolvimento de testes. 1.2 Contexto No desenvolvimento de software existem processos como os modelos Cascata, Espiral, em V e Ágil que tentam delinear as metodologias mais eficientes para o desenvolvimento de cada produto. Cada modelo assenta num conjunto de princípios diferentes para desenvolvimento de aplicações. Desta forma, um modelo de desenvolvimento é escolhido consoante as caraterísticas de um produto e dos seus desenvolvedores [1]. DESENVOLVIMENTO DE TESTES O teste de software é um processo utilizado para identificar a exatidão, completude e qualidade do produto de Software desenvolvido. Normalmente, o teste de software é enquadrado num propósito de maneira a que as metodologias escolhidas para a criação, desenvolvimento e execução de testes sejam as mais efetivas e eficientes para o projeto em mão [1]. As atividades mais gerais envolvidas no desenvolvimento de teste são inspeções e revisão de código, desenho e execução de cenários de teste, teste unitário, modular e de integração, e debugging [1, 2]. Existem diferentes tipos de testes de software que podem ser aplicados nas diversas fases do desenvolvimento para aumentar a confiança na qualidade de uma aplicação de Software, por exemplo, testes de compatibilidade, testes de conformidade, testes funcionais, testes de regressão, testes unitários, testes de desempenho, testes de carga/stress [3, 4]. 1.3 Estrutura do documento Secção 2 deste documento apresenta uma descrição de alto nível de modelos de desenvolvimento de software. De seguida descreve, justificando, o processo ideal de testes para cada modelo descrito. Finalmente, a última secção apresenta um conjunto de referências recolhidas para elaboração deste relatório, entre outras consideradas como leitura relevante no tópico em mão. Link Consulting,SA Pág. 2 de 8

2 Processos de desenvolvimento de testes Diferentes modelos de desenvolvimento de software, como os apresentados, exploram diferentes capacidades dos seus desenvolvedores e das caraterísticas do projeto em si. É portanto natural que estes necessitem de diferentes processos de desenvolvimento de testes que sejam o menos intrusivos possível ao desenvolvimento e que consigam maior eficiência, maximizando a eficácia de deteção de erros. Consequentemente são apresentados, de seguida, os processos de teste mais usados em cada um dos modelos de desenvolvimento referidos neste documento [1, 2, 5]. 2.1 Modelo Cascata Este modelo é conhecido por adotar uma abordagem top-down, quer para desenvolvimento de software, quer para testes de Software. Nesta metodologia, são especificados um número de passos a seguir e estes são percorridos iterativamente [6]. Tipicamente, no caso do desenvolvimento de testes, estes passos são [7]: Análise de Requisitos; Especificação de Casos de Teste; Implementação dos Casos de Teste; Teste, Debug e Validação do produto; Publicação e Manutenção do produto. Neste tipo de modelo, não é dada a possibilidade de um testador saltar passos ou refazer passos anteriores isoladamente. Também não é contemplada a possibilidade da execução de várias destas tarefas em paralelo. Desta maneira, este modelo garante que cada tarefa é executada tendo como premissa a tarefa anterior, o que pode permitir desenvolver testes mais rapidamente. Por outro lado, se alguma das tarefas for mal executada, este modelo requer que o testador refaça todas as tarefas dependentes. De acordo com esta metodologia, o processo de testes é normalmente executado no final do ciclo de vida do desenvolvimento, i.e., depois do design e implementação de todos os requisitos da aplicação. Como consequência, os erros são mais complicados de detetar e custam, em média, mais recursos a reparar. Desta maneira, é possível afirmar que este modelo é indicado para uma equipa de testes com conhecimentos avançados, menos inclinada a cometer erros [6]. 2.2 Modelo Espiral O modelo Espiral tem no nome a sua principal característica. Este modelo é baseado em múltiplas iterações ( espiral ) sobre todos os passos descritos no modelo Cascata de maneira a que estes sejam todos executados, por ordem, múltiplas vezes. Este modelo é ideal para aplicações cujas funcionalidades não estão todas disponíveis no início do desenvolvimento [8]. Desta maneira, cada espiral tem como objetivo desenvolver e testar apenas parte das funcionalidades da aplicação (as disponíveis, ou as selecionadas). Isto é verificado também para o desenvolvimento de testes neste modelo. Cada espiral deste modelo contempla portanto os passos descritos acima para o desenvolvimento de testes do modelo Cascata. No entanto, através da segmentação no desenvolvimento de funcionalidades, o modelo Espiral garante que algumas das desvantagens do Link Consulting,SA Pág. 3 de 8

desenvolvimento de testes do modelo cascata (no qual se baseia) são eliminadas. No modelo em espiral, por exemplo, os erros são encontrados com mais facilidade e corrigidos em média com menor gasto de recursos [9]. 2.3 V-model Este modelo, por comparação ao modelo Espiral, aplica também uma segmentação no que diz respeito ao desenvolvimento dos testes, sendo essa essencialmente a sua característica: dividir estruturalmente o desenvolvimento dos testes (daí o seu nome e a sua representação característica, mostrada na Fig. 1). O processo pelo qual este modelo se rege pode ser descrito como desenvolvimento top-down e testes botom-up. O benefício em usar este modelo está na interligação e paralelismo das atividades de desenvolvimento e testes [10]. Figura 1 Imagem representativa do Modelo em V A metodologia específica para desenvolvimento dos testes no modelo em V assenta, portanto, numa subdivisão lógica na qual se partem de testes mais pequenos e independentes, para testes mais abrangentes em que todos os módulos são envolvidos. Concretamente, os testes deverão ser corridos de maneira a testar primeiro os componentes e o seu funcionamento (testes unitários), seguidos dos testes de integração entre os componentes, testes ao sistema como um todo e finalizando com testes de aceitação de maneira a validar os requisitos do produto [10, 11]. 2.4 Modelo Ágil A metodologia de testes Ágil consiste num equilíbrio entre uma abordagem iterativa e uma sequencial. Em termos de desenvolvimento, este modelo incita o desenvolvimento rápido e incremental de funcionalidades. Em termos de testes, esta característica tem como repercussão a obtenção de iterações rápidas, práticas e que podem ser usados para testes finais com o utilizador (tendo em conta que parte das funcionalidades da aplicação poderão ser mock objects ou estar mesmo em falta) [12, 13]. Neste modelo estão incorporadas várias técnicas para desenvolvimento de testes (tais como [14]: Test-driven development; Rapid aplication development; Scrum) que assentam no mesmo princípio de desenvolvimento ágil, enunciado acima [15]. Link Consulting,SA Pág. 4 de 8

2.4.1 Test-Driven Development Test-Driven Development (TDD) é um processo de desenvolvimento de software baseado na repetição de um ciclo de desenvolvimento muito curto no qual o desenvolvedor escreve um caso de teste automatizado relativo a uma nova funcionalidade e só depois a implementa de maneira a passar o teste anteriormente criado [16, 18]. Este método de desenvolvimento está relacionado com os conceitos de desenvolvimento de teste do método Extreme Programming (XP) [17]. O método de desenvolvimento de testes desta metodologia é simples e baseia-se em desenvolvimento de testes unitários e, como dito anteriormente, no desenvolvimento de testes a priori da implementação de uma funcionalidade. Concretamente, os passos a seguir para cada nova funcionalidade são os seguintes [16, 18]: Conceber o teste unitário; Correr os testes e confirmar que este falha (isto porque pode acontecer a nova funcionalidade já ser suportada pela implementação atual); Escrever o código mínimo para o teste passar; Fazer refactor do código de maneira a otimizá-lo e confirmar que os testes ainda passam. 2.4.2 Rapid Application Development Este modelo adota uma abordagem de desenvolvimento rápido baseado no desenvolvimento de componentes iterativamente. A diferença deste modelo é a prioridade das diferentes tarefas de desenvolvimento, nomeadamente o da interface. Em cada iteração, é apresentada uma versão diferente (melhorada) da interface da aplicação e o cliente pode dar o seu feedback quanto ao progresso da mesma [19, 20]. O processo de desenvolvimento parte portanto da interface do cliente para o desenvolvimento de funcionalidades, ao contrário dos outros modelos. No modelo RAD os testes são desenvolvidos logo após o cliente fornecer o feedback sobre a interface de utilização. Pode-se afirmar que os cenários de testes são criados a partir (e logo após) do feedback do cliente, no entanto, a fase em que são implementados pode variar consoante existam recursos para os desenvolver em paralelo com a implementação das funcionalidades [20]. Por exemplo, pode ser seguida uma metodologia de TDD em que os testes tomam prioridade sobre o desenvolvimento; podem, como o modelo cascata, ser desenvolvidos depois da implementação das funcionalidades; ou podem ser desenvolvidos em paralelo. Em qualquer dos casos, a nova iteração da interface é feita após a conclusão de ambas as fases de desenvolvimento e de testes. 2.4.3 Scrum O método Scrum é considerado um método ágil de desenvolvimento de software. Este método é maioritariamente usado em gestão de projetos onde é divcil planear com antecedência [21]. Neste método são usados mecanismos de controlo através de processos empíricos, i.e., são usados mecanismos de feedback constante por parte dos desenvolvedores (feedback loops) em vez da gestão de projetos baseada numa hierarquia de decisões estrita (command-and-control), considerada ultrapassada [21, 22]. Nesta metodologia, o desenvolvimento de testes é visto de uma maneira completamente diferente. Este, tal como outros métodos de desenvolvimento de testes, assenta em iterações (normalmente mensais) chamadas sprints. Os sprints são geridos por um coordenador e atribuídos a Link Consulting,SA Pág. 5 de 8

cada membro da equipa que darão feedback sobre o desenvolvimento do seu trabalho numa reunião diária de 15 minutos [21]. O fluxo do desenvolvimento de testes desta metodologia pode ser visto na Fig. Figura 2 Workflow do processo de testes da metodologia Scrum [22] Link Consulting,SA Pág. 6 de 8

3 Referências [1] James A. WhiZaker, Jason Arbon, Jeff Carollo: How Google Tests Software, Addison Wesley publishing, 2012. [2] Edward Kit: Software Testing In The Real World: Improving The Process, ACM Press Books, 1995. [3] Myers, G., Sandler, C.: The art of Software testing, 2004. [4] Weyuker, E.: Testing component-based Software: A cautionary tale. Software, IEEE. 54-59, 1998. [5] Ilene Burnstein: Practical Software Testing: A Process-Oriented Approach, Springer, 2003. [6] Software Testing Mentor: Waterfall Model, Outubro 2012. [7] Wikipedia: Waterfall model, Outubro 2012. [8] Wikipedia: Spiral model, Outubro 2012. [9] Software Testing Mentor: Spiral model, Outubro 2012. [10] Wikipedia: V-Model (Software development), Outubro 2012. [11] Software Testing Mentor: Vmodel, Outubro 2012. [12] Lisa Crispin, Janet Gregory: Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley, 2008. [13] David Talby, Arie Keren, Orit Hazzan, Yael Dubinsky: Agile Software Testing in a Large-Scale Project, Sch. of Comput. Sci. & Eng., Hebrew Univ., Jerusalem, Volume 23, Issue 4, pp. 30-37, 2006. [14] Wikipedia: Agile Software development, Outubro 2012. [15] Software Testing Mentor: Agile Methodology, Outubro 2012. [16] Wikipedia: Test-driven development, Outubro 2012. [17] Wikipedia: Extreme programming, Outubro 2012. [18] Kent Beck: Test-Driven Development: By Example, Addison-Wesley Longman, 2002. [19] Jamie Munro: Rapid Application Development With CakePHP, Createspace Independent, 2011. [20] Beynon-Davies P., Carne C., Mackay H., Tudhope D.: Rapid application development (RAD): an empirical review, European Journal of Information Systems, Volume 8 Number 3, pp. 211-223, 1999. [21] Wikipedia: Scrum (development), Outubro 2012. [22] Scrum testing methodology, SlideShare, Outubro 2012, hzp://www.slideshare.net/gaya1985/scrum-testingmethodology [23] Crispin, Lisa, and Janet Gregory. Agile testing: A practical guide for testers and agile teams. Addison-Wesley Professional, 2008. [24] Marick, Brian. "Agile methods and agile testing." Software Testing and Quality Engineering Magazine 3.5, 2001. [25] Peachord, Bret. "Agile Testing Challenges." Proc. Pacific Northwest Software Quality Conf. 2004. [26] Robert Culbertson, Chris Brown, Gary Cobb: Rapid Testing, Prentice Hall PTR Upper Saddle River, 2001. [27] Cusumano, Michael A. and Smith, Stanley A.: Beyond the waterfall : Software development at MicrosoI, Sloan School of Management, MassachuseZs Institute of Technology, 1995 [28] Liu Shuping and Pang Ling:The Research of V Model in Testing Embedded Software, Conference on Computer Science and Information Technology, 2008. [29] Bart Broekman and Edwin Notenboom: Testing Embedded Software, 2003. [30] Davis, G.: Managing the test process [Software testing], Conference on Software Methods and Tools, pp. 119-126, 2000. [31] Rex Black: How Agile Methodologies Challenge Testing, The Magazine for Professional Testers, 2009. [32] Sumrell, M.: From Waterfall to Agile - How does a QA Team Transition?, Agile Conference (AGILE), pp. 291-295, 2007. Link Consulting,SA Pág. 7 de 8