portalb2b e optimização do processo de testes · proposta de otimização de testes incluindo um...

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Departamento de Engenharia Informática e de Sistemas

Mestrado em Informática e Sistemas Estágio/Projeto Industrial

Relatório Final

PortalB2B e Otimização do Processo de Testes

Hugo Luís Rodrigues Vitória Lopes

Orientador:

João Carlos Costa Faria da Cunha

Instituto Superior de Engenharia de Coimbra

Coimbra, setembro, 2012

Portal B2B e Testes RESUMO

ii

RESUMO Este documento descreve o trabalho realizado pelo autor na empresa Present Technologies,

durante o ano letivo 2011/2012, no contexto da disciplina Estágio/Projeto Industrial do Mestrado em

Informática e Sistemas do Instituto Superior de Engenharia de Coimbra.

O estágio consistiu no desenvolvimento e implementação de uma proposta de procedimento de

testes destinada ao usufruto da Present Technologies, baseada no estudo e análise de práticas

realizadas pela organização, bem como, de recomendações existentes na literatura científica sobre

atividades de testes de software. O foco principal incidiu nos testes sobre interface de aplicações web,

explorando de um ponto de vista prático, as suas principais caraterísticas, potencialidades e limitações.

Para se apurar a adequabilidade das recomendações propostas, o procedimento de testes foi

aplicado a um produto web denominado de Portal B2B. As soluções e técnicas para implementação de

testes automáticos web foram abordadas com recurso às ferramentas WebDriver e Arquillian

Graphene.

O Portal B2B resultou de um projeto adjudicado à Present Technologies, no qual o estagiário foi

parcialmente responsável pelo desenvolvimento da interface web de um sistema de gestão Machine-

To-Machine. O cliente do projeto, dono de uma plataforma Machine-To-Machine, pretende ocupar um

lugar de referência neste segmento de mercado, onde se estima que cerca de 50 mil milhões de

dispositivos já se encontram atualmente a beneficiar deste tipo de comunicação. O principal objetivo é

a exploração de serviços inteligentes, soluções capazes de atuar e reagir perante a informação

remotamente recolhida.

O trabalho desenvolvido permitiu aumentar o conhecimento da Present Technologies na área de

Software Testing, proporcionando os seguintes resultados tecnológicos: a aplicação Portal B2B; a

proposta de otimização de testes incluindo um guia de testes e template para plano de testes;

documentação da aplicação dessa mesma proposta ao produto Portal B2B.

Portal B2B e Testes ABSTRACT

iii

ABSTRACT This document describes the work performed by the author in the company Present

Technologies, throughout the academic year 2011/2012, in the context of the discipline Estágio/Projeto

Industrial for the master's degree in Engenharia Informática e de Sistemas of the Instituto Superior de

Engenharia de Coimbra.

The internship consisted in the development and implementation of a test procedure proposal

conceived for the usufruct of the Present Technologies based on the study and analysis of practices

performed by organization and recommendations existing in the scientific literature about software

testing activities. The main focus was web interface tests, exploring from a practical point of view,

their main features, potentialities and limitations.

To ascertain the suitability of the proposed recommendations, the tests procedure was applied to

a web product named Portal B2B. The solutions and techniques for automated testing of web were

addressed using the tools WebDriver and Arquillian Graphene.

Portal B2B has resulted from a project adjudicated to Present Technologies, in which the intern

was partially responsible for the development of a web interface for a management system Machine-

To-Machine. The project’s client, owner of one Machine-To-Machine platform, has chased a place of

reference in this market segment, where it’s estimated that about 50 thousand millions of devices are

already been benefiting from this type of communication. The main goal is the exploration of

intelligent services, solutions that are able to act and react to information remotely collected.

The work developed has raised knowledge of the Present Technologies in the Software Testing

field, providing the following technological results: Portal B2B application; a proposed optimization

of tests including a test guide and template for test plan; documentation of the application of this same

proposal to the B2B Portal product.

Portal B2B e Testes PALAVRAS-CHAVE

iv

PALAVRAS-CHAVE Testes web, Testes GUI, Aplicações web, Testes funcionais, Processo de testes, Plano de testes, TMMi, Técnicas de desenho de testes web, Model-Driven Test Design, Qualidade de software, Testes Java EE

KEYWORDS Web tests, GUI tests Web applications, Functional tests, Test process, Test Plan, TMMi, Web test design techniques Model-Driven Test Design, Software Quality, Java 2EE testing

Portal B2B e Testes GLOSSÁRIO

v

GLOSSÁRIO Termo Descrição

AJAX Asynchronous JavaScript And XML – Utilização metódica das tecnologias HTTP, JavaScript e XML na comunicação assíncrona com o servidor com o intuito de receber e apresentar informação sem interromper a interface utilizador.

API Application Programming Interface – Conjunto de métodos estabelecidos por um software para utilização das suas funcionalidades.

AUT Application Under Test – Aplicação de software verificada e validada com o processo de teste.

B2B Business To Business – Comércio associado a operações de compra e venda de informações, produtos e serviços com outros parceiros de negócio.

B2C Business To Consumer – Comércio efetuado diretamente entre a empresa produtora, vendedora ou prestadora de serviços e o consumidor final.

Browser Aplicação cliente que permite a receção, interpretação e visualização de recursos disponíveis na web.

Bug Tipicamente é um erro no funcionamento comum de um software.

Build Refere-se ao processo de conversão de código-fonte em artefactos de software que podem ser posteriormente executados num computador.

ContextPath Prefixo de um caminho URL que identifica qual a aplicação web para a qual os pedidos devem ser encaminhados.

CRUD Create/Read/Update/Delete – Refletem as quatro funções base relacionadas com a persistência da informação de uma aplicação.

CDI Context Dependency Injection – Permite, através da utilização de anotações Java, injectar dependências de forma simplificada.

Change Request Tipicamente uma declaração de pedido de ajuste/alteração de uma funcionalidade de um sistema.

Checklist Lista de tarefas utilizada para compensar memória ou atenção do autor.

CSS Cascading Style Sheet - Linguagem que permite definir estilos a documentos escritos em HTML e XHTML.

Deployment Processo composto por todas as atividades necessárias para que o sistema fique disponível para uso.

DOM Document Object Model – Convenção para representação e interação com objetos em documentos HTML e XHTML independente de plataformas/linguagens.

EAR Enterprise Archive - Formato de ficheiro utilizado pelo Java EE que agrupa um ou mais módulos num arquivo apenas para que o deployment desses módulos ocorra simultaneamente de maneira consistente no servidor aplicacional.

eHealth Serviços de saúde assegurados por processos e comunicação eletrónica.

End-to-end testing Consiste no processo de teste que inclui funcionalidades de todas as camadas constituintes da arquitetura da solução.

Fleet management Solução para gestão de frota de transporte de uma companhia.

Framework Consiste numa plataforma de software (conjunto de bibliotecas, classes) reutilizável para desenvolvimento de aplicações, produtos e soluções. Pode ser vista como uma abstração de funcionalidades genéricas que podem ser personalizadas pelos programadores.

Front-end Termo generalizado para especificar a camada do sistema de software que interage diretamente com o utilizador.

GUI Graphical User Interface – representa a exteriorização visual da aplicação com a qual o utilizador tem a possibilidade de interagir.

HTML HyperText Markup Language – Linguagem de markup predominante na criação de páginas web, interpretada por um browser para disponibilização de conteúdo para o utilizador final.

HTTP HyperText Transfer Protocol – Protocolo de comunicação de nível aplicacional.

Hub Arquitetura que permite a transmissão e difusão de determinada informação em simultâneo para vários recetores.

IDE Integrated Development Environment – programa que reúne caraterísticas e ferramentas de apoio ao desenvolvimento de software com o objetive de agilizar o processo.

IEEE Institute of Electrical and Electronics Engineers – Organismo profissional dedicado à evolução


vi

e inovação tecnológica e excelência. Internet Sistema global de redes de computadores interligadas. Issue Tracker Sistema onde são mantidos e geridos vários problemas de um determinado projeto de software.

JAR Java Archive - Formato de ficheiro utilizado que agrega vários ficheiros Java .class associando meta-dados e recursos (texto, imagens e etc) num arquivo apenas para distribuição de software aplicacional numa plataforma Java.

Java Linguagem de programação orientada a objetos, derivada das linguagens de programação C e C++.

JavaScript Linguagem de script geralmente utilizada no lado do cliente das aplicações web e que permite o acesso e manipulação de dados de forma dinâmica melhorando a interface utilizador.

Java Virtual Machine ou JVM Corresponde ao componente da plataforma de software Java responsável pela execução do código (normalmente Java bytecode).

jQuery Bibliotecas da linguagem JavaScript que simplifica a interação com HMTL, tratamento de eventos, animações interações AJAX.

JSON JavaScript Object Notation - Formato de dados leve de fácil interpretação. JSP Tecnologia que providencia uma maneira simples e rápida de criar conteúdo dinâmico web.

M2M Machine To Machine – Conceito de negócio, originado pelo desenvolvimento de telemetria, utilizado para medir e transmitir automaticamente dados provindos de fontes remotas através de uma rede.

Mock Objeto utilizado durante o desenvolvimento e realização de testes que simula o comportamento de um objeto real.

MVC Model-View-Controller – Arquitetura padrão utilizada em Engenharia de Software que permite isolar a lógica computacional da interface utilizador, permitindo desenvolver e testar cada componente separadamente.

Open-Source Filosofia de desenvolvimento e distribuição de software que inclui a disponibilização do código fonte de todas as aplicações.

Quality Assurance Conjunto de atividades planeadas e sistemáticas implementadas num sistema de qualidade para que os produtos ou serviços efetuados satisfaçam os requisitos de qualidade.

RFP Request For Proposal – Processo de aquisição, onde os fornecedores são convidados a apresentar uma proposta para um serviço específico.

Sandbox JS Componente constituinte dos browsers responsável pela interpretação do código JavaScript.

Script Ficheiro executável desenvolvido numa linguagem de programação que executa uma rotina pré-definida.

Servlet Classe de programação Java utilizada para estender as capacidades dos servidores web. Utilizam o modelo de programação pedido-resposta.

Smart Metering Solução constituída pela medida de consumo por parte de um dispositivo em intervalos de tempo regulares e posteriores envios dessa informação para uma unidade centralizada para monitoria e faturação.

Smart Service Serviço inteligente capaz de agir perante informação recolhida de maneira autónoma. SQL Injection Técnica utilizada para atacar base de dados através de um site web.

Stub Semelhante ao Mock mas conserva um estado interno derivado das chamadas durante a execução dos testes.

SVN Sistema de controlo de versão desenhado especificamente para ser um substituto do CVS. Tag library Define um conjunto de tags personalizadas para utilização nas JSPs.

TestRunner Componente de framework de testes tipicamente responsável pela gestão do ciclo de vida dos testes, incluindo a sua execução.

TMMi Test Maturity Model integrated – modelo de otimização do processo de testes baseado no modelo Capability Maturity Model Integration (CMMI).

URL Uniform Resource Locator – Especifica um texto que referencia um recurso da internet.

User Stories Cenários de utilização descritos numa linguagem simplificada para que o utilizador final ou utilizador do sistema compreenda o que necessita de fazer durante a interação com o sistema.

Voucher Trata-se de um título, recibo ou documento que comprova o pagamento e o direito a um serviço ou a um produto.

VPN Virtual Private Network - Rede de comunicações privada normalmente utilizada por uma empresa ou um conjunto de empresas e/ou instituições, construída em cima de uma rede de comunicações pública (como por exemplo, a Internet).


vii

WAR Web Application Archive – Utilizado para agrupar JSPs, Java Servlet, Java .class, ficheiros XML e outros recursos que constituem uma aplicação web.

Web Abreviatura para Worl Wide Web. Sistema de documentos de diversos tipos de conteúdos interligados e acessíveis através da internet.

Wiki Termo identificativo de um conjunto de documentos em hipertexto ou o software colaborativo usado para a sua criação.

XSS Cross Site Scripting – Tipo de vulnerabilidade de segurança tipicamente associada a aplicações web, onde hackers injetam script do lado do cliente.

Portal B2B e Testes ÍNDICE

viii

ÍNDICE Resumo .................................................................................................................................................................... ii Abstract .................................................................................................................................................................. iii Palavras-Chave ....................................................................................................................................................... iv Keywords ............................................................................................................................................................... iv Glossário .................................................................................................................................................................. v Índice .................................................................................................................................................................... viii Índice de Figuras ..................................................................................................................................................... x Índice de Tabelas .................................................................................................................................................... xi 1. INTRODUÇÃO .................................................................................................................................................. 1

1.1. Apresentação do projeto/estágio ............................................................................................................ 1 1.2. Apresentação da Organização ................................................................................................................ 2 1.3. Introdução ao M2M ............................................................................................................................... 2 1.4. Motivação .............................................................................................................................................. 4 1.5. Objetivos atingidos ................................................................................................................................ 5 1.6. Estrutura do documento ......................................................................................................................... 6

2. ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES ............................................................. 8 2.1. Procedimentos de testes em vigor .......................................................................................................... 8 2.2. Resultado de projetos antecedentes ...................................................................................................... 12

2.2.1. Projeto A ..................................................................................................................................... 12 2.2.2. Projeto B ..................................................................................................................................... 13

2.3. Análise Informal .................................................................................................................................. 15 2.3.1. Ausência de uma política comum de testes ................................................................................. 15 2.3.2. Smoke tests .................................................................................................................................. 15 2.3.3. Testes no cliente .......................................................................................................................... 16 2.3.4. Formação e suporte documental ................................................................................................. 16 2.3.5. Testes automatizados ................................................................................................................... 16 2.3.6. Testes estáticos e registo de defeitos ........................................................................................... 17 2.3.7. Ensaio com Test-Driven Development ........................................................................................ 17

3. METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE ................................................................................. 18 3.1. Processos de testes ............................................................................................................................... 18

3.1.1. Contextualização de processos de testes ..................................................................................... 18 3.1.2. Otimização do processo de teste ................................................................................................. 22 3.1.3. Modelo em V ............................................................................................................................... 25 3.1.4. Metodologias de teste .................................................................................................................. 27 3.1.5. Plano de testes............................................................................................................................. 30 3.1.6. Sumário de processos de testes ................................................................................................... 33

3.2. Testes de interface web ........................................................................................................................ 34 3.2.1. Aplicações web ............................................................................................................................ 34 3.2.2. Desafios de testes web ................................................................................................................. 35 3.2.3. Contexto de testes web ................................................................................................................ 36 3.2.4. Técnicas de testes WUI ............................................................................................................... 38 3.2.5. Critérios de testes WUI ............................................................................................................... 39 3.2.6. Sumário de testes de interface web ............................................................................................. 41

3.3. Ferramentas de automatização de testes............................................................................................... 42 3.3.1. Ferramentas de testes funcionais ................................................................................................ 42


ix

3.3.2. Ferramentas de testes web .......................................................................................................... 44 3.3.3. Ferramentas de testes in-container ............................................................................................. 50 3.3.4. Ferramentas de testes JavaScript ................................................................................................ 56

4. CONCEÇÃO DE UM GUIA E PLANO DE TESTES PARA A PRESENT TECHNOLOGIES ............................................. 61 4.1. Software Testing Guide ........................................................................................................................ 61 4.2. Test Plan Template ............................................................................................................................... 64 4.3. Modelo de otimização TMMi .............................................................................................................. 66

5. CASO DE ESTUDO: PROJETO PORTAL B2B ....................................................................................................... 68 5.1. Principais Conceitos ............................................................................................................................. 68 5.2. Descrição do projeto ............................................................................................................................ 69 5.3. Arquitetura ........................................................................................................................................... 70 5.4. Tecnologias .......................................................................................................................................... 71

5.4.1. Java EE ....................................................................................................................................... 71 5.4.2. JBoss ........................................................................................................................................... 72 5.4.3. Stripes Web Framework .............................................................................................................. 72 5.4.4. Sitemesh ...................................................................................................................................... 72 5.4.5. JQuery ......................................................................................................................................... 73 5.4.6. HTML5 e CSS3 ............................................................................................................................ 73

5.5. Metodologia de desenvolvimento ........................................................................................................ 73 5.5.1. Planeamento e Especificação de requisitos ................................................................................ 73 5.5.2. Implementação ............................................................................................................................ 74 5.5.3. Validação ..................................................................................................................................... 74 5.5.4. Aceitação ..................................................................................................................................... 74

5.6. Responsabilidades................................................................................................................................ 74 5.7. Ferramentas de apoio .......................................................................................................................... 75

6. APLICAÇÃO DO NOVO PROCEDIMENTO DE TESTES ........................................................................................ 76 6.1. Planeamento ......................................................................................................................................... 76 6.2. Desenho ............................................................................................................................................... 76

6.2.1 Testes de Navegação ................................................................................................................... 76 6.2.3. Testes de Validação de entradas .................................................................................................. 78 6.2.4. Testes da estrutura HTML e CSS ................................................................................................. 80 6.2.5. Testes AJAX ................................................................................................................................. 81

6.3. Automatização e Execução .................................................................................................................. 82 6.4. Avaliação e resultados .......................................................................................................................... 85

7. CONCLUSÕES ................................................................................................................................................ 88 7.1. Revisão do trabalho realizado .............................................................................................................. 88 7.2. Dificuldades ......................................................................................................................................... 89 7.3. Trabalho futuro .................................................................................................................................... 90

8. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................... 91 9. ANEXOS ........................................................................................................................................................ 93


x

ÍNDICE DE FIGURAS Figura 1 - Mercados alvo dos contributos de M2M (com base em [1]) ................................................................... 3 Figura 2 - Smart Services ........................................................................................................................................ 3 Figura 3- Processo de desenvolvimento da Present Technologies ........................................................................... 9 Figura 4 - Diagrama de atividade do processo de teste atual para aplicações web ................................................ 16 Figura 5 – Envolvente económica de testes de software (baseado em [33]).......................................................... 19 Figura 6 Testes estáticos e dinâmicos .................................................................................................................... 21 Figura 7 - Inquérito Forrester Consulting [7] ........................................................................................................ 25 Figura 8 - Modelo em V [5] ................................................................................................................................... 27 Figura 9 - Método de desenvolvimento TAD ........................................................................................................ 28 Figura 10 - Método de desenvolvimento TDD ...................................................................................................... 28 Figura 11 - Padrão Modelo-Vista-Controlador [35] .............................................................................................. 35 Figura 12 - Utilização dos browsers no StatCounter entre 08/2011 e 08/2012 ..................................................... 38 Figura 13 - Hierarquias de teste JUnit e TestNG ................................................................................................... 43 Figura 14 - Teste de pesquisa de filme .................................................................................................................. 48 Figura 15 – Elemento assinalado pelo Watir ......................................................................................................... 50 Figura 16 - Modos de execução do Arquillian (in-container vs client) ................................................................. 54 Figura 17 – Resultado do teste QUnit ................................................................................................................... 58 Figura 18 - Resultado do teste Jasmine ................................................................................................................. 59 Figura 19 - Índice do STG ..................................................................................................................................... 62 Figura 20 - Ciclo de vida de testes ........................................................................................................................ 63 Figura 21 - Ferramentas de teste selecionadas ...................................................................................................... 64 Figura 22 - Índice do TPT ..................................................................................................................................... 65 Figura 23 - Mapeamento do processo de testes para nível 2 do TMMi ................................................................. 67 Figura 24 – Diagrama de deployment do projeto ................................................................................................... 70 Figura 25 - Composição do Portal B2B ................................................................................................................. 71 Figura 26 - Ciclo de vida em Cascata .................................................................................................................... 73 Figura 27 - Grafo referente à navegação do Portal Business ................................................................................. 77 Figura 28 - Passo 1 e 2 do wizard de edição de Utilizador .................................................................................... 79 Figura 29 - Estados da dropdown de seleção de Aplicação Vertical ...................................................................... 80 Figura 30 - Testes automáticos Portal B2B ........................................................................................................... 82 Figura 31 - Exemplo de interações com os Page Ojects ....................................................................................... 83 Figura 32 - Execução automática de testes nos browsers IE e Chrome ................................................................. 84 Figura 33 - Resultado dos testes implementados ................................................................................................... 86 Figura 34 - Diagrama de contributos do estágio .................................................................................................... 88

Portal B2B e Testes ÍNDICE DE TABELAS

xi

ÍNDICE DE TABELAS Tabela 1 – Caso de teste no Test Case Specification Template .............................................................................. 11 Tabela 2 - Resultados do projeto A ........................................................................................................................ 13 Tabela 3 - Resultados do Projeto B........................................................................................................................ 14 Tabela 4 - Descrição dos níveis de maturidade TMMi .......................................................................................... 24 Tabela 5 - Componentes do Plano de testes IEEE 629-1983 ................................................................................. 32 Tabela 6 - Componentes do Plano de testes essenciais [19] .................................................................................. 33 Tabela 7 - Resumo das atividades do ciclo de vida dos testes ............................................................................... 63 Tabela 8 - Funcionalidades macro do Portal B2B ................................................................................................. 69 Tabela 9 - Casos de teste Navegação resultantes do critério Edge-Coverage ........................................................ 78 Tabela 10 - Input Space Partitioning da operação Edição de Utilizador ............................................................... 80 Tabela 11 - Casos de teste de transição de estado .................................................................................................. 81

CAPÍTULO 1

1

1. INTRODUÇÃOEste estágio encontra-se inserido na disciplina de “Estágio/Projeto Industrial” do Mestrado

em Informática e Sistemas do Instituto Superior de Engenharia de Coimbra, sob orientação do

Professor João Cunha. Os trabalhos foram realizados nas instalações da empresa Present

Technologies, em Coimbra, sob orientação do Eng.º Samuel Santos devido à sua disponibilidade e

conhecimento técnico do projeto desenvolvido no contexto deste estágio.

1.1. Apresentação do projeto/estágio O trabalho apresentado neste documento insere-se no contexto de desenvolvimento e testes

de aplicações web. O âmbito inicial do projeto enquadrava-se apenas na aplicação Portal B2B

para gestão de uma plataforma Machine-To-Machine de um cliente e elaboração de testes

específicos de interface utilizador web. Contudo, a empresa não dispunha de documentação sobre

os procedimentos de teste em vigor. Assim, foi considerado útil a inclusão da formalização e

melhoria destas atividades no contexto do estágio. Por fim, como prova de conceito, o

procedimento de testes foi aplicado ao Portal B2B e foram retiradas conclusões do mesmo.

O início do estágio ocorreu no dia 14 de Novembro de 2011, tendo sido o esforço repartido

da seguinte forma (valores aproximados): 40% no desenvolvimento do projeto Portal B2B, 35%

na formalização e otimização do processo de testes e investigação de testes de interface gráfica

web. Finalmente, uma parcela de 25% foi dedicada à aplicação do processo de testes ao produto

Portal B2B.

Antes da realização deste trabalho, o estagiário encontrava-se com vínculo contratual full-

time com a Present Technologies. Esta situação obrigou a que o estágio não fosse pautado pela

carga horária da disciplina. O esforço despendido no estágio foi dinamicamente acordado com a

empresa, uma vez que paralelamente o estagiário executou tarefas referentes ao desenvolvimento

de outros projetos. Foram realizadas reuniões formais com periodicidade mensal, para atualização

do estado do projeto e definição de objetivos.

O projeto de desenvolvimento de software referente ao Portal B2B foi realizado em

parceria tecnológica com o cliente e implicou a integração de mais três elementos da Present

Technologies. O componente referente à otimização do processo de testes, numa vertente

documental, foi realizado apenas com a contribuição do estagiário e orientadores visando o

estabelecimento de boas práticas e recomendações atuais na implementação de testes de software

na empresa. Foi realizada também, a aplicação do processo de testes sob o Portal B2B, no sentido

de verificar a real mais-valia na adoção futura deste processo.

INTRODUÇÃO

2

1.2. Apresentação da Organização A Present Technologies foi fundada em 2000 e tem vindo a providenciar soluções e

serviços para diferentes mercados incluindo telecomunicações, finanças, indústria e setor público.

As soluções desenvolvidas destinam-se a clientes de renome em Portugal e no estrangeiro, entre

os quais Portugal Telecom Inovação, SAPO, Critical Software, ISA, Banco BPI, Siemens, TMN,

Optimus, Vodafone, Vivo (Brasil) e CVT (Cape Vert Telecom). A empresa encontra-se sediada na

cidade de Coimbra e tem como atividade principal, trazer tecnologia de informação para o

mercado, através do desenvolvimento de soluções inovadoras e competitivas, centradas nas áreas

de negócio de soluções móveis, aplicações empresariais e aplicações/serviços de internet.

Tem na sua constituição uma equipa fortemente especializada em investigação/inovação e

desenvolvimento, sendo fator resultante do compromisso de colaboração da empresa com grupos

de investigação em Universidades e participação em projetos de I&D juntamente com parceiros

de negócio. Os seus clientes e parceiros reconhecem a qualidade e profissionalismo empregue nos

seus serviços, nomeadamente na colaboração de projetos de software e consultadoria em

tecnologias de informação.

De forma a cimentar cada vez mais os padrões de excelência e qualidade das soluções

desenvolvidas pela Present Technologies, esta implementou um sistema de gestão integrado que

se encontra neste momento certificado pelas normas de Gestão de Qualidade – ISO 9001:2008 e

de Sistemas de Gestão da Investigação, Desenvolvimento e Inovação – NP 4457:2007.

O estagiário ocupa lugar numa equipa responsável pelo suporte, gestão e construção de

aplicações web empresariais especializada na experiência avançada para o utilizador final,

seguindo as normas web e compromisso com usabilidade da interface.

1.3. Introdução ao M2M Para enquadramento do leitor, nesta secção é efetuada a descrição do conceito

comunicações Machine-To-Machine, uma vez que se trata da área de negócio do Portal B2B.

Machine-To-Machine, ou simplesmente M2M, é visto por um número de organizações cada

vez maior como uma forma rápida, confortável e económica de retirar vantagens da ligação em

rede entre máquinas e dispositivos utilizados diariamente nas vidas de todos (por exemplo em

edifícios ou em veículos), de modo a alavancar novos serviços no mercado. Pode ser visto como

um conjunto de interações entre as pessoas e os seus produtos, que permitem obter informação de

estado de um dispositivo, como a sua localização, energia, temperatura, histórico de manutenção e

níveis de produtividade. Além de operações de consulta passiva, é ainda possível atuar sobre um

ou mais dispositivos selecionados através do envio de ordens de execução.

INTRODUÇÃO

3

Nos ambientes construídos com recurso ao M2M, os conteúdos e serviços são

automaticamente entregues ao consumidor com pouca ou nenhuma intervenção/manipulação

humana, abstraindo ainda a comunicação entre os diversos dispositivos [1]. A Figura 1 mostra as

principais áreas e mercados onde se tem vindo a verificar a aceitação com sucesso das tecnologias

M2M.

Figura 1 - Mercados alvo dos contributos de M2M (com base em [1])

Os dispositivos e máquinas envolvidas no M2M acabam por beneficiar da evolução

significativa das infraestruturas de comunicação, que providencia uma maior zona de cobertura,

taxas de transmissão de dados mais rápidas e baixo custo de instalação. Estes fatores habilitam a

criação de Smart Services, aplicações inteligentes capazes de atuar e reagir perante a informação

recolhida, e são extremamente importantes na comunicação e agregação de dados de maneira

semântica e de forma autónoma.

Figura 2 - Smart Services

INTRODUÇÃO

4

Como se pode observar no diagrama da Figura 2, os Smart Services baseiam-se na

automação e controlo, na localização, na provisão e na monitorização remota de dispositivos. Os

exemplos mais conhecidos são as soluções de Smart Metering, Fleet Management, eHealth,

gestão remota de máquinas automáticas de venda, domótica, sistemas de segurança,

infraestruturas de telecomunicações e equipamentos de gás e combustível.

De acordo com um estudo de mercado realizado em 2009, as estimativas apontavam para

que existissem aproximadamente 50 mil milhões de dispositivos a beneficiar das comunicações

M2M. Dada esta escala, o número de organizações que compete por uma posição de destaque

neste nicho de mercado é cada vez maior.

Com o surgimento de cada vez mais empresas a oferecer estes tipos de serviços, tornou-se

importante para o cliente da Present Technologies, através deste projeto, ocupar um lugar neste

panorama. A gestão de serviços à medida dos seus parceiros económicos é viabilizada através da

construção de uma plataforma genérica. Por questões de confidencialidade de informação

contratual, a empresa cliente será denominada neste documento como apenas Cliente.

1.4. Motivação Atualmente, as empresas competem a um ritmo acelerado, num mercado global em que os

clientes e seus colaboradores esperam serviços fáceis de usar, inovadores, sempre disponíveis e

competitivos.

O projeto incluído neste estágio surge no contexto da proposta, submetida pela Present

Technologies como resposta a um Request For Proposal do Cliente, para o desenvolvimento e

implementação de um Portal de Operação e Manutenção (POM) e Portal de Negócio (PN) para

uma plataforma M2M. A aplicação final deve oferecer aos seus utilizadores uma experiência rica,

com conteúdos dinâmicos e uma visão de serviço centrado no utilizador. No desenvolvimento foi

utilizada a framework da Present Technologies para aplicações web Java baseada nas tecnologias

Stripes1 e EJB32.

A metodologia utilizada anteriormente, à realização do estágio, não incluía testes

automáticos web. Os testes funcionais e de regressão na empresa eram executados com base num

esforço manual considerável, que tornava as aplicações web mais suscetíveis a defeitos, o que

podia afetar a qualidade das aplicações produzidas. Para prevenir estas situações, pretende-se que

seja elaborado um estudo tendo em consideração as novas ferramentas, e técnicas utilizadas para

automatizar o processo de execução de testes à camada de apresentação web, levando à

consequente redução excessiva dos recursos despendidos na etapa de execução dos testes.

1 http://www.stripesframework.org/display/stripes/Home 2 http://www.oracle.com/technetwork/java/javaee/ejb/index.html

INTRODUÇÃO

5

Durante o decurso do estágio, surgiu a oportunidade de incluir como objetivo, a elaboração

documental de um guia de testes de software na empresa de modo a formalizar as atuais práticas

de teste em vigor na empresa e adicionar novas atividades a ter em conta para testes de interface

de utilizador, facilitando assim a entrega de produtos com um nível de qualidade mais elevado.

A solução proposta do procedimento de testes deve contribuir para a normalização da etapa

de testes de software dos atuais e futuros projetos web dentro do contexto da Present

Technologies. É pretendido que, os resultados da pesquisa e desenvolvimento efetuados durante o

decurso deste trabalho, resultem numa real e efetiva contribuição de valor para a disseminação

interna de conhecimento da área de testes de software.

Seguindo a política da empresa, todas as soluções propostas deveriam privilegiar a

utilização de tecnologias e componentes de software open source, cujo código fonte é

disponibilizado ao público permitindo a cópia, modificação e distribuição legal sem custos ou

restrições.

1.5. Objetivos atingidos No âmbito deste estágio foram atingidos os seguintes objetivos:

Desenvolver o componente de apresentação gráfica que integre com a plataforma M2M

de acordo com os requisitos especificados e APIs disponibilizadas em articulação com o

trabalho da equipa do Cliente;

Explorar e selecionar ferramentas, técnicas, critérios e políticas de teste emergentes para

front-end de aplicações web, adquirindo o know-how para a sua utilização no âmbito de

diferentes projetos;

Implementar uma proposta de procedimento de testes composto pelos documentos Test

Plan Template e Software Testing Guide, incluindo a formalização das práticas que já se

encontravam em vigor na empresa, que ateste a correção, completude, precisão,

consistência e testabilidade de um produto de software;

Validar o novo procedimento de testes através da sua aplicação ao projeto Portal B2B e

subsequente análise de resultados;

Disseminar na Present Technologies o conhecimento sobre os assuntos do estágio

relacionados com testes de software.

INTRODUÇÃO

6

1.6. Estrutura do documento Para além desta introdução, este relatório está organizado da seguinte forma:

Capítulo 2 - Análise à prática de testes de SW na Present Technologies: o objetivo

deste capítulo é apresentar e descrever as metodologias relacionadas com testes de

software, exercidas na empresa na altura do início do estágio, fornecendo assim uma

vista global e background tecnológico interno existente na empresa. Numa vertente

mais de avaliação de qualidade de software produzido, são analisados os resultados de

projetos anteriores ao estágio.

Capítulo 3 - Metodologias e práticas de testes de software: neste capítulo é

apresentada uma análise do estado da arte sobre processo de testes de software.

Inclui ainda um estudo que distingue os métodos, critérios de cobertura,

técnicas e ferramentas atualmente disponíveis e mais utilizadas para elaboração

de testes com maior foco nos testes de interface utilizador web.

Capítulo 4- Conceção de um guia e plano de testes para a Present

Technologies: dando seguimento aos capítulos anteriores, é descrito o processo

de elaboração dos documentos reguladores de testes que visam combinar as

principais tecnologias e atividades de teste que melhor se adequam à realidade

atual da empresa.

Capítulo 5 - Caso de estudo: projeto portal b2b: neste capítulo é apresentado

o projeto Portal B2B, suas funcionalidades e arquitetura, descrevendo a

metodologia utilizada no seu desenvolvimento e o papel do estagiário na

equipa. É ainda realizada uma contextualização do sistema onde foi aplicado o

procedimento de testes elaborado no estágio.

Capítulo 6 - Aplicação do novo procedimento de testes: este capítulo existe

com o objetivo de demonstrar a viabilidade dos procedimentos de teste

propostos utilizando o Portal B2B como protótipo. Após a realização da

experiência são analisados e discutidos os resultados.

Capítulo 7 - Conclusões: neste capítulo é analisada a aplicação do novo

procedimento de testes desenvolvido, sendo extrapoladas conclusões e

oportunidades de melhoria baseadas nos resultados. É ainda efetuado um

balanço sobre o trabalho realizado, com destaque para objetivos alcançados e

INTRODUÇÃO

7

dificuldades sentidas. No final são apresentadas perspetivas e aspirações

futuras do estagiário.

Capítulo 8 - Referências Bibliográficas: possui a listagem de referências que

serviram de inspiração à escrita de conteúdos do relatório.

Capítulo 9 - Anexos: Inclui a lista de anexos do relatório.

CAPÍTULO 2

8

2. ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES

Uma da pretensões pessoais a atingir com a realização do estágio foi que o trabalho

desenvolvido fosse relevante e útil para o dia-a-dia na Present Technologies. Logo numa fase

inicial foi apurado que, de uma maneira geral, os programadores desconhecem o que é esperado

deles no que diz respeito a testes de software. Este aspeto acaba por ser reforçado pela insuficiente

documentação de procedimentos ou templates que possam ser utilizados durante os projetos.

Partindo destes pressupostos, um dos objetivos deste estágio foi recomendar uma otimização do

processo informal de testes da Present Technologies.

Para cumprir este objetivo, este capítulo pretende dar a conhecer os métodos de testes

efetuados antes do novo procedimento de testes proposto neste estágio. Esta informação foi

maioritariamente extraída do processo de desenvolvimento de software existente na organização,

que se passa a descrever.

2.1. Procedimentos de testes em vigor A organização utiliza o modelo de desenvolvimento em Cascata (Waterfall). Nesta

metodologia, apenas se pode transitar para uma fase seguinte caso a anterior se encontre

completa. Não existe paralelização de fases e não contempla iterações. Esta abordagem é simples,

sistemática e ortodoxa. Uma das principais desvantagens é o facto da maioria dos erros no código

apenas serem detetados quando se realiza a fase de testes. Esta situação penaliza o projeto sendo

necessário restabelecer o equilíbrio com um aumento de tempo, orçamento ou outros recursos.

Os projetos são normalmente realizados em parceria tecnológica com outras organizações,

sendo que cada uma das organizações gere o seu plano de projeto internamente, sincronizando

ocasionalmente em reuniões de controlo do projeto. Nestes projetos, o desenvolvimento é

realizado em conjunto com equipas de outras organizações, sendo por isso muitas vezes sujeitos à

metodologia imposta pelo cliente ou parceiro. A típica curta duração dos projetos e a experiência e

maturidade da empresa ajudam a atenuar as desvantagens desta metodologia relativamente a

abordagens iterativas e incrementais.

Toda a produção de sistemas de informação da empresa é regida de acordo com o processo

de gestão de desenvolvimento de software em vigor na empresa, que se destina a todos os

colaboradores envolvidos nas atividades de gestão ou de implementação dos projetos. O processo

é certificado pela norma internacional ISO 9001:2008 e pela norma portuguesa NP 4457:2007.

Encontra-se previsto neste processo a adoção de metodologias ágeis em situações excecionais,

ANÁLISE À PRÁTICA DE TESTES DE SW NA PRESENT TECHNOLOGIES

9

onde é considerada como a melhor opção face às caraterísticas intrínsecas dos projetos. A Present

Technologies considera os seguintes tipos de projetos:

Projeto de Desenvolvimento de Software: projeto de desenvolvimento habitualmente impulsionado por pedido de cliente;

Projeto R&DI: especialização de projeto de desenvolvimento que contém uma componente de inovação, explorando uma nova ideia de produto/serviço ou

tecnologia;

Projeto de Suporte e Manutenção: projeto que providencia um serviço ao cliente baseado na manutenção ou melhoria de um produto existente;

Projeto de Design e Usabilidade: projeto cujo objetivo é preparar e desenvolver um desenho gráfico e estudo de usabilidade para um produto/serviço.

A formalização do procedimento de testes de software da empresa incide no contexto dos

três primeiros tipos de projetos apresentados.

O processo de desenvolvimento endereça e descreve as seguintes atividades: Início do

projeto, Fase de requisitos, Fase de implementação, Fase de validação, Fase de aceitação, Fase de

garantia, Fase de suporte e manutenção e por fim Disseminação de resultados do projeto R&DI

(Figura 3).

Inicio do projecto

Fase de validação

Fase de requisitos

Fase de aceitação

Fase de suporte e manutenção

Fase de implementação

Fase de garantia

Fase de suporte e manutençãod)

Figura 3- Processo de desenvolvimento da Present Technologies

1) Início de projeto

Nesta atividade é assegurada a definição da infraestrutura para o decurso do projeto,

nomeadamente através da criação do projeto nas ferramentas de controlo de versões CVS3 e de 3 http://www.nongnu.org/cvs/


10

gestão de projetos Redmine4 adotadas pela empresa. Envolve a elaboração do plano do projeto de

alto nível de acordo com a informação recebida pelo responsável da proposta ou diretor R&DI.

Durante esta atividade o gestor de projeto define o Quality Assurance Plan (QAP) no Redmine

estabelecendo as adaptações necessárias dependentes do tipo e caraterísticas do projeto.

No documento QAP os testes de software apenas são abordados no tópico Verificação e

Validação, onde está contemplada a identificação dos tipos de testes a realizar no projeto e a

advertência de que seja utilizada a última versão estável e recomendada das ferramentas de testes.

Depois de efetuadas tarefas de administração como a definição da equipa do projeto e a

criação de plano de faturação, a atividade é concluída com a realização da KOM (Kick-Off

Meeting), onde é apresentado o projeto, a equipa, a lista de artefactos a entregar bem como os

pressupostos e riscos.

2) Fase de requisitos

Esta atividade é constituída essencialmente pela definição dos requisitos e pela elaboração

do documento de especificação da arquitetura. Através dos métodos de comunicação

estabelecidos previamente com o cliente, são detalhados os requisitos funcionais e não funcionais.

Por outro lado, na elaboração da arquitetura da solução, deve ter-se em conta a experiência

adquirida em projetos anteriores e visa identificar os componentes principais, interfaces externas

do sistema e as tecnologias mais adequadas para o projeto.

3) Fase de implementação

Num passo inicial engloba a estimativa de esforço, dependências, precedências e atribuição

das tarefas de implementação aos recursos do projeto. Depois da calendarização das tarefas no

plano ficar concluída, dá-se início ao desenvolvimento de acordo com as normas e melhores

práticas das tecnologias aplicáveis ao projeto. Esta tarefa é realizada tendo em conta os requisitos

definidos na atividade anterior, assegurando o armazenamento dos artefactos e informação

produzida num sistema de controlo de versões (interno ou disponibilizado pelo cliente). No final

desta atividade, o processo menciona a especificação de casos de teste antes da fase de validação

de acordo com o documento Test Case Specification Template já existente. Neste documento

apenas considera a descrição tabelar de casos de testes, que foi de resto reutilizada no plano de

testes concebido no âmbito deste estágio, através do preenchimento de campos típicos, entre os

quais identificador do teste, objetivo, autor, valores de entrada, valores de saída, dependências e

requisitos cobertos (Tabela 1).

4 http://www.redmine.org/


11

Tabela 1 – Caso de teste no Test Case Specification Template

Especificação de teste Identificador de teste: Última atualização: Responsabilidade: Present Technologies Versão de teste: X.Y Objetivo: Autor(es): Especificações de entrada:

1. Entrada 1. 2. Entrada 2.

Especificações de saída: 1. Saída 1. 2. Saída 2.

Dependências: PROJECT-TCS-NNNN, … Requisitos: PROJECT-SWR-NNNN,…

4) Fase de validação

Esta atividade representa o ponto onde são executados os testes definidos no documento de

especificação mencionado na atividade anterior. Inicialmente é preparada uma release do produto

para testes. À medida que são detetadas anomalias durante a execução dos testes, estas são

registadas no Redmine e/ou no issue tracker disponibilizado pelo cliente como Defect para

posterior resolução da equipa de desenvolvimento. Caso se justifique a correção de defeitos pode

dar origem a uma nova release do software para um novo ciclo de testes.

5) Fase de aceitação

Nesta atividade é disponibilizada uma nova release do produto para o cliente. Tipicamente

esta versão é alvo de testes de aceitação por parte do cliente, de onde podem resultar novos

defeitos ou melhorias que deverão ser introduzidas devidamente no issue tracker. Normalmente o

cliente fica responsável por delinear um plano de testes e, caso assim o deseje, a Present

Technologies pode disponibilizar a especificação dos casos de teste utilizada na fase de validação.

A responsabilidade destes testes é do cliente, sendo o mesmo responsável por reportar os erros à

equipa de desenvolvimento da Present Technologies. Desta ação, poderão resultar dois tipos de

diligências: análise e correção dos defeitos identificados ou implementação de Change Requests.

Numa fase posterior, o termo de aceitação é oficializado por parte do cliente e é agendada a

reunião de fecho do projeto onde serão discutidos e analisados os seus resultados. A presente

atividade termina com o preenchimento de um questionário de satisfação pelo cliente, tendo como

base o processo de análise de satisfação interno da empresa.


12

6) Fase de garantia

No processo de desenvolvimento encontra-se previsto um período de garantia, onde são

analisados eventuais defeitos reportados pelo cliente seguindo o fluxo descrito na fase de

aceitação.

7) Fase de suporte e manutenção

Atendendo ao tipo de contrato efetuado para o projeto, o período de suporte e manutenção

que pode ser ativado com um pedido formal por parte do cliente. Nesta atividade, similarmente às

anteriores, são disponibilizadas correções ou novas funcionalidades ao cliente.

8) Disseminação de resultados do projeto R&DI

Tal como o nome indica, trata-se de uma atividade específica para projeto R&DI, onde é

realizada a análise de resultados obtidos contra os objetivos definidos no início do projeto e

avaliada a ideia o que gerou o projeto, bem como as lições aprendidas.

2.2. Resultado de projetos antecedentes Nesta secção são analisados resultados de projetos finalizados antes do estágio para

conhecer melhor o efeito prático da aplicação do processo informal de testes que vigorava na

empresa.

Foram analisados dois projetos Java Enterprise Edition, adiante designados de A e B,

devido ao abrigo da confidencialidade inerente nos contratos oficializados com os clientes. As

métricas de avaliação averiguadas foram o número de bugs por funcionalidade e a percentagem de

tempo total do projeto dedicada à correção de erros (planned versus actual effort). As métricas

selecionadas providenciam a rápida e resumida informação sobre os incidentes/anomalias

ocorridos e como o projeto foi influenciado pelo custo inerente à correção destes problemas.

2.2.1. Projeto A A primeira aplicação foi construída especificamente para dispositivos móveis, tendo como

objetivo facilitar a utilização de uma bolsa online para os seus clientes. A Present Technologies foi

parte integrante em todas as fases do ciclo de desenvolvimento, tendo sido responsável pela

implementação do front-end e camada de Enterprise JavaBeans (EJB) para recolha e preparação

dos dados recebidos através de WebServices. Durante a fase de implementação e engenharia foram

executados testes unitários e testes de validação manuais. A Tabela 2 apresenta uma visão geral da

estrutura do plano e dos recursos alocados em cada uma das fases, assim como a quantidade de

defeitos detetados e o cálculo das métricas referidas.


13

Tabela 2 - Resultados do projeto A

Analisando a Tabela 2 é possível destacar que foram identificados 3,86 erros por

funcionalidade implementada e que o tempo total necessário para correção dos defeitos superou

em 5,81% o tempo inicialmente previsto na elaboração do plano do projeto. Para o cálculo destes

valores não foi considerada a fase de aceitação devido ao acentuado desvio em relação à

estimativa inicial, provocado pelos procedimentos de aceitação do cliente. As equações (1) e (2)

ilustram as expressões utilizadas para o cálculo dos valores apresentados.

𝐵𝑢𝑔𝑠 𝑝𝑜𝑟 𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑𝑒 =247 𝑏𝑢𝑔𝑠

64 𝑓𝑝′𝑠= 𝟑, 𝟖𝟔, (1)

% 𝑇𝑒𝑚𝑝𝑜 𝑟𝑒𝑎𝑙 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 − % 𝑇𝑒𝑚𝑝𝑜 𝑝𝑙𝑎𝑛𝑒𝑎𝑑𝑜 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 = 20,28% − 14,47% = 𝟓, 𝟖𝟏% (2)

2.2.2. Projeto B O Projeto B é uma aplicação web escalável e de alto desempenho que providencia as

funcionalidades necessárias para automatizar o processo de venda de vouchers. No âmbito deste

projeto, a Present Technologies foi responsável por todas as fases do ciclo de desenvolvimento,

excluindo as fases de validação e aceitação. Além dos testes unitários, foram implementados

testes de integração para validação da comunicação com interfaces de sistemas externos.


14

Tabela 3 - Resultados do Projeto B

A Tabela 3 mostra que a média aritmética dos erros detetados por funcionalidade é inferior

a um (0,29). Como os valores referentes à fase de aceitação não foram disponibilizados pelo

cliente, utilizando as medidas da fase de validação como amostra, o tempo dedicado a correções

foi prolongado em apenas 2,17%. Os valores foram calculados conforme as expressões (3) e (4).

𝐵𝑢𝑔𝑠 𝑝𝑜𝑟 𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑𝑒 =26 𝑏𝑢𝑔𝑠

93 𝑓𝑝′𝑠= 𝟎, 𝟐𝟗, (3)

% 𝑇𝑒𝑚𝑝𝑜 𝑟𝑒𝑎𝑙 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 − % 𝑇𝑒𝑚𝑝𝑜 𝑝𝑙𝑎𝑛𝑒𝑎𝑑𝑜 𝑐𝑜𝑟𝑟𝑒çõ𝑒𝑠 = 14,13% − 11,96% = 𝟐, 𝟏𝟕% (4)

Com base nos dados apresentados neste estudo, pode dizer-se que a aplicação do anterior

processo de testes informal não resultava em percalços significativos no que diz respeito à

qualidade observada nos artefactos produzidos. Os atrasos que maioritariamente se verificam nos

projetos são normalmente provocados por fatores externos e aos quais a Present Technologies é

completamente alheia. Torna-se assim essencial garantir a continuidade das tarefas de teste já

executadas na empresa, integrando novas tecnologias resultantes deste estágio de modo a, pelo

menos, manter o mesmo nível de qualidade.


15

2.3. Análise Informal Durante o tempo de atividade do estagiário na organização foi possível constatar que

geralmente a empresa disponibiliza os seus produtos e serviços dentro dos prazos estabelecidos.

Os dados revelados na análise de projetos na secção 2.2 conferem que a Present Technologies

apresenta um modelo de negócio sustentável, reforçado pela satisfação demonstrada pelos clientes

que acabam por regressar em futuros projetos.

A perceção dos seguintes aspetos foi extraída em reuniões do estágio e inferência dos

projetos que o estagiário tomou parte, bem como em conversa com colegas envolvidos noutros

projetos.

No âmbito deste trabalho é utilizada a definição defeito-erro-falha, tradução livre de fault-

error-failure para descrever os tipos de problemas existentes em software tal como consta em

[15]. O defeito refere-se à causa do erro, o erro a um estado erróneo interno do sistema e por fim,

falha significa a demonstração exterior do erro através do comportamento não conforme com o

que foi especificado ou é esperado.

2.3.1. Ausência de uma política comum de testes Antes da realização do estágio, a empresa não dispunha de uma política comum que

clarificasse a visão sobre objetivos e princípios de teste aos colaboradores, que pudesse depois ser

expandida por cada estratégia de teste adotada num determinado projeto. Este facto

impossibilitava uma estimativa de esforço e avaliação de resultados dos testes eficaz.

Encontrava-se previsto no documento Test Case Specification Template uma secção

referente ao plano de testes, no entanto não continha as orientações a tomar.

2.3.2. Smoke tests Relativamente a projetos de camadas de apresentação web (mobile ou não), após a

atribuição de um dado requisito a um programador, este implementa-o e executa o código para

verificar se o requisito se encontra devidamente implementado. Se for detetado um erro/defeito, o

programador efetua a sua correção e volta a executar o código novamente. Este processo

denominado de smoke tests continua até que todas as funcionalidades se encontrem

implementadas e não existam aparentes erros catastróficos.

Antes da disponibilização do software ao cliente, que geralmente é responsável pela

realização de testes mais rigorosos, são efetuados testes de validação manuais procurando passar

em revista o maior número de features implementadas, não descurando aspetos importantes como


16

o de segurança. Estes testes não são executados seguindo um processo formal. Na Figura 4 é

ilustrado o processo de teste atual através de um diagrama de atividade UML.

Figura 4 - Diagrama de atividade do processo de teste atual para aplicações web

2.3.3. Testes no cliente Normalmente o que se verifica é que o cliente fica com o ónus de realizar os testes de

validação de sistema, uma vez que é o detentor do ambiente de testes e habitualmente é um

parceiro tecnológico e de negócio e não o consumidor final. Dado que o processo de testes

anterior não se encontrava formalizado, não estavam definidos os níveis e tarefas de teste, sendo

por vezes adotadas medidas ad-hoc em projetos onde são solicitados comprovativos de qualidade

de software.

2.3.4. Formação e suporte documental Um dos problemas identificados é a inexistência de um plano que conduza à formação

interna ou externa dos colaboradores na área de testes de software ou na utilização das

ferramentas de teste adotadas. Como consequência da ausência de suporte documental para os

resultados dos testes informais, o processo atual não pode ser mensurado ou monitorizado como

seria aconselhável.

2.3.5. Testes automatizados Um aspeto positivo observado prende-se com a implementação de testes automatizados em

projetos Java, onde a Present Technologies é responsável pelo desenvolvimento da camada de

lógica de negócio ou quando existe integração com módulos ou subsistemas externos. São

utilizadas ferramentas de teste xUnit5 e in-container, isto é, com a aplicação sob teste em

5 http://en.wikipedia.org/wiki/XUnit


17

execução num container Java EE. Nos projetos referidos são concebidos testes de integração,

procurando tipicamente testar funcionalidades de interoperabilidade entre a camada de serviços e

a camada de acesso a dados. Normalmente são utilizadas técnicas informais de testes, que têm

como base as exceções que podem ser geradas nas operações invocadas aos serviços.

2.3.6. Testes estáticos e registo de defeitos Outro dos pontos positivos verificado prende-se com a análise estática do código, liderada

pelo departamento de qualidade através de revisões de código regulares, essencialmente em

projetos com forte preocupação a nível de desempenho.

Noutros projetos foi ainda utilizado o Google Docs6 para registo do resultado de testes

manuais, seguindo uma estrutura ad-hoc. Tipicamente os erros/defeitos capturados são

apropriadamente monitorizados, geridos e ordenados num issue tracker.

2.3.7. Ensaio com Test-Driven Development Tendo consciência das potencialidades da técnica TDD (Test-Driven Development),

constituinte da metodologia eXtreme Programming, foi realizada uma tentativa de aplicação, com

a qual foi possível apurar que esta abordagem não se adequa ao desenvolvimento efetuado na

empresa. A tentativa foi rapidamente abandonada devido ao fator de imprevisibilidade, que

provocava danos de produtividade bastante acentuados. Devido ao modo como o TDD se

processa, facilmente são criados muitos scripts de teste que tendem a ficar desatualizados e o

custo da sua manutenção pode ser desajustado relativamente aos prazos do projeto. Aliado a este

fator, por vezes a possibilidade de múltipla execução dos testes não é relevante em determinados

projetos.

6 https://docs.google.com

CAPÍTULO 3

18

3. METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE Esta secção fornece um background tecnológico e das metodologias referentes à área em

que o projeto esteve inserido, o que ajuda a entender as opções tomadas durante a conceção do

manual Software Testing Guide (Anexo A) e do documento Test Plan Template (Anexo B) no

capítulo 4.

Este capítulo é constituído por três subsecções: Processo de testes; Testes de interface web

e Ferramentas de automatização de testes. Na primeira é efetuada uma introdução ao que

representa um processo de testes de software, descrevendo os modelos e metodologias de suporte.

Seguidamente foram analisadas as recomendações de melhorias a implementar na elaboração do

template do plano de teste.

Ao longo da segunda subsecção, é feito um estudo sobre o paradigma de testes de interface

web, perspetivando a sua abrangência e soluções para superar os desafios atualmente impostos.

Por fim, na última subsecção é efetuada a análise das tecnologias relacionadas com os

testes web, como por exemplo o Selenium7 e o Arquillian8.

3.1. Processos de testes A doutrina de testes de software deve ser vista especialmente como uma forma de controlo

de qualidade. Trata-se de um instrumento que contribui com informação precisa, através da

interpretação dos resultados de testes, da qualidade de um sistema de informação. O processo de

teste deve providenciar uma evidência objetiva, de que o sistema e produtos associados satisfazem

inteiramente os requisitos respeitando as regras de negócio e regulamentos restritivos.

3.1.1. Contextualização de processos de testes As definições do conceito de testes de software compreendidas nas normas IEEE 610.12

Standard Glossary of Software Engineering Terminology ([27]) e Standard glossary of terms used

in Software Testing ([28]), convergem para a definição de um processo que consiste num conjunto

de atividades, estáticas e dinâmicas, atendendo ao planeamento, preparação e avaliação dos

produtos de software para determinar se satisfazem os requisitos especificados.

Similarmente ao processo de desenvolvimento de software, o processo de testes possibilita

às organizações uma maior estruturação e eficiência do trabalho desenvolvido. Uma metodologia

ou estrutura de testes de software tem a finalidade de formalizar as fases, atividades, funções,

7 http://seleniumhq.org/ 8 http://arquillian.org/

METODOLOGIAS E PRÁTICAS DE TESTES DE SOFTWARE

19

artefactos e responsabilidades necessárias para o planeamento e execução sistemática de testes. O

principal objetivo deste processo é expor o número máximo de falhas, dispondo de um esforço

ponderado e adequado, para determinar se um produto cumpre as especificações no ambiente para

o qual foi desenhado.

A razão pela qual o planeamento e controlo se devem iniciar simultaneamente com o

projeto é justificada pelos dados sobre quais as fases onde são originados mais defeitos, e as fases

que registam mais despesas na correção dos defeitos encontrados. Segundo o estudo presente em

[21], 85% dos defeitos são introduzidos logo nas fases iniciais do projeto, mais

pormenorizadamente na documentação de requisitos, arquitetura e desenho de interfaces do

sistema. Os dados apontam também no sentido de que a retificação dos defeitos é representada

por uma expressão logarítmica, onde por cada fase de desenvolvimento executada sem a devida

correção, o custo torna-se dez vezes superior. Como exemplo, uma falha detetada na fase de

especificação pode não ter um custo significativo. No entanto, o custo de correção da mesma,

quando detetada durante as fases de implementação e validação, oscila entre 10€ a 100€. Em

último caso, se for apenas revelada durante a fase de produção, a sua reparação pode ascender os

1000€ (hipoteticamente) [22].

Figura 5 – Envolvente económica de testes de software (baseado em [33])

Os dados extraídos na Figura 5 mostram que a qualidade é um atributo do software que

deve ser introduzido ao longo do processo de desenvolvimento, contrariando o entendimento

infundado de que os testes são uma fase secundária normalmente executada no final do projeto.

Para que se verifique a maior frequência de entrega de projetos dentro do orçamento e do

prazo estipulados, apresentando a qualidade e âmbito pretendidos, a norma disposta em [30]

aponta as seguintes atividades como sendo as essenciais para um processo genérico de testes:

Planeamento e controlo; Análise e desenho; Implementação e execução; Registo dos resultados dos testes; Verificação de completude.


20

Planeamento e controlo

Na atividade de planeamento é iniciada a elaboração do plano de teste que visa identificar o

âmbito, abordagens, riscos e recursos envolvidos nas atividades de testes. Uma vez que um dos

objetivos do estágio é a elaboração do template para o plano de testes, este documento é descrito

mais detalhadamente na secção 3.1.5. Depois de definido o plano de testes dá-se início ao

controlo projeto, comparando periodicamente o progresso atual contra o planeado. Este exercício

deve ser contínuo e dar resposta a mudanças de objetivos, estratégias de teste e/ou alterações do

projeto.

Análise e desenho

A análise, inicialmente consiste na revisão de documentos que servem de base para os

testes. Após este passo é necessário proceder à identificação dos tipos de teste para garantir a

cobertura dos componentes do sistema a testar, previamente acordados na iniciação do plano de

testes.

Numa fase posterior desta atividade, são empregues técnicas de desenho de testes definidas

na atividade de planeamento. Os casos de teste têm origem na especificação de requisitos e na

experiência retida em anteriores projetos pelos membros de equipa envolvidos. Esta atividade

incorpora as tarefas de verificação e validação (V&V), suportadas por técnicas de análise estática

e dinâmica.

Na verificação é avaliado se os componentes de software estão a ser desenvolvidos

conforme os padrões e metodologia estabelecida para o projeto (“Estamos a construir o produto

corretamente?”)[11]. Esta vertente estática implica revisões e inspeções sobre os artefactos

produzidos, não necessitando para isso da execução da aplicação. Para Java, o FindBugs9 e

Checkstyle10 são exemplo de ferramentas que analisam estaticamente o código (utilizadas em

projetos na Present Technologies).

Por outro lado, a validação recorre a técnicas para verificar a conformidade do software

implementado relativamente ao comportamento descrito nos requisitos. Envolve uma análise

dinâmica, ou seja, o código da aplicação é executado durante os testes (“Estamos a construir o

produto correto?”)[11]. Estes podem ser segmentados em testes funcionais e não funcionais. No

diagrama da Figura 6 é ilustrada a hierarquia dos conceitos apresentados nesta atividade.

9 http://findbugs.sourceforge.net/ 10 http://checkstyle.sourceforge.net/


21

Figura 6 Testes estáticos e dinâmicos

Implementação e execução

Tendo como base os casos de testes escolhidos na atividade anterior, é implementado o

código de teste de modo a executar o sistema sob teste. A execução destes testes é iniciada assim

que for disponibilizado o componente para testar e as pré-condições dos testes se encontrarem

satisfeitas. Os scripts de teste são normalmente priorizados e executados em múltiplos ciclos até

que sejam atingidos os critérios de cobertura definidos no plano. Os critérios de cobertura são

formados por um conjunto de regras que ajudam a determinar se um conjunto de testes testou

adequadamente um programa, orientando assim o processo de testes.

Quando nos testes são identificadas discrepâncias entre os resultados esperados e os

resultados reais, estas diferenças são registadas como defeitos, sendo de seguida analisadas e

corrigidas. Após a correção de um problema, é verificada se a mesma foi eficiente. Isto pode

significar uma nova execução dos testes para garantir que as correções realizadas eliminaram de

facto o problema.

Registo dos resultados dos testes

Na execução dos testes deve ser mantido um registo dos problemas identificados e

correções desenvolvidas. A avaliação do resultado da execução dos testes é considerada uma

atividade de gestão. Este registo divide-se em dois passos: primeiro é necessário colecionar

informação se o caso de teste passou ou falhou; depois é contabilizado o tempo gasto em testes

durante o projeto, calculando o desvio em relação ao tempo planeado. Para a tomada de decisão

são fornecidas métricas, tais como o número de testes que passaram e falharam, número total de

defeitos e custo adicional de esforço sobre o planeado resultante das correções.

Verificação de completude

Caso os critérios de cobertura especificados não se encontrem cumpridos, as atividades de

testes anteriores são novamente executadas. Por fim, as lições apreendidas durante o projeto são

registadas para a posterioridade e são identificadas oportunidades de melhoria no processo.


22

3.1.2. Otimização do processo de teste Algumas organizações anteveem o processo de testes como uma prática que ocupa

demasiado tempo, apresentando um custo superior ao planeado e que não fornece informação

suficiente sobre a qualidade do produto realizado [15].

Estes problemas são resolvidos com a melhoria e otimização do processo, contudo é difícil

definir quais e a ordem dos passos que devem ser realizados para melhorar e controlar o processo.

Para este fim, foram desenvolvidas várias iniciativas de modelos de otimização, como são o caso

de TMap [2], TPI [3], e TMMi [4]. De seguida é realizada uma descrição sintetizada, de forma a

dar a conhecer cada um destes modelos. O detalhe mais pormenorizado deste estudo pode ser

consultado no Anexo F.

TMap

O TMap11 é uma abordagem de gestão para a estrutura de testes em sistemas de

informação, desenvolvida pela Sogeti da Holanda. A definição do modelo é constituída por quatro

pontos fundamentais:

a) Base numa abordagem BDTM (Business Driven Test Management); b) Descreve um processo estruturado; c) Contém uma solução para testes completa; d) Método de testes adaptativo.

A caraterística principal deste modelo é a que diz respeito à orientação ao negócio das

tecnologias de informação. As decisões sobre quais os resultados de testes, tempo e orçamento

pretendidos, têm fundamento nos padrões racionais e económicos atuais e nos recursos

disponíveis (a). O modelo consiste ainda numa abordagem de teste estruturada e infraestrutural,

permitindo a contínua perceção do estado do sistema e riscos envolvido de uma maneira

controlada (b). O TMap fornece ainda, a informação sobre como se deve aplicar em forma de

exemplos, checklists, descrições técnicas, procedimentos, estruturas organizacionais e

ambientes/ferramentas de teste [2] (c). Adicionalmente, o TMap possui uma organização flexível

possibilitando a sua integração em projetos para novos sistemas, de suporte/manutenção ou para

utilização interna na empresa (in-house) (d).

O TMap apresenta uma abordagem bem definida baseada nos atributos de qualidade e na

análise de riscos. Utiliza uma estratégia centrada no que realmente é importante nos testes de

software. Tem como contrapartida, o facto da sua utilização numa pequena ou média empresa,

11 http://www.tmap.net/en


23

resultar numa solução demasiado dispendiosa. A curta duração dos projetos impossibilita a

utilização de todos os aspetos do modelo TMap [5].

Na opinião do estagiário a utilização completa do método formal TMap é extensa para

projetos de pequena dimensão ou com poucos riscos, como a maioria dos projetos verificados na

empresa. Porém não deve ser desconsiderado o conjunto de técnicas formais que permitem atingir

um certo grau de segurança na cobertura dos testes [5].

TPI

O modelo Test Process Improvement (TPI) foi desenvolvido com base no conhecimento e

experiências práticas adquiridas na implementação de processos de testes. A utilização do modelo

providencia os meios para determinar os pontos fortes e fracos de um processo atual, tendo em

vista a sua reformulação através de ações realistas e específicas.

Do ponto de vista geral, as principais considerações a ter no aperfeiçoamento do processo

devem ser, a deteção de defeitos (mais proximamente possível da sua fonte para minimizar os

custos de reparação) e disponibilizar informação sobre a qualidade do sistema o mais rapidamente

possível. Toda a avaliação e níveis de teste devem ser ajustados cuidadosamente, de modo a

fornecer uma estratégia ótima para que sejam identificados os erros mais importantes. O

progresso de todo o processo deve ser mensurado para permitir a melhoria contínua do mesmo.

O modelo TPI é segmentado em quatro perspetivas (cornerstones): o ciclo de vida (L);

organização (O); infraestrutura/ferramentas (I) e técnicas (T). Os diferentes aspetos das dimensões

dão origem às designadas Key areas, que correspondem a diferentes categorias do modelo de

otimização do processo de testes ([3]). Por exemplo, a utilização de ferramentas de teste, técnicas

de especificação de testes e relatório dos resultados. Cada Key area pode ser classificada em

níveis de maturidade e podem não ter o mesmo grau de importância para o desempenho do

processo. As dependências existentes entre as key areas e os níveis de maturidade A, B, C e D são

delineados na Test Maturity Matrix. Um procedimento é classificado num determinado nível, caso

preencha todos os requisitos desse nível (checkpoints). Um checkpoint deve ser visto como um

requisito.

Este modelo prepara a melhoria e otimização do processo de testes, com base na análise da

situação atual e nas propriedades a melhorar, determinando um conjunto de ações necessárias. Na

perspetiva do estagiário, devido às suas caraterísticas, o TPI podia se aplicado à Present

Technologies, no entanto, a determinação do nível de qualidade é ponderada pela avaliação

humana do processo o que pode incorrer de alguma subjetividade.


24

TMMi

Este modelo foi desenvolvido pela fundação TMMi sediada na República da Irlanda. Sem

fins lucrativos, a fundação, proporciona uma orientação e referência para otimização do processo

de testes e ajusta-se como modelo complementar do Capability Maturity Model Integration12

(CMMI) [4].

Tal como o CMMI, o modelo contém 5 etapas ou níveis, através dos quais é possível a uma

determinada organização evoluir o seu processo de testes improvisado e de difícil gestão para uma

versão controlada, definid

portalb2b e optimização do processo de testes · proposta de otimização de testes incluindo um...

Documents