Estágio Supervisionado I - Automação de Testes

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

UNIÃO DE ENSINO DO SUDOESTE DO PARANÁ – UNISEP
FACULDADE EDUCACIONAL DE DOIS VIZINHOS – FAED
CURSO DE Sistemas de informação
Jhonatan zanetti
RELATÓRIO DE ESTÁGIO SUPERVISIONADO I
DOIS VIZINHOS
2019
jhonatan zanetti
RELATÓRIO DE ESTÁGIO SUPERVISIONADO I 
Relatório apresentado como requisito parcial para a aprovação na disciplina de Estágio Supervisionado I, do curso de Sistemas de Informação da Faculdade Educacional de Dois Vizinhos.
Prof. Coordenador: MSc. Rodrigo Siega
dois vizinhos
2019
Agradecimentos
Primeiramente sou grato a minha família por sempre estar ao meu lado, em especial aos meus pais por sempre me apoiarem e aconselharem nos momentos de necessidade.
Agradeço a empresa CISS Software e Serviços pela oportunidade de realização do estágio, em especial aos lideres técnicos da equipe de Frente de Caixa, Elmir Brandt e Alex Galon, por disponibilizar o tempo necessário para realização das atividades relacionadas ao estágio.
Agradeço á Analice Ceccagna, supervisora do estágio, por prestar todo apoio necessário durante a execução do mesmo e também á Monica Cristina Eli, por toda a ajuda em questões técnicas durante todo período de estágio.
Agradeço a todos os professores do curso de Sistemas de Informação, por todo apoio e orientação. 
Lista de figuras
Figura 2.1 – Exemplo de Script de teste do software Produto X. Fonte: Autoria própria, 2019.	11
Figura 2.2 – Integração entre aplicativos no CLM. Fonte: Autoria própria, 2019.	12
Figura 2.3 – Algumas áreas de projeto do setor Fábrica. Fonte: Autoria própria, 2019.	13
Figura 2.4 – Planos de projeto presentas na área de projeto CQP. Fonte: Autoria própria, 2019	14
Figura 2.5 – Plano de teste presente no projeto FrontBox (QM) – 2019	15
Figura 2.6 – Caso de teste de uma funcionalidade do Produto X. Fonte: Autoria própria, 2019.	16
Figura 2.7 – Processo de planejamento de testes manuais. Fonte: Autoria própria, 2019.	17
Figura 2.8 – Processo de criação de scripts automatizados. Fonte: CISS S.A, 2019.	18
Figura 2.9 – WI de automação criados dentro do plano de projeto de Sprint do CQP. Fonte: Autoria própria, 2019.	19
Figura 2.10 – Estrutura de um WI pai de automação. Fonte: Autoria própria, 2019.	19
Figura 2.11 – Estrutura de um WI filho de automação. Fonte: Autoria própria, 2019.	20
Figura 2.12 – Suíte modelo utilizada pela automação. Fonte: Autoria própria, 2019.	23
Figura 2.13 – Alguns métodos genéricos utilizados durante a automação. Fonte: Autoria própria, 2019.	24
Figura 2.14 – Parte dos métodos criados para recuperar informações do banco de dados. Fonte: Autoria própria, 2019.	24
Figura 2.15 – Exemplo de erro ocorrido durante a automação. Fonte: Autoria própria, 2019.	25
Figura 2.16 – Suíte de teste completa, destaque nos scripts de teste. Fonte: Autoria própria, 2019.	26
Figura 2.17 – Lista de execução com algumas suítes de automação. Fonte: Autoria própria, 2019.	27
Figura 2.18 – Processo de execução de roteiros automatizados. Fonte: Autoria própria, 2019.	28
Figura 2.19 – Relatório de execução da suíte Atacarejo_ProdutoX. Fonte: Autoria própria, 2019.	29
Figura 2.20 – Algumas informações necessárias em uma tarefa de auditoria. Fonte: Autoria própria, 2019.	30
Lista de abreviações
	CQP
	Controle de Qualidade de Produto
	CLM
	Collaborative Lifecycle Management
	ERP
	Enterprise Resource Planning
	GCO
	Gerência de Configuração
	GUI 
	Graphical User Interface
	QM
	Quality Management 
	UFT
	Unified Functional Testing
	WK
	Work Item
	
	
 
Sumário
Agradecimentos	III
Lista de figuras	IV
Lista de abreviações	V
Sumário	VI
1	Introdução	7
2	Desenvolvimento	9
2.1	Estudo sobre automação	9
2.1.1	Quando automatizar uma funcionalidade	10
2.1.2	Script de teste	11
2.2	Rational for Collaborative Lifecycle Management (CLM)	11
2.2.1	Change and Configuration Management (CCM)	12
2.2.2	Áreas de projeto	13
2.2.2.1	Backlog	14
2.2.2.2	Sprint	14
2.2.3	Quality Management (QM)	15
2.3	Execução de casos de teste manuais	15
2.3.1	Casos de teste	16
2.3.2	Origem dos casos de teste	17
2.3.3	Porque executar casos de testes manuais	17
2.4	Criação de script de teste automatizado	18
2.4.1	Processos e WI de automação	18
2.4.2	Softwares utilizados na automação	21
2.4.3	Criando um script automatizado	22
2.4.4	Finalizando a criação de scripts automatizados	25
2.5	Executar roteiros de homologação	27
2.6	Analisar resultados	28
2.7	Abrir bugs, defeitos e auditorias	29
3	CONCLUSão	31
4	REFERÊNCIAS bibliográficas	32
Apêndices	34
APÊNDICE 1 – cronograma de estágio supervisionado I	35
Introdução
Há cerca de 30 anos a CISS Software e Serviços é uma fabrica de software que tem seu foco voltado para o desenvolvimento de soluções em gestão de lojas de matérias de construção, restaurantes, supermercados e também atacarejos. O atacarejo é um modelo de negócio onde são realizadas vendas tanto para pequenos varejistas (lojas, supermercados, açougues, entre outros comércios) como também diretamente para o consumidor final.
A empresa possui aproximadamente quatrocentos funcionários, atuando nos diversos setores da empresa como departamento de Centro de Suporte, Inovação, departamento de Talentos Humanos, Escritório Contábil, Fábrica, entre outros. O estágio foi realizado no setor Fábrica, que no período atual é responsável por manter e realizar melhorias em alguns produtos como o Produto X, que é o software de frente de caixa da CISS, e também o Produto Y, principal Enterprise Resource Planning (ERP) da empresa. Segundo PADILHA, MARINS (2005) os sistemas ERP também são conhecidos no Brasil como Sistemas Integrados de Gestão Empresarial, eles controlam e fornecem suporte a todos os processos produtivos, operacionais comerciais e administrativos da empresa.
Quando um software sofre alterações sucessivamente, realizar testes manuais começa a se tornar um desafio cada vez maior, pois quanto mais funcionalidades o software possuir mais impactos causados pelas alterações realizadas podem surgir, assim afetando pontos do sistema que estavam funcionando corretamente. Devido a isso a área escolhida para realização do estágio foi automação de testes de software, com foco no software de frente de caixa Produto X.
O estágio foi realizado com o objetivo de compreender uma nova área da garantia de qualidade, suas técnicas, processos e ferramentas. Inicialmente foi realizado um estudo sobre os princípios da automação de testes de software, depois foram executados roteiros de teste de forma manual, afim de compreender melhor a funcionalidade que vai ser automatizada. 
Após as atividades de estudo e execução manual dos testes foi realizado a criação e manutenção de scripts de teste automatizados, onde foi necessário compreender os processos que envolvem os mesmos, assim como realizar o entendimento das ferramentas de automação utilizadas. Posteriormente foi realizada a execução de diversos roteiros de teste automatizados a fim de avaliar o resultado de suas execuções e tomar decisões com base nos mesmos.
Desenvolvimento
 As tarefas realizadas durante o período de estágio serão descritas ao decorrer deste relatório. Vão ser apresentados os processos, ferramentas e obstáculos que foram encontrados durante o período. A fim de estar de acordo com o termo de confidencialidade empregado pela empresa foi necessário substituir o nome do Software que foi realizado a automação por ‘Produto X’.
Estudo sobre automação
No começo do estágio foi realizado um acompanhamento com um membro do time de automação, para poder verificar como eram realizadas suas atividades. Além disso foram realizadas algumas anotações e pesquisas sobre a automação de testes. Esse processo de aprendizagem levou cerca de quatro dias de estágio.
Automação de testes tem por definição utilizar um software externo (não sendo o software sendo testado) para controlar a execução dos testes e comparar os resultados encontrados com os resultados esperados. (IZABEL, 2014)
Existem vários tipos de testes automatizados,
na automação de testes do Produto X são aplicados testes funcionais e de regressão. Izabel (2014) define testes funcionais como um tipo de teste que visa garantir que o software funcione como o esperado, e testes de regressão como uma estratégia de teste, onde, a cada nova versão do software são realizados todos os testes executados na versão anterior, assim garantindo que as funcionalidades já testadas não apresentarão erros.
Além disso a ferramenta utilizada no setor fábrica possibilita a realização de consultas em bancos de dados, assim pode-se garantir que as informações gravadas estão de acordo com o esperado.
O automatizador de software é responsável por:
Homologação de produtos (identificação, reporte e validação de inconsistências no sistema).
Criação de roteiros de testes automatizados.
Analise dos testes criados.
Atualização de bancos para os testes.
O automatizador de teste não realiza as tarefas de correção das inconsistências encontradas e também as liberações das entregas
Quando automatizar uma funcionalidade
A equipe de automação do setor de fábrica definiu alguns critérios para determinar se certa funcionalidade deve ser automatizada. Elas são:
Funcionalidades que possivelmente venham a ser muito utilizadas pelos clientes.
Funcionalidades que demandam tempo considerável para execução de testes manuais.
Funcionalidades que se falharem, apresentam riscos de prejuízos financeiros aos clientes.
Essas definições são importantes pois, em uma aplicação que possuí diversas alterações contínuas, como exemplo do Produto X, automatizar todas as funcionalidades do software se torna inviável, devido ao grande número de possibilidades de teste.
Para realizar a automação de uma funcionalidade, primeiro é necessário possuir documentado como e quais serão os testes realizados, para isso são utilizados os scripts de teste.
Script de teste
Scripts são instruções passo a passo que permitem a execução de um teste. Pode ser observado na figura 2.1 que existe na parte esquerda a descrição do teste e a direita o resultado esperado do mesmo.
Figura 2.1 – Exemplo de Script de teste do software Produto X. Fonte: Autoria própria, 2019.
Como apresentado na figura 2.1 scripts de teste apresentam pré-condições, cenários, passos a serem executados e seus resultados esperados. Os roteiros automatizados ou scripts automatizados são criados usando como base os scripts de teste.
Durante o estágio não foi realizada a criação de scripts de teste manuais, foram utilizados scripts já existentes.
Rational for Collaborative Lifecycle Management (CLM)
Durante o período de estágio surgiu a necessidade de compreender melhor o funcionamento da solução de controle de chamados e tarefas utilizadas pelo setor Fábrica, para essa tarefa foi solicitado ajuda de um colaborador que não fazia parte do time de automação. Essa pesquisa tomou cerca um dia de estágio.
O setor fábrica como um todo utiliza a solução CLM, para realizar a gestão de suas atividades. Conforme IBM (2019a), o CLM é responsável por fornecer a integração entre algumas aplicações como o Change and Configuration Management (CCM) e o Quality Management (QM) do JAZZ Team Server. É possível visualizar na figura 2.2 a integração entre o CCM e o QM.
Figura 2.2 – Integração entre aplicativos no CLM. Fonte: Autoria própria, 2019.
Segundo a IBM (2019b), o JAZZ Team Server fornece serviços como gerenciamento de usuários e gerenciamento de licenças, ele permite que os aplicativos do CLM trabalhem de forma integrada como um servidor lógico.
Change and Configuration Management (CCM)
O CCM ou Gerenciamento de Mudanças e Configuração caso traduzido, é um aplicativo que está presente no CLM que possui diversos recursos, porém o principal e que foi mais utilizado durante o estágio foram os Work Items (WI). Os WI seriam os itens de trabalho, que controlam e coordenam histórias, defeitos, itens de planos e tarefas diversas.
Dentro do CCM é possível criar diversas áreas de projeto, é dentro das áreas de projeto que as equipes executam suas tarefas, estimam chamados. Também dentro das áreas de projeto são controlados os recursos da equipe.
Áreas de projeto 
Uma área de projeto é o local em que informações sobre um ou mais projetos de software são armazenados. Uma área de projeto define a estrutura da equipe, o processo e o planejamento (IBM, 2019c). 
No caso da Fábrica, cada área de projeto dentro do CCM pode representar um produto ou equipe, como pode ser observado na figura 2.3.
 
Figura 2.3 – Algumas áreas de projeto do setor Fábrica. Fonte: Autoria própria, 2019.
A área de projeto utilizado pela equipe de automação de teste é o Controle de Qualidade de Produto (CQP). Dentro da área de projeto são criados os planos de projeto, neles são determinados os recursos necessários para as tarefas além de definir e realizar estimativas das tarefas a serem realizadas pelos membros da equipe. 
Dentro dos planos de projeto são encontrados os WI, eles são os itens de trabalho dentro da ferramenta CCM e possuem vários tipos como por exemplo: defeito, história, banco de dados, bug, tarefa, entre outros.
É possível visualizar na figura 2.4, que para a área de projeto CQP existem dois tipos de planos de projeto. O plano de Backlog e o plano de Sprint.
Figura 2.4 – Planos de projeto presentas na área de projeto CQP. Fonte: Autoria própria, 2019
É importante compreender que o setor fábrica trabalha com a metodologia ágil de desenvolvimento Scrum. Nele são definidos os conceitos de backlog e sprint
Backlog
A CISS S.A (2019) define Backlog como uma lista onde ficam as solicitações aguardando análise ou desenvolvimento. No caso do Backlog de automação são os WI que ainda não foram estimados para automatizar. Após as tarefas serem estimadas elas deixam o Backlog e são alocadas em uma Sprint.
Sprint
Para a CISS S.A (2019) Sprints seriam interações de uma, duas, três ou quatro semanas, que geram um produto potencialmente lançável, já na automação de testes as Sprints são utilizadas para entregar tarefas de automação e também realizar a homologação da nova versão dos produtos. No caso do setor fábrica, as Sprints têm duração de duas semanas. Em uma sprint são alocados os WI estimados para automatização.
Quality Management (QM) 
Ainda dentro do CLM foi necessário conhecer a ferramenta QM. A ferramenta possibilita o planejamento de testes, construção de testes e também o gerenciamento dos artefatos de teste (IBM, 2019b).
Para melhor controle dos artefatos de teste, o time de automação criou dois projetos dentro do QM: O Produto Y_Homologação (QM) e o projeto Produto X (QM) que abrange as funcionalidades do Produto X. Dentro de cada um dos projetos é possível encontrar os planos de teste.
Figura 2.5 – Plano de teste presente no projeto FrontBox (QM) – 2019
Segundo CISS S.A (2019) um plano de teste é um agrupador de casos de teste, especificados por módulo ou funcionalidade. A funcionalidade que foi designada para automação durante o período de estágio está dentro no plano de teste apresentado na figura 2.5.
Execução de casos de teste manuais
No primeiro momento foram realizados a execução dos casos de teste de forma manual. Com isso é possível verificar se o comportamento da funcionalidade ainda ocorre como descrito nos scripts de teste. Para essa tarefa foram gastos cerca de dois dias de estágio, nessa tarefa a configuração do ambiente acabou demorando mais que o previsto.
Casos de teste
Casos de teste são um conjunto de condições utilizadas para teste de software. Um caso de teste pode agrupar vários scripts de teste, como pode-se verificar na figura 2.6.
 
Figura 2.6 – Caso de teste de uma funcionalidade do Produto X. Fonte: Autoria própria, 2019.
O caso de teste apresentado na figura 2.6 foi o escolhido para ser automatizado durante o período de estágio. Nele existem três scripts de teste pendentes a automatizar.
Origem dos casos de teste
Para começar a executar os scripts de forma manual, primeiro
foi necessário compreender como é realizada a criação dos casos de testes. Pode ser visualizado na figura 2.7, o processo de criação de um caso de teste. Devido as politicas confidencialidades algumas etapas dos processos não podem ser apresentadas.
 
 Figura 2.7 – Processo de planejamento de testes manuais. Fonte: Autoria própria, 2019.
Durante o processo planejamento de testes manuais de uma funcionalidade, é realizado o planejamento de casos de testes. Caso seja definido que é necessário criar casos de teste, os mesmos vão ser alocados dentro de um plano de teste do QM. Em uma situação em que já exista um caso de teste referente a funcionalidade, vão ser criados apenas os scripts de teste dentro do caso de teste existente.
Porque executar casos de testes manuais
A execução manual dos casos de teste pode ser mais necessária em situações em que a funcionalidade foi implementada a um tempo considerável e não foi realizado a automatização da mesma. 
Em casos onde o comportamento da funcionalidade está diferente do descrito nos scripts de teste manual, se faz necessário realizar a correção dos scripts antes de iniciar a tarefa de automatização.
No caso da funcionalidade descrita na figura 2.6, foi realizado a execuções dos scripts de forma manual e o software se comportou conforme descrito. Nesse caso foi possível dar inicio ao processo de criação dos scripts automatizados.
Criação de script de teste automatizado
A criação de um script de teste automatizado envolve vários processos e ferramentas que trabalham em conjunto para possibilitar o desenvolvimento dos scripts. Nesta tarefa foram apresentadas as maiores dificuldades do estágio, isso se devido ao conhecimento em ferramentas que foi necessário adquirir.
Primeiramente foi necessário compreender os processos que envolvem a automação e também os artefatos criados durante a automatização dos scripts.
Processos e WI de automação
A criação dos scripts automatizados faz parte do processo de testes como um todo. O seu fluxo pode ser observado na figura 2.8.
Figura 2.8 – Processo de criação de scripts automatizados. Fonte: CISS S.A, 2019.
A criação dos scripts automatizados acontece em paralelo a execução dos testes manuais.
Para começar a automatizar os scripts de teste, primeiramente foram criados os WI relacionadas ao caso de teste. As tarefas foram alocadas dentro do plano de projeto de Sprint do CQP, como pode ser observado na figura 2.9.
Figura 2.9 – WI de automação criados dentro do plano de projeto de Sprint do CQP. Fonte: Autoria própria, 2019.
Em destaque na figura 2.9 é possível encontrar WI pai, ele geralmente se refere ao caso de teste e vai possuir WI filhos. Um WI pai só é concluído após todos seus filhos forem finalizados. 
Figura 2.10 – Estrutura de um WI pai de automação. Fonte: Autoria própria, 2019.
O tipo do WI é ‘Automatizar’, esse tipo está disponível apenas no plano de projeto CQP. Como se trata de um WI pai ele possui em sua descrição o link para os casos de teste. 
É possível verificar na figura 2.6 que o caso de teste está com um estado ‘Automatizar’, o que significa que existem scripts de teste ainda não automatizados dentro do caso de teste.
É possível visualizar na figura 2.6 os WI filhos. Como se pode observar na figura 2.10 os WI filhos tem uma estrutura diferente de WI pais.
 
Figura 2.11 – Estrutura de um WI filho de automação. Fonte: Autoria própria, 2019.
O tipo do WI é ‘Tarefa’. Dentro dos planos de projeto as tarefas contêm várias classificações, na figura 2.11 é possível observar que o do tipo da tarefa é ‘Criar Script’, esse tipo de tarefa é utilizado quando serão criados novos scripts automatizados.
Em tarefas do tipo ‘Criar Script’ são anexados os links para os scripts de teste. Pode-se analisar na figura 2.6 que os scripts estão com estado como ‘Automatizar’, isso significa que a criação dos scripts automatizados ainda não foi realizada.
Para definir quais casos de testes seriam automatizados e realizar sua estimativa, foi realizado uma reunião de planejamento de atividades, que dura cerca de meio dia e é feita ao inicio de cada nova Sprint. Foi necessário um dia de estágio para realizar a reunião.
O processo de estimar as tarefas foi realizado por toda equipe de automação responsável pelo produto Produto X. Cada membro do time informou uma determinada quantidade de horas, após isso foi realizado uma discussão e chegado a um consenso da quantidade total de horas que a atividade possivelmente iria demandar. 
Após definir o caso de teste a ser automatizado e forem criadas e estimadas as tarefas, foi possível dar inicio a automatização dos scripts. 
Softwares utilizados na automação
A automatização de um script de testes envolve a utilização de diversos softwares. Um dos principais é o Git, ele é um sistema de controle de versão de arquivos, através dele é possível que os principais responsáveis do projeto controlem as alterações que são realizadas no mesmo. 
A equipe de automação utiliza outros softwares em conjunto com o Git para facilitar o controle e versionamento de alterações, como por exemplo, o GitLab, que é um gerenciador de repositório de software, nele se encontram os repositórios dos projetos do setor fábrica. Outra ferramenta utilizada foi em conjunto com Git foi o Git Extensions, ele é uma interface gráfica de usuário para o Git, que permite usar as funcionalidades do mesmo sem a necessidade de linhas de comando.
Além disso foi utilizado PostGreSql para realizar consulta no banco de dados do Produto X. PostGreSql é um sistema gerenciador de banco de dados relacional. 
Para realizar a automação dos scripts é utilizado a ferramenta HP Unified Functional Testing (UFT). Segundo a MICRO FOCUS (2019) é uma solução abrangente para automação de testes funcionais e testes de regressão. Ele utiliza o Visual Basic Script como linguagem de programação
 O Visual Basic Script é uma linguagem derivada do Visual Basic da Microsoft. Ela utiliza o conceito de programação orientada a objetos.
“A proposta da orientação a Objetos é representar o mais fielmente possível as situações do mundo real nos sistemas computacionais. Nós entendemos o mundo como um todo composto por vários objetos que interagem uns com os outros. Da mesma maneira, a Orientação a Objetos consiste em considerar os sistemas computacionais não como uma coleção estruturada de processos, mas sim como uma coleção de objetos que interagem entre si.” (FARINELLI, 2007, p.4).
Criando um script automatizado
Primeiramente foi escolhida uma das tarefas filhas que podem ser visualizadas na figura 2.8, e realizado a mudança de seu status ‘Novo’ para ‘Em andamento’. Isso indica que a tarefa foi iniciada.
Uma tarefa de automação pode possuir alguns status que são alterados conforme o andamento da mesma:
‘Novo’: Quando a tarefa foi criada e ainda não foi iniciado o desenvolvimento da mesma.
‘Em andamento’: Quando o desenvolvimento da tarefa é iniciado.
‘Pronto’: Quando todas as partes do desenvolvimento da tarefa é concluída.
Para começar a criação do novo script foi necessário obter o repositório de desenvolvimento da equipe de automação, para isso foi utilizado uma ferramenta desenvolvida internamente pela empresa para realizar a clonagem do repositório para a máquina. Depois de feito o download do repositório, foi utilizado o Git Extensions para obter as ultimas alterações realizadas no mesmo.
Após clonado e atualizado o repositório, foi feita a instalação do software UFT. Nesse momento foi disponibilizado pela equipe de automação um documento de treinamento para automatizadores, que possui os principais conceitos e praticas de automação no UFT.
Para automatizar um novo script primeiro é carregado uma suíte de teste modelo, que possui as principais Library´s, Objetos e PageObjects que serão utilizados durante o desenvolvimento.
Objeto: É criado sempre que algo que possa ter atributos ou características. 
PageObject: Qualquer tela do sistema que for automatizada deverá possuir uma PageObject genérica,
caso essa tela possua abas, cada uma deverá possuir seu próprio PageObject.
Library´s: Local onde serão criados métodos genéricos que poderão ser utilizados na grande maioria do sistema para auxiliar no desenvolvimento dos testes.
Uma suíte de teste representa um conjunto de scripts que são organizados para testar uma funcionalidade, também pode ser definido como um roteiro de teste. Dentro de uma suíte de teste são criados as actions, elas representam um script ou parte de um script de teste. Pode-se observar na figura 2.12 como é feita a organização dos elementos em uma suíte de teste.
Figura 2.12 – Suíte modelo utilizada pela automação. Fonte: Autoria própria, 2019.
Durante a automação do script de teste não foi necessário criar objetos, pageObjetcts ou librarys, pois foram utilizados recursos já criados, assim como foram reutilizados alguns métodos genéricos já existentes.
 Figura 2.13 – Alguns métodos genéricos utilizados durante a automação. Fonte: Autoria própria, 2019. 
Nesse ponto a maior dificuldade foi em compreender a linguagem de programação utilizada, Visual Basic Script, suas regras e seus erros, além de manter as boas práticas e padrões empregados pela equipe de automação.
Uma prática que foi adota pelo time são os comentários no código, quase todas as linhas de código possuem um comentário explicando o que ela faz, tanto nas actions, como em métodos criados. 
Foi necessário criar alguns métodos dentro de uma library para realizar consulta de determinadas informações no banco de dados. Quando são criados métodos dessa forma, os mesmos devem possuir comentários explicando exatamente qual dado ele retorna. 
Os métodos mostrados na figura 2.14 são métodos de consulta em banco de dados, os mesmos funcionaram conforme o esperado além de possuir comentários falando o que os mesmos fazem.
 
Figura 2.14 – Parte dos métodos criados para recuperar informações do banco de dados. Fonte: Autoria própria, 2019.
Finalizando a criação de scripts automatizados
A equipe de automação possui apenas um membro responsável por validar e aceitar todas as alterações realizadas em ambos os projetos, tanto na automação do Produto X como no Produto Y. Ele também é responsável por indicar possíveis mudanças que melhorem o código, além de validar se as boas práticas indicadas pelos manuais da equipe são seguidas.
Como exemplo pode-se usar o método ‘getIdClienteVendaRecebimento’ mostrado na figura 2.14. Após as alterações serem enviadas, o responsável pelas validações de código relatou que os métodos estavam fora dos padrões, pois, todo método que realiza consulta em banco de dados deveria terminar seu nome com ‘_Db’. Após isso os métodos foram corrigidos e as alterações aceitas.
Durante a criação do script foi comum se deparar com erros. Como apresentado na figura 2.15, onde o UFT não conseguiu encontrar o elemento da tela esperado.
Figura 2.15 – Exemplo de erro ocorrido durante a automação. Fonte: Autoria própria, 2019.
Durante o processo de criação dos scripts automatizados houve o auxilio de um membro da equipe mais experiente, que ajudou em diversas dúvidas além de sugerir algumas mudanças no código antes do mesmo ser de fato enviado para validação.
Logo após a conclusão da automatização do primeiro script, foram realizados a criação dos próximos scripts automatizados relacionados ao WI pai da figura 2.9. Todos os scripts foram criados dentro da mesma suíte de teste, isso foi realizado pois os scripts faziam parte do mesmo caso de teste. Como pode ser observado na figura 2.16, cada action em destaque representa o inicio de um script de teste diferente.
 
Figura 2.16 – Suíte de teste completa, destaque nos scripts de teste. Fonte: Autoria própria, 2019. 
Após a conclusão da suíte, todos os WI relacionados tiverem seus status mudados para ‘Concluído’ além de ser realizada uma breve documentação em cada WI, informando o que foi realizado para criação do mesmo. Para finalizar o processo de criação, a suíte foi cadastrada na ferramenta interna de homologação.
O processo de criação de cada um dos scripts de automação levou de quatro a cinco dias, totalizando cerca de doze dias de estágio.
Executar roteiros de homologação
Antes de realizar a liberação de uma nova versão do Produto X, o mesmo passa por um processo de homologação. Esse processo consiste em executar todos os roteiros automatizados criados, afim de validar os testes de regressão.
Para realizar a tarefa de execução é utilizada uma ferramenta interna. Nela foram criadas listas de suítes automatizadas que serão executadas. Como pode ser observado na figura 2.17. 
Figura 2.17 – Lista de execução com algumas suítes de automação. Fonte: Autoria própria, 2019.
Através da ferramenta, as suítes são executadas em máquinas virtuais de forma automática, sendo que ao final de cada execução é gerado um relatório sobre a mesma. 
Em alguns casos foi necessário intervir manualmente nas suítes, pois, durante as execuções ocorreram alguns erros que não eram falhas no sistema, muitos deles ocorriam devido a lentidão das máquinas virtuais. Essa lentidão fazia as telas do sistema abrirem mais devagar fazendo o script automatizado se perder.
O processo básico de execução de suítes automatizadas na homologação pode ser visualizado na figura 2.18.
Figura 2.18 – Processo de execução de roteiros automatizados. Fonte: Autoria própria, 2019.
Na equipe de automação do Produto X um membro da equipe é responsável pela homologação. Este é um processo rotativo, ou seja, após um determinado número de sprints, outro membro da equipe se torna responsável pela homologação. 
Nessa tarefa foram gastos cerca de quatro dias, ainda assim não foi possível executar todas as suítes de homologação devido a sua grande quantidade. 
Analisar resultados
Após a execução de alguns roteiros foi necessário realizar a validação dos que apresentaram falhas ou ficaram pendentes para revisão, isso pode ser verificado na figura 2.17, na coluna ‘Status’. 
Foi verificado que a suíte ‘Atacarejo_ProdutoX’ apresentou erro em sua execução. Seu relatório apresentou divergência de valores, como pode ser visualizado na figura 2.19. 
	Figura 2.19 – Relatório de execução da suíte Atacarejo_ProdutoX. Fonte: Autoria própria, 2019.
Após validar a divergência foi necessário ajustar os valores na suíte de automação, esse ajuste foi necessário pois houve uma mudança do sistema que gerou a alteração de valores de forma proposital. Após realizados os ajustes, a suíte foi executada novamente e concluída sem erros.
Quando todas as suítes de automação apresentarem sucesso em sua execução, é responsabilidade do membro da equipe que está realizando a homologação informar a equipe de Gerência de Configuração (GCO), que se pode realizar a liberação da nova versão do Produto X.
A análise de resultados demandou cerca de três dias de estágio, junto com a análise foram realizadas as atividades de manutenção de script e validação dos mesmos.
Abrir bugs, defeitos e auditorias
O tempo restante de estágio foi utilizado para verificar casos onde foi necessária a abertura de atividades como bugs, defeitos e auditorias.
Em alguns casos ao analisar algumas suítes que não tiveram sucesso, são encontrados erros no sistema. Caso seja verificado que esse erro não ocorria em versões anteriores do software, é realizada a criação de um WI do tipo ‘Auditoria’, segundo a equipe de automação esse tipo de tarefa é a mais comum de ser aberta durante a homologação. 
O WI de ‘Auditoria’ foi aberto na área de projeto do GCO. Foi necessário documentar algumas informações nessa tarefa, como pode ser visto na figura 2.20.
Figura 2.20 – Algumas informações necessárias em uma tarefa de auditoria. Fonte: Autoria própria, 2019.
Além da descrição de como realizar a simulação da situação, também são documentadas informações sobre o banco de dados. Nesse caso também foi disponibilizado um backup (cópia de segurança) do banco de dados para ser utilizado.
Um
dos papeis do GCO é descobrir qual alteração que causou o erro no sistema, para isso é necessário simular o erro. Após simulado a equipe de GCO abriu um defeito e o mesmo foi corrigido pela equipe de desenvolvimento.
Depois de corrigida a situação, a suíte que encontrou a mesma foi executada novamente e não relatou erros. Esse processo de abertura de auditorias pode ocorrer tanto na execução da homologação quanto na criação de novos scripts automatizados.
CONCLUSão
Após finalizar a experiência de estágio foi possível verificar que a área automação de testes abrange muito mais que a criação de scripts automatizados. Seus processos são parte crucial da garantia da qualidade do produto e compreender os mesmos garantiu uma nova visão, não apenas sobre a área de automação, mas também sobre a área de qualidade de software como um todo.
 Durante o período de estágio a atividade mais desafiadora foi o entendimento das ferramentas utilizadas para automatizar scripts, principalmente em compreender a linguagem de programação utilizada para automação e seguir as boas práticas de codificação empregadas pela equipe. Apesar de complexa, foi uma das atividades que mais agregou conhecimento técnico durante o período de estágio.
Um ponto importante a se destacar é que foram realizadas tarefas que agregaram na qualidade do produto, foi aberta uma auditoria durante o período de estágio, que resultou na correção de um erro. Assim como também foi possível agregar ao processo de automação de testes, realizando a criação de scripts automatizados de um caso de teste que possuia três scripts de teste.
A experiência de estágio possibilitou o surgimento de novas oportunidades em diversas áreas de atuação de qualidade de software. Dessa forma é possível concluir que o conhecimento adquirido sobre os processos, ferramentas e a automação de teste como um todo foi positivo de forma profissional e pessoal.
REFERÊNCIAS bibliográficas
CISS SOFTWARE E SERVIÇOS. Glossário. Dois Vizinhos, 2019.
CISS SOFTWARE E SERVIÇOS. Guia de Teste de Software. Dois Vizinhos, 2019.
FARINELLI, Fernanda. Conceitos Basicos de programação orientada a objetos. Instituto Federal Sudeste de Minas Gerais, p. 4. 2007. Disponível em: < https://s3.amazonaws.com/academia.edu.documents/38693459/Apostila_Java_B.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&Expires=1559519832&Signature=TNyFK%2BATdt4Sjiq1BUKqMdUoOzs%3D&response-content-disposition=inline%3B%20filename%3DSubClasse_Roedores_SubClasse_Caes_SubCla.pdf>. Acesso em: 02, junho, 2019
IBM. IBM Knowledge Center: Visão geral do Collaborative Lifecycle Management. 2019a. Disponível em: <https://www.ibm.com/support/knowledgecenter/pt-br/SSYMRC_5.0.2/com.ibm.help.common.jazz.calm.doc/topics/c_calm_common.html>. Acesso em: 30, maio, 2019.
IBM. IBM Knowledge Center: Visão geral da solução Rational for Collaborative Lifecycle Management. 2019b. Disponível em: <https://www.ibm.com/support/knowledgecenter/pt-br/SSYMRC_5.0.2/com.ibm.help.common.jazz.calm.doc/topics/c_capabilities.html>. Acesso em: 31, maio, 2019.
IBM. IBM Knowledge Center: Área de Projetos. 2019c. Disponível em: < https://www.ibm.com/support/knowledgecenter/pt-br/SSYMRC_5.0.2/com.ibm.jazz.platform.doc/topics/c_project_area.html>. Acesso em: 31, maio, 2019.
IZABEL, Leonardo Roxo Pessanha. Testes Automatizados No Processo De Desenvolvimento De Softwares, p. 17. 2014. Tese de Doutorado. Universidade Federal do Rio de Janeiro. Disponível em: <http://www.monografias.poli.ufrj.br/monografias/monopoli10012548.pdf>. Acesso em: 22, maio, 2019.
MICRO FOCUS. Unified Functional Testing Help Center: Welcome to UFT. 2019. Disponível em: <https://admhelp.microfocus.com/uft/en/14.50-14.52/UFT_Help/Content/User_Guide/Ch_UFT_Intro.htm>. Acesso em: 02, junho, 2019. 
MOLINARI, Leonardo. Inovação e automação de testes de software. São Paulo: Érica, 2010.
PADILHA, Thais Cássia Cabral; MARINS, Fernando Augusto Silva. Sistemas ERP: características, custos e tendências. Production, v. 15, n. 1, p. 104, 2005. Disponível em: <http://www.scielo.br/pdf/%0D/prod/v15n1/n1a08.pdf>. Acesso em: 25, maio, 2019.
Apêndices
APÊNDICE 1 – cronograma de estágio supervisionado I