Investigandoestrategiasteste-Costa-2022

Prévia do material em texto

Universidade Federal do Rio Grande do Norte
Instituto Metrópole Digital
Programa de Pós-graduação em Tecnologia da
Informação
Mestrado Profissional em Tecnologia da
Informação
Investigando Estratégias de Teste de
Regressão: Um Estudo de Caso na
STI-UFRN
Samuel Alves da Costa
Natal-RN
Julho de 2022
Samuel Alves da Costa
Investigando Estratégias de Teste de Regressão: Um
Estudo de Caso na STI-UFRN
Dissertação de Mestrado apresentada ao Pro-
grama de Pós-graduação em Tecnologia da
Informação da Universidade Federal do Rio
Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Tecnologia
da Informação.
Universidade Federal do Rio Grande do Norte – UFRN
Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Tecnologia da Informação – PPgTI
Orientador: Dr. Sérgio Queiroz de Medeiros
Coorientador: Dra. Roberta de Souza Coelho
Natal-RN
2022
Costa, Samuel Alves da.
 Investigando Estratégias de Teste de Regressão: Um Estudo de
Caso na STI-UFRN / Samuel Alves da Costa. - 2022.
 75 f.: il.
 Dissertação (mestrado) - Universidade Federal do Rio Grande
do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação
em Tecnologia da Informação, Natal, RN, 2022.
 Orientador: Prof. Dr. Sérgio Queiroz de Medeiros.
 Coorientador: Profa. Dra. Roberta de Souza Coelho.
 1. Teste de software - Dissertação. 2. Testes automatizados
de sistema - Dissertação. 3. Classe de equivalência -
Dissertação. 4. UI.Vision - Dissertação. 5. STI - Dissertação.
I. Medeiros, Sérgio Queiroz de. II. Coelho, Roberta de Souza.
III. Título.
RN/UF/BCZM CDU 004.41
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Elaborado por Ana Cristina Cavalcanti Tinoco - CRB-15/262
Dissertação de Mestrado sob o título Investigando Estratégias de Teste de Regressão: Um
Estudo de Caso na STI-UFRN apresentada por Samuel Alves da Costa e aceita pelo
Programa de Pós-graduação em Tecnologia da Informação da Universidade Federal do Rio
Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo
especificada:
Prof. Dr. Sérgio Queiroz de Medeiros
Presidente
ECT – Escola de Ciências e Tecnologia
UFRN – Universidade Federal do Rio Grande do
Norte
Profa. Dra. Roberta de Souza Coelho
Examinador
DIMAp – Departamento de Informática e
Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do
Norte
Prof. Dr. Eiji Adachi Barbosa
Examinador
IMD – Instituto Metrópole Digital
UFRN – Universidade Federal do Rio Grande do
Norte
Prof. Dr. Uirá Kulesza
Examinador
DIMAP – Departamento de Informática Aplicada
UFRN – Universidade Federal do Rio Grande do
Norte
Prof. Dr. Rodrigo Bonifácio de Almeida
Examinador
CIC – Departamento de Ciência da Computação
UnB – Universidade de Brasília
Natal-RN, 18 de julho de 2022.
Samuel Alves da Costa
Investigando Estratégias de Teste de Regressão: Um
Estudo de Caso na STI-UFRN
Dissertação de Mestrado apresentada ao Pro-
grama de Pós-graduação em Tecnologia da
Informação da Universidade Federal do Rio
Grande do Norte como requisito parcial para
a obtenção do grau de Mestre em Tecnologia
da Informação.
Trabalho aprovado. Natal-RN, 18 de julho de 2022.
Prof. Dr. Sérgio Queiroz de Medeiros
Orientador
Profa. Dra. Roberta de Souza Coelho
Examinador
Prof. Dr. Eiji Adachi Barbosa
Examinador
Prof. Dr. Uirá Kulesza
Examinador
Prof. Dr. Rodrigo Bonifácio de
Almeida
Examinador
Natal-RN
2022
Dedico este trabalho aos meus pais: Helena e Manoel.
Agradecimentos
Agradeço a Deus por permitir minha chegada até aqui.
Agradeço aos meus pais Helena e Manoel e aos meus irmãos Daniel e Raquel por
todo apoio.
Agradeço à Universidade Federal do Rio Grande do Norte pela oportunidade de
crescimento profissional.
Agradeço aos meus orientadores, Professor Dr. Sérgio Queiroz de Medeiros e
Professora Dra. Roberta de Souza Coelho, que com paciência, compreensão, empenho e
disciplina me guiaram nesta jornada.
Agradeço ao Professor Dr. Uirá Kulesza que trouxe significativas contribuições ao
trabalho.
Agradeço a Clarissa Lorena, Diretora de Sistemas da Superintendência de Tecno-
logia da Informação - STI-UFRN, pelo incentivo desde o primeiro momento que apresentei
a proposta para cursar o mestrado.
Agradeço a toda minha prezada equipe de trabalho do SIGAA, ao pessoal da
secretaria e a todos os demais colaboradores da STI; em especial Rafael Gomes.
Agradeço ao corpo docente e administrativo do PPgTI (Programa de Pós-Graduação
em Tecnologia da Informação) a todos os demais funcionários do IMD (Instituto Metrópole
Digital).
Agradeço aos meus colegas de turma do PPgTI.
Agradeço a todos que de forma direta ou indireta contribuíram nessa jornada.
Muito obrigado!
O sucesso é a soma de pequenos esforços repetidos dia após dia.
Robert Collier
Resumo
A Superintendência de Tecnologia da Informação - STI, é responsável por desenvolver
e manter os sistemas computacionais da UFRN. Cada sistema possui equipes de testes
responsáveis pelos testes de sistemas. Um destes sistemas é o Sistema Integrado de Gestão
de Atividades Acadêmicas - SIGAA, ele possui mais de 5 mil casos de uso. A equipe de teste
dele realiza testes exploratórios e de regressão manualmente, contudo, para um sistema
desse porte, realizar teste de regressão manual é inviável, de modo que os testes de regressão
acabam sendo feitos em quantidade pouco significativa, porém aumenta-los continuando
da forma manual irá tirar a capacidade de fazer muitos outros testes exploratórios. Devido
ao alto número de casos de uso, é inviável automatizar todos os testes de regressão.
Assim, deseja-se realizar testes automatizados de regressão para funcionalidades que
apresentam maiores chances de falhar e dessa forma encontrar indicadores que irão mostrar
os casos de uso mais relevantes para terem os testes automatizados, permitindo assim
que a equipe de testes possa focar nos testes exploratórios e, de maneira geral, expandir
a cobertura dos testes sem precisar aumentar o número de membros da equipe. Dessa
forma, esta pesquisa buscou estratégias de seleção de funcionalidades para construção
de testes automatizados de sistemas por meio de um estudo de caso na STI-UFRN. A
pesquisa identifica características de casos de uso do SIGAA que devem ter os testes
automatizados priorizados; para isso foram realizados dois estudos que buscaram medir
a influência de critérios como: diferentes complexidades da tela e de tempos da última
alteração; e funcionalidades que demandaram maior tempo de testes manuais durante o
período de um mês. Assim, os testes das funcionalidades escolhidas foram automatizados
com o UI.Vision, considerando as classes de equivalência e happy path na construção deles.
Com base nos resultados das execuções diárias destes testes, foi possível perceber que os
critérios que apresentaram maior relevância para terem os testes automatizados foram:
telas que dependem de serviços externos ao sistema e funcionalidades que demandaram
muitos testes manuais recentemente.
Palavras-chave: Teste de Software; Testes Automatizados de Sistema; Classe de Equivalên-
cia; UI.Vision; STI.
Abstract
The Superintendência de Tecnologia da Informação - STI is responsible for developing and
supporting UFRN’s computational systems. Each system has a testing team responsible
for system testing. One of these systems is the Sistema Integrado de Gestão de Atividades
Acadêmicas - SIGAA, it has more than 5 thousand use cases. The test team performs
exploratory and regression tests manually, however, for a system of this size, performing
manual regression tests is unfeasible, thus the regression tests end up being done in a
negligible amount, but the task to increase the amount of regression tests is not easy,
especially if the are performed manually, given that it will will take away the ability to do
many other exploratory tests. Due to the high number of use cases, it is impracticalto
automate all regression tests. Therefore, the aim is to perform automated regression tests
for features that are most likely to fail and then find indicators that will show the most
relevant use cases at which the automated tests are justified, thus allowing the testing
team to focus on exploratory tests, and, generally speaking, expand test coverage without
having to increase the number of team members. Thus, this research sought strategies for
selecting features for building automated system tests through a case study at STI-UFRN.
This study identifies features from use cases of SIGAA which must have automated tests
prioritized, in order to do this it was performed two studies which sought to measure the
influence of criterias such as: different screen complexity and time from the last change,
features that demanded more time of manual tests during the period of one month. Thus,
the tests of the chosen features were automated with UI.Vision, considering the equivalence
classes and happy path in their construction. Based on a daily execution of these tests,
it was possible to note that the criterias which were more relevant in order to determine
which tests would be automatized were: screens that are dependent on external services
and features which required a large amount of manual tests recently.
Keywords: Software Testing; Automated System Tests; Equivalence Class; UI.Vision; STI.
Lista de ilustrações
Figura 1 – Processo Simplificado de Testes no Fluxo de Sustentação . . . . . . . . 17
Figura 2 – Quadro de tarefas da Versão Atual no GAS (Adaptado) (GAS, 2022) . 18
Figura 3 – Recorte da tela do Relatório de Erros no Inspectore (STI, 2022) . . . . 19
Figura 4 – Print(recorte) da planilha de Acompanhamento - Métricas de Testes
do SIGAA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figura 5 – Modelo V (PRESSMAN; MAXIM, 2016). . . . . . . . . . . . . . . . . 26
Figura 6 – Fluxo do processo Scrum (PRESSMAN; MAXIM, 2016). . . . . . . . . 28
Figura 7 – Cadastrar Discente (SIGAA, 2021). . . . . . . . . . . . . . . . . . . . . 40
Figura 8 – Cadastrar Componente Curricular (SIGAA, 2021). . . . . . . . . . . . 41
Figura 9 – Recorte da planilha de registro de dados dos testes automatizados . . 47
Figura 10 – Percentual de testes automatizados que com sucesso e falha na execução 50
Figura 11 – Porcentagem de erros relacionados a ambiente/serviço externo e código 51
Figura 12 – Porcentagem de quebras por UC . . . . . . . . . . . . . . . . . . . . . 52
Figura 13 – Porcentagem de UC do G5 que foram testados novamente em maio e
em junho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 14 – Cadastrar Discente de Graduação (imagem completa) (SIGAA, 2021). . 66
Lista de tabelas
Tabela 1 – Os princípios dos métodos ágeis (SOMMERVILLE, 2011). . . . . . . . 28
Tabela 2 – Classes de Equivalência do programa identifier (BARBOSA et al., 2000). 31
Tabela 3 – Classes de Equivalência de Nome (Oficial/Social) . . . . . . . . . . . . 42
Tabela 4 – Classes de Equivalência de Ano de Conclusão (do ens. médio) . . . . . 42
Tabela 5 – Classes de Equivalência de Código (componente curricular) . . . . . . . 43
Tabela 6 – Grupos de casos de uso do Estudo 1 . . . . . . . . . . . . . . . . . . . 45
Tabela 7 – Casos de uso que apresentaram quebra no teste . . . . . . . . . . . . . 47
Tabela 8 – Casos de uso do Estudo 2 . . . . . . . . . . . . . . . . . . . . . . . . . 54
Tabela 9 – Casos de uso do Estudo 2 que demandaram testes em maio . . . . . . 57
Tabela 10 – Casos de uso do Estudo 2 que demandaram testes em junho . . . . . . 57
Lista de Abreviaturas e Siglas
API Application Programming Interface (interface de programação de aplicações)
CSV Comma-separated values
FAT Facilidade de Automação
DAS Diretoria de Atenção à Saúde do Servidor
GAS Gerenciador de Atividades de Sistemas
ISTQB International Software Testing Qualifications Board
RNP Rede Nacional de Ensino e Pesquisa
RPA Robotic Process Automation
SIG Sistema Integrado
SIGAA Sistema Integrado de Gestão de Atividades Acadêmicas
SIGPS Sistema Integrado de Gestão de Processos Seletivos
SiSU Sistema de Seleção Unificada
SPI Software Process Improvement (Melhoria do Processo de Software)
STI Superintendência de Tecnologia da Informação
UC Use case
Sumário
Capítulo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Problema de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . 23
Capítulo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 CONCEITOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 24
2.1 A STI e o SIGAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Atividades de Testes do SIGAA . . . . . . . . . . . . . . . . . . . . . 25
2.3 Processo de desenvolvimento na STI baseado no Scrum . . . . . . . 27
2.4 Técnicas de Testes de Software . . . . . . . . . . . . . . . . . . . . . 29
2.4.1 Técnica Estrutural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.2 Técnica Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.3 Classes de Equivalência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Utilização do UI Vision na Automatização de Testes . . . . . . . . . 31
Capítulo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 33
3.1 Critérios para priorização de testes de regressão . . . . . . . . . . . . 33
3.2 Definindo critérios para priorizar a automação de testes de UC . . . 35
3.3 Critérios para estimar complexidade do UC (página do UC) . . . . . 37
3.4 Discussões acerca dos trabalhos relacionados . . . . . . . . . . . . . 38
Capítulo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 ESTUDO DE CASO NA STI UFRN . . . . . . . . . . . . . . . . . . 39
4.1 UC do SIGAA para exemplificar classes de equivalência . . . . . . . 39
4.1.1 Classes de equivalência para Cadastrar Discente . . . . . . . . . . . . . . . 41
4.1.2 Classes de equivalência em Cadastrar Componente Curricular . . . . . . . . 42
4.2 Estudo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Estudo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Capítulo 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Contribuições da pesquisa à STI . . . . . . . . . . . . . . . . . . . . . 61
5.3 Lições Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
APÊNDICES 65
APÊNDICE A – CLASSIFICAÇÃO DA COMPLEXIDADE EM CASO
DE USO . . . . . . . . . . . . . . . . . . . . . . . 66
APÊNDICE B – PLANILHA DE COLETA DIÁRIA DOS TESTES
DO ESTUDO 1 . . . . . . . . . . . . . . . . . . . 68
APÊNDICE C – PLANILHA DE COLETA DIÁRIA DOS TESTES
DO ESTUDO 2 . . . . . . . . . . . . . . . . . . . 74
15
1 Introdução
Com o natural aumento de tamanho e complexidade dos sistemas de software, o
maior desafio na engenharia de software é garantir a confiança desses sistemas; e para
confiar em um sistema é importante saber que ele estará disponível quando necessário e
executará conforme o esperado (SOMMERVILLE, 2011). Dessa forma, além da necessidade
de possuir boa infraestrutura física, é necessário que o sistema funcione de acordo com o
que seespera dele, por isso um software adequadamente testado proporcionará melhor
experiência ao usuário. Sendo que a atividade de teste é crucial para o sucesso de um
projeto de software, mas essa atividade geralmente requer cerca de 50% dos recursos de
desenvolvimento de software (BEIZER, 2003).
Nesse contexto, notoriamente a sociedade demanda por contínuas soluções tec-
nológicas que possam resolver problemas e promover melhor qualidade de vida. Por isso,
softwares cada vez mais complexos precisam ser gerados em tempos menores e com maior
qualidade (SOUZA; OLIVEIRA; MORAES, 2020). Além disso, as soluções em software
propiciam melhor gerenciamento da dinâmica necessária à disseminação do conhecimento,
possibilitando inclusive interiorização das instituições de ensino do País de forma inclusiva.
Diante de tais necessidades da sociedade, é imprescindível investir em estratégias
que contribuam para o desenvolvimento de sistemas, contudo diversos desafios diários
precisam ser vencidos. Realizar controle de qualidade de software é um desafio devido
à alta complexidade do produto e diversas dificuldades relacionadas ao processo de
desenvolvimento, que envolve questões humanas, técnicas, burocráticas, negociais e políticas
(BERNARDO; KON, 2008). Nessa perspectiva, equipes responsáveis por executar as
atividades de controle de qualidade lidam com múltiplos problemas, onde o gerenciamento
das demandas como criação e execução de planos de testes, verificações e validações
diversas são determinantes para o bom funcionamento da ferramenta.
Por isso, para que todos os sistemas funcionem com qualidade, em especial os da
Universidade Federal do Rio Grande do Norte - UFRN que são usados em diversas intuições
brasileiras, eles precisam passar por processos de Teste de Software e serem validados
nas suas respectivas Equipes de Testes, só assim as versões são lançadas no ambiente de
produção. E para cada nova versão a ser lançada os impactos dela são previamente avaliados
e novos testes são refeitos a fim de que as soluções atendam da melhor forma às expectativas
dos usuários sem causar impactos negativos às funcionalidades já estáveis nas versões
anteriores. Por tudo isso, a realização de testes de software, em especial os de regressão1,
1 O teste de regressão envolve a execução de conjuntos de testes que tenham sido executados com
sucesso, após as alterações serem feitas em um sistema. Este teste verifica se essas mudanças não
Capítulo 1. Introdução 16
permite identificar erros gerados pelas melhorias ou correções no software, proporcionam
maior qualidade ao sistema e aumento da confiança nas soluções desenvolvidas.
1.1 Contexto
A Superintendência de Tecnologia da Informação - STI-UFRN é responsável pelo
desenvolvimento dos sistemas SIG da Universidade (STI, 2021), como o Sistema Integrado
de Gestão de Atividades Acadêmicas - SIGAA e o Sistema Integrado de Gestão de Processos
Seletivos - SIGPS que são sistemas acadêmicos; já o Sistema Integrado de Gestão de
Recursos Humanos - SIGRH, e o Sistema Integrado de Patrimônio, Administração e
Contratos - SIPAC, compõem os sistemas administrativos (UFRN, 2021).
Todos esses sistemas citados possuem dois fluxos de desenvolvimento: Fluxo de
Sustentação e Fluxo de Evolução. Em Sustentação são realizadas contínuas manutenções
e correções das funcionalidades do sistema, já o Fluxo de Evolução é onde as novas
funcionalidades são implementadas em sprints seguindo adaptações da metodologia Scrum.
Entre esses sistemas SIG, o SIGAA é um dos que mais se destaca pela quantidade
de funcionalidades, ele possui um total de 5268 casos de uso, de acordo com levantamento
de 2017. Nele, além da Equipe de Codificação e de Requisitos, o sistema possui a Equipe de
Testes que é responsável por realizar todos os testes de sistemas do software desenvolvido.
E nesse contexto a Equipe de Testes atua tanto no Fluxo de Sustentação quanto no Fluxo
de Evolução.
Dessa forma, este trabalho de pesquisa identifica características de funcionalidades
do SIGAA que devem ter os testes automatizados priorizados; para isso foram realizados
dois estudos que buscaram medir a influência de critérios como: diferentes complexidade
da tela e de tempos da última alteração; funcionalidades que demandaram maior tempo
de testes manuais durante o período de um mês. Assim, os testes das funcionalidades
escolhidas foram automatizados com a ferramenta UI.Vision, considerando as classes de
equivalência e happy path na construção deles.
E com base nos resultados das execuções diárias destes testes, foi possível perceber
que os critérios que apresentaram maior relevância para terem os testes automatiza-
dos foram: telas que dependem de serviços externos ao sistema e funcionalidades que
demandaram muitos testes manuais recentemente.
É importante destacar que a STI apresenta um processo de testes de sistemas com
características como: existir uma política e estratégia de testes; realiza planejamento de
introduziram novos bugs no sistema e se o novo código interage com o código existente conforme o
esperado (SOMMERVILLE, 2011). Dessa forma é possível verificar se uma correção/atualização pode
gerar impactos negativos no que já funcionava
Capítulo 1. Introdução 17
testes; monitoramento e controle do teste; modelagem e execução do teste; e utilizar-se de
ambiente próprio para realização dos testes e boa relação com os stakeholders (as partes
interessadas).
Para Sustentação, o processo de testes é mostrado de forma simplificada na
Figura 1, que mostra todas as principais etapas desde o momento inicial do desenvolvimento
até a validação da tarefa, de forma que para uma tarefa ser validada, ela deve passar por
todas as etapas.
Figura 1 – Processo Simplificado de Testes no Fluxo de Sustentação
Já o fluxo de evolução envolve uma complexidade maior de mensurar o tempo de
testes, haja vista que os testes e correções nele ocorrem, na prática, de forma simultânea
e o fluxo não é contínuo (muitos dias, semanas ou meses entre o fim de uma sprint e
início da próxima, e nesse intervalo o fluxo de trabalho fica pausado, de modo que toda
equipe é realocada para trabalhar apenas em Sustentação que tem em geral demandas
mais urgentes). Por estes motivos, apenas o fluxo de Sustentação foi selecionado para ser
trabalhado nesta pesquisa.
Nesse contexto, todas as tarefas são gerenciadas no Gerenciador de Atividades de
Sistemas - GAS, que é responsável por todo acompanhamento das demandas, como ilustra
a Figura 2 (adaptada para preservação de informações) na qual é exibido o quadro da
"Versão atual" que irá ser lançada e facilmente identifica-se as tarefas prontas para integrar,
tarefas testando, aguardando correções ou validadas por testes. Além disso, diversas
outras informações relevantes como prioridade, número da tarefa e pessoa responsável são
Capítulo 1. Introdução 18
facilmente encontradas, haja vista o quadro permitir uma visão geral da versão.
Além disso, o número de tarefa (número que identifica a tarefa) apresentado no
quadro permite que os membros da equipe possam clicar nele e ter todo o detalhamento
da tarefa, como histórico dos logs com observações relacionadas a ela,pessoa que criou,
status nos quais a tarefa passou, entre outras informações.
Figura 2 – Quadro de tarefas da Versão Atual no GAS (Adaptado) (GAS, 2022)
Paralelamente ao GAS é usado o Inspectore, um sistema integrado ao GAS e
responsável pelo gerenciamento dos erros nas tarefas, como ilustra a Figura 3 que mostra
parte do relatório de erros de uma tarefa. É no Inspectore onde cenários e narrativas são
criados e o Relatório de Erros é gerado com os erros que são cadastrados por tarefa. O
Inspectore permite também o gerenciamento dos status de cada erro (erros cadastrados,
corrigidos, desconsiderados, finalizados, reincidentes), de modo que o processo de testes e
correções é bastante transparente entre todos os membros que compõem o SIGAA.
Contudo, apesar da Equipe de Testes realizar testes exploratórios manuais exaus-
tivos, ela possui uma limitaçãopara realizar os testes de regressão. No entanto, existe a
necessidade de aumentar o fluxo de funcionalidades testadas e inserir os testes automatiza-
dos de regressão de forma ampla e estratégica, a fim de conseguir melhor aproveitamento
da força de trabalho já existente.
Nesse sentido, é importante destacar que o teste de regressão é caro e geralmente
impraticável quando um sistema é testado manualmente, pois os custos com tempo e
esforço são altos. Assim, a aplicação da estratégia de testes de regressão é importante para
Capítulo 1. Introdução 19
Figura 3 – Recorte da tela do Relatório de Erros no Inspectore (STI, 2022)
a garantia da qualidade, mas pode ser custosa dependendo do tamanho do conjunto de
casos de teste de um projeto (MALIMPENSA, 2018).
Todavia, realizar os testes de regressão de forma automatizada é algo viável e
permite reduzir os custos com testes de regressão manual. Haja vista que os testes existentes
podem ser executados novamente de forma rápida e barata (SOMMERVILLE, 2011).
Dessa forma, realizar os testes de regressão de forma automatizada representa
diversos ganhos para o desenvolvimento, como maior capacidade de testes em menor
intervalo de tempo. O que consequentemente impacta de forma positiva nos custos,
qualidade e tempo total de desenvolvimento do produto de software. Gerando assim maior
capacidade de desenvolvimento e maior credibilidade aos responsáveis pela criação do
produto.
Capítulo 1. Introdução 20
1.2 Problema de Pesquisa
A instituição utiliza metodologia ágil para o desenvolvendo do SIGAA e o fluxo
de novas tarefas é bastante intenso, sejam elas de correção ou ajustes, estando no contexto
de Sustentação ou de Evolução; ou seja, em uma frequência bastante elevada novas
atualizações com correções do software são lançadas no ambiente de produção. Contudo,
a correção de um defeito pode introduzir outros erros (CUNHA, 2010) e essas novas
atualizações podem acarretar novos erros em produção, por isso é necessário e importante
realizar testes de regressão, que verificam se essas mudanças e correções não introduziram
novos bugs no sistema e se o novo código interage com o já existente conforme esperado
(SOMMERVILLE, 2011).
Nesse contexto, é importante que a inclusão de testes automatizados de regressão
siga critérios adequados, inclusive, conforme (VIANA, 2006) menciona: um problema
clássico no caso de automação de testes de regressão é identificar que casos de testes devem
ser automatizados para que seja possível obter bons resultados dos testes executados.
Dessa forma, nesta pesquisa é proposta uma abordagem para auxiliar a gerência de testes
a selecionar quais os casos de uso devem ter prioridade na criação dos testes automatizados
de sistemas e assim formar suítes de testes automatizados que possam complementar os
testes manuais.
Assim é importante identificar qual seria um bom critério para automatização de
testes de sistemas no contexto de uma instituição com as características gerais da STI.
Com essas ações, espera-se aumentar a visibilidade por parte da liderança/gerência
de testes no sentido de auxiliar na tomada de decisões, como avaliar os testes automatizados
que devem ou não serem continuados, bem como avaliar os benefícios da automatização
usando as métricas de número de testes realizados a cada execução e quantidade de testes
novos e antigos em uso.
Contudo, é importante destacar que os testes automatizados se somam aos testes
manuais, de modo que a gravação com o UI.Vision, se refere principalmente à etapa de
testar o happy path que antecede a realização dos testes exploratórios, que por sua vez são
testes manuais, porém gravados e executados para o teste de regressão (com Replay do
teste).
1.3 Metodologia
Inicialmente foi realizada uma revisão da literatura à procura de conceitos e
publicações relacionadas a este trabalho de pesquisa. Em seguida foi realizada uma
avaliação com dois estudos que são analisados ao longo do trabalho a fim de identificar os
Capítulo 1. Introdução 21
melhores critérios para automatização dos testes com base nos critérios vistos a seguir,
mas sem destaque para comparações entre os tempos de testes manuais e automatizados.
Em ambos os estudos foram coletados dados diários dos testes que são discutidos com
relação às possíveis melhores estratégias para priorizar os testes dos casos de uso a serem
automatizados, considerando os resultados obtidos em 5 diferentes grupos, que serão vistos
em detalhe nos estudos.
No estudo 1 é analisado o comportamento de testes automatizados criados com
base na complexidade da tela do caso de uso2 e no tempo da última alteração do código
relacionado a ele. Neste estudo os testes automatizados são implementados a fim de se
avaliar o comportamento deles ao longo da pesquisa. Para a análise considera as quebras
dos testes e a influência da complexidade da tela na quantidade de quebras do testes
automatizados. Assim o estudo 1 possui quatro grupos (G1 a G4) que consideram estes
aspectos nas suas respectivas formações.
Já no estudo 2 os testes automatizados foram criados com base nos testes manuais
que consumiram os maiores tempos de testes durante um período (neste trabalho este
período foi fixado em um mês). Assim, seis casos de uso que demandaram maiores tempo
de testes manuais tiveram os testes automatizado a fim de ser avaliado diariamente o
comportamento das execuções desses testes, considerando se havia significativa quebra
dos testes automatizados e também se havia necessidade de novos testes para os casos
de uso que consumiram os maiores tempos. A partir destes critérios, foi criado o quinto
grupo (G5) para ser analisado e neste estudo observou-se que os testes automatizados
não tiveram quebras, porém os testes manuais que tiveram maiores tempos de testes em
determinado mês, tendem a demandar também considerável tempo de teste nos meses
subsequentes, o que indica que é vantajoso automatizar estes testes manuais
Para automação dos testes foi utilizada a ferramenta UI.Vison no contexto do
Sistema Integrado de Gestão de Atividades Acadêmicas - SIGAA/UFRN, contudo, outras
ferramentas que possibilitem a automatizar também poderiam ser usadas. Assim, de
acordo com a complexidade do caso de uso (UC, do inglês use case) e o tempo da última
correção nele, levando-se em consideração os grupos citados acima, os testes automatizados
são implementados considerando as classes de equivalências envolvidas na funcionalidade
(exceto o G4) e à medida que os testes são executados, são coletadas informações que
posteriormente serão analisadas com base em aspectos como quantidade de falhas e sucesso
das execuções.
Todos os dados coletados foram armazenados em planilhas. A primeira palhinha
2 Um caso de uso representa uma utilização do sistema por um ator, que pode ser uma pessoa, dispositivo
físico, mecanismo ou subsistema que interage com o sistema alvo, utilizando algum de seus serviços
(NAKAGAWA, 2019). No contexto abordado neste trabalho, um caso de uso é uma funcionalidade do
sistema; por exemplo, o caso de uso Cadastrar Discente que será visto ao longo do trabalho.
Capítulo 1. Introdução 22
do G5, denominada planilha de acompanhamento, foi compartilhada com a Equipe de
Testes, como ilustra a Figura 4, onde todos os testadores da Equipe de Testes do SIGAA
tiveram acesso. Nessa planilha, todas as vezes que determinada tarefa entrou no fluxo de
testes, importantes informações foram cadastradas pelo testador que realizou o teste, como
o módulo do sistema, caso de uso envolvido, número da tarefa e tempo de início e fim do
teste, de forma que o tempo de teste apresentado na coluna “Tempo Gasto” (coluna G) é
calculado automaticamente na respectiva linha da tarefa. Todos esses dados são coletados
diariamente de modo que para cada mês de coleta existe uma aba relacionada na planilha.
Figura 4 – Print(recorte) da planilha de Acompanhamento - Métricas de Testes do SIGAA.
Dessa forma, os dados coletados nos testes exploratórios desta planilha de acom-
panhamento foram utilizados paraselecionar casos de uso que demandaram mais tempo de
testes em determinados períodos da coleta (para este trabalho o período foi o mês de abril
de 2022). Assim, a segunda planilha do estudo 2 é utilizada para armazenar os resultados
de sucesso ou falhas da execução diária dos testes automatizados do G5, ou seja, ela segue
a mesma lógica de registo dos outros grupos (G1 a G4) no estudo 1.
Por fim, com os dados analisados são gerados gráficos a fim de permitir melhor
visualização das informações. Dessa forma é possível facilmente observar diversas relações
como porcentagem de falhas dos testes automatizados. E isso contribui para a identifi-
cação de critérios de priorização de casos de uso que devem ter os testes automatizados
implementados.
Capítulo 1. Introdução 23
1.4 Estrutura do Documento
Este texto possui mais quatro capítulos além deste introdutório. O Capítulo 2
apresenta os conceitos relacionados a testes de software no contexto da Superintendência
de Tecnologia da Informação da UFRN, ferramentas utilizadas, atividades desempenhadas
e a dinâmica de como os testes de sistemas ocorrem. O Capítulo 3 aborda trabalhos
relacionados com a definição de critérios para priorizar a automação de testes de casos de
uso e critérios para estimar a complexidade de telas do caso de uso. O Capítulo 4 traz os
estudos realizados na STI, utilização de classes de equivalência na automatização de testes
e avaliação dos estudos realizados na pesquisa. Por fim, no Capítulo 5 são apresentadas as
considerações finais, as conclusões, as contribuições da pesquisa à STI, lições aprendidas e
trabalhos futuros.
24
2 Conceitos Relacionados
Neste capítulo são apresentados os principais conceitos e temas abordados no
trabalho. Eles estão relacionados ao local onde são desenvolvidos os testes de software
bem como às tecnologias utilizadas no contexto da Engenharia de Software.
2.1 A STI e o SIGAA
A Superintendência de Tecnologia da Informação (STI) é um órgão diretamente
subordinado à Reitoria da UFRN e é responsável por planejar, desenvolver, manter e
administrar os sistemas computacionais e a infraestrutura de rede da Universidade. A STI
elabora, em conjunto com os demais órgãos administrativos, toda a política de informática
da Instituição (STI, 2021).
Além de produzir e manter sistemas para UFRN, a STI também está presente
em diversas outras instituições do país por meio de acordos de cooperação técnica dos
sistemas SIG-UFRN, ou seja, os sistemas desenvolvidos na Superintendência são usados
em diversas universidades, institutos federais, órgãos ligados à segurança, entre outros.
Tais acordos de cooperação consistem na transferência de tecnologia da UFRN
para instituições cooperadas, permitindo capacitação delas para implantar os sistemas e
assim promover a informatização dos processos de trabalho nas Áreas Administrativas
(SIPAC), de Recursos Humanos (SIGRH) e Acadêmica (SIGAA) na busca da excelência
da gestão e dos serviços prestados à sociedade (UFRN, 2021). Dessa forma, soluções
desenvolvidas na STI têm implantações a nível nacional. Logo, o SIGAA é usado em
diversas universidades e institutos federais com suas respectivas adaptações, de forma
que, de acordo com estimativas recentes da STI, ele possui mais de 1 milhão de usuários,
levando-se em consideração todos os 31 parceiros que utilizam o Sistema.
O Sistema Integrado de Gestão de Atividades Acadêmicas - SIGAA, é um pacote
de soluções modernas para os procedimentos relacionados à área acadêmica da UFRN,
permitindo o gerenciamento das informações e atividades em todos os níveis de ensino
(STI, 2021).
O Sistema foi desenvolvido, utilizando a linguagem Java, pela STI-UFRN no ano
de 2006 e continua em pleno uso com constantes evoluções; atualmente o SIGAA/UFRN
possui 67.438 usuários considerando os mais diversos públicos da UFRN (discente, docente,
técnicos, entre outros) e tem um total de 165.458 vínculos ativos (dados de novembro
de 2021) - no caso um mesmo usuário pode ter um ou mais vínculos ativos. Além disso,
Capítulo 2. Conceitos Relacionados 25
o SIGAA possui mais de 5 mil casos de uso distribuídos entre 36 módulos/portais. A
Plataforma está na versão 4.7.5 (de 09/07/22) e se encontra disponível em <https:
//sigaa.ufrn.br/>.
2.2 Atividades de Testes do SIGAA
Os testes realizados na STI seguem o modelo em V, Figura 5, que descreve a
relação entre ações de garantia da qualidade e ações associadas à comunicação, modelagem
e atividades de construção iniciais. E à medida que a equipe de software desce em direção ao
lado direito do V, os requisitos básicos do problema são refinados em representações cada
vez mais detalhadas. Após gerado o código, as equipes responsáveis (de desenvolvimento,
testes, requisitos) passam para o lado direito do V, realizando uma série de testes (ligados
a ações de garantia da qualidade) que validam cada um dos modelos criados à medida que
se sobe pelo lado esquerdo (PRESSMAN; MAXIM, 2016).
Os testes realizados pela Equipe de Testes envolvem em especial os testes Funcio-
nais, ocorrendo apenas no nível de Teste de Sistema. Dessa forma os testes de sistemas
verificam o SIGAA como um todo, eles são realizados em ambientes de testes que têm toda
a infraestrutura necessária para execução dos testes, ou seja, eles simulam adequadamente o
ambiente real (ambiente de produção). Entre os testes de sistema, fatores como adequação
das funcionalidades aos requisitos, usabilidade e desempenho são pontos exaustivamente
testados. Dessa forma os testes manuais exercitam a interação do sistema com o usuário.
Nesse contexto são usados atualmente apenas testes exploratórios, ou seja, não se
usa de forma sistemática testes automatizados1, contudo todas as funcionalidades só são
lançadas em produção após passarem por processo de testes na Equipe de Testes que é
responsável por testes de sistemas de todos os módulos.
No que se refere à equipe responsável por cada nível de testes, considerando os
diferentes níveis de testes, como é exibido na Figura 5 criada por Pressman e Maxim
(2016), existe uma divisão de responsabilidades no SIGAA para os níveis apresentados.
Assim, considerando o modelo, cada nível do lado direito do V tem uma relação com os
artefatos do lado esquerdo, como mostram as setas saindo do lado direto para o lado
esquerdo, dessa forma existe a seguinte relação na STI:
1 Testes automatizados são programas ou scripts que executam funcionalidades do sistema sendo testado
e fazem verificações automáticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem é
que todos os casos de teste podem ser facilmente e rapidamente repetidos a qualquer momento e com
pouco esforço (BERNARDO; KON, 2008). Dessa forma, a utilização de testes automatizados facilita o
processo de teste de regressão uma vez que podem ser executados novamente de forma automática.
https://sigaa.ufrn.br/
https://sigaa.ufrn.br/
Capítulo 2. Conceitos Relacionados 26
Figura 5 – Modelo V (PRESSMAN; MAXIM, 2016).
• Os níveis "testes de unidade" e "testes de integração", que utilizam técnica estrutural
e focam respectivamente no teste da menor unidade do programa e a integração
entre elas, ficam a cargo da Equipe de Desenvolvimento (codificação);
• A Equipe de Testes é focada no nível de "testes de sistemas" que são os mais
demorados. Para isso, utiliza-se predominantemente da técnica funcional (caixa preta)
para realização dos testes, empregando planos de testes e exploração do sistema
como um todo de forma manual. Dessa forma, oficialmente, a Equipe de Testes atua
apenas com testes de sistemas;
• Por fim, o último nível, "teste de aceitação", é de responsabilidade da Equipe de
Requisitos que usa para essa atividade apenas a técnica funcional. Nesse teste,
que utiliza ambiente de testes específico, acontece o aceite final diretamente com o
usuário. Nesse caso apenas os analistas de requisitos responsáveis pelo módulo onde
a tarefa se encontra podem realizar esse teste. Por exemplo, se a tarefa envolve o
módulo de Graduação, apenas os analistasresponsivos por esse módulo fazem esse
teste; diferentemente da Equipe de Testes onde qualquer membro pode atuar em
qualquer módulo.
Além disso, cabe destacar que diversos termos usados durante o desenvolvimento,
como defeitos, erros e falhas, têm conceitos bem específicos, mas que comumente na prática
Capítulo 2. Conceitos Relacionados 27
acabam se confundindo ou usados como sinônimos.
Conforme (NETO; CLAUDIO, 2007) explica, defeito é a inserção inconsciente de
instrução ou comando incorreto durante o desenvolvimento. O erro é uma manifestação
concreta de um defeito em um artefato de software. Já a falha é um comportamento
operacional de um software diferente do esperado pelo usuário, de forma que uma falha
pode ter sido causada por vários erros e alguns erros podem nunca gerar uma falha.
Durante o dia a dia de trabalho é comum se usar o termo “erro” para se referir
a “falha”. Por exemplo, na STI, se no sistema ocorre um comportamento inesperado é
exibido para o usuário a tela conhecida como “Erro Vixe”. Ou seja, mesmo sendo um
comportamento incorreto do sistema, o que é uma falha, é conhecido como erro. Já no que
se refere aos testes, por serem focados na técnica funcional (caixa-preta) as situações de
defeito em geral não são abordadas pela Equipe de Testes.
2.3 Processo de desenvolvimento na STI baseado no Scrum
Métodos ágeis são estratégias de desenvolvimento incremental que se concentram
em desenvolvimento rápido, releases frequentes do software, redução de overheads dos
processos e produção de códigos de alta qualidade; bem como o envolvimento do cliente
diretamente no processo de desenvolvimento (SOMMERVILLE, 2011). Como é abordado
por Dantas e Junior (2016), os diversos benefícios do seu uso, entre eles o melhoramento
contínuo, e as entregas mais rápidas, bem como equipes auto organizáveis, vêm motivando
o aumento da adoção por parte de instituições dos mais diversos portes nos últimos anos.
Os métodos ágeis possuem importantes princípios norteadores, entres eles o de
manter a simplicidade. Na Tabela 1, recortada de Sommerville (2011), são mostrados os
princípios dos métodos ágeis e suas respectivas descrições que sintetizam a abordagem
ágil.
Dentre os métodos ágeis mais usados tem-se o Extreme Programming (XP) e o
Scrum. Porém, como o Scrum é o método usado na STI, é dada ênfase a ele nesta seção.
De forma resumida, o método Scrum é uma metodologia ágil que fornece um
framework de gerenciamento de projetos. É centralizado em torno de um conjunto de
sprints, que são períodos determinados de tempo, quando um incremento de sistema é
desenvolvido (SOMMERVILLE, 2011). A Figura 6, retirada de Pressman e Maxim (2016),
mostra o "fluxo do processo Scrum", onde são abordados importantes conceitos como
"Backlog do produto", "Backlog da sprint", período de 30 dias de duração da sprint e como
é o acompanhamento diário.
Cabe destacar que é comum cada instituição, inclusive a STI, fazer as adaptações
Capítulo 2. Conceitos Relacionados 28
Tabela 1 – Os princípios dos métodos ágeis (SOMMERVILLE, 2011).
Princípios Descrição
Envolvimento do cliente
Os clientes devem estar intimamente envolvidos no processo de
desenvolvimento. Seu papel é fornecer e priorizar novos requisitos
do sistema e avaliar suas interações.
Entrega incremental O software é desenvolvido em incrementos com o cliente,especificando os requisitos para serem incluídos em cada um.
Pessoas, não processos
As habilidades da equipe de desenvolvimento devem ser
reconhecidas e exploradas. Membros da equipe devem desenvolver
suas próprias maneiras de trabalhar, sem processos prescritivos.
Aceitar as mudanças Deve-se ter em mente que os requisitos do sistema vão mudar.Por isso, projete o sistema de maneira a acomodar essas mudanças.
Manter a simplicidade
Focalize a simplicidade, tanto do software a ser desenvolvido
quanto do processo de desenvolvimento. Sempre que possível,
trabalhe ativamente para eliminar a complexidade do sistema.
necessárias às suas respectivas necessidades, onde, por exemplo, a sprint pode ter duração
diferente de trinta dias, assim como as reuniões diárias podem demorar um tempo maior
ou menor que quinze minutos.
Figura 6 – Fluxo do processo Scrum (PRESSMAN; MAXIM, 2016).
Na STI, considerando especificamente o contexto do SIGAA, a duração da sprint
é de vinte dias úteis, mas pode ser atribuído um prazo diferente a depender do escopo a
ser desenvolvido e o time escalado. De modo que em uma mesma sprint os membros são
os mesmos do início ao fim.
Antes de iniciar a fase de desenvolvimento, todos os membros envolvidos (gerente
Capítulo 2. Conceitos Relacionados 29
de projetos, analistas de requisitos, desenvolvedores e testadores) avaliam as demandas,
discutem e estimam a complexidade do que será desenvolvido. Feito isso, em seguida são
organizadas e distribuídas as atividades e no dia seguinte já começa a contar o primeiro
dia de sprint. Durante os vinte dias, em todos eles tem-se uma rápida reunião onde os
membros, de forma sucinta, dizem o que fizeram desde a reunião anterior, se tem algum
impedimento e em que estão trabalhando.
Todas as atividades da Equipe de Testes estão dentro do Scrum, logo o geren-
ciamento leva em consideração as diversas fases do framework em especial no contexto
de testes de sistemas, mas também considerando as etapas de codificação e correção de
erros. Dessa forma, o gerenciamento (de testes) acompanha a evolução da codificação para
prever possíveis atrasos da chegada das demandas para testes, bem como acompanhamento
de todas as demandas já em testes a fim de realizar tomadas de decisões com base em
planejamento e gestão dinâmica adequada à necessidade do momento.
2.4 Técnicas de Testes de Software
As técnicas de teste são classificadas de acordo com a origem das informações
utilizadas para estabelecer os requisitos de teste (NETO; DIAS, 2007), e como será visto a
seguir, existem as técnicas estrutural e funcional:
2.4.1 Técnica Estrutural
Em linhas gerais, o teste estrutural ou de caixa branca é uma abordagem siste-
mática para testes nos quais o conhecimento do código-fonte do programa é usado para
projetar testes de defeitos. O conjunto de testes deve garantir que todo caminho lógico do
programa seja executado, com a consequência de que cada declaração do programa seja
executada ao menos uma vez (SOMMERVILLE, 2011). Dessa forma, a técnica do teste
estrutural avalia o comportamento da estrutura do software.
Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se
casos de teste que cubram todas as possibilidades do componente de software (NETO;
DIAS, 2007). Dessa forma a realização desses testes exigem acesso ao código fonte da
aplicação, diferentemente dos testes funcionais.
2.4.2 Técnica Funcional
De forma sucinta, o teste funcional, também chamado de teste de caixa-preta ou
comportamental, focaliza os requisitos funcionais do software. De forma que tenta encontrar
erros nas categorias de "funções incorretas ou ausentes", "erros de interface", "erros em
Capítulo 2. Conceitos Relacionados 30
estruturas de dados ou acesso a bases de dados externas", "erros de comportamento ou de
desempenho"e "erros de inicialização e término"(PRESSMAN; MAXIM, 2016).
Dessa forma o testador realiza as operações de testes sem ter acesso ao código
fonte, ou seja, o código fonte está em uma "caixa-preta", e o testador se preocupa com a
entrada e saída de valores no programa e não com o comportamento interno do componente
de software.
Essa técnica tem se mostrado positiva nos testes de sistemas utilizados na Supe-
rintendência, de modo que ela é amplamente aplicada nos sistemas SIG, como é o caso do
SIGAA.
A seção seguinte aborda os conceitos de classe de equivalência. Elas são usadas
para proporcionar uma boa cobertura dos casos de testes.
2.4.3 Classes de Equivalência
O Particionamento de Equivalência, também conhecido como Teste de Classe de
Equivalência, é usado em testes para agrupar em classes valores de entrada que devem
se comportar da mesma maneira.Essas classes são chamadas classes de equivalência e
representam um conjunto de estados válidos e inválidos para uma condição de entrada.
Dessa forma, particionamento de equivalência é um método de teste caixa-preta que divide
o domínio de entrada de um programa em classes de dados a partir das quais podem ser
criados casos de teste (PRESSMAN; MAXIM, 2016).
Uma classe de equivalência representa um conjunto de estados válidos (classe de
equivalência válida) ou inválidos (classe de equivalência inválida) para condições de entrada.
Tipicamente, uma condição de entrada é um valor numérico específico, um intervalo de
valores, um conjunto de valores relacionados ou uma condição booleana(PRESSMAN;
MAXIM, 2016).
Ao utilizar a classe de equivalência pode-se ter uma ampla cobertura de testes com
uma quantidade reduzida de casos de testes, pois pode-se utilizar apenas um caso de teste
de cada classe definida. De forma sucinta, particionamento em classes de equivalência tem
por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste
de cada classe, pois em princípio todos os elementos de uma classe devem se comportar de
maneira equivalente (NETO; DIAS, 2007).
Para exemplificar: em (BARBOSA et al., 2000) é abordado a aplicação de classes
de equivalência para o programa identifier. Em resumo, o programa deve determinar se
um identificador é válido ou não, de modo que: "Um identificador válido deve começar com
uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo um caractere
e no máximo seis caracteres de comprimento".
Capítulo 2. Conceitos Relacionados 31
Para essa situação, como visto na Tabela 2, é possível a identificação das classes
de equivalência válidas e inválidas. Dessa forma, para ser válido um identificador deve
atender às condições (1), (3) e (5); e inválido quando se encaixa em pelo menos uma das
condições (2), (4) ou (6).
Com base nas classes de equivalência, pode-se ter conjuntos de casos de testes (T),
por exemplo: T0 = [(s1,Válido), (3A2, Inválido), (Y-31, Inválido), (B2c3D4h, Inválido)].
Onde o valor de entrada no sistema, "s1", cobre as classes (1), (3) e (5); "3A2"cobre a
classe (4); "Y-31"cobre a classe (6); e "B2c3D4h"cobre a classe (2). Dessa forma é possível
realizar os testes com base nas classes de equivalência.
Tabela 2 – Classes de Equivalência do programa identifier (BARBOSA et al., 2000).
Condição de Entrada Classes Válidas Classes Inválidas
Tamanho t do identificador 1 ≤ t ≤ 6(1)
t >6
(2)
Primeiro caractere é uma letra Sim(3)
Não
(4)
Só contém caracteres válidos Sim(5)
Não
(6)
A seção seguinte aborda a ferramenta UI Vision que é utilizada nos testes auto-
matizados nesta pesquisa.
2.5 Utilização do UI Vision na Automatização de Testes
UI Vision é um software RPA (Robotic Process Automation) gratuito que auto-
matiza aplicativos da web e de desktop no Windows, Mac e Linux. A ferramenta UI.Vision
RPA é uma extensão de navegador, possui código aberto, é gratuita e pode ser estendida
com aplicativos locais para automação de IU de desktop. O núcleo do UI Vision é de código
aberto e garante segurança de nível empresarial. Os dados manipulados nele nunca saem
da máquina do testador que o executa, conforme documentação da ferramenta (UIVISON,
2021).
Ele permite a gravação do teste com a possibilidade de diversas leituras e arma-
zenamentos dos elementos/valores da tela, bem como possibilita a importação de dados
(função Import CSV ) para serem usados na execução dos testes. Em especial para leitura
dos elementos da tela do SIGAA a ferramenta se apresentou bastante satisfatório, uma vez
que dificilmente se perde a referência dos elementos e quase nunca os testes "quebram"por
esse motivo.
Para este trabalho o UI.Vision é usado na versão 6.2.8, instalado no navegador
Google Chrome (Versão 95.0.4638.69, 64 bits) e sistema operacional Windows 10 Pro.
Capítulo 2. Conceitos Relacionados 32
Para o contexto aqui abordado cabe destaque à testabilidade, que conforme
Pressman e Maxim (2016), se refere ao conjunto de esforços necessários para testar um
programa de modo a garantir que ele funcione conforme planejado.
O Capítulo 3 a seguir traz e discute alguns dos trabalhos relacionados a esta
pesquisa.
33
3 Trabalhos Relacionados
Neste capítulo abordamos trabalhos relacionados à definição de critérios e modelos
para priorizar casos de uso a terem os testes automatizados, testes de regressão a serem
priorizados, bem como trabalhos que abordem a utilização de critérios para classificar a
complexidade de formulários em web page. Tendo em vista que isso tem relação com esta
pesquisa desenvolvida na STI que considera, por exemplo, a quantidade de elementos de
preenchimento na tela para classificação da complexidade do caso de uso. Dessa forma,
na seção 3.1 discutimos trabalhos relacionados à definição de critérios para priorização
de testes de regressão. Já na seção 3.2 abordamos trabalhos relacionados à definição de
critérios para priorizar a automação. Na seção 3.3 discutimos trabalhos relacionados a
critérios para estimar complexidade de UC (página do UC). E na seção 3.4 trazemos
considerações acerca dos trabalhos relacionados.
3.1 Critérios para priorização de testes de regressão
Almeida, Jino e Fantinato (2010) fazem um experimento e implementação de uma
técnica de seleção de casos de teste de "caixa preta" baseada em dados históricos coletados
de software para Web. Os autores comparam três técnicas de seleção de testes de regressão
considerando: eficiência na detecção de defeitos; e confiabilidade do software atingida com
sua aplicação. Como resultado do estudo, a técnica priorização de Park, chamada pelos
autores de Retest Using Historical Data (RuHD), mostrou-se mais eficiente na detecção de
defeitos e produziu uma melhora maior na confiabilidade do software, quando comparada
com as técnicas Reteste de Casos de Uso de Maior Risco e Reteste por Perfil Operacional.
A técnica de priorização considera, entre outros fatores, os custos (tempos de
execução, em minutos, de cada caso de testes), severidades de falha relativas totais, tempos
de execução e as criticidades de falha.
Esta técnica considera o histórico dos testes e se baseia nos testes de "caixa preta",
assim como o estudo 2, o que a princípio poderia também ser usada na pesquisa realizada
na STI, porém a técnica usa variáveis que apresentam certo grau de subjetividade no
cálculo do valor histórico, como é o caso de criticidades de falha; além disso, a quantidade
de casos de testes no estudo, 40, representa um valor relativamente baixo e ainda precisa
de uma maior quantidade de análises para validar a técnica RuHD. Sendo assim, optou-se
por não adotar esta estratégia na pesquisa realizada na STI, contudo um valor histórico
do tempo de testes gasto, que pode ser entendido como o tempo que a funcionalidade foi
testada, é considerando no estudo 2.
Capítulo 3. Trabalhos Relacionados 34
Já Malimpensa (2018) explica uma abordagem de priorização de casos de teste
baseada em rastreabilidade. Esta estratégia foi usada para priorizar um conjunto de
casos de teste de regressão a partir de vários requisitos. A abordagem faz uso da Matriz
de Rastreabilidade de Requisitos (RTM-E) proposta por Ditomaso (2014) para obter a
dependência entre os requisitos, porém, diferentemente dele, que classifica essa dependência
calculada em forte, fraca ou inexistente para selecionar os casos de teste associados; esta
abordagem considera o valor da dependência entre os requisitos para priorizar os casos de
teste.
Em linhas gerais, Malimpensa (2018) desenvolveu um plug-in de priorização de
casos de teste e utiliza um conjunto casos de teste no qual: para cada requisito da sprint
ele seleciona um requisito da sprint e em seguida seleciona todos os casos de teste que
pertencem àquele requisito e adiciona esses casos de teste à lista de casos de teste de
regressão com 100% de importância. A partir disto ele gerar a Matriz de Rastreabilidade
de Requisitos (RTM-E). Posteriormente ele selecionatodos os casos de teste pertencentes
aos requisitos que têm alguma dependência com o requisito em questão e os adiciona à
lista de casos de teste de regressão com a importância equivalente à dependência que seus
respectivos requisitos têm com o requisito em questão. Feito isto, ele normaliza os valores
de importância dos casos de teste e prioriza a lista de casos de teste de regressão pelo
valor de importância. Como resultado final tem-se uma lista de casos de teste de regressão
que não são redundantes.
A abordagem de Malimpensa (2018) se assemelha à proposta na pesquisa rea-
lizada na STI, pois visam priorizar de casos de testes a serem automatizados; contudo,
a rastreabilidade de requisitos considerada é uma abordagem muito diferente do atual
contexto de trabalho da Equipe de Testes e demandaria considerável tempo para equipe
se adaptar a essa estratégia, de mosto que optou-se por utilizar-se de técnicas que fossem
mais próximas às atuais atividades já desenvolvidas pela equipe.
Oliveira e Machado (2013) explicam uma nova técnica de reteste seletivo baseada
em modificações que considera o valor de cada caso de teste e a similaridade entre casos
de testes, a fim de selecionar os mais importantes e reduz de 70% a 80% o tamanho do
conjunto de casos de testes, sem afetar a capacidade de detecção de defeitos.
Para essa técnica é construída uma matriz de similaridade entre pares de casos
de teste provenientes de dois conjuntos de casos de teste diferentes. Dessa matriz são
removidos os casos de teste: obsoletos; os que não interagem com nenhuma modificação
realizada no modelo; e os menos importantes, dentre os que interagem com as modificações.
Assim reduz o tamanho do conjunto de casos de testes, o que permite melhor uso dos
recursos disponíveis para a realização do teste de regressão, e mesmo assim consegue ter
uma cobertura satisfatória dos testes.
Capítulo 3. Trabalhos Relacionados 35
Diferentemente do trabalho de pesquisa na STI, que prioriza os casos de testes
a serem automatizados, o trabalho de Oliveira e Machado (2013) aborda uma técnica
de seleção de conjunto de testes já automatizados; assim, essa técnica não pode ser
usada no trabalho de pesquisa, haja vista que ainda não há testes automatizados a serem
selecionados pela Equipe de Testes. Contudo, em um aprofundamento da pesquisa na STI,
será importante a priorização de casos de testes que vierem a ser automatizados, bem
como a remoção de casos de testes automatizados que estiverem redundantes.
3.2 Definindo critérios para priorizar a automação de testes de UC
Viana (2006) propõe um método com o objetivo de contribuir com a seleção de
testes de regressão para automatização. O método proposto baseia-se em critérios que
permitem calcular uma pontuação para os casos de testes analisados; os que possuem
maior pontuação serão considerados os melhores candidatos para automação.
Para o cálculo da pontuação são usadas diferentes métricas como "Tempo médio
de Execução do Teste", "Vida Útil do Teste", "Fator de Exposição ao Risco", "Facilidade
de Automação", entre outras. Todas elas, juntamente com pesos, compõem uma expres-
são matemática com 12 variáveis que permitem obter o valor referente à prioridade da
automatização do teste do caso de uso.
É possível observar que o trabalho de Viana (2006) tem relação com esta dissertação
no sentido de definir uma estratégia da melhor seleção de casos de uso para automatizar. Ela
utiliza uma pontuação para priorizar a automatização de testes de UC, já diferentemente
da abordagem dela, nesta dissertação foi utilizado, por exemplo, critérios de quantidade
de maior tempo gasto em testes manuais no último mês, como será visto com estudo 2.
A estratégia abordada por Viana (2006) não se mostra adequada para o contexto
da STI, haja vista a complexidade de mensurar diversos valores que são subjetivos, como,
por exemplo, a “Facilidade de Automação” (FAT) que se refere a quão fácil é a criação do
teste automatizado, sendo classificada em "Alta" (valor FAT =9 na expressão matemática
do cálculo da complexidade), "Média" (FAT = 3) e "Baixa" (FAT = 1). Porém atribuir
essa classificação é algo subjetivo uma vez que o critério não traz mais detalhes, ficando a
cargo da interpretação individual de cada testador.
O fato da expressão de cálculo da complexidade usada por ela conter muitas
variáveis, diferentes pesos e subjetividades, faz com que a abordagem dela não seja prática
no cenário real com fluxo intenso de atividades, como é o caso da STI, uma vez que
gera considerável trabalho para análise e classificação. Assim, neste trabalho de pesquisa
optou-se por adotar uma forma mais simples para classificar a complexidade de um caso
de uso (e consequentemente do testes automatizado relacionado a ele).
Capítulo 3. Trabalhos Relacionados 36
Cartaxo, Neto e Machado (2007) explica uma estratégia para seleção automática
de casos de testes já automatizados. Essa estratégia partiu da necessidade de diminuir
custos de produção (testes) e manter a qualidade do produto com testes que consigam
fazer coberturas adequadas. A estratégia é baseada no uso de uma função de similaridade,
e sempre que a cobertura total da geração de casos de teste baseada em modelo for
inviável e/ou os casos de teste forem redundantes, uma função de similaridade pode ser
aplicada para descartar automaticamente casos de teste semelhantes, mantendo os mais
representativos e aqueles que ainda geram uma cobertura adequada. Com base no grau de
similaridade entre cada par de casos de teste, os casos de teste a serem eliminados são
aqueles que têm o maior grau de similaridade: um deles é eliminado. Os autores mostram
que essa escolha é feita observando o caso de teste que possui o menor caminho, ou seja, o
menor número de funcionalidades.
Esse trabalho tem relação com o estudo na STI no sentido de ambos tentarem
encontrar melhor estratégia para seleção dos melhores casos de testes a fim de consigam
fazer a melhor cobertura dos testes de maneira eficiente e com a melhor utilização do
tempo de execução de testes. No caso Cartaxo, Neto e Machado (2007) usam uma função
de similaridade; e este trabalho de pesquisa utiliza classes de equivalência no estudo 1, de
forma que os dois tentam minimizar testes desnecessários ou redundantes.
Porém o trabalho de Cartaxo, Neto e Machado (2007) aborda a seleção de testes
já automatizados, diferentemente do estudo na Superintendência que tenta encontrar
uma melhor estratégia para seleção de casos de uso a terem o teste automatizado no
contexto do SIGAA, por isso a estratégia deste artigo não é adequada para o estudo na
STI, todavia, em possíveis aprofundamentos do estudo, a estratégia de seleção dos casos de
uso já automatizados pode trazer significativas contribuições para avanço desta pesquisa.
Walters (2005) explica uma estratégia geral de automação, de modo que para
priorizar os casos de testes de regressão que são candidato a automatização é calculada
uma pontuação (score); os casos de testes que obtiverem maior pontuação indica que são
bons candidatos em potencial para serem automatizados. Para o cálculo da pontuação de
cada caso de teste são considerados os critérios: "Tempo de execução manual", "Execuções
por mês" e “Multiplicador de criticidade". E a pontuação é calculada multiplicando-se os
critérios.
Dessa forma, os casos de testes que possuem maior pontuação são considerados
mais prioritários para automatização. Em outros testes, além dos de regressão, Walters
(2005) recomenda evitar selecionar para automação os casos de difícil automatização e os
que testam novas funcionalidades, inclusive o autor recomenda remoção da casos de testes
que sua Obsolescência seja iminente.
O trabalho de Walters (2005) também usa pontuação para priorização dos casos
Capítulo 3. Trabalhos Relacionados 37
de testes a serem automatizados, porém, diferente de Viana (2006), utiliza a métrica do
“Tempo de execução manual”, que é utilizada também nesta dissertação.
Contudo Walters (2005) também faz uma abordagem subjetiva,pois para o “Mul-
tiplicador de criticidade” (valor que classifica o caso de testes de acordo com a visibilidade
e impacto no caso de ocorrência de falhas na funcionalidade coberta pelo caso de teste)
foram utilizados os valores "1", "3" e "5" onde 1 indica baixa visibilidade/impacto limitado,
3 – visibilidade moderada/impacto médio, e 5 - alta visibilidade/impacto significativo; de
modo que essa classificação não é prática e objetiva para o contexto da STI.
3.3 Critérios para estimar complexidade do UC (página do UC)
Cleary (2000) propôs o método de contagem Web Points, que baseia-se no número
e complexidade de páginas HTML para estimar tamanho e esforço para Web sites. Neste
método, a complexidade de cada página é classificada em três níveis (baixa, média e alta)
de acordo com dois fatores: contagem de palavras e combinação de números de hyperlinks
internos e externos, mais o número de componentes não textuais de cada página. Para
cada nível de complexidade é utilizado um valor de referência que compõe a contagem.
O método proposto por Cleary (2000) que também é explicado de maneira didática
e prática por Drach (2005), é bastante objetivo, uma vez que realizada a contagem simples
dos elementos da página é possível classificar a complexidade, seguindo uma abordagem
semelhante ao desta dissertação no sentido de contar elementos da página (da tela do caso
de uso que contém mais campos a serem preenchidos).
Contudo, o método Web Points não é adequado para o estudo na STI, haja vista
que para mensurar a complexidade ele considera a quantidade de palavras e links na tela,
o que não é relevante para a abordagem na Superintendência uma vez que esses elementos
não influenciam na quantidade de campos a serem preenchidos nos formulários dos casos
de uso e consequentemente nos testes realizados.
Reifer (2002) propõe o método Web Objects. Este método é voltado para aplicações
Web, ele estende a contagem de Pontos de Função tradicional e acrescenta quatro outros
grupos de elementos funcionais que são: links, componentes multimídia, scripts, e blocos
de construção. O autor justifica a adição desses elementos dizendo que o método original
aborda características de aplicações mais tradicionais, como o número de entradas e saídas;
dessa forma, utilizando estes grupos adicionais é possível entender e contabilizar diferentes
elementos de uma aplicação, incluindo os específicos para Web.
Assim, os passos para contagem são: identificação e contagem do número de
elementos funcionais; identificação e contagem do número de operadores; identificação e
contagem do número de operações únicas executadas sobre os operadores identificados.
Capítulo 3. Trabalhos Relacionados 38
Uma vez calculado o número de Web Objects pode ser usado em cálculos de esforço e
duração de projetos Web.
Este método tem relação com o usado no estudo realizado na STI no sentido de
ambos mensurar a complexidade considerando, por exemplo, os elementos da tela, porém
a abordagem explicada por Reifer (2002) é bastante ampla, pois considera elementos,
como links, que não são relevantes na execução definida para automatização de testes na
Superintendência, e mesmo que o método não considerasse a adição dos quatro grupos, a
contagem de Pontos de Função ainda se torna muito ampla para avaliação da complexidade
que se desejou utilizar no estudo no SIGAA.
A seção seguinte discute a respeito dos trabalhos vistos acima.
3.4 Discussões acerca dos trabalhos relacionados
Nenhum dos trabalhos relacionados que foram citados acima apresenta uma
estratégia que pudesse ser completamente adequada à abordagem proposta para o estudo
na STI, porém eles serviram de inspiração para aprofundamento e discussões das estratégias
usadas. Assim, para este trabalho de pesquisa foi necessário estabelecer e utilizar critérios
que fossem adequados à classificação de complexidade da página (baixa, média ou alta),
bem como definição dos próprios critérios para avaliar a priorização de casos de uso a
terem os testes automatizados, como é visto no Capítulo 4 a seguir.
39
4 Estudo de Caso na STI UFRN
Neste capítulo, discutimos o estudo de caso feito na STI-UFRN que buscou definir
critérios para priorizar a automação de testes de casos de uso do SIGAA. Ele descreve os
critérios de escolhas para divisão de grupos para automatização de testes de casos de uso
e os estudos realizados, bem como toda dinâmica utilizada na coleta de dados. Além disso,
traz uma visão geral da utilização de classes de equivalência em testes automatizados na
ferramenta UI.Vison e ilustra como os testes automatizados dos casos de uso Cadastrar
Discente e Cadastrar Componente Curricular (ambos do SIGAA) podem ser realizados
usando classes de equivalência. Ao final de cada seção são apresentadas, respectivamente,
considerações relacionadas à utilização de classes de equivalência, ao estudo 1 e ao estudo
2.
A avaliação foi realizada com dois estudos a fim de encontrar melhores estratégias
para automatizar testes de casos de uso. O objetivo do estudo 1 foi: automatizar os testes
com base na complexidade da tela do caso de uso e no tempo da última alteração no
código relacionado a ele. Já o objetivo do estudo 2 foi: automatizar os testes de casos de
uso que demandaram mais tempo de testes manuais recentemente.
Todos os UC utilizados na avaliação pertencem ao SIGAA e estão apresentados
nas Tabelas 6 e 8, respectivamente para os estudos 1 e 2, como é apresentado nas próximas
seções.
A seção seguinte aborda como acontece a utilização de classes de equivalências na
criação dos testes automatizados com UI.Vison.
4.1 UC do SIGAA para exemplificar classes de equivalência
Os dois casos de uso (UC) aqui abordados neste exemplo são do Módulo Graduação,
relacionados à gestão acadêmica, e foram escolhidos com base na alta frequência de
utilização e retestes por parte da Equipe de Testes. São eles:
Cadastrar Discente: O caso de uso de Cadastrar Discente, ilustrado na Figura 7,
como o próprio nome já diz, é um dos casos de uso responsáveis por cadastrar discentes de
cursos de graduação da Universidade. Finalizado o cadastro, o discente passa a ter vínculo
no Sistema (caso ele já possua um vínculo anterior, passa a ter um novo vínculo).
Esse caso de uso está disponível apenas para usuários que atuam na gestão de
graduação e pode ser acessado em "SIGAA > Módulo Graduação > Alunos > Cadastrar
Discente > Cadastrar Discente".
Capítulo 4. Estudo de Caso na STI UFRN 40
Figura 7 – Cadastrar Discente (SIGAA, 2021).
Cadastrar Componente Curricular: Esse caso de uso não é tão utilizado quanto
outros da área administrativa, porém recentemente muitas alterações foram realizadas
nele, como adição, por exemplo, de Carga Horária de Aula Extensionista entre outras, que
necessitam de vários testes relacionados à criação de componentes curriculares. Esse UC,
ilustrado na Figura 8, é utilizado para cadastrar todos os tipos de componentes (Disciplina,
Atividade, Módulo e Bloco; presencial ou a distância). Ao final da operação de cadastro, é
criado o componente que fica associado a uma unidade responsável e pode ser utilizado no
cadastro/alteração de estrutura curricular e criação de turmas.
Dependendo da Unidade responsável selecionada, se ela já tem componentes
cadastrados, o Sistema sugere um código de componente a ser utilizado. Isso é muito bom,
porém os testes para esse momento, a fim de verificar as classes de equivalência, não irão
usar a sugestão de código.
Esse caso de uso é restrito a usuários que atuam na gestão de graduação e está
disponível em "SIGAA > Módulo Graduação > DDP > Componentes Curriculares >
Capítulo 4. Estudo de Caso na STI UFRN 41
Cadastrar".
Figura 8 – Cadastrar Componente Curricular (SIGAA, 2021).
4.1.1 Classes de equivalência para Cadastrar Discente
Para o caso de uso de Cadastrar Discente, por exemplo, pode-se definir classes de
equivalência para diferentes campos, como é o caso dos campos Nome e Ano de Conclusão
(do ensino médio), como destacados na Figura 7.
Dessa forma, no caso docampo Nome existe a regra negocial que de forma sucinta
diz: O Nome (Oficial/Social) precisa ter no mínimo 3 e no máximo 80 caracteres, podendo
ser números, letras ou caracteres especiais (como @, &, #), porém precisa ter no mínimo um
espaço entre o primeiro e segundo nome (ou seja, deve ser nome composto por pelo menos
duas expressões separadas por espaço). Ex.: não pode ser apenas "Pedro" ou "AbCD1@",
precisa ser no mínimo "Pedro Sobrenome" ou "AbCD!@ AbCD1@". De modo que na Tabela
3 é possível ver as classes de equivalência que podem ser elencadas.
Capítulo 4. Estudo de Caso na STI UFRN 42
Tabela 3 – Classes de Equivalência de Nome (Oficial/Social)
Condição de Entrada (Nome) Classes Válidas Classes Inválidas
Quantidade de caracteres (Qc) 3 ≤ Qc ≤ 80("1")
Qc <3
("2")
Qc >80
("2b")
Tem pelo menos um espaço entre
nomes (expressões)?
Sim
("3’)
Não
("4") -
Permite a entrada de caracteres
especiais?
Sim
("5’)
Não
("6") -
Já para o campo Ano de Conclusão do ensino médio existe a regra negocial que
diz: O campo Ano de Conclusão do ensino médio precisa ter exatamente 4 caracteres
inteiros, de forma que o ano seja maior ou igual a 1900 e menor ou igual a 2022 (sempre o
ano atual que no caso é 2022). De forma que a Tabela 4 reflete classes de equivalência que
podem ser extraídas com base nessa regra.
Tendo as classes de equivalência definidas, é possível elencar representantes dessas
classes que são valores usados durante os testes, de forma que em um arquivo .csv tem
os valores que serão usados para testar as classes de equivalência válidas e em um outro
arquivo .csv classes inválidas. Ao excetuar os testes, a ferramenta Ui.Vision irá percorrer
todos os valores dos arquivos .csv e usá-los para testes automatizados; com isso será
possível testar a funcionalidade com todos os valores elencados no arquivo.
Tabela 4 – Classes de Equivalência de Ano de Conclusão (do ens. médio)
Condição de Entrada (Ano) Classes Válidas Classes Inválidas
Quantidade de caracteres (Qt) Qt = 4("1")
Qt <4
("2")
Qt >4
("2b")
Ano de conclusão (Ac) 1900 ≤ Ac ≤ 2022("3’)
Ac <1900
("4")
Ac >2022
("4b")
Apenas números inteiros Sim("5")
Não
("6") -
4.1.2 Classes de equivalência em Cadastrar Componente Curricular
Para o cadastro de componente curricular, como destacado na Figura 8, um campo
que pode ser bastante explorado é o do Código do componente. Esse código deve seguir um
padrão para criação e como exemplos, alguns códigos válidos são "ECT1105" para Escola
de Ciências e Tecnologia; "DCA0105" para o Departamento de Engenharia de Computação
e Automação, de forma que a regra geral é assim descrita:
• O código do componente deve ser composto por sete caracteres;
• Os três primeiros caracteres devem ser a sigla da unidade responsável (exemplo:
ECT, EAJ, DCA);
Capítulo 4. Estudo de Caso na STI UFRN 43
Tabela 5 – Classes de Equivalência de Código (componente curricular)
Condição de Entrada (Cod. Componente) Classe Válida Classe Inválida
Quantidade de caracteres (Qc) Qc = 7("1")
Qc <7
("2")
Qc >7
("2b")
Os três primeiros caracteres são letras? Sim("3’)
Não
("4") -
Os quatro útimos caracteres são números? Sim("5’)
Não
("6") -
Permite a entrada de qualquer caractere? Não("7’)
Sim
("8") -
O sistema já possui o código que se deseja
cadastrar?
Não
("9’)
Sim
("10") -
• Os quatro últimos caracteres devem ser números inteiros;
• O sistema não deve permitir cadastrar um código já existente;
• Nenhum componente curricular pode ser cadastrado sem atender a todos os itens
anteriores.
De forma que as classes de equivalências elencadas com base na regra geral são
apresentadas na Tabela 5, que apresenta cinco classes válidas e seis classes inválidas.
Tendo as classes de equivalência definidas, deve-se seguir a mesma estratégia
citada na seção anterior para criação do arquivo .csv.
Criados os arquivos .csv para cada caso de uso, um arquivo formado com valores
representantes das classes de equivalência válidas e outro arquivo com os valores represen-
tantes das classes inválidas, procede-se com a inserção deles no UI.Vison que possibilita
construir testes com as variáveis presentes no arquivo .csv, de modo que as variáveis são
lidas em sequência no arquivo, permitindo assim a gravação dos passos realizados nos testes
manuais. Posteriormente os passos gravados são executados para os testes automatizados.
A utilização das classes de equivalência para os testes permitiu explorar a funcio-
nalidade de forma satisfatória e sem criar testes redundantes, o que possibilita um teste
mais assertivo e evita esforços desnecessários para execução deles. Seria possível também
ter optado por utilizar a análise do valor limite para criação dos casos de testes, o que
geraria, por exemplo, uma quantidade maior de caos de testes; dessa forma, optou-se por
utilizar as classe de equivalência, pois atendem adequadamente aos objetivos de criação de
casos de testes da pesquisa.
Além disso, tendo em vista que as classes de equivalência possibilitam testes com
abordagens tanto em alto quanto em baixo nível, neste trabalho as classes não focam em
alto nível. Dessa forma, utiliza, por exemplo, a quantidade de caracteres como condição
Capítulo 4. Estudo de Caso na STI UFRN 44
de entrada na avaliação de classes válidas e inválidas, o que representa um nível baixo.
Essa estratégia foi utilizada porque ela é trabalhada no fluxo de atividades da Equipe de
Testes e por restrições de tempo não foi possível aprofundar para classes de alto nível.
Contudo, para utilização de classes em alto nível, poderia, por exemplo, definir
classes que envolvam o cadastro de discentes que já estivessem na base de dados do SIGAA
(devido a vínculo anterior com a UFRN). Nessa situação, quando o usuário insere o CPF
da pessoa que será cadastrada para determinado curso, o sistema já reconhece o CPF do
estudante e automaticamente preenche o formulário de cadastro com as informações que
estão na base, sendo necessário apenas confirmações do usuário até a finalização do fluxo
de cadastro. Eventualmente o uso das classes de equivalência com foco em testes de nível
mais elevado pode ser abordado em trabalhos futuros a fim de aprofundar as discussões.
A seção seguinte aborda o estudo 1.
4.2 Estudo 1
O estudo 1 é baseado (i) na data da última alteração do caso de uso e (ii) na
complexidade da tela do caso de uso. Em situações onde o caso de uso possui mais de uma
tela, selecionou-se a tela que continha mais campos a serem preenchidos.
A complexidade se refere à quantidade de campos a serem preenchidos na tela do
caso de uso, ou seja, os campos são elementos de preenchimento, especialmente do tipo
form, mas também combobox e checkbox. De forma que a complexidade foi definida em três
níveis (I, II e III), sendo: I - de complexidade baixa os UC que apresentam até 10 campos;
II - de complexidade média os que apresentam de 11 a 25 campos e III - de complexidade
alta, formado por casos de uso que apresentam mais de 25 campos. A explicação detalhada
da classificação de complexidade pode ser vista no Apêndice A.
Este estudo é composto por 24 casos de uso, o que representa aproximadamente
0,5% dos casos de uso do SIGAA, haja vista o sistema possuir um total de 5268 UC (como
visto no Capítulo 2). Os casos de uso desse estudo foram divididos em quatro grupos (G1,
G2, G3, G4), como visto na Tabela 6. De modo que a formação dos grupos considera o
tempo da última alteração relacionada ao caso de uso (com base no GAS) e complexidade
da tala.
Dessa forma, houve a seguinte definição dos grupos:
• G1 é formado por casos de uso nos quais a última alteração foi entre 1 e 6 meses;;
• G2 é formado por casos de uso nos quais a última alteração foi entre 6 e 12 meses;
• G3 é formado por casos de uso que apresentarem última alteração há mais 12 meses;
Capítulo 4. Estudo de Caso na STI UFRN 45
• G4 é formado por casos de uso cuja última alteração foi há menos de 1 mês;
• Para cada um dos grupos G1, G2 e G3, foram selecionados sete casos de uso,
sendo três de maior complexidade,