Relatório de Estágio - bdigital.ipg.ptbdigital.ipg.pt/dspace/bitstream/10314/3734/1/Adriana Dias_1011858.pdf · t Tp daGuarda ESC() Ia S ti periei de Tecnologia e O estilo RELATÓRIO

t Tp daGuardaESC() Ia S ti pe ri eide Tecnologia e O estilo

RELATÓRIO DE ESTÁGIO

Curso Técnico Superior Profissional em

Testes de Software

Adriana Catarina Ferreira Dias

junho 12016

Gesp.010.03

Escola Superior de Tecnologia e Gestão Instituto Politécnico da Guarda

R E L A T Ó R I O D E E S T Á G I O

ADRIANA DIAS

RELATÓRIO PARA A OBTENÇÃO DO DIPLOMA DE TÉCNICO SUPERIOR PROFISSIONAL

EM TESTES DE SOFTWARE

Junho/2016

Escola Superior de Tecnologia e Gestão Instituto Politécnico da Guarda

RELATÓRIO DE ESTÁGIO

Adriana Catarina Ferreira Dias Nº1011858

RELATÓRIO PARA A OBTENÇÃO DO DIPLOMA DE TÉCNICO SUPERIOR PROFISSIONAL EM

TESTES DE SOFTWARE

Junho de 2016

Relatório de Estágio | Altran | Fidelidade Mundial

A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a ii

Ficha de Apresentação A luna do Cur so de Técn ico Super ior Prof iss ional (TeSP) de Te stes de Software Adriana Catarina Ferreira Dias | nº1011858 |Designer de Equipamento Inst itu ição Instituto Politécnico da Guarda (IPG) Escola Superior de Tecnologia e Gestão (ESTG) Morada: Av. Dr. Francisco Sá Carneiro nº50, 6300-559, Guarda. Tel.:+351271220100 e Fax: +351271222690 E-mail: [email protected] Orientador de Estágio Prof. Doutor José Fonseca | Coordenador do TeSP de Testes de Software do IPG Tutor Altran Félix Lopes | Gestor de Negócios dos Serviços Financeiros da Altran Chefe de Equipa da F ide l idade José Reis | Coordenador da Área de Testes e Formação do Departamento de Sistemas de Informação da Dire-ção de Gestão e Procura da Fidelidade Seguros Duração do Estágio De 01.03.2016 a 30.06.2016 (4 meses)

5 Palavras -chave Testes | Software | Qualidade |Certificação |Automação

Resumo O presente relatório descreve e ilustra o trabalho desen-

volvido durante o estágio curricular do TeSP em Testes de Software através da Altran, na Fidelidade. Neste âmbito fo-ram realizadas muitas atividades diversificadas, das quais se destacam os testes de software, (funcionais, exploratórios, regressivos e automáticos), a metodologia de gestão de ati-vidades de teste, o desenvolvimento de manuais de suporte aos utilizadores das várias ferramentas utilizadas durante a execução dos testes de software, o design gráfico de interfa-ces, e o apoio ao desenvolvimento da framework de um pro-grama de automação de testes.

mailto:[email protected]


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a iii

Índice

1 Introdução 1

1.1 Enquadramento 1 1.2 Objetivos 1 1.3 Planificação das Atividades – Gráfico de Gantt 3 1.4 Estrutura do Relatório 3

2. Apresentação das Empresas Intervenientes no Estágio 4

2.1 Apresentação da Altran 4 2.2 Apresentação da Fidelidade 5

3 Elaboração de Manuais 6

3.1 Ferramentas Usadas 6 3.2 Trabalho Desenvolvido 6

3.2.1 Apresentação AGITe 6 3.2.2 Manual do Utilizador FASTest 7

3.3 Conclusão 7

4 Metodologia de Gestão de Atividades 9

4.1 Ferramentas Usadas 9 4.2 Trabalho Desenvolvido 9

4.2.1 Restruturação do OneNote da equipa C.A.M.A. 9 4.2.2 Restruturação da metodologia de desenvolvimento do FASTest 14

4.3 Conclusão 14

5 Testes de Software 15

5.1 Ferramentas Usadas 15 5.2 Upgrade GIS Oferta Vida 15 5.3 Simulador Nova Oferta de Saúde 19 5.4 Upgrade do Outsystems 31 5.5 Conclusão 32

6 Testes de interface e regressão no FASTest 33

6.1 Ferramentas Usadas 33 6.2 Testes Regressivos 33 6.3 Automação de Testes 35 6.4 Design de Comunicação 40

6.4.1 O Logotipo 40 6.4.2 Imagética 42 6.4.3 Melhorias Ergonómicas da Framework 44

6.5 Conclusão 47

7 Conclusão Final 48 Bibliografia 49 8 Anexos 50

Anexo 1 – Organigrama da História da Fidelidade 50 Anexo 2 – Manual do FASTest 53


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a iv

Siglas e Abreviaturas

Sigla

Descrição

AC Acidentes Pessoais

AGITe Aplicação de Gestão Integrada de Testes

APP Administração Pública Portuguesa

AT Acidentes de Trabalho

ATF Área de Testes e Formação

BD Base de Dados

BV Business Value

CAMA Cristina Adriana Machado Alexandre

CGD Caixa Geral de Depósitos

CP Cliente Principal

CS Cliente Secundário

CQIB Controlo de Qualidade Império Bonança

CT Caso de Teste

DGPROC Direção de Gestão e Procura

DSI Direção dos Sistemas de Informação

EQC Equipa de Certificação

FA Fora de Âmbito

FM Fidelidade Mundial

FNM Ficheiro Nacional de Matrículas

GA Gestão de Alteração

GA Gestor de Atividade

GR Gestor de Relação

IB Império Bonança

MR Multirriscos

SE Sem Efeito

SI Sistema de Informação

PES Plataforma Estratégica de Seguros

PPR Plano Poupança Reforma

PS Pessoa Segura

PC Responsabilidade Civil

RES Restantes Equipas

RIT Reunião Inicial de Testes

TS Tomador de Seguro


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a v

Lista de Programas e Plataformas Informáticas

Programa | Plataforma | Canal

Funcionalidade da Ferramenta

Artefactos Plataforma de armazenamento dos requisitos

ADN Canal Império Bonança

Bonsai Questionário médico

CANAL CGD Canal da Caixa Geral de Depósitos

CISN Canal Fidelidade Seguros

Cogen 2.2 Back-end sinistros

CONTROL-D Repositório de outputs

Developer Tools Verificar código e fazer correções imediatas

GIMP Edição de imagens

GIS VIDA AS/400 iSeries Back-end dos produtos vida

Mantis Programa de gestão de incidências

Medinet Canal Fidelidade Mundial

Microsoft Office Excel Elaboração de tabelas de apoio aos testes

Microsoft Office OneNote Gestão de informação das evidências entre equipas

Microsoft Office Outlook E-mail de comunicação entre todos os membros da companhia

Microsoft Office PowerPoint Elaboração de manuais e apresentações

Microsoft Office Word Ferramenta de auxílio aos testes.

MyFidelidade Site da empresa Fidelidade Seguros

NAVE Emulador para aceder ao PostalNet2G

Intranet Fidelidade Motor de busca interno da companhia

OutSystems Programa de desenvolvimento de software

Paint Para printscreens de auxílio aos testes

PostalNet Canal dos CTT

TestLink Programa de gestão de testes


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a vi

Índice de Imagens Figura 1 Gráfico de Gantt que ilustra o início e o fim de cada tarefa

executada durante o estágio. 3 Figura 2 Lema da Altran 4 Figura 3 Organigrama do workflow do report de incidências

(Fidelidade, 2016) 6 Figura 4 Ficheiro da página do OneNote da equipa C.A.M.A. antes da

restruturação 10 Figura 5 Esquema da restruturação do OneNote do C.A.M.A 11 Figura 6 Matrizes das tabelas a aplicar na recolha das evidências

segundo o tipo de intervenção ATF. 11 Figura 7 Colocação de uma Flag no OneNote com alerta para a Agenda

do OutLook 12 Figura 8 Ilustração dos link que redirecionam para as páginas,

contendo a informação da atividade dedicada aos membros da equipa. A formatação é sempre a mesma para todas as atividades. 12

Figura 9 Página com o resumo das atividades a serem tratadas pela equipa. 13

Figura 10 Exemplo de uma página da atividade com a informação destinada aos membros da equipa depois da restruturação. 13

Figura 11 Exemplo da nova tipificação de incidências em curso no projeto FASTest 14

Figura 12 Interface do GIS 16 Figura 13 Casos de teste a executar após o Upgrade do GIS (TestLink) 16 Figura 14 Exemplo das coberturas dos planos da Oferta Vida. 17 Figura 15 Exemplos de erros devolvidos pelo GIS 17 Figura 16 Exemplo duma simulação no Seguro Vida particular ou PME

18 Figura 17 Estado da atividade no OneNote à data do relatório 19 Figura 18 Tabela auxiliar ao plano de testes após a sua execução. 19 Figura 19 Tabela dos pressupostos para os testes NOVA OFERTA

SAÚDE 20 Figura 20 Pressupostos para os casos de teste genéricos onde se

reportam todas as incidências excecionais (TestLink). 20 Figura 21 BL1 do simulador saúde 21 Figura 22 CT´s do BL1 do simulador saúde (TestLink) 21 Figura 23 BL2 do simulador saúde 22 Figura 24 CT´s do BL2 do simulador saúde (TestLink) 22 Figura 25 BL3 do simulador saúde (parte da tipificação do plano) 23 Figura 26 CT´s do BL3 do simulador saúde (TestLink) 24 Figura 27 BL3 do simulador saúde (parte da conversão em proposta) 24 Figura 28 CT´s do BL1 da proposta saúde (TestLink) 25 Figura 29 Pressupostos dos dados do tomador no BL1 da proposta 25 Figura 30 BL1 da proposta saúde 26 Figura 31 BL1 da proposta saúde com dados reais do tomador 27 Figura 32 CT´s do BL2 da proposta saúde (TestLink) 28 Figura 33 BL2 da proposta saúde com dados automáticos da pessoa

segura 28 Figura 34 BL3 da proposta saúde 29 Figura 35 Mapa de evidências da 201500176 – NOVA OFERTA DE

SAÚDE 29 Figura 36 Simulador LIBER 3G Multiplanos 30


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a vii

Figura 37 OneNote da atividade 201500079 – UPGRADE OUTSYSTEMS 31

Figura 38 Tabela de verificação da integridade do URL das aplicações (antigo e novo). Aqui só estão contemplados os links que sofreram alterações. 32

Figura 39 Logotipo do Outsystems 33 Figura 40 Ecrã de desenvolvimento no Outsystems 34 Figura 41 Incidências do FASTest carregadas no Mantis 34 Figura 42 Criação de um projeto dentro do TestPlanDesign (FASTest) 35 Figura 43 Organigrama do processo de gestão testes no FASTest 35 Figura 44 Criação de uma TestSuite dentro do Project (FASTest) 36 Figura 45 Criação ou edição de um TestCase dentro da TestSuite

(FASTest) 36 Figura 46 Criação ou edição de um UseCase dentro do TestCase

(FASTest) 37 Figura 47 ObjectList dentro do UseCase (FASTest) 37 Figura 48 Quadro Edit Usecase Object dentro da ObjectList (FASTest) 38 Figura 49 Galeria de objetos do simulador Auto no HP UFT 38 Figura 50 Separador da DATAPOOL, onde são criadas as tabelas de

dados corridas durante os testes automáticos 39 Figura 51 Imagem atual da Fidelidade Seguros (Fidelidade, 2016) 40 Figura 52 Esboço feito por Carlos Cesteiro 40 Figura 53 Estudos para o Logo do FASTest 41 Figura 54 Estudo final do conceito aprovado 41 Figura 55 Produto final do logo do FASTest 41 Figura 56 Site www.fidelidade.pt (Fidelidade, 2016) 42 Figura 57 Exemplos da tabela de categorização dos ícones do FASTest.

43 Figura 58 Pantone aplicado ao FASTest no Outsystems 43 Figura 59 Ambiente de trabalho do FASTest no Outsystems. 44 Figura 60 O antes e depois dos tabs de navegação do FASTest 44 Figura 61 Ecrã do TEST LAB, já com dados introduzidos e processados,

no TestRunne, TestSteps e TestResult. 45 Figura 62 Ecrã do TEST LAB, já com dados processados no TestResult. 46 Figura 63 Sequência de 3 imagens que compõem o organigrama da

Fidelidade 50


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a 1 | 64

1 Introdução Neste capítulo consta toda a informação de contextualização do trabalho desenvolvido durante o meu estágio

curricular na Fidelidade.

1.1 Enquadram ento

O presente relatório descreve e ilustra as atividades realizadas como Tester de Software às aplicações informáticas da Fidelidade Seguros, no âmbito do estágio curricular do segundo semestre do curso de Téc-nico Superior Profissional de Tester de Software do Instituto Politécnico da Guarda (IPG), em parceria com a consultora multinacional Altran.

A Altran assignou-me o seu cliente, Fidelidade Seguros, onde trabalhei durante os 4 meses de duração deste estágio. Dentro da Fidelidade fiz parte da Área de Testes e Formação (ATF) do Departamento de Sis-temas de Informação (DSI) da Direção de Gestão e Procura (DGPRC).

A ATF gere e certifica a qualidade das aplicações informáticas desenvolvidas para a Fidelidade, através de testes de certificação, aceitação e gestão de aceitação, para garantir o controlo de qualidade das mesmas.

Neste âmbito, foram-me assignadas tarefas que compreendem a elaboração de uma apresentação da metodologia de testes exercida na ATF, manuais de procedimentos, testes funcionais e regressivos aos front-ends das aplicações informáticas, desenvolvimento e implementação de uma maneira mais eficiente de comunicar entre os vários elementos de uma equipa e o departamento de recolha de evidências1.

Fora do âmbito previsto para este estágio, mas de todo não menos importante, é o trabalho por mim realizado em conjunto com o developer do programa de automação de testes da Fidelidade, o FASTest. Neste projeto desenvolvi o logotipo e a imagética2 (ícones, botões, links, etc.) do FASTest, e apoiei o desen-volvimento gráfico e ergonómico do seu interface e framework. Em paralelo elaborei também, o manual de utilizador do programa.

Para poder exercer corretamente as minhas funções foi necessária uma formação intensiva na área de negócio dos seguros, assim como da gestão do volume da informação processada diariamente pelos siste-mas de informação da Fidelidade.

1.2 Objet ivos

Os objetivos deste estágio estão divididos pela tipologia das tarefas executadas na Fidelidade:

Elaboração de manuais de procedimentos

Durante a minha formação sobre o negócio dos seguros, no início do estágio, consultei vários manuais de procedimentos e de utilizador sobre o TestLink e o Mantis na Fidelidade. Aquando desse processo e devido à minha formação anterior em design de equipamento, foi-me pedido que fizesse uma compilação desses documentos numa apresentação em PowerPoint. Essa apresentação servi-ria para explicar a metodologia agilizada de execução de testes de software, ou Aplicação de Gestão Integrada de Testes (AGITe) desenvolvida pela ATF, destinada ao departamento francês e ex-coló-nias. Já na reta final do estágio, durante a formação em automação de testes e do desenvolvimento da interface do FASTest, decidi por iniciativa própria elaborar um manual de utilizador do programa.

1 Evidências são os dados que permitem à ATF comunicar o estado de evolução do trabalho realizado pelos seus vários elementos (datas,

prazos, percentagens do trabalho concluído, imprevistos, etc.) 2 Imagética é a expressão para um conjunto de imagens.


A d r i a n a D ia s | n º 1 0 1 1 8 5 8 | I P G _E S T G | T eS P _T es te s d e S o f tw a re P á g i n a 2

Desenvolvimento da metodologia de gestão de atividades das equipas da ATF

Nesta fase pretendeu-se aplicar o conhecimento sobre a metodologia e organização do processo de design dos testes, adquirido durante o curso de TeSP de Testes de Software, aos procedimentos já implementados na ATF da Fidelidade Seguros. Foi-me pedido pelo chefe da equipa C.A.M.A. (Cristina, Alexandre, Machado e Adriana) Alexandre Silva, equipa essa da qual passei a fazer parte após a restru-turação da ATF, que reformulasse a página do OneNote das equipas da ATF. O OneNote é a ferramenta de documentação e atualização da informação do estado das atividades de cada equipa de trabalho da ATF. Esta restruturação vai servir para que a comunicação das evidências das atividades a enviar ao departamento de coordenação, seja mais clara e fácil de recolher.

Testes Funcionais

Nesta secção o objetivo foi efetuar vários tipos de testes funcionais ao software da Fidelidade, se-gundo o âmbito da intervenção das atividades assignadas à ATF. Chamam-se atividades a todas as ta-refas que envolvem um projeto de testes, como por exemplo: o planeamento dos casos de testes ba-seados nos requisitos, gestão das equipas de teste (testers, developers e utilizadores), gestão e envio das evidências à coordenação. A cada atividade é assignado um nome que segundo a regra da ATF compreende a sua data de início e o número consoante a hierarquia de início de atividades deste ano, precedida pelo título da atividade (Ex: 201500176 – Nova Oferta de Saúde, sendo que 2015 corres-ponde ao ano de início e 00176 é o número sequencial das atividades). A cada atividade é ainda atri-buído um gestor que fica responsável pela mesma. Para abreviar daqui para a frente, não colocarei o código numérico das atividades, referindo apenas os títulos.

Durante o estágio participei ativamente em três atividades principais. São elas:

Upgrade do GIS. Esta atividade compreende os testes exploratórios aos front-ends dos canais de mediação dos produtos vida, para verificar se a sua integridade se mantem após a implementação das alterações e melhorias no GIS, que é o software de back-end dos produtos vida da Fidelidade.

Nova Oferta de Saúde. Aqui são efetuados testes funcionais de gestão de aceitação ao front-end do novo simulador de produtos de Saúde, para verificar que o que está em desenvolvimento está pronto para ser implementado.

Upgrade do Outsystems. Esta atividade compreende testes de certificação, para veri-ficar que a integridade dos canais de distribuição da companhia se mantem após a im-plementação das alterações no back-end.

Testes de Interface e Regressão no FASTest

Nesta parte, a minha tarefa prendeu-se com o apoio ao desenvolvimento do programa de automação de testes FASTest, que está a ser criado pela Fidelidade para automatizar os testes manuais da ATF. Aprendi a carregar os simuladores de seguros para o FASTest e a criar os planos de testes automáticos. Ao longo de todo este processo, foram feitos testes regressivos após cada melhoria e alteração, quer no carregamento de dados, quer na implementação de novas funcionalidades.

Em paralelo com os testes e o desenvolvimento do software desenhei o logotipo do programa para promover a identidade do FASTest e o seu potencial comercial, seguindo as diretrizes da nova imagem da Fidelidade. Dentro da mesma linguagem, criei ainda a imagética da interface e da framework do programa, tendo em conta ergonomia e funcionalidade para os utilizadores.



1.3 P lan i f icação das A tiv idades – Gráf ico de Gantt Apesar de existir uma planificação prévia do meu estágio por parte da Altran, o meu trabalho na Fideli-

dade adquiriu uma dinâmica diferente do planeado, a partir do momento em que o coordenador da ATF, José Reis, se apercebeu da minha capacidade de adaptação e potencial como trabalhadora. Desta perce-ção, surgiram os projetos da reformulação do OneNote e do Design do FASTest (Figura 1).

1.4 Estrutur a do Re latór io

O relatório está organizado segundo os seguintes capítulos:

1. Introdução

Contém toda a informação necessária para a compreensão do trabalho executado durante o estágio. 2. Apresentação das Empresas Intervenientes no Estágio

Contém a informação relativa à Altran e à Fidelidade Seguros. 3. Elaboração de Manuais

Informação relativa aos manuais de utilizador criados por mim para a Fidelidade. 4. Metodologia de Gestão de Atividades

Descrição do trabalho efetuado de forma a melhorar a comunicação das equipas através do OneNote. 5. Testes de Software

Descrição do tipo de testes efetuados em cada uma das atividades assignadas. 6. Testes de Regressão e Interface do FASTest

Descrição do trabalho executado no desenvolvimento do FASTest (testes, design e ergonomia). 7. Conclusão Final

Contém as minhas elações retiradas da experiência de estágio na Fidelidade. 8. Anexos

Contém informação complementar para uma melhor compreensão do trabalho desenvolvido.

Figura 1 Gráfico de Gantt que ilustra o início e o fim de cada tarefa executada durante o estágio.



2. Apresentação das Empresas Intervenientes no Estágio

Neste capítulo irá constar a informação relativa à Fidelidade Segundos, empresa na qual estagiei direta-mente, e relativa à Altran, empresa que fez a mediação entre a Fidelidade Seguros e o IPG.

2.1 Apresentação da Altran

Em seguida, descrevo o enquadramento da empresa Altran no mercado e falarei do seu papel no meu

estágio. Sector de Atividade: Consultadoria em Sistemas de Informação Sede: Oriente em Lisboa Morada: Av. D. João II, Lote 1.07.2.1 Piso 2, 1990-096 Lisboa O Grupo Altran, multinacional francesa já atua no mercado da consultadoria há 30 anos. Com mais

de 24.000 colaboradores, 500 contas-chave a nível mundial e operacional em mais de 20 países. Em Portugal, a Altran está presente desde 1998, tendo-se consolidado a marca Altran em 2009 (ALTRANPORTUGAL, S.A., 2016).

Como líder global em inovação e consultoria de engenharia de alta tecnologia, a Altran acompanha

os seus clientes na criação e desenvolvimento de produtos e serviços. Os “Innovation Makers” (Figura 2) da Altran têm vindo a disponibilizar o seu conhecimento há mais de 30 anos, em sectores chave como aeroespacial, automóvel, defesa, energético, financeiro, ciências da vida, ferroviário, e telecomunica-ções, entre outros. Estando presente em cada etapa do desenvolvimento do projeto, desde o planea-mento estratégico da nova tecnologia à fase de produção, a Altran capitaliza a experiência e know-how dos seus colaboradores em cinco áreas chave: Innovative Product Development, Intelligent Systems, Lifecycle Experience, Mechanical Engineering, e Information Systems. No mercado português desde 1998, a Altran Portugal conta com 700 colaboradores. Em 2014 o grupo Altran gerou receitas de 1.756 mil milhões de euros, demonstrando uma clara expansão no mercado em que se enquadra.

Figura 2 Lema da Altran



2.2 Apresentação da F ide l idade

A Fidelidade é uma marca de seguros com mais de 200 anos. Foi fundada em 1808 como Fundação da Bonança tendo como primeira apólice a casa de Ângelo Freire em Alcântara no dia 30 de Setembro de 1808. Com a sua sede no Largo Calhariz 30, 1249-001 Lisboa, possui cerca de 2685 trabalhadores a nível nacional3. A Fidelidade Mundial e a Império Bonança uniram-se, sendo agora simplesmente, Fide-lidade. Esta fusão jurídica levou a um grande aumento do volume de negócios e consequente proces-samento de informação. A empresa apresenta agora 4 segmentos de negócio: A Fidelidade Famílias, Empresas, Corporate e Instituições, com cerca de 43 produtos personalizáveis de acordo com as neces-sidades dos clientes (Fidelidade, 2016).

O meu estágio decorreu no edifício da R. Alexandre Herculano nº 53 em Lisboa, onde se situa a ATF do DSI. Para informações complementares sobre o percurso da empresa, consultar o anexo 1.

A Altran e a Fidelidade

Sendo a Altran uma empresa de consultadoria a nível dos Sistemas de Informação, possui uma vasta carteira de clientes onde coloca os seus colaboradores de acordo com as necessidades do projeto a desenvolver. A Fidelidade é um dos clientes que requisita os serviços da Altran. Como é referido durante todo o meu relatório a Fidelidade encontra-se em expansão e a desenvolver novos produtos para os seus clientes. Neste sentido a Altran disponibiliza à Fidelidade vários colaboradores com as apetências específicas necessárias para realizar os projetos do seu cliente.

O meu estágio como Tester de Software na Fidelidade deve-se à anterior parceria entre a Altran e o IPG na abertura do TeSP de Testes de Software, no qual após a conclusão da parte letiva a Altran se disponibilizou a colocar os estudantes, agora em fase de estágio, nos projetos dos seus clientes. No meu caso em particular, e uma vez que me disponibilizei para estagiar num dos clientes da Altran sediado em Lisboa, fiquei colocada no projeto de automação do FASTest no cliente Fidelidade, onde trabalhei diretamente nas instalações do cliente.

3 Dados recolhidos do orçamento interno da Fidelidade em 2014, com autorização do coordenador José Reis.



3 Elaboração de Manuais

Este capítulo descreve o trabalho feito no manual/apresentação AGITe que engloba a metodologia do TestLink e do Mantis de acordo com o fluxo de incidências da ATF e que foi elaborado durante e para auxiliar o meu processo de formação na área dos seguros da Fidelidade. Explica também o trabalho efetuado no manual de utilizador do FASTest que inclui os procedimentos do HP UFT (ferramenta de captura de objetos virtuais) e da automação do FASTest, explicando assim a metodologia da automação de testes desenvolvida para os produtos do grupo Fidelidade Seguros.

3.1 Ferram entas Usadas

Neste projeto foram usadas as seguintes ferramentas:

Intranet (site interno da Fidelidade) – para consulta de procedimentos e manuais.

TestLink (programa de gestão de testes) – para capturas de ecrã e autoformação.

Mantis (programa de gestão de incidências) – para capturas de ecrã e autoformação.

HP UFT (programa de captura de objetos virtuais) – para capturas de ecrã e autoformação.

FASTest (programa de automação de testes) – para capturas de ecrã e autoformação.

Microsoft Office PowerPoint (programa de criação de apresentações) – criação dos manuais.

3.2 Trabalho Desenvolv ido

Este trabalho divide-se em duas partes, uma vez que desenvolvi dois manuais distintos.

3.2.1 Apresentação AGITe

A pedido do coordenador da ATF, José Reis, fiz a compilação de sete manuais utilizados na ATF na formação sobre abertura e gestão de incidências. Estes documentos foram a base para a metodologia de testes AGITe desenvolvida pelo próprio coordenador, José Reis como mo-delo da ATF na Fidelidade. O AGITe será apresentado a vários clientes e parceiros da empresa, nomeadamente do mercado francês e inglês. Esta apresentação compreende as práticas exe-cutadas dentro dos programas e mediante o fluxo de gestão de incidências da ATF, ilustrado na Figura 3.

Figura 3 Organigrama do workflow do report de incidências (Fidelidade, 2016)

As incidências são criadas e colocadas em curso pela ATF, que as encaminha para o departa-

mento competente consoante o âmbito da incidência (dep. desenvolvimento, canais, etc.). Após a sua análise, pelo respetivo departamento as incidências são reencaminhadas para a



ATF, onde serão retestadas e encerradas caso a situação se encontre resolvida, ou devolvidas, caso o departamento de análise não consiga, por algum motivo, reproduzir o teste. Neste caso é solicitado ao tester da ATF, que forneça informação adicional para a resolução da incidência.

Este workflow repete-se até que a situação esteja resolvida, e a incidência é então encerrada, sempre e exclusivamente pela ATF. As incidências são baseadas nos casos de teste criados pela ATF no TestLink, pelo que o programa possui uma base de acesso ao Mantis, onde aí sim, ficam registadas todas a incidências correspondentes à atividade que se está a tratar.

Esta apresentação foi uma parte fulcral na minha aprendizagem dos procedimentos da ATF, ainda durante a parte da minha formação sobre o negócio da Fidelidade.

O modelo AGITe veio agilizar o processo de testes e gestão de incidências dentro das várias equipas e departamentos intervenientes nas atividades. Foi designado de AGITe pois virá “agi-tar” a maneira como são levadas a cabo as tarefas, assim como melhorar a interação dos in-tervenientes, ficando testers, developers e clientes mais próximos. Este projeto tem em vista a diminuição dos tempos de execução das atividades, dos prazos de entrega e do erro humano devido a falhas de comunicação.

É um processo conciso mas ainda em fase de otimização, pelo que todos os dias são sugeri-das melhorias e aplicadas novas regras de execução.

3.2.2 Manual do Utilizador FASTest

Já na reta final do estágio e durante a formação em automação de testes no FASTest, eu e a

colega Mónica Braga achámos por bem elaborar um manual simplificado dos passos para cap-tura de objetos, com a ferramenta HP UFT, e consequentemente dos passos necessários para criar e executar os testes no FASTest. Este processo será descrito mais detalhadamente no capítulo 5.3 (p.35) sobre Automação onde explico toda a metodologia do processo de automa-ção, correspondente à informação contida no manual. Para que o leitor possa ter uma ideia da apresentação de conteúdos do manual do FASTest, coloquei no anexo 2, os prints da descrição da utilização do HP UFT.

3.3 Conc lusão

A apresentação do AGITe serviu em grande parte como linha orientadora da minha formação nos procedimentos da ATF. Após a correção pelo coordenador José Reis, o trabalho em formato de apre-sentação recebeu feedback de tal maneira positivo, que por sugestão do próprio me foi solicitada uma posterior adaptação desse formato para um manual em formato de leitura. Existe esta necessidade uma vez que a apresentação é interativa e a informação está em formato dinâmico. No seu estado atual o trabalho permite aos utilizadores navegarem pelos programas através de slides em formato de demonstração, passo-a-passo, facilitando assim a aprendizagem do método AGITe.

O manual do FASTest encontra-se em desenvolvimento, em paralelo com o programa, estando já contemplada e concluída a secção inicial, sobre o carregamento de objetos com o HP UFT.



4 Metodologia de Gestão de Atividades

A metodologia de gestão de atividades na ATF é um processo bem enraizado e gerido maioritariamente através de mails, e mais recentemente através do TestLink e do Mantis. Estes softwares foram introduzidos no processo pelo coordenador José Reis, que tem como premissa otimizar o método de trabalho, que em consonância com o volume de negócio, aumentou bastante devido à fusão da Fidelidade Mundial com a Império Bonança. Tendo esta informação como premissa, foi-me pedida uma revisão da informação contida na mais atual ferramenta de comunicação do departamento, o Microsoft Office OneNote.

O OneNote é, essencialmente, uma ferramenta para troca de notas em tempo real. Isto é, uma folha de trabalho que pode ser acedida por vários utilizadores em rede e cuja informação pode ser atualizada ao minuto e consultada de imediato, fazendo frente aos constrangimentos temporais do Outlook ou qualquer outra ferramenta de troca de mails (Ex: preenchimento de destinatários, título, assinaturas, etc.).

Para o efeito desenvolvi a padronização da folha de evidências da minha equipa de testes funcionais (C.A.M.A.), ficando esta mais funcional e fácil de adotar por todas as equipas da ATF.


Microsoft Office OneNote (ferramenta de comunicação das equipas da ATF) – Restruturação.

Microsoft Office Outlook (ferramenta de comunicação por email dentro da Fidelidade) - Alertas.

TestLink – para consulta da informação a constar na página da equipa.

Mantis – para consulta da informação a constar na página da equipa.

4.2 Trabalho Desenvolv ido

Aqui irei descrever o trabalho desenvolvido durante o aperfeiçoamento da metodologia de gestão das atividades da ATF. Este trabalho encontra-se dividido em duas partes, uma para o OneNote da equipa C.A.M.A. e outra para a metodologia de desenvolvimento do FASTest.

4.2.1 Restruturação do OneNote da equipa C.A.M.A.

Cada equipa da ATF possui uma pasta de OneNote onde é partilhada toda a informação sobre

o estado em que se encontra cada uma das atividades assignadas aos membros dessa mesma equipa.

Desta informação constam as evidências, constituídas pelas fases e prazos da etapa em que cada atividade se encontra, assim como comentários sobre situações pontuais e eventuais al-terações aos prazos pré-estabelecidos. Estas informações são geridas pelo chefe de equipa e pelo gestor de cada atividade, sendo disponibilizadas a todas as equipas/departamentos inter-venientes na mesma (Ex: desenvolvimento, canais, testes, cliente, etc.). A informação aí con-tida ainda não possuía uma regra nem uma organização per si, sendo que cada equipa dispo-nibiliza essa mesma informação como bem entende. No final de cada semana a colega Cristina Silva (tester), faz a recolha destes dados que são depois compilados pela mesma num ficheiro em Project e enviados à direção do DSI. No Final do ano esta informação tem impacto sobre os prémios de produtividade das equipas, e por consequência, no salário dos trabalhadores. O meu trabalho servirá para que essa recolha seja mais fácil de maneira a agilizar o processo.

Foi-me pedido pelo coordenador José Reis e pelo colega Alexandre Silva (ambos meus chefes de equipa) que reorganizasse o OneNote da equipa C.A.M.A. da qual fiz parte a 50%, sendo os outros 50% dedicados à equipa FASTest. Se a qualidade do projeto for boa e houver aceitação por parte dos colaboradores da ATF este novo layout será adotado pelas restantes equipas. De momento, a equipa C.A.M.A. possui cerca de 18 atividades assignadas aos seus quatro mem-bros. Antes da minha revisão, estas estavam detalhadas numa só página corrida com uma única nota. O chefe de equipa Alexandre Silva, por si só já havia desenvolvido um sistema de unifor-mização da informação, através da repetição da localização do tipo conteúdos duma forma sequencial e de um código de cores para cada campo (Ex: titulo da atividade em azul; tipo de intervenção ATF a verde; etc.), utilizando a penas a ferramenta de sublinhar, tal como no Word.



O colega Alexandre, elaborou também um quadro de estado das evidências, em formato de tabela (o OneNote permite a criação de tabelas simples), onde os gestores de cada atividade apontam quais os requisitos que estão tratados e quais não estão. Esta pré-organização simpli-ficou bastante o meu trabalho.

Figura 4 Ficheiro da página do OneNote da equipa C.A.M.A. antes da restruturação

Na Figura 4 podemos observar o antigo layout utilizado pela equipa na comunicação do es-

tado das atividades. A título de exemplo, podemos verificar que muita da informação aqui apresentada, nomeadamente as datas, são repetidas em todas as atividades, e podem ser apresentadas em tabelas standardizadas mais fáceis de editar.

Transformar em tabela de acordo com o tipo de intervenção.

Criar Link para separadores com a informação só para a equipa.

Informação repetida em todas as atividades. Dividir em três e transformar em tabelas.

Criar histórico



No processo de reorganização, optei por separar a informação necessária para o Project da informação interna da equipa, como demonstra a Figura 5. Depois uniformizei a informa-ção da página inicial que contém a informação para o Project, para que esta seja apresentada sempre de mesma consistente, facilitando assim a sua leitura e a localização das alterações feitas no documento.

Figura 5 Esquema da restruturação do OneNote do C.A.M.A

As atividades são divididas consoante o nível de intervenção da ATF sobre elas, isto é, exis-

tem intervenções sobre Aceitação + Certificação, Gestão de Aceitação e Certificação. Optei por dividir o quadro das evidências em 3 quadros diferentes com as evidências específicas para cada tipo de intervenção, como se pode ver na Figura 6.

Figura 6 Matrizes das tabelas a aplicar na recolha das evidências segundo o tipo de intervenção ATF.

Estas serão colocadas apenas nas páginas das atividades contendo a informação interna da

equipa. Na página inicial do Project são atualizados apenas os prazos (certificação, aceitação, RIT, etc.). Aqui uniformizei as tabelas, os títulos e utilizei links para direcionar os utilizadores para a página correspondente à atividade dentro da pasta da equipa.

Atividades C.A.M.A. numa

só página

Informação para a Equipa (atividades divididas em páginas

dentro da pasta da equipa)

Divisão por tipo de intervenção ATF

Divisão por gestor de atividade

Evidências para a Cristina Silva (project)

Resumo com a informação das evidências sintetizada (Prazos das etapas e notas

das alterações)



O OneNote permite ainda criar alertas através do Outlook (Figura 7), relativamente a reu-niões e datas que estejam a aproximar-se (releases, subidas a produção, ok clientes, etc.) o que facilitará também a gestão de tempo dos intervenientes. Esta funcionalidade será im-plementada posteriormente pelo chefe de equipa, Alexandre Silva.

Figura 7 Colocação de uma Flag no OneNote com alerta para a Agenda do OutLook

Figura 8 Ilustração dos link que redirecionam para as páginas, contendo a informação da atividade dedicada aos mem-bros da equipa. A formatação é sempre a mesma para todas as atividades.

Como podemos ver na Figura 8 após a minha intervenção a página inicial com a informação

para o Project contém links para as páginas com a informação mais detalhada de cada ativi-dade, caso seja necessário um follow-up da mesma.



Figura 9 Página com o resumo das atividades a serem tratadas pela equipa.

Figura 10 Exemplo de uma página da atividade com a informação destinada aos membros da equipa depois da restru-turação.

As Figura 9 e Figura 10 demonstram a organização da informação destinada aos membros

da equipa e respetivos gestores das atividades.

Tipo de intervenção da ATF na atividade e o número de horas para a sua execução

Tabela com o estado das evidências.

Informações adicionais da atividade.



4.2.2 Restruturação da metodologia de desenvolvimento do FASTest

No âmbito do trabalho do OneNote, sugeri ao coordenador José Reis e aos restantes mem-bros da equipa FASTest, que fosse implementada uma tipificação das incidências do FASTest no Mantis, tal como é feita para os testes funcionais noutras atividades, de maneira a organizar e sintetizar a informação. Como o programa FASTest se encontra em desenvolvimento, as inci-dências devem ser caracterizadas pelos pontos de acesso comuns em todas as plataformas (desenvolvimento, certificação e produção). Assim sendo a tipificação consiste na descrição do caminho percorrido pelo utilizador dentro do programa, até ao problema encontrado (caminho identificado em maiúsculas), seguido do problema em questão (descrito em minúsculas).

As incidências do FASTest encontram-se agora conforme a Figura 11.

Figura 11 Exemplo da nova tipificação de incidências em curso no projeto FASTest4

Como se pode verificar, desta forma é mais fácil identificar onde se encontra a incidência e

do que se trata.

4.3 Conc lusão

Depois de concluída a restruturação do OneNote da C.A.M.A., tentei adaptar o mesmo modelo ao FASTest, no entanto as características dos projetos são diferentes e as suas necessidades também. Não obstante, o feedback obtido por parte dos chefes de equipa foi muito positivo, sendo o modelo ado-tado, não só pela equipa, mas também pelo coordenador da ATF no seu OneNote pessoal, e por outros chefes de equipa da ATF, após a implementação e divulgação do ficheiro na drive do departamento. A nova tipificação de incidências do FASTest ajudou a que não houvesse repetições de reports, melho-rando a comunicação entre todos os membros da equipa. Esta revisão teve como objetivo, a colocação em prática das minhas capacidades organizacionais e capacidade de depuração na apresentação obje-tiva de informação, isto é, a capacidade de reduzir o ruido visual de um documento melhorando ao máximo a sua legibilidade.

4 Os casos GENÉRICOS são erros/melhorias recorrentes em todas as tabs do programa.



5 Testes de Software

Como já referi no capítulo 1 assim que entrei na Fidelidade, tive uma vasta formação sobre os procedi-mentos e as regras do negócio dos seguros, antes de iniciar qualquer tipo de teste. Dessa formação saliento a semana de formação em side-by-side com o colega Carlos Machado para aprender a criar entidades (cli-entes) fictícias, fazer vários tipos de simulações de apólices, e criar propostas e apólices nos vários canais de venda da Fidelidade.

Após essa necessária aprendizagem, o meu trabalho como tester de software consistiu na execução de testes funcionais aos front-ends dos vários simuladores e aplicações testados pela ATF para os produtos da Fidelidade. Isto é, fui testar a interface das aplicações, recriando situações reais, como um futuro utilizador. Uma vez que ao longo do estágio me foram assignadas três atividades prioritárias e com características diferentes, este capítulo encontra-se dividido por tipo de atividade e, consequentemente, pelo tipo de tes-tes executados.


TestLink – para a gestão do plano de testes.

Mantis – para abertura e gestão de incidências.

Microsoft Office:

Excel, Paint e Word (ferramentas de edição de texto e imagem) – para documentação das incidências.

Outlook, OneNote e Lync (ferramentas para comunicação entre colaboradores da Fideli-dade) – para comunicar com os intervenientes das atividades.

FASTest (experimental) – para correr testes automáticos.

CISN, ADN, MEDINET, MHS, PostalNet-CTT e Canal CGD (canais de mediação dos produtos da Fide-lidade5) - onde foram efetuados os testes de software.

Bonsai, GIS e Cogen (back-end software dos canais de mediação da Fidelidade) – para uma melhor compreensão do trabalho a executar.

5.2 Upgrade GIS Oferta V ida

Durante o meu período de estágio na Fidelidade, o back-end software de gestão dos produtos vida,

designado por GIS (Figura 12) dentro da companhia, sofreu alterações com um upgrade de produtos e funcionalidades. Estas alterações surtiram depois efeito nos respetivos front-ends de distribuição dos produtos. Os produtos vida da Fidelidade contemplam apólices de cobertura em caso de morte ou in-validez do tomador, tendo como beneficiários o próprio (em caso de invalidez) ou quem o tomador achar por bem. Deste rol de produtos fazem parte os seguros “Vida Segura”, “Família Segura”, “Seguro Mulher”, “Seguro Proteção Funeral”, “Rendas Vitalícias”, entre outros.

Esta atividade foi designada por Upgrade GIS Oferta Vida, e os testes que executei foram funcionais de carácter exploratório, isto é, foi necessário testar a simulação do mesmo produto (Ex: “Seguro Mu-lher”) em todos os canais de mediação da Fidelidade, para confirmar que as alterações estão presentes e se os simuladores continuam a funcionar corretamente.

Antes de iniciar os testes tive uma breve formação com a colega Ana Vieira (tester) sobre o funciona-

mento do GIS e como se trabalha nessa plataforma para ter uma melhor compreensão do tipo de inci-dências que poderiam surgir durante os testes funcionais nos front-ends em CISN, ADN, MEDINET, Pos-talNet_CTT e Canal CGD.

5 Canais de venda e gestão de produtos e entidades da Fidelidade.



Figura 12 Interface do GIS

Os testes exploratórios desta atividade são de carácter genérico, isto é, como esta atividade tem im-

pacto sobre todos os canais de mediação de todos os produtos vida, os casos de teste (Figura 13) con-templam apenas os canais (em ambiente de certificação), uma vez que a priori a lista dos produtos vida é igual em todos. As incidências são reportadas através do TestLink no Mantis, onde é feita a sua gestão.

Figura 13 Casos de teste a executar após o Upgrade do GIS (TestLink)



Neste caso os testes funcionais consistem na simulação dos vários produtos vida. Por exemplo, faze-mos uma simulação no CISN (canal de mediação Fidelidade) duma apólice “Seguro Mulher” e das suas tipologias de forma a garantir a integridade do sistema após as alterações nas características dos planos das apólices. Assim, o objetivo é fazer o máximo de combinações possíveis dentro do produto (Figura 14), e caso encontremos uma incidência, reportamo-la de imediato no TestLink e no Mantis e repetimos o teste nos restantes canais de mediação.

Figura 14 Exemplo das coberturas dos planos da Oferta Vida.

Durante o processo de testes foram encontrados erros do tipo (Figura 15):

Figura 15 Exemplos de erros devolvidos pelo GIS

Desta forma fiquei a saber que existem erros de sistema e erros de produto, e que é necessário dis-

cernir qual o tipo de erro que encontramos para saber para onde reencaminhar a incidência, neste caso seriam enviados para a DSI-DSOV-ASSC ou Área de Sistemas Complementares. Se fosse um erro de pro-duto, independente do canal de venda, encaminha-se para a DSI-DCSA-CAN - Sector de Canais.

As incidências são encaminhadas no estado EM CURSO. Após a sua resolução são devolvidas no es-tado RETESTAR ATF. Posteriormente são aceites e passadas ao tester que as abriu para as RETESTAR. Após o re-teste, caso a situação esteja resolvida, a incidência passa a ENCERRADA, se houver uma rein-cidência, passa de novo para EM CURSO e é encaminhada para o respetivo departamento, repetindo todo o processo (ver Figura 3).

Os testes são manuais, em ambiente de certificação. Dependendo do produto em si, o número de steps aumenta e a probabilidade de encontrar erros também.



Figura 16 Exemplo duma simulação no Seguro Vida particular ou PME

Os simuladores são bastante idênticos aos planos das brochuras, e basta preencher os campos de acordo

com a tipologia da apólice que queremos (Figura 16 - As caixas vermelhas, assinalam os campos que devem ser testados em cada simulador).

Este trabalho serviu para dar suporte à colega Ana Vieira a quem foi assignada esta atividade. De acordo com as alterações indicadas no Artefactos (base de dados onde se podem consultar os requisitos de cada atividade) os testes devem contemplar o máximo de hipóteses, ainda que dentro do prazo de entrega esta-belecido. Isto é, após testar os casos de teste contemplados no TestLink, se houver tempo fazem-se testes fora de âmbito para cobrir potenciais falhas não incluídas nos casos de teste iniciais, as incidências proveni-entes destes testes devem ser reportadas nos casos genéricos, como podemos ver na Figura 13.

Em suma, o meu trabalho nesta atividade consistiu em efetuar os testes exploratórios não contemplados nos CT’s (casos de teste). Nesta altura do estágio as equipas de trabalho da ATF ainda não estavam definidas, sendo que o meu



5.3 Simulador Nova Oferta de Saúde

De maneira a contextualizar esta atividade há que explicar que a Fidelidade também faz mediação de planos de saúde. Em 2015 foram desenvolvidos novos produtos dentro do ramo dos seguros de saúde. A atividade Nova Oferta de Saúde contempla os testes ao simulador de distribuição desses produtos em todos os canais de mediação da Fidelidade. Nesta atividade, como podemos ver na Figura 17, a intervenção da ATF foi ao nível da Gestão de Aceitação.

Figura 17 Estado da atividade no OneNote à data do relatório

Por esta altura já tinham sido definidas as novas equipas da ATF, ficando eu em duas equipas: na

equipa C.A.M.A. e na equipa FASTest. A gestão desta atividade ficou atribuída à colega Cristina Santos com a qual tive formação sobre o produto e metodologia de testes de Gestão de Aceitação (produtos novos).

Os testes desta atividade são de carácter funcional feitos nos front-ends. Eu fiquei encarregue de tes-tar o simulador nos canais ADN e MEDINET, enquanto a colega testou os canais CISN e MHS.

Figura 18 Tabela auxiliar ao plano de testes após a sua execução.

Tal como demonstra a Figura 18, os campos devem ser testados segundo uma matriz de idades, e os

sexos dos clientes. Logo é necessário criar esses clientes (entidades) nos canais nos quais estamos a trabalhar, nomeadamente para exceções contempladas nos CT´s (Figura 19).



Os pressupostos são essas exceções.

Pressupostos na definição da grelha de recomendação:

1 - Os Planos são recomendados com base na idade da 1ª pessoa a segurar e género, bem como, no fator "Preço" ou "Proteção".

2 - A Grelha de Recomendação foi construída assumindo que vamos apresentar ao Cliente 3 soluções de saúde/combinações que este poderá modificar (incluir ou excluir coberturas opcionais). Existem situações em que apresentamos mais do que uma combinação do mesmo Plano.

3 - O Cliente pode, se desejar, "Ver mais produtos". Por exemplo, se recomendarmos o "h1", "h5" e "h7", quando o Cliente clicar em "Ver mais produtos" vai poder visualizar, para além dos que foram apresentados (Planos "Inicial" e "Básico"), os Planos "Intermédio", "Oncológico" e "Cartões de Saúde". O Cliente pode selecionar até 3 planos. Os planos selecionados serão apresentados só com as coberturas base e com as opcionais por selecionar.

4 - Intervalos Etários

] 0 ; 18 ] Limitado a 18 anos devido à idade mínima de contratação do Seguro Oncológico.

] 18 ; 30 ] Estudantes e pessoas que entram no mercado de trabalho.

] 30 ; 40 ] Constituem família. Preocupam-se com a saúde.

] 40 ; 50 ] Vida familiar estabilizada. Preocupam-se com a saúde.

] 50 ; 60 ] Idade máxima de subscrição: 60 anos; A saúde é uma das grandes preocupações.

] 60 ; ∞ ] Idade a partir da qual apresentamos os Cartões de Saúde.

5 - Género: Importante para recomendar planos de saúde com a cobertura de Parto para as mulheres em idade fértil

6 - "Preço" vs. "Proteção" - Cliente escolhe uma opção de entre "Preço" ou "Proteção" permi-tindo a recomendação da montra mais adequada ao seu perfil

7 - Intervalos de preço - definidos com base na tarifa, sendo que dois dos planos ficam dentro do intervalo de preço selecionado e o mais caro com uma pequena diferença de preço em relação ao plano "escolha certa", para dar a possibilidade comercial de fazer upgrade por um pequeno acréscimo mensal no valor a pagar

8 - Proteção - plano "inferior" com acesso à rede na cobertura escolhida (exceto "Doenças Gra-ves" em que recomendamos um plano com um capital elevado no IH-100.000€ e Consultas-5.000€); "escolha certa" com capital na cobertura escolhida; opção superior com capital superior e/ou coberturas adicionais

Figura 19 Tabela dos pressupostos para os testes NOVA OFERTA SAÚDE

A grelha criada na Figura 18 foi baseada nestes pressupostos, e contempla apenas a parte da simula-

ção dos planos (os CT´s estão divididos em “simulação” e “proposta”).

Figura 20 Pressupostos para os casos de teste genéricos onde se reportam todas as incidências excecionais (TestLink).



Esta informação encontra-se disponível apenas para os testers, dentro do TestLink (Figura 20), não sendo disponibilizada aos utilizadores.

O simulador é igual em todos canais, exceto no CISN, uma vez que este trabalha com a IB (Império Bonança) e FM (Fidelidade Mundial)6, e contém várias entidades e moradas para o mesmo cliente. Por este motivo existem mais steps em cada caso de teste do canal CISN.

O simulador possui duas etapas distintas:

Simulação

Proposta Em primeiro lugar nos CT´s vem a simulação, que deve ser testada no prazo de 3 a 5 dias em todos os

canais (nesta fase ainda não tínhamos acesso à parte da proposta no simulador (Figura 22)).

A simulação é composta por 3 blocos:

BL1 - Dados da simulação

BL2 - Recomendação

BL3 - Resultado Na Figura 21 podemos ver o BL1 do simulador e os CT´s correspondentes.

Figura 21 BL1 do simulador saúde

Figura 22 CT´s do BL1 do simulador saúde (TestLink)

6 Isto deve-se ao facto de ainda existirem clientes com produtos ativos, das duas antigas marcas, que ainda não foram descontinuados.

Campo de escolha obrigatória



No primeiro bloco “Dados da Simulação”, a única obrigatoriedade para prosseguir com a simulação é o sexo do segurado. Para passar ao próximo bloco temos de escolher um ou outro e clicar no botão “Continuar” (Figura 21).

Em seguida, no segundo bloco “Recomendações”, podemos prosseguir sem escolher qualquer uma das opções, simplesmente clicando no botão “Simular” (Figura 23). O sistema vai devolver a melhor compilação de 3 ofertas para o sexo da pessoa segura escolhido no BL1.

Figura 23 BL2 do simulador saúde


Embora não estejam contemplados nos CT´s da Nova Oferta de Saúde, é necessário testar que cada

uma das opções quando selecionada passa sem erros ao bloco seguinte. Caso ocorra um erro, este deve ser reportado nos CT´s do BL2 (Figura 24) ou nos CT´s genéricos, mediante justificação.

Nesta fase da minha formação, quando ocorria um erro fora de âmbito, solicitava sempre à colega Cristina Santos uma validação da tipificação da incidência antes de a reportar, para evitar repetições ou encaminhamentos incorretos.



No BL3 (Figura 25) é necessário validar o máximo de combinações possíveis para cada resultado. Uma vez que as probabilidades (cerca de 6983 CT´s só para propostas singulares particulares) excedem a nossa capacidade (recursos humanos e tempo) para cumprir os prazos estipulados, os testes são feitos transversalmente abarcando o maior número de hipóteses possíveis dentro das datas expostas na Fi-gura 17.

Figura 25 BL3 do simulador saúde (parte da tipificação do plano)



Como se pode ver nos casos de teste (Figura 26), existe uma primeira parte para testar as combina-ções dos planos e coberturas, validando os resultados segundo os pressupostos da grelha da Figura 18.


Figura 27 BL3 do simulador saúde (parte da conversão em proposta)

Os restantes casos de teste do BL3 (Figura 27) contemplam as condições contratuais de pagamento

do plano escolhido.



Após a entrega dos testes da parte da simulação e segundo o fluxo do plano, foram iniciados os testes no segmento da proposta. Este, à semelhança do anterior, também contém 3 blocos:

BL1 - Proposta

BL2 - Pessoas Seguras

BL3 - Pagamento

Figura 28 CT´s do BL1 da proposta saúde (TestLink)

No BL1 da proposta é necessário colocar os dados reais do tomador, pois será gerado um contrato

que deve ser impresso e entregue ao cliente (Figura 28 e Figura 29 – esta parte é especificada nos CT´s do BL1). Caso exista alguma inconsistência nos dados do tomador o simulador não passa ao BL2.

Figura 29 Pressupostos dos dados do tomador no BL1 da proposta

Para validar os dados do tomador de forma automática basta que este esteja inserido na Base de

Dados da companhia. Isto é, portanto, um pré-requisito para a criação da proposta.



Figura 30 BL1 da proposta saúde

Ao inserir todos os dados corretamente (Figura 30), clicamos no botão “Continuar” para passar ao

BL2, onde iremos inserir as pessoas abrangidas pelo seguro7.

7 NOTA: Mais à frente, ao tentarmos automatizar esta parte da proposta no FASTest é necessário programar os campos de dados manuais

(Dados da Proposta) com tabelas de Excel contendo os casos excecionais.



Figura 31 BL1 da proposta saúde com dados reais do tomador

Como podemos observar na Figura 31, ao inserir determinados dados na proposta aparecem novos

campos8. Esta situação deve também ser contemplada aquando da montagem da automação.

8 Aqui devemos comparar as Figura 30 e Figura 31 para uma melhor perceção do que aqui é disposto.



Ao clicar no botão “Continuar”, com dados válidos, passamos então ao BL2 (Figura 32 e Figura 33), onde devem constar os dados da Pessoa Segura. Para este caso o Tomador e a Pessoa Segura, são uma, e a mesma pessoa. Logo os dados são transferidos automaticamente. Basta clicar no botão “Gravar Proposta”.

Figura 32 CT´s do BL2 da proposta saúde (TestLink)

Figura 33 BL2 da proposta saúde com dados automáticos da pessoa segura



Ao passarmos ao BL3 é-nos apresentada a possibilidade de download e/ou impressão da documen-tação legal da proposta a entregar ao cliente (Figura 34).

Figura 34 BL3 da proposta saúde

Na presente data, o mapa de evidências da atividade 201500176 – NOVA OFERTA DE SAÚDE encon-

tra-se com o aspeto ilustrado Figura 35.

Figura 35 Mapa de evidências da 201500176 – NOVA OFERTA DE SAÚDE



O fim desta atividade está agendado para dia 18 de Novembro de 2016. Até lá devem estar concluídos todos os testes para assegurar a qualidade e aceitação do produto. Há sempre que contar com alguns períodos de indisponibilidade quando são implementadas as alterações, correções e melhorias, o que pode influenciar as datas de entrega de cada etapa. A próxima etapa será testar os produtos desenvol-vidos para PME´s (pequenas e médias empresas). Estes testes serão feitos paralelamente no FASTest para comparar resultados.

Ao todo, nesta atividade, foram-me assignados 58 casos de teste, não incluindo os testes genéricos e

os testes baseados nos pressupostos.

29 Casos de Teste x 2 canais (ADN e MEDINET) = 58 CT´s

Os testes funcionais deste simulador ajudaram-me a compreender bastante melhor as aplicações dos produtos da companhia e a forma como estes são distribuídos. Esta aprendizagem é válida para qual-quer outro simulador de complexidade equivalente, como é o caso do simulador Automóvel LIBER 3G Multiplanos (Figura 36), que será o meu próximo projeto de automação no FASTest, quando regressar à Fidelidade.

Figura 36 Simulador LIBER 3G Multiplanos



5.4 Upgrade do Outsystems

O Outsystems é um programa de desenvolvimento de software, usado pelos programadores da Fide-lidade, para criar os seus programas e plataformas informáticas. Quando o programa é atualizado, há que verificar a integridade de todos os programas nele criados, sendo necessário correr testes em todos os canais de mediação e nos produtos neles contidos, de uma maneira geral.

Nesta atividade, como podemos ver na Figura 37, a intervenção ATF foi ao nível da Certificação:

Figura 37 OneNote da atividade 201500079 – UPGRADE OUTSYSTEMS

Em paralelo com a atividade 201500176 – NOVA OFERTA DE SAÚDE, foram-me assignados testes fun-

cionais de certificação na atividade 201500079 – UPGRADE OUTSYSTEMS. O gestor assignado foi o co-lega e chefe de equipa Alexandre Silva, da equipa C.A.M.A. Este encarregou-me de testar todos os links (URL) dos canais de mediação internos da Fidelidade, assim como das plataformas informáticas de dis-tribuição (Ex: Intranet, site da Fidelidade, etc.)

Após o Upgrade do Outsystems houve a necessidade de testar genericamente a integridade de todos

os canais e aplicações do grupo Fidelidade. Isto é, entrar no canal em si e verificar que o URL funciona corretamente, sem corromper utilizadores e contas de mediação, etc.9, e de seguida fazer uma ou duas simulações em produtos diferentes para verificar se estas mantinham a integridade das suas caracterís-ticas.

As alterações/atualizações do Outsystems podem ter impacto sobre as mais elementares operações

efetuadas nos servidores e canais usados diariamente pelo grupo Fidelidade, tais como:

A entrada nos canais (mudanças no URL).

Pesquisas de entidades, simulações e apólices.

Criação de entidades, simulações e apólices.

Passwords e users, etc.

9 As contas de mediação e os user da Fidelidade são dados confidenciais pelo que não poderei detalhar mais este assunto.



Foi-me assignada a confirmação da integridade do URL de todas as aplicações e canais listados na

Figura 38.

Figura 38 Tabela de verificação da integridade do URL das aplicações (antigo e novo). Aqui só estão contemplados os links que sofreram alterações.

Após a confirmação dos links corretos, foi enviado um mail a todos os colaboradores da ATF com a listagem

corrigida, para que a partir de agora passem a utilizar os novos URL em certificação.

5.5 Conc lusão

A minha participação dedicada nos testes funcionais destas três atividades (Upgrade GIS Oferta Vida, Nova Oferta de Saúde e Upgrade Outsystems) e, de forma mais esporádica noutras que por não serem tão relevantes foram omissas neste relatório, serviu para adquirir uma maior noção da complexidade dos sistemas informáticos da Fidelidade. Os produtos são complexos, com muitas variáveis, e estão disponíveis em vários canais de mediação, o que exige uma grande organização e capacidade de gestão das atividades dos testes, por parte dos gestores das atividades.

A Fidelidade encontra-se numa fase de adaptação à expansão do negócio e, por consequência, tam-bém a ATF, onde estão a ser desenvolvidas novas metodologias de testes para lidar com as alterações sofridas com a fusão da Império Bonança e da Fidelidade Mundial.

Os testes exploratórios, funcionais e regressivos, são atividades minuciosas que pedem uma grande

coordenação e cooperação entre os membros das equipas. O TestLink e o Mantis são, nesse sentido, ferramentas cruciais para acelerar o processo de testes e garantir uma comunicação eficaz, relativa ao tratamento das incidências, entre os vários intervenientes. Para além destas ferramentas, o Microsoft Office com o seu Word, Excel e Paint são também uma mais-valia como ferramentas auxiliares e com-plementares, para documentação e comunicação dentro das atividades. São utilizados na captura (prints) das imagens de erro, que são depois carregados (.doc, .png, .xlsx10, etc.) dentro das incidências no Mantis, para auxiliar as equipas de desenvolvimento a identificar mais rapidamente o tipo de erro devolvido pelo programa.

Em suma os testes de software exigem uma grande concentração e uma boa capacidade de trabalho

em equipa, de forma organizada e coerente. Há que transmitir as ideias de uma forma clara e objetiva dentro de uma linguagem comum a todos os intervenientes, sejam eles, testers, developers, clientes e utilizadores. Por este motivo, sinto que a nível profissional esta é sem dúvida uma aposta e um desafio que quero e vou abraçar, com todo o gosto.

10 Tipologia do tipo de documentos que podem ser carregados no Mantis.

HostName Link Correcto

Cisncertupgrade.fidelidademundial.com certcisn/

http://medinetcertupgrade.fidelidademundial.com/Mediacao_Common/ certmedinet/

http://adncertupgrade.fidelidademundial.com/Mediacao_Common/ certadn/

canaldirectocertupgrade.fidelidademundial.com certfidelidade.fidelidademundial.com

csaicertupgrade.fidelidademundial.com certcsai/

myitcertupgrade.fidelidademundial.com certmyit.fidelidademundial.com

multicareclientescertupgrade.fidelidademundial.com certmulticare/

http://multicareprestadoresbocertupgrade.fidelidademundial.com http://certprestadoresmulticare/MLTC_Prestadores/

dsignaturecertupgrade.fidelidademundial.com ???????????????????????

http://myempresascertupgrade.fidelidademundial.com/CANW_Layout/ https://certmyfidelidade.fidelidademundial.com/canw_auth/LoginPage.aspx

Simuladorescertupgrade.fidelidademundial.com certsimuladores.fidelidade.com

201500079_UPGRADE_OutSystems_18.05.2016



6 Testes de interface e regressão no FASTest

O FASTest é um programa de automação de testes que está a ser criado pela Fidelidade, com o intuito de auxiliar os testers da ATF nos testes repetitivos e com muitas variáveis (Ex: planos da NOVA OFERTA DE SAÚDE). Esta ferramenta é uma mais-valia no que diz respeito aos processos de criação de simulações, apó-lices, sinistros, entidades, etc.

Uma vez que as aplicações criadas pela Fidelidade processam uma grande quantidade de informação, por vezes testar todas as variáveis e combinações possíveis em cada uma das aplicações torna-se difícil e con-some muito tempo e recursos. O FASTest irá reduzir ambos e melhorar bastante a sua gestão e execução. Isto é, um plano de testes manual que pode levar uma semana, no FASTest corre em algumas horas e com o dobro das variáveis. Para além disso, os testes manuais apresentam alguns “vícios”, isto é, o utilizador aprende a contornar eventuais erros e irregularidades contidas no sistema, para prosseguir com o processo. A máquina não permite fazer isso. É objetiva e precisa, não há como dar “um jeitinho”.


Mantis – para registar as incidências.

CISN e FASTest – para execução de testes automáticos aos simuladores. Testes de regressão efetuados ao FASTest. Desenvolvimento do Interface do FASTest.

HP UFT – para captura dos objetos dos simuladores e carregamento dos mesmos no FASTest.

GIMP (programa de edição de imagem) – para criar os ícones e trabalhar o logotipo.

Outsystems – para implementar as alterações e carregar as imagens criadas para o FASTest.

6.2 Testes Regressivos

O programa FASTest está a ser desenvolvido diretamente na ATF. De momento está a ser desenvolvido pela colega Mónica Braga (tester) o plano de testes funcionais a levar a cabo assim que o programa esteja pronto. Entretanto estão a ser efetuados testes exploratórios e de regressão durante o processo de desen-volvimento, sempre que há alterações e melhorias na framework do FASTest.

O programa utilizado no desenvolvimento é o Outsystems, cujo logotipo é apresentado na Figura 39.

Figura 39 Logotipo do Outsystems



Figura 40 Ecrã de desenvolvimento no Outsystems

Na Figura 40 estão assinalados os módulos do FASTest nos quais eu trabalhei. No módulo Front-End, foram

feitos acertos ao nível da legibilidade dos conteúdos e ergonomia do interface, tendo em conta a facilidade de utilização por parte dos utilizadores. No módulo Images, foram feitas melhorias na imagética e no layout da framework. Essas intervenções são detalhadas mais à frente, no entanto é de mencionar que a minha formação no que diz respeito aos testes regressivos do FASTest, começou com a compreensão do funciona-mento do Outsystems.

Os testes de regressão no FASTest prendem-se maioritariamente com a execução das baterias de testes

já integradas11 para verificar se após a sua implementação, estas mantêm a sua integridade e correm sem problemas. Se se verificarem quebras, falhas ou bugs, estes são reportados diretamente no Mantis (Figura 41) na atividade “Fastest”, sem passar pelo TestLink, uma vez que ainda não há utilizadores envolvidos no processo de testes.

Figura 41 Incidências do FASTest carregadas no Mantis

11 Isto é, já existem casos de testes criados no programa que são novamente corridos a cada atualização.



6.3 Autom ação de Testes

A automação dos testes manuais no departamento da ATF é uma prioridade premente para aliviar a carga de trabalho repetitivo levada a cabo pelos testers da Fidelidade. O aumento da exigência no controlo de qualidade é também um fator determinante no desenvolvimento do FASTest. Isto porque, os simuladores de seguros que testamos internamente serão um dia disponibilizados diretamente ao cliente no site da Fi-delidade, para que este possa fazer uma pesquisa pessoal sobre o produto que melhor se adequa às suas necessidades.

Principalmente por estes motivos, o processamento massivo de dados nas aplicações da Fidelidade, pede a implementação de uma ferramenta como o FASTest, o mais rapidamente possível.

Uma das ferramentas usadas que auxilia o processo de testes no FASTest é o HP UFT. Esta ferramenta

rastreia os objetos virtuais que constituem um simulador (caixas de texto, botões, checkboxes, etc.), mape-ando-os para que possamos depois carregá-los no FASTest e “montar” o nosso teste. Uma vez que este procedimento consta no manual do FASTest, elaborado por mim, incluí os prints demonstrativos no Anexo 3. Após o carregamento dos objetos no HP UFT atualizamos o repositório das baterias de dados já existentes, ficando os novos objetos disponíveis para “montar” os casos de uso no FASTest.

Em seguida irei explicar o processo atual de criação dos projetos no FASTest. Primeiro criamos um novo projeto no separador “TEST PLAN DESIGN” (Figura 42).

Figura 42 Criação de um projeto dentro do TestPlanDesign (FASTest)

Neste passo é criado o projeto dentro do qual serão armazenadas as pastas dos testes (test suites), que por sua vez contêm os casos de teste (test cases), que são compostos por casos de uso (use cases), con-forme mostra o organigrama da Figura 43.

Figura 43 Organigrama do processo de gestão testes no FASTest

ProjetoPastas

de TesteCasos de

TesteCasos de

UsoObjetos



Figura 44 Criação de uma TestSuite dentro do Project (FASTest)

Dentro de um projeto podem existir várias pastas de teste (test suites). Estas são agrupadas pelo tipo de

ação executada nos testes (Figura 44 e Figura 45). Numa fase posterior, podemos por exemplo, criar um projeto de testes do simulador Saúde, onde irão

constar pelo menos duas suites, uma para a parte do simulador e outra para a parte da proposta.

Figura 45 Criação ou edição de um TestCase dentro da TestSuite (FASTest)

Dentro da pasta de testes, cabem, por exemplo, as oito combinações do quadro das recomendações

do simulador saúde12 e ainda o CT contido na atividade do TestLink (Figura 24 CT´s do BL2 do simulador saúde (TestLink)), que permite seguir na simulação sem escolher qualquer uma das opções do BL2.

12 Ver Figura 23 BL2 do simulador saúde, na página 28.



Figura 46 Criação ou edição de um UseCase dentro do TestCase (FASTest)

Na Figura 46 podemos verificar que dentro de um caso de teste são colocados os casos de uso (use

cases), que por sua vez são grupos de ações/objetos (Figura 47) capturados pelo HP UFT nos simulado-res. Um caso de uso pode ser constituído apenas por um step, no entanto o normal são pelo menos três (Ex: clicar, escrever, clicar).

Figura 47 ObjectList dentro do UseCase (FASTest)

Na Figura 47 podemos ver os steps do caso de uso da proposta do simulador saúde.



Figura 48 Quadro Edit Usecase Object dentro da ObjectList (FASTest)

Na Figura 48 podemos observar o quadro do “Edit Usecase Object”. É aqui que se adicionam os obje-

tos capturados pelo HP UFT (Figura 49) e que são armazenados no repositório do QTP113.

Figura 49 Galeria de objetos do simulador Auto no HP UFT

13 O QTP1 é a máquina virtual, onde se encontra instalado e onde está a ser desenvolvido o FASTest.



Figura 50 Separador da DATAPOOL, onde são criadas as tabelas de dados corridas durante os testes automáticos

No separador “DATAPOOL” (Figura 50), são configuradas as tabelas de dados para serem corridos em

determinados steps dos casos de uso. Por exemplo, num campo onde é necessário colocar um NIF, são carregados numa tabela vários números de contribuinte que são corridos nesse step. Isto é válido para No-mes, IBANS, Cartas de Condução, Matrículas, etc.

O meu trabalho na automação de testes consistiu no carregamento dos objetos dos simuladores para o

HP UFT e, seguindo o processo descrito anteriormente, fazer a montagem dos testes automáticos desses mesmos simuladores no FASTest, para depois correr os testes de regressão.



6.4 Des ig n de Comunicação

Esta parte do meu trabalho foi-me atribuída, devido à minha anterior formação (licenciatura) em Design de Equipamento, pela Faculdade de Belas Artes da Universidade de Lisboa, concluída em setembro de 2009. Tendo em vista este aspeto o coordenador José Reis achou por bem propor-me o desafio do desenvolvi-mento da imagem do FASTest, uma oportunidade que abracei com gosto e dedicação. Esta parte do meu trabalho em paralelo com os testes funcionais serviu para por em prática o conhecimento que adquiri nas duas áreas, testes de software e design. Uma completou a outra criando uma excelente dinâmica na execu-ção das tarefas que me foram atribuídas.

A renovação da imagem do FASTest prende-se com a já referida fusão da Império Bonança e Fidelidade

Mundial. Com esta fusão a companhia adquiriu o novo nome Fidelidade Seguros SA. e com ele a nova ima-gem da companhia (Figura 51).

Figura 51 Imagem atual da Fidelidade Seguros (Fidelidade, 2016)

Por uma questão de coerência, a imagem do FASTest deve seguir a da Fidelidade uma vez que é um

produto de sua autoria, e com potencial comercial.

6.4.1 O Logotipo

O conceito por trás da criação do logotipo prende-se com a automação dos testes manuais.

É uma mão que é mecanizada por um aparato que a

transforma numa ferramenta para apanhar “bugs”. O conceito foi esboçado pelo developer Carlos Cesteiro

que me pediu que o aperfeiçoasse (Figura 52). O logotipo deve ser uma imagem original, criada de raiz, seguindo a ideia que já existia, mas com uma nova abordagem.

Foram feitos vários esboços (Figura 53 e Figura 54) e limadas arestas para que a imagem idealizada fosse clara, precisa e objetiva, sem margem para interpreta-ções.

Optamos por uma imagem clássica, desenhada à mão,

o mais fiel à realidade possível (Figura 5514). Figura 52 Esboço feito por Carlos Cesteiro

14 A imagem da joaninha foi retirada do site (NoBacks, 2016)



Figura 53 Estudos para o Logo do FASTest

Figura 54 Estudo final do conceito aprovado

Figura 55 Produto final do logo do FASTest



6.4.2 Imagética

No seguimento da criação do logotipo e imagem do FASTest a imagética (ex. objetos, ícones, botões, alertas) deve possuir a mesma linguagem da Fidelidade.

A base do FASTest é o branco e o cinzento, tal como o site da Fidelidade (Figura 56).

Figura 56 Site www.fidelidade.pt (Fidelidade, 2016)

Para seguir esta linguagem foram criadas várias categorias de ícones organizados segundo uma hierar-

quia que faz sentido na estética do FASTest. Hierarquia de ícones:

Informativos do programa

Funcionais do programa

Informativos dos testes

Funcionais dos testes.

Este processo encontra-se ainda em desenvolvimento, e é de carácter evolutivo. Isto é, à medida que são criadas e melhoradas as funcionalidades, o colega Carlos Cesteiro e eu tentamos encontrar uma solu-ção visual que descreva e comunique da melhor maneira a ação ou funcionalidade criada.

Uma vez que o processo é orgânico e dinâmico, foi elaborada uma tabela ilustrativa desta hierarquia

que vai sendo atualizada consoante as necessidades do produto, com a nomenclatura organizacional para a imagética (Figura 57).

Dentro da hierarquia existem objetos, ícones, botões, alertas, etc. Todas estas componentes têm uma

localização específica na framework do programa pelo que é necessário apresentar esse caminho na de-signação da imagem. Essa linguagem é também aperfeiçoada à medida que vamos desenvolvendo o pro-grama e as imagens.



A tabela de relações dos ícones foi criada para que haja uma organização e uma melhor gestão das alterações dos e nos mesmos. Nesta tabela (Figura 57) podemos ver o estado atual do ícone e caso este não funcione por qualquer motivo, é desenvolvida uma nova versão, que é colocada na tabela, e após a implementação, a informação é atualizada em conformidade. Na tabela consta ainda a localização do ícone no programa e a sua respetiva flag15.

INFORMATIVOS DO PROGRAMA

Função Ícones Descrição/Nome Localização Correções Flags

Tab_Home

Menu_home2_fid Topo da barra do menu

- SEM FLAG

Tab_TestPlanDesign

Topmenu_TestPlan_fid Topo da barra do menu

- SEM FLAG

FUNCIONAIS DO PROGRAMA

Editar

Edit

Em todos os separadores onde haja necessidade de editar algo

- SEM FLAG

Sair do editar

Edit_Stop

Em todos os separadores onde haja necessidade de parar a edição

- SEM FLAG

INFORMATIVOS DOS TESTES

Test Steps off

testlab_test_steps_gr_fid TESTLAB – Plan List –TestSteps grey

- SEM FLAG

Test Result on

object_testplan_check_fid TESTLAB – Plan List –TestResult red

- SEM FLAG

FUNCIONAIS DOS TESTES

Test Runner

testlab_testrunner_runner_object_

TESTLAB – test runner - run

- Run Test

Ver ficheiro do relatório

object_view_fid TESTLAB – Plan List –TestResult – view rep file

- View report file

Figura 57 Exemplos da tabela de categorização dos ícones do FASTest.

Os ícones foram uniformizados com as cores da companhia (Figura 58).

Figura 58 Pantone aplicado ao FASTest no Outsystems

15 A flag é uma label ou etiqueta que surge ao passarmos o rato por cima do ícone, alguns ícones são acompanhados de um link descritivo

da sua ação e por esse motivo não possuem flag



Estes possuem (na sua maioria) um design skeuomorphico, isto é, plano e minimalista com uma ou

duas cores no máximo. Salvo uma ou outra exceção com tridimensionalidade.

6.4.3 Melhorias Ergonómicas da Framework

Após a elaboração dos primeiros ícones, eu e o colega Carlos Cesteiro fizemos uma revisão da fra-mework já criada, uma vez que com a nova imagética alguns aspetos já implementados deixaram de funcionar a nível visual e ergonómico. Fui então informada, que a base da framework (Figura 59) era para ser mantida de acordo com os requisitos, pelos que as alterações ao nível da interface deveriam incorporar e a adaptar-se à base.

Figura 59 Ambiente de trabalho do FASTest no Outsystems.

Houve uma alteração ao nível das labels dos separadores (tabs) que foram aumentadas, e por esse

motivo, faz sentido colocar a fonte das mesmas em maiúsculas (tal como no site). Esta alteração, jun-tamente com a uniformização dos ícones, torna a barra mais inteligível (Figura 60).

Figura 60 O antes e depois dos tabs de navegação do FASTest

Como se pode ver na Figura 60, também foi retirado o fundo vermelho por trás dos tabs, o que me-

lhora consideravelmente a visibilidade das imagens e a legibilidade do texto, reduz o ruído visual e aumenta o contraste da informação.



Os botões e as caixas de texto não possuem tridimensionalidade, tal como os ícones que são editados no formato PNG, sem fundo, o que faz com que o programa os processe mais facilmente, ficando mais rápido. As tabelas de apresentação dos testes e dos dados ficaram com uma base em cinzento claro com a grelha no mesmo tom. Uma linguagem mais depurada, objetiva e funcional, é a nossa visão para este projeto. Queremos também uma framework intuitiva e simplificada para melhorar a eficácia e o trabalho dos utilizadores.

Figura 61 Ecrã do TEST LAB, já com dados introduzidos e processados, no TestRunne, TestSteps e TestResult.

Na Figura 61 podemos ver os TestSteps, após o teste automático ter sido corrido no QTP1, com a indi-

cação dos TestResults em cada um dos steps. Em amarelo, encontra-se assinalada a minha intervenção.



Figura 62 Ecrã do TEST LAB, já com dados processados no TestResult.

Como podemos observar nas Figura 61 e Figura 62, ainda existem aspetos que devem ser melhorados,

mas a cada implementação das melhorias, as novas alterações surtem efeitos por vezes inesperados, que são posteriormente tratados. Ainda assim é visível uma notável melhoria a nível gráfico, na apresentação da informação.

O carregamento de dados no programa influencia o modo como estes são apresentados. Isto é, por vezes

o sistema crasha, os dados desaparecem, e é perdida informação ou esta é corrompida. As melhorias na programação impactam as alterações na framework e vice-versa. Durante o mês de Julho de 2016, altura em que existem menos operações a decorrer nas plataformas

informáticas, serão levadas a cabo várias implementações no núcleo de carregamento e processamento de dados do FASTest. Assim, as alterações que efetuei na framework durante o último mês de estágio (Junho) só serão implementadas após a conclusão desse processo. Por este motivo não pude incluir os prints dessas mesmas alterações no relatório.



6.5 Conc lusão

Para concluir este capítulo destaco que a minha prestação no FASTest foi uma agradável surpresa. Foi uma oportunidade dada pelo coordenador José Reis, onde pude exercer as minhas capacidades como de-signer a nível gráfico e ergonómico. Penso que foi uma abordagem visionária por parte do coordenador José Reis, que desta maneira juntou o melhor de dois mundos: as minhas aptidões como tester de software e designer de equipamento. Vejo esta situação como uma mais-valia, pois desta feita fiquei com uma melhor noção do reverso da medalha. Ver o programa simultaneamente pelos olhos do developer e dos utilizadores deu-me uma perspetiva mais abrangente do software em si, e de como procurar e resolver as anomalias ainda durante o processo embrionário do seu desenvolvimento.

Espero que com o meu regresso à empresa em Setembro a minha prestação no FASTest continue em paralelo com a atividade de testes, tal como até agora, pois penso conseguir agilizar bastante bem as duas funções e qualquer outro desafio que surja no meu percurso profissional dentro da ATF e da Fidelidade. Intelectualmente serão bem-vindos.



7 Conclusão Final

A título de conclusão devo referir que a minha experiencia de estágio excedeu em muito as minhas espec-tativas. Com o trabalho executado durante todas as tarefas referidas nos capítulos deste relatório superei-me a nível profissional e pessoal. Penso ter realizado um excelente trabalho, em todos os aspetos, sejam eles: a capacidade de adaptação a um novo ambiente com novos colegas e novas metodologias de trabalho, tão diferentes do ambiente académico, o que me levou a adaptar os meus conhecimentos letivos à realidade profissional de uma maneira dinâmica e proactiva; a gestão de tempo, pela capacidade que demonstrei na execução de várias tarefas em simultâneo; a vontade de trabalhar, ajudando os colegas e aceitando de bom grado os desafios que me colocaram; e acima de tudo, as relações interpessoais, com as quais cimentei ainda mais a minha capacidade de lidar com vários tipos de personalidades num ambiente onde a pressão impera e o trabalho não pode esperar.

Penso que por tudo o que já foi referido neste capítulo, e pela minha capacidade de trabalho em equipa referida nos capítulos anteriores, me foram atribuídas tarefas que estavam para lá do planeado no início do meu estágio. Com especial destaque para o desenvolvimento da imagem do FASTest e da reestruturação do OneNote, que não faziam parte do plano, mas nas quais adorei participar e saber que ao fim de dois meses de estágio já havia demonstrado as minhas capacidades e merecido tais tarefas.

No que diz respeito à maneira como lidei com os colegas, adaptei-me à sua maneira de ser respeitando a individualidade de cada um e aprendi o máximo que consegui com cada um dos colegas mencionados ao longo dos vários capítulos deste relatório. Faltou mencionar outros tantos, que também contribuíram bas-tante para o meu desempenho e bem-estar dentro da Fidelidade, mas com os quais não trabalhei direta-mente. São eles: a Filomena Rosário (tester), o Rui Santos (tester), o Luis Faria (tester), a Marta Pereira (tester) e a Fernanda Alves (tester), que contribuíram para me esclarecer dúvidas sobre procedimentos da ATF e da Fidelidade, e mais ainda para o excelente acolhimento que tive da parte de toda a equipa durante o meu estágio.

É por todos estes motivos que irei regressar à Fidelidade em Setembro, com energias renovadas e muita vontade de continuar o trabalho que iniciei, sempre à espera de novos desafios e outras tantas surpresas como as que surgiram durante este estágio que em tanto enriqueceu a minha vida profissional.

A todos os participantes nesta fase inicial da minha futura carreira, um sincero e sentido,

Muito Obrigada.



Bibliografia

ALTRANPORTUGAL, S.A. (Junho de 2016). About Us: Altran. Obtido de Altran: http://www.altran.pt/

Cristian Bogdan Rosu. (2016). Glypho Free Icons. Obtido de Glypho : http://glypho.eu/free-icons

Fidelidade. (Junho de 2016). About Us: Fidelidade. Obtido de Fidelidade: https://www.fidelidade.pt

Müller, T., Friedenberg, D., Beer, A., Graham, D., Veenendaal, E. v., Black, R., . . . Thomson, G. (2016). www.istqb.org. Obtido de ISTQB -

International Software Testing Qualifications Board: http://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html

NoBacks. (Maio de 2016). Nobacks Ladybug Seven. Obtido de NoBacks ISOLATED FREE STOCK PNG PHOTOS: http://nobacks.com/ladybug-

seven/

Pressman, R. S. (2011). Engenharia de Software (7 ed.). (BookMan, ABDR, Edits., & A. Griesi, Trad.) McGrawhill.

Sommerville, I. (2007). Engenharia de Software (8ª ed.). (A. Wesley, Ed., & S. S. Melnikof, Trad.) São Paulo: Pearson.



8 Anexos

Nos anexos consta a informação complementar do trabalho executado, mas que não é essencial para a compreensão do mesmo. Não obstante, é informação que fez parte do meu trabalho e é por isso relevante no meu estágio e dentro da Fidelidade.

Anexo 1 – Organ igram a da Histór ia da F ide l idade

Em seguida fica um organigrama ilustrativo do percurso empresarial da Fidelidade desde o ano de

1800.

Figura 63 Sequência de 3 imagens que compõem o organigrama da Fidelidade







Anexo 2 – Manual do FASTest

Prints do Manual do Fastest elaborado por mim (como captar objetos no HP UFT).

Prints do Manual do Fastest (como captar objetos no HP UFT).



O resto do manual encontra-se a aguardar a implementação das novas atualizações do programa.

Documents

Relatório de Estágio - bdigital.ipg.ptbdigital.ipg.pt/dspace/bitstream/10314/3734/1/Adriana Dias_1011858.pdf · t Tp daGuarda ESC() Ia S ti periei de Tecnologia e O estilo RELATÓRIO