fl Tpï daGuarda - Biblioteca Digital do IPG: Página...
Transcript of fl Tpï daGuarda - Biblioteca Digital do IPG: Página...
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: [email protected]
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).
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