O papel das ferramentas de automação
de testes funcionais em contexto de
projetos dinâmicos e complexos
VERSÃO PROVISÓRIA
-DISSERTAÇÃO DE MESTRADO
EM ENGENHARIA INFORMÁTICA
Gustavo Emanuel Pinto de Moura e Miranda Coutinho
Sob orientação do Professor Paulo Nogueira Martins
Curso de Mestrado em Engenharia Informática
O papel das ferramentas de automação
de testes funcionais em contexto de
projetos dinâmicos e complexos
VERSÃO PROVISÓRIA
-Dissertação do curso de Mestrado em Engenharia Informática
de
Gustavo Miranda Coutinho
Dissertação submetida à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Informática, elaborada sob a orientação do Professor Paulo Nogueira Martins da Universidade de Trás-os-Montes e Alto Douro.
I
“QUANTO MAIOR SÃO AS DIFICULDADES A VENCER, MAIOR SERÁ A SATISFAÇÃO.” - Cícero.
III
Resumo
Atualmente o software faz parte das nossas vidas e sociedade e estamos cada vez mais dependentes dele. A complexidade do software também está a crescer e, de modo a verificar todos os seus componentes e funcionalidades, é necessário efetuar uma quantidade exorbitante de casos de teste durante a fase de desenvolvimento. O teste de software é uma atividade crítica no ciclo de vida de desenvolvimento de software e pode ser testado quer manualmente ou automaticamente. No contexto da automação de testes, a utilização de uma
framework permite melhorar de forma eficiente a extensibilidade e reutilização de testes
automáticos.
Esta dissertação foi realizada em âmbito do estágio numa empresa internacional de seguros que se encontra a fazer um upgrade do seu sistema antigo para um core system mais moderno. Trata-se de um projeto de grandes dimensões e complexidade, sendo que para realizar as atividades de teste de software envolve uma grande quantidade de esforço, quer na criação ou na execução de vários casos de testes.
O trabalho realizado para esta dissertação consistiu no desenvolvimento de testes funcionais automáticos para testar uma aplicação web-based pertencente ao core system. A aplicação suporta e gere processos de seguros centrais em toda a cadeia de valores, desde o planeamento das atividades de marketing ou a criação de cotações até todo o ciclo de vida de uma apólice, comissões, sinistros, incluindo integração a fornecedores de serviços externos, ajuste de perdas, resseguros e gestão de informação.
Nesse sentido, exploraram-se conceitos da automação de testes e utilizou-se esse conhecimento para desenvolver testes automáticos numa nova proposta/framework, permitindo o reaproveitamento do código dos scripts de testes para o desenvolvimento de novos testes e para a criação de novos casos de teste a serem executados.
Através do desenvolvimento de testes automáticos foi possível perceber qual o impacto que a automação de testes pode trazer em projetos complexos e dinâmicos, sendo também importante a definição de uma framework adequada à automação dos testes funcionais. Ficou claro que a automação de testes permite auxiliar as atividades de teste manual do software e reduzir o esforço necessário para a execução dos casos de teste.
V
Abstract
Currently the software is part of our lives and society and we are increasingly dependent on it. The complexity of the software is also growing and in order to check all its components and features, it must perform an exorbitant amount of test cases during the development phase. Software testing is a critical activity in the software development life cycle and can be tested either manually or automatically. In the context of test automation, the use of a framework enables efficiently improve the extensibility and reuse of automated tests.
This work was performed on stage under an international insurance company that is doing an upgrade from its old system to a more modern core system. It is a project of great size and complexity, whereas to carry out software testing activities it involves a lot of effort, both in the creation and execution of several test cases.
The work done for this thesis was the development of automated functional testing to test a web-based web application belonging to the core system. The application supports and manages core insurance processes across the value chain, from planning of marketing activities, creating quotations to the entire life cycle of a policy, commissions, insurance claims, including integration to external service providers, adjustment losses, reinsurance and management information.
Accordingly, concepts of test automation were explored and that knowledge was used to develop automated testing with a new proposal/framework, allowing code reuse of test scripts for the development of new tests and creating new test cases to be performed.
Through the development of automated testing was possible to see what impact test automation can bring in complex and dynamic projects, also being important to define an appropriate framework for automating functional tests. It was clear that the test automation allows assist manual testing activities of software and reduces the effort required for the execution of test cases.
VII
Agradecimentos
A realização desta dissertação foi uma etapa marcante na minha vida, cuja realização só foi possível devido a importantes apoios e incentivos sem os quais não se teria tornado uma realidade e aos quais estarei eternamente grato.
À Universidade de Trás-os-Montes e Alto Douro que me acolheu e foi determinante para a minha formação, proporcionando-me oportunidades que me posicionam onde me encontro neste momento.
Ao Professor Paulo Nogueira Martins, pela sua orientação, disponibilidade, opiniões, críticas e total colaboração em horários inoportunos que permitiram solucionar algumas dúvidas e problemas que foram surgindo ao longo da realização deste trabalho e por todas as suas palavras de incentivo e ânimo.
Ao Pedro Tavares Oliveira, pela sua atenção, disponibilidade e sugestões que contribuíram para o desenvolvimento deste trabalho.
Ao Rui Manuel Luis, pelas suas sugestões, motivação e ajuda prestada ao longo da realização deste trabalho.
À Maria del Rocio Estevez Lima, por todo o seu carinho, amor, paciência e compreensão que sempre me deu mais ânimo durante o desenvolvimento deste trabalho.
À Maria Henriqueta de Freixo Guedes Moura, minha avó, pois desempenhaste um papel importantíssimo em toda a minha vida e se não fosse a tua ajuda nunca chegaria a este patamar. Obrigado pelo cuidado, carinho e amor que me mantiveram com força e ânimo para continuar em frente.
A todos os colegas, amigos e restantes familiares que, direta ou indiretamente, contribuíram para o sucesso deste meu percurso, o meu obrigado!
Por fim, não por esquecimento mas sim por ser um agradecimento muito especial, tendo consciência que sozinho nada disto teria sido possível, dirijo um agradecimento à Ana Rosa da Costa Pinto, minha mãe, por toda a sua educação, carinho, amor e dedicação para me conseguir colocar nesta posição. Sem dúvida tu foste uma das minhas maiores motivações para querer chegar até aqui. Um muito obrigado por tudo que fizeste e continuas a fazer por mim. A ti dedico este trabalho!
IX
Índice
Resumo ... III Abstract ... V Agradecimentos ... VII Índice ... IX Índice de Figuras ... XIII Índice de Tabelas ... XV Siglas e Acrónimos ... XVII1. Introdução ... 1 1.1. Objetivos ... 2 1.2. Metodologia ... 2 1.3. Contributo ... 3 1.4. Organização da Dissertação ... 4 2. Revisão de Literatura ... 5
2.1. Projetos Complexos e Dinâmicos ... 5
2.1.1 Tamanho de Projeto ... 6 2.1.2 Dificuldade Técnica ... 7 2.1.3 Incerteza ... 7 2.1.4 Relações Pessoais ... 8 2.2. Teste de Software... 9 2.2.1 Objetivos e Definições ... 10 2.2.2 Limitações ... 12
2.3. Tipos de Teste de Software ... 13
2.4. Automação de Testes ... 16 2.4.1 Objetivos ... 16 2.4.2 Benefícios ... 18 2.4.3 Limitações ... 20 2.4.4 Frameworks ... 24 2.4.5 Boas Práticas ... 25
2.5. Ferramentas de Automação de Testes ... 27
2.5.1 Selenium ... 27
2.5.2 IBM Rational Functional Tester ... 29
X
3. Enquadramento dos Testes Automáticos no Desenvolvimento de um Sistema Informático 33
3.1. Necessidade da Utilização de Testes Automáticos ... 33
3.2. Setor de Negócio ... 34
3.3. Core System - Sistema Informático Aplicado ao Setor de Negócio ... 37
3.4. Critérios de Escolha da Ferramenta da Automação de Testes ... 41
3.5. Seleção da Ferramenta Utilizada ... 44
4. Desenvolvimento de Testes Automáticos ... 49
4.1. Metodologia Utilizada ... 49
4.1.1 Decision to Automate Test... 50
4.1.2 Test Tool Aquisition ... 51
4.1.3 Automated Testing Introduction Phase ... 51
4.1.4 Test Planning, Design, and Development ... 52
4.1.5 Execution and Management of Tests ... 52
4.1.6 Test Program Review and Assessment ... 53
4.2. Análise de Requisitos Técnicos ... 53
4.3. Onde a Automação é Aplicada e Tipo de Teste ... 55
4.4. Arquitetura e Framework ... 57
4.4.1 Descrição do Caso de Teste ... 58
4.4.2 Valores de Entrada Dinâmicos (Ficheiro Excel) ... 59
4.4.3 Scripts ... 60 4.4.4 Repositório de Objetos ... 61 4.4.5 Biblioteca de Funções ... 63 4.4.6 Repositório de Imagens ... 66 4.4.7 Cenários de Recuperação ... 68 4.4.8 Outros Ficheiros ... 69
4.5. Fluxo de Desenvolvimento do Teste Automático ... 70
4.5.1 Fase 1 – Analisar a Aplicação ... 72
4.5.2 Fase 2 – Preparar a Infraestrutura do Teste ... 72
4.5.3 Fase 3 – Adicionar Passos nas Ações ... 73
4.5.4 Fase 4 – Reforçar o Teste ... 73
4.5.5 Fase 5 – Executar o Teste e Debugging ... 74
4.5.6 Fase 6 – Análise de Resultados de Execução e Relatório de Defeitos ... 75
5. Considerações Finais e Trabalho Futuro ... 77
XI
Bibliografia ... 79
Anexos ... 83
Anexo A – Requisitos Mínimos e Recomendados do Sistema (UFT 12.50) ... 83
XIII
Índice de Figuras
Figura 1. Diagrama de Keviat com os quatro atributos de um caso de teste (Fewster &
Graham, 1999). ... 23
Figura 2. Tecnologias e sistemas operativos suportados pelo Selenium. ... 29
Figura 3. Algumas aplicações (azul), sistemas operativos (verde) e linguagens de programação suportados pela ferramenta de automação de testes da IBM. ... 30
Figura 4. Navegadores web, os sistemas operativos e tecnologias suportadas pela ferramenta HP UFT. ... 32
Figura 5. O que é segurável? ... 36
Figura 6. Processo de gestão de um sinistro pela empresa seguradora. ... 37
Figura 7. Processos e componentes do core system de seguros. ... 38
Figura 8. Arquitetura do core system de seguros. ... 39
Figura 9. Software HP UFT apresentando o fluxo de um teste automatizado. ... 45
Figura 10. Automated Testing Life-Cycle Methodology (ATLM) (Dustin, 1999). ... 50
Figura 11. Ambiente de trabalho. Computador de desenvolvimento de testes automáticos à direita e computador de execução de testes automáticos à esquerda. ... 54
Figura 12. Automação de testes funcionais na aplicação Oracle Forms na “Camada Cliente” do core system de seguros. ... 55
Figura 13. Componentes que constituem um teste automático. ... 58
Figura 14. Ficheiro Excel com dados referentes a um teste automático para criar uma apólice. ... 60
Figura 15. Tabela interna da ferramenta UFT com dados referentes ao ficheiro Excel da Figura 14. ... 60
Figura 16. Fluxo de ações de um teste automático e excerto de código associado ao script da ação “0. Login TIA”. ... 61
Figura 17. Propriedades e métodos de um objeto da aplicação (Oracle Text Field). ... 62
Figura 18. Pequena parte de um repositório de objetos de um teste automático. ... 62
Figura 19.Parte do script da biblioteca de funções criadas para os testes automáticos. ... 63
Figura 20. Palavras-chave destacada em azul, indicando o "Nome" e "Tipo" de Objeto (Campo de Texto). ... 64
XIV
Figura 22. Visualizador de resultados da ferramenta HP UFT apresentando os resltados ao
final da execução de um teste automático. ... 66
Figura 23. Função para capturar uma imagem da aplicação na ocorrência de um erro durante o teste automático. ... 67
Figura 24. Mensagem de erro na aplicação Oracle Forms do sistema. ... 67
Figura 25. Estrutura da pasta de um teste automático. ... 69
XV
Índice de Tabelas
Tabela 1. Características entre projetos tradicionais e complexos. Traduzido de (Shane et al,
2012). ... 6
Tabela 2. Medição do nível de incerteza desenvolvida por Eddie Obeng. Traduzido de (Obeng, 1994). ... 8
Tabela 3. Tipos de teste para core systems. ... 14
Tabela 4. Tabela para classificar e comparar ferramentas de automação de testes... 44
Tabela 5. Resultados do POC. ... 47
Tabela 6. Significado dos requisitos avaliados no POC. ... 48
Tabela 7. Exemplo de um caso de teste de regressão do core system para criar uma apólice de Frotas. ... 57
XVII
Siglas e Acrónimos
A ADF
Application Development Framework API
Application Programming Interface AQ
Advanced Queuing ATLM
Automated Test Life-Cycle Methodology AUT
Application Under Test C
CICS
Customer Information Control System F
FTP
File Transfer Protocol G
GUI
Graphial User Interface H
HP
Hewlett Packard J
JMS
Java Message Service M
MIPS
XVIII P PAM
Product Availability Matrix PL/SQL
Procedural Language/Structured Query Language POC
Proof Of Concept Q
QTP
Quick Test Professional S
SAP
Systems Applications and Products SI
System Integrations SOA
Service Oriented Architecture U
UFT
Unified Functional Testing UI
User Interface V
VBScript
Visual Basic Script W
WS-I
1 Empresas de software enfrentam cada vez mais desafios no que respeita a validação dos seus produtos. Estes desafios têm vindo a crescer e a tornaram-se cada vez mais complexos. Testar software tornou-se mais complexo e árduo devido ao amplo número de novas linguagens de programação, sistemas operativos, plataformas, hardware e tecnologias que vão evoluindo ao longo do tempo (Myers et al, 2014). O teste de software deve ser considerado uma tarefa muito importante e deve ser levada com muita seriedade, de modo a ser executado com efetividade e eficiência, podendo assim resultar no aumento da qualidade do software (Singh, 2012).
A maioria dos prazos estabelecidos para o desenvolvimento de software não são cumpridos e em algumas situações é necessário prolongar essas datas ou remover funcionalidades no seu desenvolvimento de modo a cumprir os prazos estabelecidos (Dustin
et al, 1999). Na consequência disso, é solicitado aos gestores de projetos e programadores
para desenvolverem os seus produtos em datas cada vez mais apertadas e com recursos mínimos. Na tentativa de fazer mais com menos, as empresas também necessitam de testar os seus produtos em desenvolvimento dentro de um curto período de tempo. Para alcançar esse objetivo, como também para auxiliar o teste manual, as empresas começaram a optar pelo auxílio recorrendo à automação de testes.
Tendo sido dada a oportunidade de utilizar uma ferramenta de automação de testes no projeto de uma empresa de consultoria, durante o estágio profissional, sendo um projeto complexo e dinâmico, de grandes dimensões, envolvendo várias equipas, tecnologias e sistemas, pretende-se com esta dissertação perceber o papel das ferramentas de automação de testes em projetos complexos e dinâmicos e qual a mais-valia que pode ser acrescentada com a execução de testes funcionais.
Para isso, desenvolveram-se vários testes automáticos com auxílio de uma ferramenta de automação de testes (HP Unified Functional Testing), propondo-se diferentes frameworks1 no contexto de automação de testes a serem utilizadas em projetos de desenvolvimento de
software.
1 No contexto de automação de testes, framework é um modelo conceptual que suporta ou fornece diretrizes para a criação ou expansão de scripts de teste para atingir a automação de teste, garantindo menor manutenção e fácil capacidade de expansão (Bhargava, 2013).
1. Introdução
2
1.1. Objetivos
O foco principal desta dissertação é o desenvolvimento de testes funcionais automáticos para um core system de seguros, sendo uma solução integrada para gestão de atividades seguradoras, nomeadamente clientes, agentes e outras entidades, apólices, sinistros, pagamentos e recebimentos, resseguro e co-seguro.
Neste contexto, pretende-se perceber o papel das ferramentas de automação e qual a sua mais-valia no desenvolvimento de projetos complexos e dinâmicos. Para tal foi necessário alcançar os objetivos parcelares mencionados a seguir:
Estabelecer critérios para escolher uma ferramenta de automação de testes; Perceber o desenho de frameworks que possibilitam o desenvolvimento de
testes automáticos;
Desenvolver testes automáticos para o core system de seguros.
1.2. Metodologia
Esta dissertação foi realizada em âmbito de estágio profissional numa empresa de consultoria e auditoria, onde se esteve envolvido num projeto que consiste em implementar um novo core system para um cliente pertencente à indústria de seguros. Com o propósito de suportar as atividades de teste do sistema, uma das propostas apresentadas consiste na utilização de testes automáticos. Todo o estudo e desenvolvimento da presente dissertação apoia-se no conhecimento adquirido e nas atividades exercidas no decorrer do projeto e com foco na automação de testes.
Para a realização desta dissertação foi necessário, numa primeira fase, adquirir conhecimento teórico sobre software testing e sobre as funções exercidas por um software
tester. Nesse sentido, fez-se pesquisas sobre trabalhos e bibliografias relacionados com teste
de software e complementaram-se as pesquisas com formações online, disponibilizadas pela empresa onde o estágio foi realizado, cujos temas estavam relacionados com as atividades de teste de software em grandes projetos. De forma a adquirir um conhecimento mais prático sobre os mesmos tópicos, também se escreveram e executaram testes sobre o sistema em desenvolvimento pela empresa (Anexo B). Desta forma foi possível recolher informações e vários conceitos sobre os tópicos mencionados, permitindo assim a concretização de um
3 estado de arte mais crítico, baseando-se em fundamentos de vários autores e também na experiência adquirida durante o estágio profissional.
Após a aquisição de algumas bases sobre os tópicos mencionados anteriormente, a próxima fase consistiu em adquirir conhecimento direcionado para a automação de testes, ao qual foi útil não só para complementar o estado de arte, mas principalmente para o desenvolvimento prático desta dissertação. Numa primeira parte e após a realização de uma prova de conceito efetuada pela empresa de consultoria que envolveu três ferramentas de automação de testes, obteve-se formação prática na ferramenta de automação de testes escolhida pela empresa, uma vez que se adaptava às necessidades do projeto e devido ao potencial da ferramenta. A formação foi fornecida pelo próprio fabricante da ferramenta, Hewlett Packard (HP), tendo todo o conteúdo disponibilizado durante a formação, desde manuais, vídeos e scripts, servido de suporte para a automação de testes do projeto. Em seguida, de forma a complementar a formação e trazer mais qualidade para o trabalho, realizaram-se pesquisas sobre as diferentes metodologias no desenvolvimento de testes automáticos, analisando-se de forma crítica os benefícios e as limitações na utilização de cada uma delas.
Por fim, a última fase consistiu no desenvolvimento dos testes automáticos utilizando algumas das metodologias mencionadas e na compreensão de todo o processo envolvido na automação de testes em projetos complexos e dinâmicos. Posteriormente, foram retiradas as conclusões na realização dos testes automáticos para cada uma das metodologias, bem como o impacto que a ferramenta de automação pôde causar no projeto.
1.3. Contributo
Esta dissertação divulga conteúdo que pode vir a auxiliar qualquer projeto de desenvolvimento de software que inclua a automação de testes como reforço à fase de teste do
software.
Contudo, o principal contributo desta dissertação está na apresentação de uma
framework para se utilizar na automação de testes funcionais, definindo a importância da sua
1. Introdução
4
1.4. Organização da Dissertação
No primeiro capítulo fez-se uma introdução ao trabalho realizado e mencionaram-se os motivos, os objetivos do trabalho e o contributo desta dissertação.
No segundo capítulo efetuou-se uma revisão de literatura, procurando compreender diferentes conceitos e fundamentos utilizados nas atividades de teste de software em projetos complexos e dinâmicos. Menciona-se qual o propósito da automação de testes e indica-se os seus benefícios, limitações e boas práticas. Posteriormente definem-se as frameworks e apresentam-se algumas ferramentas de automação de testes funcionais.
No terceiro capítulo faz-se o enquadramento dos testes automáticos no desenvolvimento de um sistema informático. Em primeiro lugar menciona-se o problema e o motivo que levou à realização deste trabalho, mencionando-se a automação de testes como forma de mitigar o problema. Em seguida, apresenta-se alguns conceitos básicos da indústria em que o sistema se insere e qual o propósito desse sistema, apresentando-se também uma visão global da sua arquitetura. Finalmente indica-se como se escolheu a ferramenta de automação de testes e quais os critérios de escolha que foram utilizados para a escolha de uma ferramenta de automação de testes.
No quarto capítulo explica-se as fases da metodologia utilizada na automação de testes, isto é, as fases que dividem o progresso de todo o trabalho desta dissertação, desde o planeamento à execução da automação de testes. Em seguida faz-se o levantamento dos requisitos técnicos necessários para o desenvolvimento dos testes automáticos, mencionando onde a automação foi aplicada e quais os tipos de teste automatizados. Finalmente, apresenta-se os componentes e a arquitetura dos testes automáticos que apresenta-serviram de baapresenta-se à proposta para a framework a ser utilizada no desenvolvimento dos testes automáticos.
No quinto e último capítulo são apresentadas as conclusões retiradas deste trabalho, assim como são apresentadas algumas propostas de trabalho futuro, de forma a contribuir com uma reflexão válida sobre o custo de esforço necessário para desenvolver testes automáticos.
5 Tendo em conta que o âmbito desta dissertação está focado em perceber o papel das ferramentas de automação de testes funcionais em projetos complexos e dinâmicos, para a realização deste trabalho foi necessário compreender diferentes conceitos e fundamentos utilizados nas atividades de teste de software em projetos complexos e dinâmicos.
Neste capítulo é exposta uma visão geral sobre esses conceitos e atividades, onde se define o que são projetos complexos e dinâmicos e como se pode medir essa complexidade. Em seguida apresenta-se os motivos que levam à necessidade de testar software, indicando também quais os objetivos e limitações em testar software. Após a breve introdução do tema testar software, entramos no paradigma da automação de testes que visa auxiliar as atividades relacionadas com o teste de software, mencionando quais os objetivos, benefícios, limitações,
frameworks e boas práticas. Por fim, são apresentadas algumas ferramentas de automação de
testes funcionais, dos principais fornecedores, que permitem o desenvolvimento de testes funcionais automáticos.
2.1. Projetos Complexos e Dinâmicos
Todos os projetos são temporários e empreendidos para criar um produto, serviço ou resultado que é único (Project Management Institute, 2008). Tal como um jogo de xadrez, a complexidade de um projeto é dinâmica, onde as partes de um sistema podem reagir ou interagir umas com as outras em diferentes formas (Shane et al, 2012). A Tabela 1 apresenta muito resumidamente as características entre projetos complexos e projetos tradicionais.
Do ponto de vista da teoria da complexidade (Mosaic, 2011), todos os projetos são complexos. As equipas do projeto necessitam de trabalhar em conjunto para entregar o produto e no seu processo de desenvolvimento têm que lidar com desafios e tensões relacionadas com o projeto e com as partes interessadas externas ao projeto. As ações e influências dessas partes interessadas causam uma necessidade para as equipas do projeto se adaptarem ao ambiente e se empenharem proativamente em conjunto com essas partes interessadas de modo a entregar resultados de sucesso (Weaver, 2007).
2. Revisão de Literatura
6
Tabela 1. Características entre projetos tradicionais e complexos. Traduzido de (Shane et al, 2012). Cada projeto tem o seu grau de complexidade, da mesma forma que tem um tamanho definido, um grau de dificuldade técnica e um grau de incerteza. Todas essas quatro dimensões interagem e umas afetam as outras. As quatro dimensões básicas de todos os projetos são (Mosaic, n.d.a):
O seu tamanho próprio, geralmente medido em termos de valor financeiro; O grau de dificuldade técnica na criação de resultados, devido às características
do trabalho do projeto e dos entregáveis; O grau de incerteza envolvido no projeto;
A complexidade das relações, tanto dentro das equipas do projeto como ao redor do projeto.
2.1.1 Tamanho de Projeto
O tamanho do projeto terá um impacto sobre o grau de dificuldade na realização dos objetivos, contudo, projetos grandes não são necessariamente complicados ou complexos (Mosaic, n.d.a). A medição do tamanho de um projeto pode ser feita determinando várias e diferentes métricas, dependendo do tipo de projeto (produto, software, serviço. etc.).
Efetuaram-se pesquisas sobre como medir o tamanho de um projeto, encontrando-se uma infinidade de diferentes opiniões entre autores, entrando quase num beco sem saída. As características que podem ajudar na medição do tamanho de um projeto variam entre o custo de desenvolvimento, o número de pessoas ou equipas envolvidas, o número das partes
Projetos Tradicionais Projetos Complexos
Práticas que podem ser utilizadas: o Projeto
o Financiamento o Contratação Interações estáticas
Alto nível de similaridade com projetos anteriores gera segurança
Práticas que não podem ser utilizadas:
o Projeto
o Financiamento o Contratação Interações dinâmicas
Alto nível de incerteza a respeito dos objetivos e/ou implementações
7 interessadas, o esforço interno e externo para alcançar o sucesso do projeto, a duração, os prazos estabelecidos, o domínio da experiência, o número de tecnologias envolvidas, a quantidade dos objetivos definidos, as dependências e a complexidade por si só, entre outros.
2.1.2 Dificuldade Técnica
A dificuldade técnica associada a qualquer projeto é uma combinação do trabalho necessário para cumprir os objetivos do projeto e as características do produto a ser produzido (Mosaic, n.d.b).
Deveria ser óbvio que os projetos, envolvendo alta tecnologia, são inerentemente mais complicados do que projetos simples. A natureza das dificuldades técnicas e do grau de segurança dependem de quão o trabalho é bem entendido. O grau de compreensão das características do projeto e da forma como vai ser realizado é tão importante para o sucesso do projeto como o conhecimento das equipas do projeto. Quanto mais baixos forem os níveis de conhecimento, mais difícil se torna alcançar um resultado bem-sucedido para o projeto, bem como oferecer os benefícios esperados para o cliente (Mosaic, n.d.a).
2.1.3 Incerteza
O grau de incerteza tem um grande impacto sobre a gestão do projeto (Mosaic, n.d.a). Quanto menor forem as certezas do cliente em relação aos requisitos do projeto de modo a desenvolver uma compreensão clara do que é necessário para alcançar resultados de sucesso, maior será a incerteza associada à entrega do projeto com sucesso e maior será o esforço exigido das equipas envolvidas no projeto para trabalhar com o cliente.
Poderão ocorrer problemas se as expetativas em torno do projeto são expressas em termos de realização de uma entrega “na hora certa, com o orçamento desejado”, quando os resultados não são definidos e os benefícios não são claros (Bourne, 2007). A gestão desta incerteza está associada com a complexidade e influência das relações mencionadas na Tabela 2.
2. Revisão de Literatura
8
Obscuro Semi-Aberto Aberto
O
que f
az
er
As partes interessadas estão muito seguras sobre como o projeto deve ser feito.
As partes interessadas estão inseguras sobre o que deve ser feito.
As partes interessadas estão inseguras sobre o que deve ser feito.
As partes interessadas estão inseguras sobre como o projeto deve ser feito. A organização é clara sobre o método a
ser utilizado e tem o conhecimento especializado.
A organização está a tentar fazer algo que não foi feito anteriormente. A organização necessita de dispensar
tempo para definir “o que fazer”.
A organização necessita de dispensar tempo para definir “o que fazer” e “como fazer”.
Fechado Semi-Fechado
As partes interessadas estão seguras sobre o que deve ser feito.
As partes interessadas estão seguras sobre o que deve ser feito.
As partes interessadas estão muito seguras sobre como o projeto deve ser feito.
As partes interessadas estão inseguras sobre como o projeto deve ser feito. A organização está a seguir um projeto
repetitivo e sabe que aptidões necessitam.
A organização necessita de dispensar tempo para definir “o que fazer”. Procedimentos escritos, métodos e
sistemas estão disponíveis para replicar o que foi feito no passado.
Claro Como fazer Obscuro
Tabela 2. Medição do nível de incerteza desenvolvida por Eddie Obeng. Traduzido de (Obeng, 1994).
2.1.4 Relações Pessoais
Este aspeto do projeto é imprevisível e centra-se na eficácia das relações dentro das equipas do projeto e com a comunidade externa das partes interessadas.
A teoria da complexidade (Mosaic, 2011) tornou-se uma ampla plataforma para a investigação de situações interdisciplinares complexas, ajudando a entender os comportamentos sociais das pessoas e das equipas envolvidas em torno de um projeto. Essas ideias aplicam-se tanto a projetos grandes, como a projetos pequenos.
A gestão eficaz das partes interessadas é a chave para obter o empenho necessário para efetivamente entregar o projeto tanto em formato interno, dentro da equipa, como também às partes interessadas (Mosaic, n.d.c).
9
2.2. Teste de Software
Como será visto ao longo desta dissertação, “testar” é o processo de descobrir erros (Kaner et al, 1999) e é um aspeto importante no ciclo de vida do desenvolvimento de software (Singh, 2012). Sensivelmente pouco tempo depois de os computadores pessoais surgirem, cerca de cinquenta por cento do tempo de desenvolvimento e mais do que cinquenta por cento do custo total no desenvolvimento de software, eram despendidos nas atividades de teste de
software (Myers, 1979). Atualmente, esses mesmos valores ainda são válidos. Seria esperado
que o processo de testar software fosse aperfeiçoado para uma ciência exata, mas ainda se está longe disso (Myers et al, 2012).
Desde o primeiro programa até à mais recente aplicação, o software nunca foi perfeito (Whittker, 2009). Um dos maiores problemas da indústria de software é a inevitabilidade de desenvolver software sem erros. As empresas estão regularmente a obter relatórios de falhas nos seus produtos e este número aumenta a cada dia (Singh, 2012). Perante um software cujo funcionamento não está de acordo com o que foi especificado, seja devido à existência de um erro ou à falha na sua implementação, o seu utilizador adquire um nível de insatisfação bastante considerável. Este mesmo desagrado também é partilhado por todos os intervenientes no processo de desenvolvimento de software (Whittker, 2009). Por princípio, pode-se afirmar que uma empresa que desenvolve e vende software considera inadmissível uma situação em que os seus produtos apresentam, constantemente, erros e não respondem às necessidades que se tentam suprimir. Um software deve ser previsível e consistente, sem apresentar surpresas para os utilizadores.
De modo a reduzir o número de falhas, as empresas que desenvolvem software testam os seus produtos (Whittker, 2009), simulando a sua utilização numa perspetiva de utilizador e de forma a identificar, à partida, os problemas que possam existir. Assim encontrados, os problemas poderão ser corrigidos de modo a garantir uma maior qualidade do software.
O procedimento modelar para testar um software pode ser resumido à execução das funcionalidades do mesmo, com determinados valores de entrada (inputs) e observando-se os resultados obtidos (outputs) conformemente. Esses resultados obtidos são posteriormente comparados com os resultados esperados e, se for detetada uma similaridade entre ambos, pode-se afirmar que a funcionalidade do software está correta segundo as suas especificações. No entanto, um bom teste conduz a mais do que apenas executar um programa com valores de
2. Revisão de Literatura
10
entrada desejados (Singh, 2012).
Seguindo alguns princípios o teste de software pode tornar-se mais efetivo e assegura que os objetivos são cumpridos, apesar de existirem certas limitações. Testar software é importante para garantir a qualidade do mesmo e as atividades envolvidas necessitam de ser bem planeadas, tendo em conta os seus objetivos, princípios e limitações que são mencionados a seguir.
2.2.1 Objetivos e Definições
Compreender a verdadeira definição e objetivo de testar software, pode trazer uma enorme diferença no sucesso dos esforços utilizados para essa atividade. Os humanos tendem a ser extremamente orientados a objetivos, e ao estabelecerem um objetivo estão a provocar um efeito psicológico sobre eles. Se o objetivo de um profissional que executa testes é demonstrar que um software não tem erros, inconscientemente, ele estará orientado a esse resultado através da escolha de dados que têm uma baixa probabilidade de causar uma falha no software. Em contrapartida, se o objetivo é demonstrar que o software tem erros, ele poderá escolher dados que têm uma maior probabilidade de encontrar erros. Geralmente, casos de teste que têm dados com uma maior probabilidade de encontrar erros são considerados bons testes. Em contrapartida, casos de testes que utilizam dados com baixa probabilidade de causar falhas no software são considerados fracos casos de teste (Myers et
al, 2012).
Existem várias definições para testar software (Singh, 2012), sendo algumas delas mencionadas a seguir:
Testar é o processo de demonstrar que erros não estão presentes;
Testar é demonstrar que um programa executa as funcionalidades pretendidas corretamente;
Testar é o processo de estabelecer confiança de que o programa faz o que é suposto fazer.
A razão das três definições é semelhante. Elas apontam que um software deve comportar-se conforme as suas especificações. Contudo estas definições estão invertidas. Quando se testa software pretende-se adicionar valor. Isso significa elevar a qualidade e
11 confiança do programa, que por sua vez implica encontrar e remover erros. Não se deve testar para mostrar que o software funciona, mas, preferencialmente, começar com a suposição de que existem erros e, desse modo, deve-se testar com o objetivo de encontrar o máximo de erros possível.
A correta definição para testar software é o processo de executar um programa com o propósito de encontrar erros (Myers et al, 2012). Num livro sobre a filosofia da ciência, Karl Popper (1965) argumenta que o procedimento correto para testar uma teoria científica não é tentar verificá-la, mas procurar contradizer a teoria, ou seja, provar que tem falhas. Este raciocínio de Popper também pode ser aplicado diretamente no contexto de teste de software (Kaner et al, 1999).
O problema das definições comuns mencionadas nos pontos anteriores, é que mesmo assim podem ainda existir erros no software. Os erros são claramente visíveis quando um programa não faz o que é suposto fazer. Mas, igualmente se pode afirmar que há erros quando um programa faz o que não era suposto fazer. Para testar ambas as situações, são utilizados casos de teste designados por “Testes Positivos”, ou seja, através do input de dados válidos verifica-se se o software se comporta conforme a sua especificação. Juntamente podem ser utilizados casos de teste designados por “Testes Negativos”, que através do input de dados inválidos se averigua se o software não faz nada que não era suposto fazer.
Outra forma de reforçar a definição apropriada para teste de software é analisar o uso e sentido das palavras “com sucesso” e “sem sucesso” num contexto particular em classificação dos resultados de um teste. A maioria dos gestores de projeto referem-se a um caso de teste que não encontra erros, como um caso de teste executado com sucesso. Por sua vez, um caso de teste que falha, devido à ocorrência de erros no software, referem-se a um caso de teste sem sucesso. De acordo com a anterior definição e objetivo para testar software (Myers et al, 2012), essa forma de classificar o resultado de um teste está igualmente confundida.
Um “teste sem sucesso” denota algo indesejável ou desapontante, mas, uma vez que o objetivo é precisamente encontrar erros para serem corrigidos, um caso de teste que encontra erros deve ser considerado um sucesso. Dificilmente um teste que encontra erros poderá ser considerado como um teste sem sucesso uma vez que provou o seu valioso investimento. Mais facilmente se pode chamar a um teste sem sucesso, àquele que não verifica
2. Revisão de Literatura
12
adequadamente o software ou não encontra erros, uma vez que a ideia de que um programa não tem erros é surreal (Myers et al, 2012).
Myers considera a analogia de uma pessoa que visita o médico de saúde devido a sentir-se com sintomas de uma doença. Se o médico efetuar exames ao paciente e esses exames não localizarem o problema, não se pode afirmar que os exames foram um sucesso. Os exames foram um insucesso, pois não só o paciente contínua sem saber qual o seu problema, como ainda teve despesas financeiras com a consulta e pode questionar as capacidades do médico. Contudo, em medicina os termos são bem aplicados no seu sentido apropriado. Quando os exames médicos indicam que o paciente tem uma determinada doença, os exames são considerados positivos, ou com sucesso, porque o médico já sabe qual é o problema e como poderá aplicar o tratamento adequado (Myers et al, 2012).
É importante manter a visão de que o processo para testar software serve para encontrar erros e não para provar que eles não existem. Testar software é um processo, ou série de processos, designados para garantir que o código faz o que foi programado para fazer e, reciprocamente, não faz nada não intencional (Myers, 1979). O próximo tema apresenta as limitações para testar software, evidenciando também os motivos que justificam que as definições como “testar é o processo de demonstrar que não existem erros” estão erradas.
2.2.2 Limitações
As empresas tencionam testar tudo antes de entregar o software ao cliente. Mas esse “tudo” é bastante ilusivo e pode referir-se a um dos vários pontos (Singh, 2012) mencionados a seguir:
Executar todas as ações do programa;
Executar todas as condições verdadeiras e falsas; Executar todas as condições de decisão;
Executar todos os caminhos possíveis; Executar com todo o input de dados válidos; Executar com todo o input de dados inválidos.
É impraticável alcançar todos estes pontos, ou até mesmo um único ponto, devido às limitações do tempo e recursos disponíveis nas várias fases dos projetos. Apesar das boas
13 intenções e do esforço, é impossível testar completamente um software (Kaner et al, 1999). Isso significaria que, após a execução de todos os testes, nenhum erro novo seria descoberto, ou seja, todos os problemas e falhas eram conhecidos e entendidos. Se foram ou não corrigidos é outra questão.
Assim sendo, testar não permite garantir que um software funciona corretamente em todas as condições, mas apenas garante que o software não funciona para uma determinada condição. Como as atividades de teste são utilizadas para encontrar erros e não para demonstrar que eles não existem, não se consegue garantir que o sistema a ser testado está livre de erros. Hoje em dia é necessário desenvolver software (programas ou aplicações) para
desktop, web, smartphones, tablets, diferentes sistemas operativos, etc. A sua
interoperabilidade e compatibilidade com os vários equipamentos e vários sistemas operativos torna difícil assegurar a estabilidade do produto para todos os ambientes (Dalal & Chhillar, 2012).
Os testes não aprovam que um software está habilitado funcionalmente para entrar em produção (Quadri & Shiekh, 2010) e uma das maiores limitações em testar software está representada pela afirmação de que testar apenas demonstra a presença de falhas e não a ausência delas (Ammann & Offutt, 2008).
2.3. Tipos de Teste de Software
Cada tipo de teste pode ter um objetivo particular como, por exemplo, testar uma determinada função do sistema ou de um componente do sistema, testar uma característica não funcional como a confiabilidade, testar a estrutura ou arquitetura de um componente do sistema ou testar eventuais alterações efetuadas no sistema, de modo a confirmar se os defeitos foram corrigidos ou procurar por alterações não intencionadas.
Dependendo dos objetivos, os testes podem ser organizados por diferentes tipos. Segundo (Jorgensen, 2013), os testes podem ser identificados em duas categorias sendo elas: testes funcionais, conhecidos por black-box2, e testes estruturais, conhecidos por white-box3.
2 É um método de teste de software que analisa a funcionalidade de uma aplicação sem investigar as suas estruturas internas. Obtido em: https://en.wikipedia.org/wiki/Black-box_testing. Acedido em Agosto de 2015. 3 É um método de teste de software que tem uma perspetiva de testar internamente o sistema ou o seu funcionamento, em oposição à sua funcionalidade. Obtido em: https://en.wikipedia.org/wiki/White-box_testing. Acedido em Agosto de 2015.
2. Revisão de Literatura
14
Os tipos de teste que podem ser efetuados em sistemas centrais partilham definições muito comuns. As normas para gestão de testes geralmente mencionam apenas dois tipos de testes, sendo eles do tipo funcional e não-funcional. Os testes do tipo funcional focam-se em testar como a solução se combina com os processos de negócio. Os testes do tipo não-funcional focam-se em testes realizados em background. Para perceber melhor esses conceitos é apresentado na Tabela 3 os testes que se enquadram nesses dois tipos, sendo definido em seguida cada um deles.
F un cio na l Configuration Unit Test
String/System Testing Integration Testing Regression Testing User-Acceptance Testing Code Unit Testing Nã o -F un cio na l Security Unit Testing Environment/Infrastructure Testing Data Conversion Testing Security Testing (SI only) Performance & Stress Testing
Tabela 3. Tipos de teste para core systems.
Configuration Unit Test - Consiste em componentes, ou transações, individuais do sistema que são testados para assegurar que cumprem as configurações do projeto. Code Unit Testing - Divide-se em dois tipos. Primeiro, o teste ao objeto funcional,
onde os objetos individuais de desenvolvimento estão ligados entre si e testados para garantir que cumpram a especificação funcional. Segundo, o teste de unidade técnica, onde os objetos de desenvolvimento individuais são testados para garantir que cumprem as especificações técnicas.
String/System Testing - É conduzido ao nível do subprocesso, para assegurar que as tarefas de processos e operações do subprocesso interagem corretamente. Este é tipicamente um teste exaustivo, incidindo sobre as funções do sistema dentro do contexto de um processo de negócio.
Integration Testing - É um teste executado desde uma extremidade a outra
(end-to-end) de forma a assegurar que todos os componentes da solução estão integrados. É
um teste representativo, com foco em processos de negócios e em variantes de chave desses processos, necessário para apoiar as operações de negócios. O teste de
15 integração para System Integrations (SI) é uma fase em teste de software onde os testes individuais são combinados e testados como um grupo. Isso ocorre antes do System Testing e aplica-se a testes definidos em um plano de teste de integração para esses sistemas. O sistema integrado é fornecido como saída.
Regression Testing - É o processo de executar um novo teste de produção ou não-produção de componentes que podem ter sido impactados por alterações posteriores ou alterações subsequentes.
User-Acceptance Testing - É uma fase em que os utilizadores verificam se o negócio está pronto para passar para a nova solução. Centra-se no local, na disponibilidade do utilizador e na validação da correção de transição.
Security Unit Testing - Envolve testes de funções de negócios individuais para assegurar que cumpram a arquitetura das funções de negócio.
Environment/Infrastructure Testing - Garantem que o hardware e o software do sistema estão prontos para a produção.
Data Conversion Testing - É um teste de software utilizado para converter dados de sistemas legados4 para uso em novas implementações de sistemas.
Security Testing (SI only) - É o processo de realização de um ataque conhecido e de identificação de cenários obtidos no modelo de ameaça, no sentido de verificar que as contramedidas aplicáveis foram executadas como previsto, bem como a realização de testes de penetração para simular os potenciais comportamentos de um atacante externo.
Performance & Stress Testing - É utilizado para determinar a velocidade ou a eficácia de uma computação, rede, software ou dispositivo. Este processo pode envolver testes quantitativos feitos em um laboratório, como medir o tempo de resposta ou o número de MIPS (milhões de instruções por segundo) envolvidos em determinadas funcionalidades do sistema. Atributos qualitativos, tais como confiabilidade, escalabilidade e interoperabilidade, também podem ser avaliados. O Performance Testing é muitas vezes feito em conjunto com o Stress Testing.
4 Termo utilizado em referência aos sistemas computacionais bastante antigos, mas que continuam a fornecer serviços essenciais e utilizam bancos de objetos obsoletos. Obtido em:
2. Revisão de Literatura
16
2.4. Automação de Testes
As atividades de teste e o seu planeamento devem começar cedo num projeto. Os engenheiros de teste devem ser incluídos durante a análise de negócio e nos requisitos do sistema de modo a preparar efetivamente a técnica dos testes e os casos de teste a executar, prevenindo ou antecipando possíveis erros de arquitetura. A preparação dos testes é um ponto extremamente importante para a utilização das ferramentas de automação, uma vez que previne que as possíveis falhas no design dos testes sejam refletidos para o código dos testes automáticos (Dustin, 1999).
A automação de testes constitui um componente importante para testar aplicações de grande escala e deve ser equiparado em termos de disciplina e objetividade ao desenvolvimento de software, isto é, a automação de testes reincide algures entre testar e desenvolver (Amaricai & Constantinescu, 2014). Isso significa que automatizar testes reúne os conceitos de testar como também os de programar.
Nesta secção são apresentados os objetivos, alguns benefícios e limitações que se podem obter com a utilização de testes automáticos, bem como algumas boas práticas no desenvolvimento de automação de testes.
2.4.1 Objetivos
Quando se pensa em automação de testes pode-se começar por levantar questões de “como” se começa a automação de testes, “o que” se deve automatizar, bem como “qual” ou “quais” as ferramentas adequadas para a automação de testes tendo em conta as necessidades do projeto. São questões geralmente levantadas pelas equipas de gestão do projeto em que se pretende iniciar atividades na automação de testes, no entanto, em primeiro lugar é importante saber quais são os objetivos que se pretende alcançar com a automação de testes (Kiranpaul, n.d.). Assim que se souberem esses objetivos, será possível responder melhor às questões levantadas anteriormente.
A compreensão dos objetivos para a automação de testes é muito importante, uma vez que a automação custa tempo e dinheiro, mesmo quando se utilizam ferramentas gratuitas. Devem ser definidas expetativas, caso contrário, se as expetativas forem surreais a automação de testes pode fracassar. Todos os elementos envolvidos na automação de testes, seja os
17 programadores ou testadores, como também todas as partes interessadas na automação de testes, devem saber o que é esperado e, mais importante ainda, o que pretendem alcançar com a automação de testes (Graham & Fewster, 2009). As ideias devem ser claras para todos, assim como o porquê de o processo de automação ter sido envolvido. Deve existir uma justificação do porquê ser necessário a automação de testes e, uma vez que existe um grande investimento a nível financeiro, devem existir objetivos específicos e claros. Esses pontos são cruciais para que a automação de testes tenha sucesso e siga um bom caminho.
O propósito do desenvolvimento de testes automáticos é idêntico aos objetivos mencionados na secção “Teste de Software”. Todavia, existem distinções entre os testes manuais e testes automáticos, que torna possível separar o teste de software em duas realidades diferentes, definindo assim diferentes finalidades para a automação de testes (Graham & Fewster, 2009). A automação de testes tem como princípio aumentar a eficiência no teste de software, pelos aspetos chave de redução dos custos em teste de software, redução do tempo dispensado durante a fase de testes, melhoria da cobertura dos testes e repetição dos testes (Trellis, 2007).
Os objetivos gerais da automação de testes são derivados por objetivos organizacionais, de domínios, de negócio e assim por diante. A lista de objetivos pode variar de empresa para empresa e pode ter algumas dependências ou limitações mencionadas mais adiante neste capítulo. Alguns desses objetivos são mencionados a seguir (Bhargava, 2013):
Aumentar capacidades de reutilização do teste; Melhorar a cobertura do teste;
Acelerar as atividades de teste para várias e frequentes software releases5; Garantir coerência no teste;
Melhorar a confiabilidade do teste; Escalabilidade.
Conforme foi mencionado, estes objetivos são genéricos ou abstratos. Num projeto que envolva automação de testes devem existir objetivos com determinadas características. Os objetivos devem ser mensuráveis para que se possa dizer se foram ou não alcançados. Os objetivos devem apoiar as atividades de teste, mas não devem ter os mesmos objetivos que o
5 No contexto de desenvolvimento de software, entende-se por software release uma versão final de uma determinada aplicação. Pode constituir um novo software ou uma atualização ao software existente. Obtido em:
2. Revisão de Literatura
18
teste de software. Devem ser realísticos e alcançáveis, caso contrário, sentir-se-á sempre uma sensação de fracasso ou que são gerados poucos resultados. É preferível alcançar objetivos de pequena escala, do que ter objetivos de grande escala e serem impossíveis de alcançar. Contudo, os objetivos devem ter um curto e longo prazo, sendo que os objetivos de curto prazo especificam o que se pretende alcançar no próximo mês ou semestre. Os objetivos de longo prazo focam-se onde se pretende estar daqui a um ano ou dois. À medida que se vai adquirindo experiência e conhecimento, os objetivos devem ser regularmente revistos (Graham & Fewster, 2009).
É importante referir e relembrar que a automação de testes serve para auxiliar e não para substituir o papel do software tester (Patton, 2005). Seria completamente errado executar apenas testes automáticos e deixar para trás os testes manuais. De facto, é muito mais comum a combinação de testes manuais com testes automáticos (Roebuck, 2012). A automação de testes deve servir de suporte às atividades de teste e não para substituir ou eliminar inteiramente essas atividades (Pettichord, 2001).
2.4.2 Benefícios
Os benefícios em utilizar testes automáticos estão relacionados com os objetivos da automação de testes mencionado anteriormente.
O aumento de capacidade de reutilização deve-se ao facto de ser possível executar os mesmos testes vezes sem conta, pretendendo-se reduzir o custo de esforço de testar manualmente. Em projetos dinâmicos certamente poderá existir a necessidade de realizar os mesmos testes mais que uma vez e os testes automáticos são uma boa opção para alcançar esse efeito.
A cobertura do teste pode ser maior nos testes automáticos em relação aos testes manuais, possibilitando o planeamento de testes mais extensos, isto é, que executem mais funcionalidades na aplicação a ser testada e que passem por mais pontos de validação, em apenas uma única execução do teste.
As atividades de teste de software podem ser aceleradas a cada software release, uma vez que se pode executar uma bateria de testes automáticos previamente desenvolvidos em
19 apenas algumas horas, enquanto manualmente poderia demorar dias. Isto só é válido dependendo da quantidade de testes a realizar e da quantidade de software testers disponíveis para testar.
A coerência pode ser obtida com os testes automáticos pois estes podem ser configurados para inserir valores com verdadeiro significado para o negócio ou ambiente em que a aplicação a ser testada se encaixa como, por exemplo, construção de apólice de seguro com valores próximos da realidade. Um software tester pode alcançar o mesmo efeito, mas devido à possibilidade de existência de uma lista enorme de testes a executar (mais de mil testes) e devido ao tempo ser restringido, os testes manuais podem conter valores não coerentes com o negócio ou a realidade em que a aplicação a ser testada se encaixa.
Os testes automáticos podem trazer mais confiabilidade em relação aos testes manuais, pois pode-se ter a certeza que serão sempre executados apenas as funcionalidades e valores que foram especificados durante o desenvolvimento dos testes automáticos. Nos testes manuais pode existir a dúvida se o software tester não cometeu falhas, como por exemplo a má inserção de valores, a não execução de determinadas funcionalidades, a validação incorreta dos testes, e por assim adiante.
Por fim, o que se pretende com a escalabilidade é que os testes automáticos possam ser reaproveitados com a inserção de novas funcionalidades, permitindo assim a sua manutenção e atualização de modo a ser executados em futuras releases do software.
Com a utilização de uma ferramenta de automação de testes, é possível gerir e executar as atividades do teste, através do desenvolvimento e execução de scripts, de modo a verificar os requisitos do teste (Dustin et al, 1999) e por sua vez do software. Os scripts contêm linhas de código que simulam uma ação do utilizador perante uma funcionalidade do
software e repetem essas ações múltiplas vezes com nenhuma, ou mínima, interação humana
(Bhargava, 2013).
As atividades de automação de testes providenciam um enorme valor quando são criados scripts para serem reutilizados ou funções para serem invocadas repetidamente nesses
scripts (Dustin et al, 1999). Os testes de regressão a nível de testes do sistema também
representam outro exemplo da utilização eficiente de automação de testes. Testes de regressão procuram verificar que as funções providenciadas por um software modificado continuam a
2. Revisão de Literatura
20
respeitar as especificações estabelecidas e que não existe nenhuma alteração não intencionada no software (Dustin et al, 1999).
Num estudo realizado a utilizadores de ferramentas de automação de testes (Fewster & Graham, 1999) foi questionado que benefícios as ferramentas de automação providenciaram. Os resultados indicam que 14% dos utilizadores consideraram que as ferramentas de automação não retornam qualquer tipo de benefício, 18% obtiveram pouco proveito, 41% obtiveram algum benefício e 27% obtiveram benefícios. Apesar de esse estudo ter sido realizado há vários anos atrás, atualmente acredita-se que os valores possam apresentar melhorias no que respeita à automação de testes, nomeadamente devido ao desenvolvimento de ferramentas mais capacitadas para a automação de testes.
2.4.3 Limitações
A perfeição é algo inalcançável ao ser humano e evidentemente todas as suas obras têm os seus limites, ou mais tarde ou mais cedo, irão falhar. A utilização de testes automáticos também tem os seus defeitos e suas limitações (Fewster & Graham, 1999). Um dos desafios na automação de testes é preservar a perspetiva de testar enquanto se desenvolve o teste automático, uma vez que é importante manter a independência entre testar versus desenvolver (Amaricai & Constantinescu, 2014).
Os próximos tópicos mencionam as fronteiras que a automação de testes não consegue atravessar:
Testes automáticos não substituem testes manuais
O primeiro ponto a considerar é que a automação de testes não substitui os testes manuais. Não é possível testar um software por completo. O mesmo se aplica para os testes automáticos, sendo que não é possível automatizar todos os casos de teste. Alguns gestores de projeto julgam que é necessário automatizar todos os casos de teste existentes, pois se assim não for, questionam-se qual é a utilidade e potencialidade das ferramentas de automação de testes se não se obtém o total proveito. Esse modo de pensar não é o correto e leva a conclusões precipitadas. Existem sempre testes mais fáceis de executar manualmente do que automaticamente, ou existem testes tão difíceis de automatizar que não fica economicamente favorável desenvolvê-los (Fewster & Graham, 1999).
21 Segundo (Fewster & Graham, 1999), alguns dos testes que não devem ser automatizados sujeitam-se a:
Testes que apenas são executados uma única vez ou raramente;
Quando o software é muito volátil, isto é, as funcionalidades mudam dependendo da versão. Neste caso específico é necessário tomar muita atenção à automação de testes, uma vez que o custo de alteração dos testes automáticos é bastante grande;
Testes onde o resultado é facilmente e rapidamente verificado por um humano;
Testes com grau de complexidade muito grande, senão mesmo impossíveis de automatizar;
Testes que envolvem uma interação física como: passar um cartão no leitor de cartões, desconectar/conectar algum equipamento, etc.
Testes automáticos encontram menos erros
Se um caso de teste vai ser automatizado, é preciso em primeiro lugar testar o caso de teste de modo a verificar que não tem erros. Não faz sentido automatizar um caso de teste com defeitos e que não verifica corretamente as validações do software.
Quando se começa a desenvolver um teste automático, um dos processos envolvidos na automação é gravar os passos do teste manualmente e com auxílio da ferramenta de automação de testes. Essa atividade é similar à execução de um teste manual. Se por acaso forem encontrados falhas ou erros, eles serão encontradas em primeiro lugar ao nível do teste manual. Por definição, todos os testes automáticos tiveram que antes ser executados pelo menos uma vez manualmente (Fewster & Graham, 1999).
Sendo assim, a probabilidade de encontrar erros no software com testes automáticos é cada vez menor, uma vez que já se fez uma primeira verificação manualmente. Mas, se o objetivo em testar software é encontrar erros, porque existe a necessidade de automatizar testes? Não é por acaso que os testes automáticos têm os seus objetivos específicos, reforçando também o tema abordado anteriormente, em que se menciona que os testes automáticos não substituem os testes manuais e portanto ambas as metodologias podem e devem existir em simultâneo.
2. Revisão de Literatura
22
Maior dependência na qualidade
Uma ferramenta de automação de testes consegue identificar os resultados obtidos com os resultados esperados através da comparação. É possível que a ferramenta afirme que não detetou erros num teste, uma vez que apenas comparou o resultado obtido com o resultado esperado previamente definido. Se o resultado esperado estiver definido erradamente, o resultado final do teste automático não é seguro e a qualidade do teste é questionada. Os testes automáticos podem, e devem, ser revistos e inspecionados para assegurar a sua qualidade. Pode existir também um esforço adicional nas atividades de automação de testes, para verificar corretamente o resultado esperado (Fewster & Graham, 1999).
Automação de testes não aumenta a eficácia
Ao contrário do que se poderia pensar, a automação de testes não é mais eficaz do que testar manualmente. A automação de testes poderá, eventualmente, aumentar a eficiência no sentido de quanto tempo eles demoram a ser executados e quanto custa para serem executados e desenvolvidos. Mas, se um teste automático não alcançar nada no final da sua execução, então é apenas um teste que alcançará nada mais rápido. Uma vez implementado, um teste automático geralmente é mais económico no sentido em que o custo de execução é menor do que um teste executado manualmente. Porém, um teste automático geralmente também custa mais para desenvolver e fazer manutenção (Fewster & Graham, 1999).
A Figura 1 apresenta um diagrama de Keviat com os quatro atributos de um caso de teste (económico, efetivo, evolutivo e exemplar). Um caso de teste executado manualmente representa as linhas sólidas. Um teste manual que seja automatizado pela primeira vez irá se tornar menos económico e evolutivo devido ao custo de esforço ter sido maior para a automação do respetivo teste. Todavia, assim que se começa a executar o teste automático um número de vezes, ele irá tornar-se mais económico em relação à sua execução manual.
23
Figura 1. Diagrama de Keviat com os quatro atributos de um caso de teste (Fewster & Graham, 1999).
As ferramentas não têm imaginação
Os testes automáticos são como um software e portanto apenas obedecem a instruções. O teste automático irá seguir essas instruções a cada execução de um caso de teste, mas uma pessoa, dados os mesmos conjuntos de instruções, pode efetuá-los de maneira diferente. Por exemplo, dado um caso de teste e o respetivo resultado esperado, quando essa pessoa for executar manualmente o caso de teste e verificar que o resultado obtido é igual ao resultado esperado, então pode concluir que o teste está correto. Mas, a pessoa também pode verificar que apesar de o resultado obtido ser igual ao resultado esperado, ambos poderão estar errados segundo as especificações do software. Um bom profissional a executar testes pode utilizar a sua imaginação e criatividade para adicionar valor aos testes executados, desviando-se do plano do caso de teste ou reparando em detalhes adicionais durante a execução do teste.
Outra situação em que os humanos são claramente superiores às ferramentas de automação é quando acontecem eventos inesperados e não fazem parte do plano do caso de teste. Por exemplo, se a conexão à Internet for abaixo, ou se aparecer uma mensagem do sistema operativo ou de outro comportamento anormal do sistema, o engenheiro de teste consegue contornar o problema e voltar ao ponto em que estava na execução do teste. Às vezes o engenheiro de teste poderá fazer isto inconscientemente, sem se aperceber que fugiu do plano do caso de teste.
Os scripts podem ser preparados para se desviar de eventuais problemas, e atualmente já existem ferramentas que ajudam nesse processo de uma forma baseada em eventos, mas tal como os astronautas descobriram, não existe nada como a ingenuidade do humano para
