fl
Tpï
daGuarda
Escola Superior de Tecnologia e Gcsüio
RELATÓRIO DE ESTÁGIO
Curso Técnico Superior Profissional em
Testes de Software
Steven Afonso Portela
R E L A T Ó R I O D E E S T Á G I O
STEVEN AFONSO PORTEL A
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
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
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
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
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
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
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
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.
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
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;
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;
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.
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).
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
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
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
58
Anexo 2 – Exemplo da execução de um caso de
teste com sucesso (passed)
61
Anexo 3 – Exemplo da execução de um caso de
teste com um defeito detetado (failed)
63
Anexo 4 – Exemplo de evidência de teste com
captura de imagem de execução
67
