fl

Tpï daGuardaEscola Superiorde Tecnologia e Gcsüio

RELATÓRIO DE ESTÁGIO

Curso Técnico Superior Profissional em

Testes de Software

Steven Afonso Portela

julho 1 2016

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

STEVEN AFONSO PORTELA

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

DE SOFTWARE

JULHO|2016

Escola Superior de Tecnologia e Gestão

Instituto Politécnico da Guarda

Escola Superior de Tecnologia e Gestão

Estágio realizado na Altran Portugal (Fundão)

Relatório de estágio realizado no âmbito da

unidade curricular de Estágio Curricular do

segundo ano do curso de Técnico Superior

Profissional de Testes de Software do

Instituto Politécnico da Guarda.

Orientador na instituição de ensino: Professor Doutor José Carlos Fonseca

Orientador na entidade acolhedora: Luís Miguel Barreiros

iii

Elementos identificativos

Nome do formando: Steven Afonso Portela

Número de aluno: 1011875

Docente orientador: Professor Doutor José Carlos Coelho Martins Fonseca

Instituição de estágio: Altran Portugal

Morada: Praça Amália Rodrigues – Pavilhão Multiusos

6230-350 Fundão

Morada Sede (Portugal): Av. D. João II - Lote 1.07.2.1 Piso 2

1990-096 Lisboa

Contactos: Telefone: +351 210 331 600

Fax: +351 210 331 639

E-mail: info@altran.pt

Ramo de atividade: consultoria de Tecnologia e Inovação

Orientador na entidade: Luís Miguel Barreiros

Duração do estágio: 4 meses (750h), início a 01 de março 2016

iv

Resumo

O presente documento foi escrito no âmbito da unidade curricular de Estágio,

prevista no segundo semestre do segundo ano do curso Técnico Superior Profissional de

Testes de Software, lecionado na Escola Superior de Tecnologia e Gestão, do Instituto

Politécnico da Guarda.

Além da apresentação da empresa Altran e do seu modelo de negócio, apresento

o conjunto de atividades realizadas ao longo dos quatro meses de estágio no projeto

Altran Corporate, onde se inclui o estudo de toda a documentação sobre novas

funcionalidades a serem implementadas, o planeamento dos testes e a sua execução.

Realço igualmente a importância da fase posterior aos testes, onde se retiram todas as

conclusões provenientes da execução, seja com vista à melhoria de metodologias de

trabalho, ao envio de pedidos de esclarecimento sobre determinado comportamento da

funcionalidade.

Em suma, pretendo que após a leitura deste relatório, conclua-se que testar é

mais do que a utilização da ferramenta de teste. Na verdade, essa é das etapas do ciclo

de desenvolvimento de um software, que menos tempo ocupa o tester.

Palavras-chave: Processo de testes; Qualidade de software; Release; Testes de

software; Testes de regressão.

v

Agradecimentos

The secret of getting ahead is getting started de Samuel Langhorne Clemens,

vulgarmente reconhecido por Mark Twain, é provavelmente dos melhores ensinamentos

que retiro do escritor e que se enquadra perfeitamente no desafio que foram estes dois

últimos anos.

Volvidos quatro anos de atividade profissional, o regresso ao mundo académico

e a todas as suas vicissitudes é feito com alguma resistência e reticência nas nossas

capacidades. A reconversão profissional pode ser entendida como resultado de opções

erradas no passado. Todavia, o passar do tempo tolda-nos a forma de pensar e como é

diferente a nossa visão do futuro aos 27 anos comparativamente aos 18.

Aliado à minha capacidade de comunicação, o ramo da comunicação e

multimédia foi a opção para o futuro, na qual os programas que utilizava eram

simplesmente para embelezar o que as palavras pretendiam transmitir. Todavia, a

precariedade laboral e o deslumbramento já inexistente por este ramo, levou-me de

cidade em cidade até ao contact center da Vodafone na Covilhã. Com competências de

back office, constatei o descontentamento de clientes e os custos elevados de que uma

falha pode ter para uma empresa.

O regresso à formação de longa duração deu-se no novo curso de testes de

software do Instituto Politécnico da Guarda, primeiro curso a nível nacional dedicado a

assegurar qualidade e fiabilidade ao nível do software. Agora em 2016, confirmo como

pode ser estimulante esta área profissional, uma vez que esta é pautada pela ausência de

tarefas repetitivas e pelo imprevisto.

Valorizo por isso, o esforço e empenho que todos os docentes do Instituto

Politécnico da Guarda tiveram, na transmissão da informação para um público-alvo não

relacionado com as tecnologias da informação. Em particular, gostaria de agradecer aos

consultores da Altran que lecionaram algumas unidades curriculares do curso, em

particular ao Luís Barreiros, que além de formador, foi o meu orientador na empresa.

Em todos os momentos permitiu sugestões e liberdade na execução das tarefas,

possibilitando que em momento algum me sentisse como estagiário, mas antes como um

consultor. Tal comportamento transmite a confiança necessária a quem é novo na área,

na empresa e no projeto e, como tal, quer demonstrar conhecimento. O mérito dele é

vi

também o mérito da equipa, que funciona tal como o significado da palavra. É graças a

eles que consegui uma evolução diária no meu desempenho profissional.

Por fim, uma última palavra ao professor José Carlos Fonseca pelo seu empenho

e disponibilidade permanente. O sucesso desta primeira edição do curso é em grande

parte, o seu.

vii

Índice

Elementos identificativos .............................................................................................. iii

Resumo ........................................................................................................................... iv

Agradecimentos .............................................................................................................. v

Índice.............................................................................................................................. vii

Índice de figuras............................................................................................................. ix

Índice de tabelas.............................................................................................................. x

Glossário ......................................................................................................................... xi

Capítulo I - Introdução ................................................................................................ 15

Objetivos propostos ................................................................................................................ 15

Descrição da entidade de acolhimento ................................................................................... 16

Estrutura do relatório .............................................................................................................. 19

Capítulo II - Enquadramento teórico e a sua aplicação prática .............................. 20

Objetivo dos testes de software .............................................................................................. 20

Terminologia dos testes .......................................................................................................... 21

Testes através do ciclo de vida de um software ...................................................................... 21

Níveis de teste ........................................................................................................................ 24

Processo de teste na Altran Corporate .................................................................................... 27

Capítulo III - Projeto ASC-TRA-Hermes .................................................................. 29

Apresentação da equipa .......................................................................................................... 29

Importância do modelo de negócio da Altran para os testes ................................................... 30

Responsabilidades dos stakeholders ................................................................................... 31

Ferramentas utilizadas ............................................................................................................ 32

SharePoint Server 2007 ...................................................................................................... 33

EasyVista ........................................................................................................................... 33

JIRA ................................................................................................................................... 34

Zephyr ................................................................................................................................ 35

Deltek Maconomy .............................................................................................................. 36

Ranorex Studio ................................................................................................................... 37

Relação da utilização das aplicações com o processo de teste ............................................ 38

Capítulo IV - Atividades desenvolvidas ...................................................................... 39

Análise de requisitos – Specify .............................................................................................. 40

viii

Desenho de planos de testes – Design e Develop ................................................................... 41

Execução de testes – Test ....................................................................................................... 44

Manutenção dos testes – Run ................................................................................................. 44

Sugestões de alterações nas atividades de teste baseadas nas lessons learned ........................ 45

Rácio tempo/atividade desenvolvida ...................................................................................... 46

Capítulo V - Considerações finais ............................................................................... 48

Bibliografia .................................................................................................................... 50

Anexos ............................................................................................................................ 51

ix

Índice de figuras

Imagem 1 – Localizações da Altran ............................................................................ 16

Imagem 2 - Setores de atividade da Altran Portugal ................................................ 17

Imagem 3 - Instalações Altran no Fundão ................................................................. 18

Imagem 4 - Interior das instalações Altran Fundão .................................................. 18

Imagem 5 - Alguns clientes da Altran Portugal (2015) ............................................. 18

Imagem 6 - Custo relativo para corrigir um defeito - Adaptado de Altran

Corporate Test Center (2014) .............................................................................. 22

Imagem 7 - Modelo de Ciclo de Vida em “V” (Pressman, 2000).............................. 23

Imagem 8 - Modelo em Espiral (Boehm, 1981) .......................................................... 23

Imagem 9 - Modelo Agile, adaptado de Cohen, Lindvall & Costa (2004) ............... 24

Imagem 10 - Imagem representativa do nível de teste integração na ferramenta de

execução Maconomy ............................................................................................. 25

Imagem 11- Imagem representativa do nível de teste de sistema na ferramenta de

execução Maconomy (ambiente pré-produção) .................................................. 26

Imagem 12 - Imagem representativa do nível de teste de aceitação na ferramenta

de execução Maconomy (ambiente QA) .............................................................. 26

Imagem 13 - Fluxograma representativo do processo de testes na Altran Corporate

................................................................................................................................. 27

Imagem 14 - Representação das atividades de teste da equipa ASC-TRA ............. 29

Imagem 15 - Competências da equipa de testes ASC-TRA ...................................... 30

Imagem 16 – Modelo de negócio Altran Corporate .................................................. 31

Imagem 17 - Imagem representativa da utilização Sharepoint ................................ 33

Imagem 18 - Imagem representativa da utilização do EasyVista ............................ 34

Imagem 19 - Imagem representativa da utilização do JIRA .................................... 35

Imagem 20- Imagem representativa da utilização do Zephyr .................................. 36

Imagem 21 - Imagem representativa da utilização do Maconomy .......................... 37

Imagem 22 - Imagem representativa da utilização Ranorex Studio ........................ 37

Imagem 23 - Calendário de atividades previstas em cada release ........................... 40

Imagem 24 - Estudo de impacto das novas funcionalidades e dos testes a executar

(release de junho) ................................................................................................... 41

x

Imagem 25 - Estudo de impacto das novas funcionalidades e dos testes a executar

(release de julho) .................................................................................................... 42

Imagem 26 - Alteração do passo número 9 do caso de teste 513 - Finance

Reconciliation (Zephyr)......................................................................................... 43

Imagem 27 - Alteração do passo número 11 do caso de teste 513 - Finance

Reconciliation (Sharepoint) ................................................................................... 44

Imagem 28 - Funcionalidade "Blanket Credit Memo" retirada da implementação

na release de abril .................................................................................................. 45

Imagem 29 - Rácio de tempo - atividade desenvolvida ............................................. 47

Índice de tabelas

Tabela 1 - Responsabilidade dos stakeholders no modelo de negócio ...................... 32

Tabela 2 - Representação da relação entre as ferramentas utilizadas em cada

processo de teste .................................................................................................... 38

Tabela 3 - Alterações de atividades de teste, baseadas nas lessons learned ............. 46

xi

Glossário

Termo Definição

Addon Aplicativos que potenciam ou personalizam as

caraterísticas originais das ferramentas de teste.

Ambiente de teste Ambiente de teste é onde o teste é executado,

compreendendo todas as configurações de

hardware, software e documentação. A sua

finalidade é possibilitar a realização de testes

em condições conhecidas e controladas, o mais

próximo às que o utilizador terá na utilização

em ambiente real.

ASC-TRA Application Service Centre – Testing & Quality

Assurance: Sigla representativa da equipa de

testes onde desempenhei funções no projeto

Altran Corporate.

Caso de Teste – test case Descreve uma condição particular a ser testada

e é composto por valores de entrada, restrições

para a sua execução e um resultado ou

comportamento esperado.

Cobertura dos testes A cobertura dos testes é a “medida” da

abrangência do teste. No âmbito dos testes é

expressa pela cobertura dos requisitos e os seus

casos de teste relacionados.

Critérios de entrada – entry

criteria

Conjunto de condições específicas que evitem

que uma atividade (geralmente um teste)

implique mais esforços ou recursos como

tempo, em comparação com o esforço que é

necessário.

xii

Critérios de saída – exit criteria Conjunto de condições genéricas e específicas,

previamente acordadas, que permite que um

processo seja oficialmente considerado

concluído.

Os critérios de saída são utilizados nos

documentos de estratégia de testes para planear

o momento de interromper os testes.

Dashboard Expressão utilizada para indicar um "painel de

indicadores".

Debug Atividade de desenvolvimento que deteta,

analisa e remove acausa da falha, efetuada

geralmente pelo programador.

Evidências de teste – test

evidences

Documento formal elaborado geralmente por

quem executa o caso de teste, com o resultado

e a demonstração das evidências de todas as

atividades de teste executadas. Deve incluir

geralmente toda a informação sobre o teste

efetuado como o ambiente de testes, passos e

resultados esperados, data de execução. Serve

igualmente como referência para aprendizagem

futura (lessons learned).

ISTQB O International Software Testing

Qualifications Board, é uma entidade que

oferece uma estrutura de certificação em testes

de software.

Lições aprendidas - Lessons

learned

Terminologia utilizada na Engenharia de

Software para quaisquer alterações nas

metodologias de trabalho, processo ou

atividade de teste, resultantes de uma

necessidade anterior.

xiii

Plano de teste – test plan Documento formal que descreve o âmbito,

descrevendo, os recursos e o cronograma das

atividades de teste, quem testa o quê, os

critérios de entrada e de saída a serem

adotados. Contém igualmente os eventuais

riscos que podem ocorrer e os planos de

contingência se aplicável.

Prioridade de testes – test priority Nível de importância atribuída a uma

funcionalidade, seja com efeito de testes,

desenvolvimento ou impacto no software já

existente, sendo por isso estabelecida através

de uma avaliação de risco.

Release Previamente planeada ao nível de duração e de

funcionalidades a desenvolver, considera-se

por release a conclusão de um ciclo de

desenvolvimento e a entrega final de uma

versão do produto.

Stakeholders Termo utilizado na Engenharia de Software

que designa o conjunto de pessoas relacionadas

ou interessadas com o planeamento e

resultados do desenvolvimento de uma solução.

Técnica de teste baseada na

experiência - Experienced based

testing

As técnicas de teste baseadas na experiência

baseiam-se no conhecimento adquirido por

parte dos intervenientes, sejam programadores

ou testers, e na sua intuição de antecipar erros.

Testers Profissional especializado para executar os

diferentes tipos de teste.

Testes de aceitação – Acceptance

testing

Testes realizados por stakeholders, a fim de

determinar se um componente ou sistema

satisfaz as necessidades previstas, dentro dos

xiv

processos de negócios existentes.

Testes ad-hoc Execução de testes sem um documento de

testes formal estabelecido (test plan).

Testes End-to-End (E2E) Metodologia de testes utilizada para testar os

fluxos e assegurar que a informação é

transmitida entre os diversos sistemas sem

incoerências.

Testes funcionais Os testes baseados em características e no

comportamento esperado e obtido do software,

devidamente registado em documentos, sendo

por isso um tipo de teste em caracterizar o que

é suposto o software executar.

Testes não funcionais Testes baseados em aspectos que se baseiam

em caracterizar como funciona a solução ao

nível de desempenho, fiabilidade, portabilidade

ou usabilidade, e não na sua utilidade/função.

Testes de manutenção Qualquer alteração efetuada numa solução de

software após o seu desenvolvimento e

implementação, de forma melhorar o

desempenho, funcionalidades ou correção de

defeitos.

Testes de regressão Os testes de regressão consistem na repetição

de um caso de teste que detetou um defeito

anteriormente. O objetivo é confirmar que a

correção desse defeito não teve impacto

noutras funcionalidades.

UAT User Acceptance Testing.

Termo utilizado para designar o nível de teste

de aceitação efetuado no processo de teste da

Altran Corporate.

15

Capítulo I - Introdução

O estágio consiste numa aprendizagem social, cultural, na qual é demonstrada a

contextualização profissional de todos os conhecimentos adquiridos durante o período

de formação.

Neste estágio curricular do TeSP em Testes de Software estive integrado na

Altran Corporate, de 1 de março a 30 de junho do presente ano.

Objetivos propostos

Na Altran Corporate fui integrado no projeto Hermes, que se dedica

essencialmente à manutenção de software e garante a gestão financeira de todos os

projetos do grupo. Dentro desse projeto desempenhei funções de consultoria tecnológica

nas diversas vertentes da área de testes de software, das quais destaco a identificação de

exigências funcionais, elaboração de documentação de resultado de testes e anomalias,

aplicação de metodologias dos testes funcionais, de regressão e automáticos, todos

conceitos amplamente abordados ao longo do curso de TeSP em Testes de Software.

Especificamente, os meus objetivos foram:

1. Preparar a execução de testes, através da avaliação prévia do possível

impacto de novas funcionalidades nas já existentes;

2. Execução de testes funcionais e de regressão, através de uma ferramenta

ERP (Enterprise Resource Planning), em ambientes de teste próximos do

ambiente real de produção;

3. Identificação de anomalias mediante o resultado obtido da execução de

testes;

4. Desenhar casos de teste funcionais, de regressão e automáticos;

5. Participar em sessões de teste integrados (end to end) com outros

domínios do projeto Altran Corporate tais como: CRM (Customer

Relationship Management) ou ERM (Environmental Resources

Management);

16

6. Colaboração com membros de outras equipas da Altran Corporate

(programadores, utilizadores da área de negócio, etc);

Descrição da entidade de acolhimento

A Altran é uma empresa multinacional francesa fundada em 1982, cuja principal

atividade baseia-se na consultoria tecnológica, visando responder aos desafios dos seus

clientes em termos de inovação e assegurar valor e os padrões qualidade na área das

tecnologias de informação. O grupo conta já com mais de 25.000 colaboradores em

mais de 20 países (Imagem 1) [1].

Imagem 1 – Localizações da Altran

Em Portugal desde 1998, a empresa reúne cerca de 900 colaboradores,

distribuídos por quatro setores de atividade (Imagem 2) e está presente em três cidades:

Lisboa onde se situa a sede, no Porto e no Fundão, onde se situa a sua Global Delivery

Center (GDC).

17

Imagem 2 - Setores de atividade da Altran Portugal

Este conceito diferenciador de GDC [2] baseia-se em serviços externos de

proximidade, isto é, na transferência dos processos de negócio dos clientes para

localizações especializadas da Altran, em países próximos geograficamente e com todas

as condições de trabalho adequadas ao desempenho de funções (Imagem 3 e Imagem 4).

A vantagem dos pressupostos desta abordagem para os clientes da Altran (Imagem 5),

visam essencialmente o contacto permanente e a reutilização de processos, pois permite

criar metodologias de trabalho padronizadas e assim diminuir os riscos naturais de

independência entre equipas nas diversas fases do ciclo de vida de desenvolvimento de

um software.

Comité Executivo da Altran Portugal [3]

José Ramon Magarzo Célia Reis

Presidente Executivo Diretora Geral

Maria da Luz Penedos Susana Chaves

Diretora Técnica e Diretora de Diretora Financeira e

Marketing & Comunicação Diretora de Recursos Humanos

18

Instalações do Fundão

Imagem 3 - Instalações Altran no Fundão

Imagem 4 - Interior das instalações na Altran Fundão

Alguns clientes da Altran Portugal

Imagem 5 - Alguns clientes da Altran Portugal (2015)

19

Estrutura do relatório

O presente relatório de estágio encontra-se organizado em cinco capítulos:

No capítulo 1, Introdução, é realizada a apresentação ao presente relatório, onde

é descrito em detalhe a entidade de acolhimento, o âmbito e os objetivos do estágio.

O capítulo 2, Enquadramento teórico e a sua aplicação prática, visa apresentar

sucintamente os príncipios fundamentais obtidos no decorrer do período de formação e

que de alguma forma serviram de base à adaptação eficaz em contaxto laboral.

No capítulo 3, projeto ASC-TRA-Hermes visa apresentar a equipa, os processos

de teste, conceitos chave, a sua integração com as restantes equipas do projeto Altran

Corporate, as ferramentas utilizadas e metodologias adotadas.

No capítulo 4, Atividades desenvolvidas, encontram-se descritas as diversas

atividades realizadas ao longo do estágio, desde a análise de documentação, preparação,

execução dos testes, deteção e o encaminhamento das anomalias para correção por parte

da equipa de desenvolvimento.

Por fim, o capítulo 5, Considerações finais, é dedicado a analisar todo o meu

contributo na equipa, desde os pontos fortes a algumas dificuldades encontradas.

Com esta estrutura pretende-se abordar em concreto o trabalho desenvolvido ao

longo do estágio, fazendo a ponte entre os conceitos teóricos obtidos no curso, aos

objetivos propostos no plano de estágio, passando pela especificação do trabalho

desenvolvido, finalizando com um conjunto reflexões finais. É também parte integrante

deste relatório os Anexos, onde se inclui a documentação que se considera essencial à

percepção das atividades desenvolvidas.

20

Capítulo II - Enquadramento teórico e a sua aplicação

prática

Nos últimos anos, com a crescente demanda tecnológica principalmente

proveniente da internet das coisas, tem-se constatado o aumento de competitividade no

mercado de desenvolvimento de software, de forma a atender às necessidades dos

consumidores. No entanto, o que poderia ser um ponto favorável na seleção de um

produto, acaba por dificultar a escolha dos utilizadores. É reconhecido que um software

que não funciona corretamente pode provocar muitos problemas, incluindo perdas de

tempo, dinheiro ou descrédito empresarial o que nesta área de negócio poderá significar

o fim de linha para uma empresa.

Assim, a aposta das empresas de desenvolvimento de software passa pela

obtenção de certificações, padronização de processos, de forma a garantir a obtenção de

qualidade do que desenvolvem e obter o tão difícil reconhecimento dos consumidores.

Objetivo dos testes de software

Transversalmente a diversas áreas de negócio, projetos mal sucedidos e com

prazos ultrapassados, conduzem à insatisfação dos clientes, a gastos elevados com

manutenção e comprometem a notoriedade da empresa. Todavia, além da vertente

financeira, existem outros benefícios dos testes desde a otimização de processos nas

diversas etapas de desenvolvimento (sejam requisitos, documentação, critérios de saída

para conclusão dos testes), garantia de entrega dos requisitos propostos e o custo final

da resolução de erros, pois quando um erro detetado cedo, o custo é menor na sua

resolução.

Assim, no mercado de software em concreto, a necessidade de criar produtos

fiáveis tem conduzido as empresas à procura de modelos e processos que garantam

qualidade de forma a satisfazer as necessidades dos seus clientes. Em inúmeras ocasiões

ao longo do período de formação, foi-nos transmitido pelos docentes, que as únicas

verdades irrefutáveis na área de testes de software, é que da mesma forma que é

21

impossível testar todas as funcionalidades, este nunca está isento de falhas. Aliás,

grande parte destas falhas ocorre pela pressão do tempo, pela complexidade das

infraestruturas e variedade na interação entre diferentes sistemas. Um teste de software

é então uma forma de prevenção de riscos sistémicos num sistema.

Terminologia dos testes

No desenvolvimento de qualquer produto de software, deve existir o cuidado de

disponibilizar documentação adequada, com linguagem e termos acessíveis a qualquer

utilizador, de modo a que este saiba como utilizar o software e se este é adequado às

suas reais necessidades. Nesse sentido, normas de software como o IEEE N.º 610.12-

1990, garantem além da padronização de processos a padronização de conceitos, de

modo a que o qualquer utilizador possa compreender a documentação. Por exemplo,

esta norma diferencia os seguintes termos:

Engano (mistake): processo ou definição de dados incorrecto, como por

exemplo, comando incorrecto realizado por um humano;

Defeito (anomalia, defect, bug): produção de uma saída incorrecta em relação ao

especificado;

Erro (error): diferença entre o valor obtido e o valor esperado, ou seja, qualquer

estado intermédio incorreto ou resultado inesperado na execução do programa constitui

um erro;

Especificação dos requisitos: tudo o que se pretende de um determinado sistema

ou produto.

Testes através do ciclo de vida de um software

A resposta à questão “Porquê testar?” está diretamente relacionada com a

importância dos testes [4]. O custo de correção de um defeito aumenta substancialmente

consoante a fase do ciclo de vida de desenvolvimento onde é detetado (Imagem 6).

22

Imagem 6 - Custo relativo para corrigir um defeito - Adaptado de Altran Corporate Test Center (2014)

Desta forma, os testes devem começar desde o início do processo de

desenvolvimento, com o levantamento e revisão exaustiva dos requisitos e devem

continuar após o produto esteja concluído (testes de manutenção), implementado e

aceite pelo cliente.

Pode-se então afirmar que as diversas atividades de teste incluem: fase de

planeamento com base na documentação existente, análise do tipo de testes a aplicar

(sejam funcionais, não funcionais, estrutura ou regressão), conceção e execução dos

casos de teste, análise dos resultados e evolução dos testes (métricas), encaminhamento

de anomalias e avaliação dos critérios de saída (exit criteria).

Nas unidades curriculares de Fundamentos de Testes de Software, Análise de

Requisitos e Engenharia de Software, verificámos que existem diversos modelos de

desenvolvimento. Em comum, todos eles atestam que os testes não existem

isoladamente, as atividades de teste estão relacionadas com o desenvolvimento, são

parcialmente ordenadas, com a finalidade de obter o software como produto final.

Alguns dos modelos de desenvolvimento de software mais utilizados são:

Modelos sequenciais, onde se incluem o modelo Waterfall (cascata) ou o modelo

em V; modelos iterativos ou incrementais como o RAD (Rapid Application

Development) ou RUP (Rational Unified Process), modelo em espiral ou o modelo

Agile.

23

Neste tópico abordam-se três modelos, um mais recente e bastante utilizado, o

modelo em V que se aplica ao projeto onde fui inserido, um exaustivamente abordado

durante o período de formação, o modelo em espiral e por fim, o modelo Agile.

O modelo em V tem a particularidade de cada módulo no processo de

desenvolvimento ser sujeito a uma avaliação, verificação, validação e teste, em que só

se avança para a fase seguinte se todos os aspetos previstos do projecto naquela fase se

encontrarem conforme as exigências de verificação e validação (Imagem 7).

Imagem 7 - Modelo de Ciclo de Vida em “V” (Pressman, 2000)

Considero que a grande particularidade deste modelo passa por reforçar o

conceito de que o teste é uma parte integrante do ciclo de desenvolvimento do software.

O modelo em espiral carateriza-se por ser um modelo iterativo, em que os riscos

são considerados e avaliados à medida que cada evolução é realizada.

Imagem 8 - Modelo em Espiral (Boehm, 1981)

24

Por exemplo, cada passagem pela parte do planeamento resulta em ajustes nos

requisitos iniciais obtidos do cliente, sendo o custo e os protótipos adequados conforme

o parecer do mesmo a cada iteração.

Por fim, o modelo Agile que é cada vez mais aplicado no desenvolvimento de

novas soluções. Com a constante demanda por novas versões, novas funcionalidades

para uma crescente variedade de equipamentos e plataformas, os métodos ágeis

caraterizam-se por minimizar o risco através do desenvolvimento e entregas ao cliente

em curto espaço de tempo (sprints), geralmente um mês e incluírem as diversas fases

previstas para um modelo de desenvolvimento dito “tradicional”. Outra particularidade

passa pela simplicidade de processos, destacando a importância da comunicação e o

envolvimento de todos os intervenientes.

Imagem 9 - Modelo Agile, adaptado de Cohen, Lindvall & Costa (2004)

Níveis de teste

Considera-se que a introdução de um modelo de desenvolvimento é uma das boas

práticas aplicadas à Engenharia de Software. Independentemente do modelo adotado, é

reconhecido pelos programas de certificação de testes como o ISTQB, que o

planeamento dos testes deve ocorrer em paralelo ao desenvolvimento do produto e em

diferentes níveis. Por níveis de teste entendem-se os objetivos genéricos, os casos de

teste, o que deve ser testado, os defeitos mais comuns, requisitos de equipamento de

teste, as suas configurações, etc.

Em detalhe:

Testes de componentes ou unitários: este nível carateriza-se por ser aplicado a

um low level isto é, ainda não há a solução propriamente dita e apenas é testado

25

o código, o funcionamento dos módulos e componentes, sendo geralmente

efetuado pelo programador que fez o desenvolvimento. Normalmente é efetuado

o debug e todas as anomalias encontradas são corrigidas, sem a necessidade de

efetuar uma gestão formal das mesmas como por exemplo um plano de teste;

Testes de Integração: fase posterior ao desenvolvimento, o nível de teste de

integração consiste na junção dos diversos módulos. Durante o estágio foi com o

objetivo de testar as interfaces entre os diversos componentes e as interações

entre as diferentes partes do sistema tais como, o sistema operativo, sistema de

arquivos, base de dados, etc.

Imagem 10 - Imagem representativa do nível de teste integração na ferramenta de execução Maconomy

Testes de Sistema: Os testes de sistema verificam o comportamento de toda a

solução, incluindo a conformidade de todas as especificações de requisitos,

sendo relevante a execução de testes baseados num guião previamente

estabelecido, como um plano de teste. O ambiente de teste deve corresponder o

máximo possível ao ambiente de produção, de modo a minimizar os erros

devido a problemas de interface entre ambientes e garantir a máxima fiabilidade

dos testes aplicados.

26

Imagem 11- Imagem representativa do nível de teste de sistema na ferramenta de execução Maconomy

(ambiente pré-produção)

Testes de Aceitação: nível de teste direcionado às necessidades dos

utilizadores, requisitos e processos do negócio. O objetivo destes passa pelo

estabelecimento da confiança no sistema antes da sua disponibilização final,

permitindo obter um parecer se o sistema satisfaz ou não os critérios que

permitam a decisão de aceitação ou não da solução desenvolvida.

Imagem 12 - Imagem representativa do nível de teste de aceitação na ferramenta de execução Maconomy

(ambiente QA)

27

Processo de teste na Altran Corporate

No seguimento dos tópicos anteriores, pode-se concluir que testar um software

compreende uma conjugação de fatores, desde a adequação dos tipos de teste, os seus

objetivos em cada nível de teste e a etapa de desenvolvimento onde se encontra. Neste

contexto, se o ciclo de vida consiste numa série de etapas que visam definir como os

testes são conduzidos no projeto, o processo de teste tem como objetivo estruturar as

atividades, as responsabilidades do teste, permitindo a organização e o controlo efetivo

de todo o ciclo [5], minimizando os riscos.

No caso particular do projeto Altran Corporate (Imagem 13), a implementação

do processo de teste permite que o teste deixe de ser tratado como uma atividade

secundária, passando a ser um processo próprio, condutor do fluxo das atividades do

próprio software em desenvolvimento, possibilitando a avaliação constante da qualidade

do software pelas diversas fases do desenvolvimento.

Imagem 13 - Fluxograma representativo do processo de testes na Altran Corporate

No processo de teste aplicado na Altran Corporate, depreende-se:

28

Quem são os intervenientes (stakeholders): utilizadores finais, gestores de

projeto (BISM), programadores e equipas de teste unitários (TMA/DEV), testers

funcionais e de regressão (TRA) e restantes utilizadores das diversas aplicações

existentes no universo da empresa e que formulam um pedido de implementação

ou alteração de funcionalidades já existentes;

As diversas fases no ciclo de vida de desenvolvimento de software: Identify

(identificação de requisitos/necessidades), Specify (especificação de testes),

Develop (desenvolvimento), Test (testes), Run (aceitação e implementação da

solução);

Marcos importantes: reuniões envolvendo os intervenientes interessados

dependendo da fase de desenvolvimento onde ocorrem, especificação

(Specification), aceitação (Acceptance) e a entrega do módulo, a integração,

aceitação (Package delivery).

Considero igualmente importante realçar, que todas as atividades de teste

incluem algum tipo de documentação que quando é validada, dependendo do volume de

funcionalidades a desenvolver na release, é sempre alvo de priorização.

Aquando do início do estágio, este processo de testes implementado na Altran

Corporate, possibilitou perceber de imediato qual o modelo de desenvolvimento

aplicado no projeto (no caso o V), quem aceita/valida a funcionalidade ou o resultado

dos testes em cada nível de teste (UAT Control) e quais os tipos de teste a aplicar pela

equipa onde fui inserido, neste caso, testes funcionais e de regressão (TNR) (ver

glossário).

29

Capítulo III - Projeto ASC-TRA-Hermes

Na Altran Corporate, fui integrado na equipa de testes ASC-TRA, projeto

Hermes. Este é direcionado à gestão de todos os projetos do grupo Altran, sendo que as

minhas funções principais passaram pela avaliação do possível impacto de novas

funcionalidades nas já existentes, através da execução de testes de regressão com uma

ferramenta ERP, em ambientes de teste próximos do ambiente real de produção, e a

consequente identificação de anomalias mediante o resultado obtido.

Nas secções seguintes detalho um pouco mais qual a responsabilidade de cada

membro da equipa, a importância do modelo de negócio na atividade de testes do

projeto Hermes e as ferramentas que foram utilizadas.

Apresentação da equipa

Composta em 2015 com quatro elementos, a ASC-TRA é a equipa de testes da

Altran Corporate, responsável pelos testes da gestão financeira do grupo Altran. Estes

testes são realizados em ambiente de integração (INT) e pré-produção (Pre-prod), ou

seja, testes próximos da aceitação final da solução desenvolvida. Na verdade, a

implementação só entra em ambiente real de produção (Imagem 14) quando todos os

testes foram executados e sem anomalias detetadas.

Imagem 14 - Representação das atividades de teste da equipa ASC-TRA

Desde 2015 até ao presente, fruto da maturação de processos, de novas

ferramentas adquiridas para o planeamento, gestão e execução de testes, a equipa ASC-

TRA tornou-se responsável pelos testes a todas as áreas de domínio do negócio da

30

Altran e que serão mais detalhadas na secção seguinte: ERP através do projeto Hermes,

CRM no projeto Sales Force e ERM pelo projeto Linx.

Na Imagem 15, apresento a composição da equipa e as funções desempenhadas.

Imagem 15 - Competências da equipa de testes ASC-TRA

Importância do modelo de negócio da Altran para os testes

O objetivo de qualquer modelo de negócio, numa perspetiva simplista, é garantir

que a empresa aumenta os seus lucros. Para tal, garante-se o aumento das vendas ou a

redução de encargos. Numa empresa multinacional com a dimensão da Altran, esta teve

a necessidade de adquirir aplicações CRM (Customer Relationship Management), ERP

(Enterprise Resource Planning) e ERM (Environmental Resources Management), de

forma a garantir a estratégia do modelo de negócio, permitindo a partilha e coordenação

da informação de toda a organização.

O modelo de negócio aplicado na Altran (Imagem 16) resume-se à sequência de

processos entre os diversos domínios e as suas ferramentas.

31

Imagem 16 – Modelo de negócio Altran Corporate

Especificamente, todos os negócios realizados pelo grupo são geridos pelo CRM

através da ferramenta New Biz – Sales Force. Quando uma oportunidade de negócio dá

entrada nesse sistema e é garantida (won), é enviado para o ERP (Maconomy) todos os

dados referentes ao cliente, incluíndo o seu ramo de atividade e o DUNS, que na prática

é o código id, único de cada cliente na Altran.

A partir deste momento, é o ERP que assegura a gestão financeira, por via da

criação de projetos e a associação destes às empresas clientes contratantes, permitindo

que a Altran consiga facilmente obter uma previsão financeira quer do lucro que pode

vir a ter com esse projeto, quer dos encargos.

Por encargos entendem-se a alocação de consultores da Altran que sejam

necessários à realização desse projeto, efetuada através da ferramenta ERM, o Linx.

Responsabilidades dos stakeholders

Num modelo de negócio de uma empresa multinacional, as responsabilidades de

cada interveniente devem ser bem delineadas. Na Tabela 1, descrevo a função de cada

elemento dentro do modelo de negócio descrito na secção anterior.

32

Cargo Responsabilidade

Utilizadores da área de

negócio (key users)

Rever documentos como planos de teste (test plan) e o

desenho de casos de teste;

Esclarecer dúvidas sobre o funcionamento ou comportamento

esperado de uma determinada funcionalidade;

Estabelecer critérios de aceitação;

Gestores das diversas

áreas de negócio do

grupo Altran

Esclarecer dúvidas sobre o funcionamento ou comportamento

esperado de uma determinada funcionalidade;

Validar os critérios de aceitação estabelecidos pelos

utilizadores do negócio, sejam consultores, gestores ou

managers;

Assegurar a disponibilidade dos diversos ambientes de teste;

Test Manager / Project

Manager

Gerir equipa de testes e as suas responsabilidades;

Estabelecer o plano de testes;

Validar o desenho dos casos de teste;

Monitorizar a execução de testes;

Elaborar e disponibilizar reportes de execução de testes

periódicos;

Tester

Elaborar planos de teste;

Monitorizar a execução de testes;

Executar casos de teste;

Gestão das anomalias encontradas e o seu ciclo de vida até à

resolução no JIRA.

Tabela 1 - Responsabilidade dos stakeholders no modelo de negócio

Ferramentas utilizadas

Apresento de seguida todas as ferramentas utilizadas em âmbito de estágio.

Apesar de nenhuma ter sido diretamente abordada durante o curso, as que foram

referidas na unidade curricular Ferramentas de Teste como o Testlink (ferramenta de

gestão de testes), HP Quality Center (ferramenta de gestão de testes) ou o Mantis

(ferramenta de gestão de anomalias), contribuíram para a rápida aprendizagem em

33

contexto profissional, uma vez que acabam por ter funcionalidades e propósitos

similares às que utilizei.

SharePoint Server 2007

Plataforma intranet e extranet que possibilita a pesquisa, gestão documental e de

ficheiros, e estruturação de todo o fluxo de processos a implementar pelas diversas

equipas de testes do projeto Altran Corporate.

Imagem 17 - Imagem representativa da utilização Sharepoint

EasyVista

Plataforma que simplifica a gestão de serviços e pedidos dos utilizadores do

grupo Altran, desde o pedido de acessos a ferramentas a deteção de defeitos ocorridos

em ambiente de produção.

34

Imagem 18 - Imagem representativa da utilização do EasyVista

JIRA

Plataforma web que permite o encaminhamento e gestão dos diversos estados de

um defeito, desde a sua deteção (open) à correção (resolved). No entanto, considero que

a grande vantagem na utilização do JIRA vai além da gestão de bugs, na medida que

pode ser utilizado na gestão de novos pedidos de funcionalidades (ou melhoria) por

parte de qualquer utilizador e no controlo de todas as atividades de teste ao longo do

ciclo de vida de desenvolvimento de um software.

Outras caraterísticas relevantes:

Bastante customizável;

Elevado número de addons gratuitos que podem ser integrados;

Utilização intuitiva e user-friendly;

Comunidade de utilizadores extensa;

35

Adaptado para o desenvolvimento ágil de software na medida que possui

caraterísticas de planeamento de iterações;

Imagem 19 - Imagem representativa da utilização do JIRA

Zephyr

Addon desenvolvido e integrado no JIRA, que possibilita a gestão dos casos de

teste e a sua associação a defeitos detetados (se aplicável), numa só plataforma e com o

mesmo interface.

Considero igualmente relevante destacar as seguintes caraterísticas:

Reutilização de casos de testes;

Simplificidade na manutenção/atualização dos casos de teste;

Possibilidade de agrupar os casos de teste por ciclos, país, ambiente de

desenvolvimento ou por funcionalidade;

Gestão e disponibilização das métricas de execução de testes;

Possibilita o upload de documentos como evidência de testes ou documento de

requisitos;

36

Permite o acesso a utilizadores de outras equipas do projeto Altran Corporate;

Imagem 20- Imagem representativa da utilização do Zephyr

Deltek Maconomy

Ferramenta desktop utilizada para a execução de testes e desenvolvida pela

empresa Deltek. Esta solução ERP permite o planeamento, a gestão de todos os recursos

financeiros da Altran por projeto, antecipando os seus resultados, expetativas e

balanços.

37

Imagem 21 - Imagem representativa da utilização do Maconomy

Ranorex Studio

Ferramenta de automação de testes aplicável a todo o tipo de plataformas (web,

desktop e mobile). Os resultados podem ser obtidos por screenshots ou relatórios (logs)

além que o seu custo de manutenção é extremamente reduzido.

Outras caraterísticas que considero relevantes:

Simplicidade na reutilização e atualização dos scripts de automatizados;

Disponibiliza um interface gráfico de utilizador (GUI), o qual permite a

interação através de elementos gráficos como ícones e outros indicadores

visuais, em oposição ao interface com a linha de comando, o que permite que

esta ferramenta de automação seja orientada a qualquer utilizador mesmo que

não tenha conhecimentos avançados de programação;

Ficheiros compatíveis com o Visual Studio e Excel;

Possui um workspace de debug e um workspace de replay de execuções;

Imagem 22 - Imagem representativa da utilização Ranorex Studio

38

Relação da utilização das aplicações com o processo de teste

Das ferramentas de teste apresentadas no tópico anterior, umas são mais

utilizadas que outras, dependendo sempre em que fase do processo de testes (ver atrás a

Imagem 13 para mais detalhes) se encontra o desenvolvimento da solução: Identify,

Specify, Develop, Run.

Na Tabela 2 detalha-se esta relação, entre a utilização da ferramenta e o seu

objetivo.

Tabela 2 - Representação da relação entre as ferramentas utilizadas em cada processo de teste

39

Capítulo IV - Atividades desenvolvidas

Neste capítulo apresento o resumo das atividades desenvolvidas ao longo do

período de estágio. Para um enquadramento mais eficaz, detalho as atividades

desenvolvidas por etapa do processo de teste (Imagem 13) em que estas atividades

ocorreram.

Como fora já abordado no capítulo 2, pode-se concluir que o desempenho de

atividades de teste pressupõe geralmente, e independentemente do modelo de

desenvolvimento adotado, uma análise de requisitos, o desenho de planos e casos de

teste, a execução, o encaminhamento e gestão de defeitos e a elaboração e

disponibilização de toda a documentação dos resultados dos testes (test evidences). Em

concreto no projeto ASC-TRA, cada área de domínio (CRM, ERM, ERP) tem a sua

própria planificação e release. Todavia, é fator comum a todas elas, que a data prevista

para início dos testes não é divulgada com a antecedência desejada, resultando

geralmente em pouco tempo de preparação para os testes.

A meu ver, este acaba por ser o fator mais crítico de toda a release que testa o

Maconomy, uma vez que o sucesso da mesma passa essencialmente por um estudo

prévio das novas alterações/implementações, e do impacto que estas podem ter nas

funcionalidades já existentes (testes de regressão). Se atendermos que o projeto lida

diretamente com a faturação do grupo e que cada país onde a Altran está representada

tem especificidades próprias, a análise e planeamento eficaz da cobertura dos testes é

essencial.

Assim, estão previstos um conjunto de premissas para a equipa ASC-TRA, que

passa por garantir antes da atividade dos testes o seguinte:

Todos os elementos necessários à execução dos testes (test data) são

disponibilizados de forma a serem reproduzidos o mais fiel possível ao que

ocorre em produção;

Não seja efetuada nenhuma alteração do ambiente de testes, a menos que a

equipa assim o valide;

Execução de testes unitários efetuada e validada pelo team manager da equipa

de desenvolvimento;

40

O documento de especificação de requisitos ser disponibilizado e anexado ao

caso de teste correspondente no JIRA;

Disponibilização de pelo menos uma semana entre a fase de planeamento de

testes e a sua execução;

No entanto, estas directrizes nem sempre são seguidas, por fatores essencialmente

que obedecem a restrições de tempo. Na Imagem 23 verifica-se por exemplo, que desde

a conclusão dos testes da release de junho (15 de junho) até à conclusão do

planeamento para a release de julho (17 de junho), ocorre um intervalo de apenas 48

horas, o que claramente é um desafio para a equipa na medida em que muitas vezes, este

planeamento forçosamente tem que ser efetuado em simultâneo com a fase de execução.

Imagem 23 - Calendário de atividades previstas em cada release

Análise de requisitos – Specify

A primeira etapa do ciclo de vida de desenvolvimento passa pela análise e

levantamento das exigências, bem como da descrição detalhada de todas as

funcionalidades e regras de negócio que estas devem seguir. Todavia, o projeto Hermes

é um projeto adequado à área de domínio ERP, visando a manutenção de software de

forma periódica, não ocorrendo por isso um desenvolvimento massivo de novas

funcionalidades a cada release. Desta forma, o levantamento dos requisitos e a sua

validação é previamente efetuado pelos utilizadores do negócio, não sendo por isso uma

competência da equipa de testes.

41

Desenho de planos de testes – Design e Develop

No processo de testes da Altran Corporate (Imagem 13), as fases Design e

Develop são provavelmente as mais importantes para os testes, uma vez que acarreta

uma fase de estudo, atendendo às funcionalidades que foram aprovadas na especificação

e que serão desenvolvidas e disponibilizadas na aplicação.

Como os testes do ERP visam essencialmente a manutenção do software, existe

uma lista de casos de teste para regressão, previamente selecionada pela área de negócio

(Anexo 1) e que deve ser executada, a fim de se comprovar que as novas

funcionalidades não causaram qualquer impacto nas existentes.

No entanto, cabe ao espírito crítico do tester ir um pouco mais além, de forma a

analisar e verificar, se existirão outras funcionalidades que mesmo que não estejam na

lista para regressão, possam sofrer de algum tipo de alteração. Isto faz com que possa

ser necessário acrescentar outros casos de teste, como mostro nas duas imagens

seguintes (Imagem 24 e Imagem 25).

Imagem 24 - Estudo de impacto das novas funcionalidades e dos testes a executar (release de junho)

42

Imagem 25 - Estudo de impacto das novas funcionalidades e dos testes a executar (release de julho)

Posteriormente a este levantamento, há todo um trabalho de atualização de

documentação, com todas as alterações que devem ser efetuadas mediante o que está a

ser desenvolvido. Esta atualização é efetuada na ferramenta de gestão de testes (Imagem

26) e na versão de texto, arquivada no Sharepoint (Imagem 27).

43

Imagem 26 - Alteração do passo número 9 do caso de teste 513 - Finance Reconciliation (Zephyr)

44

Imagem 27 - Alteração do passo número 11 do caso de teste 513 - Finance Reconciliation (Sharepoint)

Execução de testes – Test

É nesta terceira etapa do processo de teste (Test) que são executados os testes de

regressão. Mais importante que o resultado do teste que pode ser passed (Anexo 2) ou

failed (Anexo 3), considero que a maior importância da execução de teste, são as

evidências obtidas do mesmo, a qual permite:

Em caso de defeito detetado em produção, se este estiver relacionado com

alguma funcionalidade selecionada para testes de regressão, é possível

comprovar que a causa da anomalia deveu-se a código que possívelmente fora

implementado após os testes de regressão terem sido realizados;

Possibilita uma melhoria de processos através de aprendizagens obtidas pela

execução dos testes da release (lessons learned);

Com as evidências de teste obtidas da execução, qualquer alteração que seja

necessária de ser efetuada na documentação de testes é mais fácil de efetuar;

Uma imagem vale mais que mil palavras. Em caso de anomalia, é mais fácil a

identificação da possível causa e o passo em que foi detetada, através do registo

de print screens do comportamento obtido (Anexo 4).

Aumento de credibilidade da equipa dos testes no projeto Altran Corporate: uma

evidência de teste detalhada e bem estruturada, é uma prova irrefutável de que

tudo o que se considera crítico na funcionalidade, fora testado.

Manutenção dos testes – Run

Para a equipa de testes, esta última fase do processo de testes significa também a

conclusão dos mesmos. Caso algum defeito se encontrar pendente de resolução após da

data estipulada para fim dos testes, o planeamento de testes e a importância das

evidências tornam-se ainda mais relevantes, uma vez que torna-se a justificação para a

não implementação da funcionalidade com anomalia em produção. Nestas situações, o

que ocorre é o adiamento para uma próxima release, como mostra a Imagem 28.

45

Imagem 28 - Funcionalidade "Blanket Credit Memo" retirada da implementação na release de abril

Como já abordado na secção, é igualmente nesta fase que se procedem às

lessons learned, baseadas nos resultados das execuções. Em suma, é efetuada toda uma

manutenção dos casos de teste, semelhante à que se realiza na etapa de Design e

Develop, seja na ferramenta de gestão de casos de teste Zephyr ou na versão word

guardada no Sharepoint. Este trabalho “invisível” acaba por ser de extrema importância

pois é neste momento que se aprimora toda a documentação existente, através da

alteração de passos de execução incoerentes ou inconsistentes, ou mesmo o pedido de

esclarecimento junto dos utilizadores do negócio, sobre o comportamento de alguma

funcionalidade que nos testes de regressão ou ad-hoc, tenha suscitado alguma suspeita

de anomalia.

Sugestões de alterações nas atividades de teste baseadas nas

lessons learned

No decorrer do período de estágio, apresentei algumas sugestões de alteração,

retiradas após a conclusão dos testes de cada release, com vista à melhoria do processo

de teste e das suas atividades. Na tabela seguinte apresento alguns dos exemplos mais

46

relevantes destas alterações por mim sugeridas e aceites pelo team manager,

encontrando-se implementadas atualmente.

Antes Ação de melhoria

Dos 64 casos de teste selecionados para

os testes de regressão, 55 encontravam-se

bastante incompletos, nomeadamente

com passos de execução inexistentes e

outros que já não se aplicam atualmente.

Transcrição para o Zephyr de todos os casos de

teste e atualização de todas as versões word do

Sharepoint.

A execução dos testes era efetuada de

forma aleatória e não pelo seu potencial

fator crítico.

Exemplo: casos de teste de validação do

processo de faturação são mais críticos

que os casos de teste de validação de

layout.

Definição das prioridades de execução para cada

caso de teste, baseadas no número de anomalias

detetadas anteriormente, do tempo de execução

médio e da funcionalidade em si. Todos os casos

de teste que visam processos de faturação de

projetos foram definidos como críticos.

Inexistência de arquivo no Sharepoint

relacionado com documentação de

especificação de funcionalidades,

evidências dos testes end to end

realizados, registo de pedidos de

esclarecimento efetuados para cada

release, etc.

Reorganização do Sharepoint (Anexo 5) da

equipa de testes (projeto Hermes).

Disponibilização de pastas específicas para

arquivo de toda especificação, do planeamento

efetuado para os testes a executar de cada

release, para sessões de teste end-to-end, arquivo

de emails de esclarecimento de dúvidas etc.

Tabela 3 - Alterações de atividades de teste, baseadas nas lessons learned

Rácio tempo/atividade desenvolvida

Para que se possa ter uma maior perceção em como foi distribuído o período de

estágio, apresento na Imagem 29, a esquematização do tempo empregue por mim a cada

fase do processo de testes descrito anteriormente. É importante mais uma vez destacar,

47

Specify

0% Design & Develop

20%

Test - 73 casos de

teste executados:

66 passed / 7

failed

30% Run

50%

que mais relevante que a própria execução, o sucesso de uma equipa de testes passa pelo

rigor no planeamento de cada teste e nas conclusões que advêm da sua execução.

Imagem 29 - Rácio de tempo - atividade desenvolvida

A Imagem 29 comprova como os testes ao projeto Hermes são voltados

essencialmente para a manutenção de software, uma vez que não há etapa levantamento

e especificação de requisitos (Specify). Na verdade, aquando da realização dos testes, já

todos os requisitos estão aprovados e as suas funcionalidades implementadas em

ambientes de testes. Assim, a maior parte da atividade de testes no projeto destina-se ao

à preparação antes da execução, e à manutenção dos casos de teste após dos testes (70%

correspondendo a 20% de Design & Develop e 50% de Run) ou seja, realizar o estudo

de impacto das futuras funcionalidades nas já existentes e garantir que nas próximas

releases, todos os casos de teste estarão atualizados de acordo com as novas

implementações efetuadas.

48

Capítulo V - Considerações finais

A leitura e análise deste documento, demonstra com exemplos práticos que a

atividade de testes alcançou uma maior dimensão na Engenharia de Software, tornando-

se no caso concreto da Altran, um trunfo evidente para aumentar a sua vantagem

competitiva no mercado.

Durante todo este período de estágio, a equipa ASC-TRA, particularmente do

projeto Hermes, garantiu sempre todas as condições adequadas à consolidação dos meus

conhecimentos teóricos. Contudo, considero que o que mais contribuiu para o meu

sucesso foi a integração no projeto, o feedback e o acompanhamento constante, que

facilitou e possibilitou uma rápida evolução. A prova disso resume-se à confiança

depositada nas minhas capacidades e em funções específicas, como o planeamento dos

testes ou mesmo na possibilidade de execução dos testes de regressão previstos na

release, logo no primeiro mês. Obviamente houve períodos de maior dificuldade, de

pressão dos prazos, da necessidade de uma maior agilização no desempenho de tarefas,

da ausência de documentação e do desconhecimento de pessoas para esclarecimento de

dúvidas específicas. No entanto, são estes todos os desafios que um tester deve

corresponder e a forma como este faz, é o que o guia ao sucesso ou ao fracasso.

O balanço deste período de estágio curricular é extremamente positivo, uma vez

que participei em todas as atividades da equipa desde o início, cumprindo todos os

objetivos propostos e o reconhecimento de um bom trabalho realizado, por parte dos

colegas e da chefia.

Atualmente, a minha situação na empresa passa pela consolidação dos meus

métodos de trabalho. A meu ver, esta organização do trabalho é a melhor aprendizagem

que retiro desta curta experiência. Independentemente da metodologia aplicada, do

processo de testes ou do planeamento do que testar, é a organização pessoal e a partilha

da informação que resolve a generalidade das dificuldades. Neste aspeto, considero que

deixei o meu contributo.

A etapa seguinte passa pela automação de testes. Considero que esta é a área de

futuro nos testes e na Engenharia de Software em geral, já que vivemos num mundo

cada vez mais dependente de novas versões e inovações. Este será o meu próximo

49

desafio, que levar-me-á ao nível seguinte de experiência e alargamento do

conhecimento. E o futuro começa já hoje.

50

Bibliografia

“Agile Is The New Waterfall — A Followup,” [Online]. Available:

https://medium.com/swlh/agile-is-the-new-waterfall-a-followup-f1c0bcd2162e#.tgtrpfofr.

[Acedido em Junho 2016].

“Altran - Notícias,” [Online]. Available: http://www.altran.pt/index.php?id=29539#.V21aUqL-

Bpt. [Acedido em Junho 2016].

“Altran Offices,” [Online]. Available: http://www.altran.com/altran-in-the-

world.html#/.V21X6qL-Bps. [Acedido em Junho 2016].

“Altran Portugal - Comité Executivo,” [Online]. Available: http://www.altran.pt/sobre-

nos/altran-portugal/comite-executivo.html#.V21bQqL-Bps. [Acedido em Junho 2016].

“Devmedia,” [Online]. Available: http://www.devmedia.com.br/. [Acedido em Junho 2016].

“Overview - Altran,” [Online]. Available: http://www.altran.com/about-

us/overview.html#.V21Wp6L-Bps. [Acedido em Junho 2016].

“Software Testing Help,” [Online]. Available: http://www.softwaretestinghelp.com/software-

testing-terms-complete-glossary/. [Acedido em Junho 2016].

A. A. E. B. A. B. O. B. S. M. S. V. e. Y. W. Luis Abad, “Innovation Through Testing - A New

Dimension for the Corporate Enterprise,” Philippe Salle, Paris, 2013.

I. S. T. Q. (ISTQB), “PSTQB_SyllabusFoundation_v2011,” 2011.

I. S. T. Q. B. (ISTQB), “GLOSSÁRIO PADRÃO DE TESTES DE SOFTWARE,” Erik van Veenendaal,

2014.

L. Crispin e J. Gregory, “Roles & Competences - Chapter 3 of ‘More Agile Testing: Learning

Journeys for the Whole Team’,” Eurostar Software Testing, 2014.

51

Anexos

Anexo 1 -

Listagem completa dos casos de teste, incluindo os selecionados para regressão ...... 41

Anexo 2 -

Exemplo de execução de teste com sucesso (passed) ................................................. 44

Anexo 3 -

Exemplo de execução de teste com defeito detetado .................................................. 44

Anexo 4 -

Exemplo de evidência de teste com captura de imagem de execução ........................ 44

Anexo 5 - Reorganização atual do Sharepoint da equipa ASC-TRA-Hermes ............... 46

52

Anexo 1 – Listagem completa dos casos de teste,

incluindo os selecionados para regressão

53

54

55

56

57

58

Anexo 2 – Exemplo da execução de um caso de

teste com sucesso (passed)

59

60

61

Anexo 3 – Exemplo da execução de um caso de

teste com um defeito detetado (failed)

62

63

Anexo 4 – Exemplo de evidência de teste com

captura de imagem de execução

64

65

66

67

Anexo 5 – Reorganização do Sharepoint da

equipa ASC-TRA-Hermes

68