Universidade Federal de Pernambuco
Centro de Informática
Bacharelado em Sistemas de Informação
Categorias de Frameworks para Automação de Testes
Web em Contextos Ágeis: Um Mapeamento da Literatura
_________________________________________
Trabalho de Graduação
Marcos Vinicius Holanda Borges
Recife
2020
Universidade Federal de Pernambuco
Centro de Informática
Marcos Vinicius Holanda Borges
Categorias de Frameworks para Automação de Testes Web
em Contextos Ágeis: Um Mapeamento da Literatura
Trabalho de Conclusão de Curso apresentado no curso de Bacharelado em Sistemas de Informação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação.
Orientador: Alexandre Marcos Lins de Vasconcelos
Recife
2020
Este trabalho é dedicado aos meus familiares, amigos e professores.
AGRADECIMENTOS
Este trabalho representa o fechamento de um ciclo que começou lá atrás. Foi uma longa e difícil jornada, mas que só foi possível graças às pessoas sensacionais que conheci nesse caminho e também por todo o suporte familiar que sempre se fez presente na minha vida. Por isso, agradeço a Deus por tanto.
Meu muito obrigado ao professor Alexandre Vasconcelos, por toda a ajuda e suporte necessário para realização deste trabalho.
Ao NTI, obrigado pela oportunidade e amizades ali criadas. Ao C.E.S.A.R, minha gratidão e agradecimento. O tema deste trabalho é, sem dúvidas, inspirado nas minhas experiências vivenciadas nesse centro de inovação.
Aos “Sonegators”, em especial, obrigado pela parceria durantes esses anos de graduação.
RESUMO
É possível observar a grande aplicação de metodologias ágeis em projetos de software nos dias atuais. A medida que o valor é entregue mais rapidamente aos clientes, também exige-se mais de algumas atividades, como testes, por exemplo. Para se adequar a isso, o uso de testes automatizados torna-se um aliado no processo, uma vez que são capazes de fornecer feedbacks de maneira mais rápida e constante. Porém, para que se obtenha o maior proveito dos benefícios da automação de testes, faz-se necessária a escolha correta das ferramentas que serão utilizadas no processo, sendo importante levar em conta o ambiente em que se está inserido. Aliado a isso, é válido destacar que maioria dos softwares hoje em dia são feitos para aplicações web, que são executadas em navegadores da internet. Com isso, este trabalho tem como objetivo realizar um mapeamento sistemático da literatura, de modo a ser capaz de mapear os tipos de frameworks utilizados para automação de testes web em contextos ágeis, as suas características, quais os benefícios eles oferecerem e também entender quais os desafios ou limitações eles apresentam.
Palavras-chave: testes de software, frameworks de automação de testes,
ABSTRACT
It is possible to observe the great use of agile methodologies in software projects nowadays. As value is delivered more quickly to customers, some activities are also more required, such as testing, for example. To suit this, the use of automated tests becomes an ally in the process, since they are able to provide feedback in a faster and more constant way. However, in order to get the most out of the benefits of test automation, it is necessary to choose the right tools to be used in the process, taking into account the environment in which it is inserted. In addition to that, it is worth noting that most software today is made for web applications, which run on internet browsers. This work aims to carry out a systematic mapping, in order to be able to map the types of tests automation frameworks used for web applications in agile contexts, such as their characteristics, what benefits they offer and also understand which ones challenges or limitations they present.
Keywords: software testing, test automation frameworks, agile methodologies, web
LISTA DE FIGURAS
Figura 1: Formulário de Extração de Dados 26
Figura 2: Quantidade de estudo por base 29
Figura 3: Estudos totais e excluídos após aplicação dos critérios de seleção de
estudos 30
Figura 4: Quantidade de artigos excluídos por cada critério 30
Figura 5: Quantidade de estudos iniciais e estudos aceitos após seleção por título e
resumo 31
Figura 6: Quantidade de estudos iniciais e aceitos após seleção por introdução e
conclusão 32
Figura 7: Quantidade de estudos inicias e estudos aceitos após seleção por leitura
completa 33
Figura 8: Avaliação de qualidade dos estudos 34
Figura 9: Somatório de todos os critérios de qualidade utilizados 35
Figura 10: Publicações por ano 36
Figura 11: Autoria por países 36
Figura 12: Ferramentas utilizadas nos estudos 37
Figura 13: Tipos de frameworks utilizados para automação de testes web em
LISTA DE QUADRO E TABELAS
Quadro 1: Palavras-chave dos termos de busca e seus sinônimos 20
Quadro 2: String de busca 20
Quadro 3: Critérios de inclusão 22
Quadro 4: Critérios de exclusão 22
Quadro 5: Níveis de qualidade 24
Tabela 1: Benefícios dos tipos de frameworks 36
SUMÁRIO
1. INTRODUÇÃO 10 1.1 OBJETIVOS 11 1.2 QUESTÕES DE PESQUISA 11 1.3 ESTRUTURA DO TRABALHO 11 2. REFERENCIAL TEÓRICO 13 2.1 INTRODUÇÃO 13 2.2 TESTES DE SOFTWARE 13 2.2.1 AUTOMAÇÃO DE TESTES 132.3 FRAMEWORKS DE AUTOMAÇÃO DE TESTES 15
2.3.1 TIPOS DE FRAMEWORKS DE AUTOMAÇÃO DE TESTES 15
2.4 APLICAÇÕES WEB 16
2.5 METODOLOGIAS ÁGEIS 17
2.5.1 EXTREME PROGRAMMING (XP) 18
2.5.2 SCRUM 18
2.6 SÍNTESE DO CAPÍTULO 19
3. PROTOCOLO DO MAPEAMENTO SISTEMÁTICO DA LITERATURA 20
3.1 INTRODUÇÃO 20 3.2 PERGUNTAS DA PESQUISA 20 3.3 ESTRATÉGIA DE BUSCA 20 3.3.1 FONTES DE BUSCA 20 3.3.2 TERMOS DE BUSCA 20 3.3.3 STRING DE BUSCA 21
3.3.4 CRITÉRIOS DE SELEÇÃO DOS ESTUDOS 23
3.3.4.1 CRITÉRIOS DE INCLUSÃO (CI) 23
3.3.4.2 CRITÉRIOS DE EXCLUSÃO (CE) 23
3.3.5 PROCESSO DE SELEÇÃO DOS ESTUDOS 24
3.3.6 AVALIAÇÃO DE QUALIDADE 24
3.3.7 EXTRAÇÃO DOS DADOS 25
3.3.8 SÍNTESE E ANÁLISE DOS DADOS 26
3.4 CONSIDERAÇÕES FINAIS DO CAPÍTULO 27
4. RESULTADOS E SUMARIZAÇÃO DO MAPEAMENTO 28
4.1 INTRODUÇÃO 28
4.2 BUSCA 28
4.2.1 CRITÉRIOS DE SELEÇÃO DOS ESTUDOS 29
4.2.2 SELEÇÃO POR TÍTULO E RESUMO 30
4.2.3 SELEÇÃO POR INTRODUÇÃO E CONCLUSÃO 31
4.2.4 SELEÇÃO PELA LEITURA COMPLETA DOS ARTIGOS 32
4.2.5 AVALIAÇÃO DE QUALIDADE DOS ESTUDOS 33
4.3 VISÃO GERAL DOS ESTUDOS 35
4.3.2 AUTORIAS POR PAÍSES 36
4.3.2 FERRAMENTAS UTILIZADAS NOS ESTUDOS 36
4.4 MAPEAMENTO DAS EVIDÊNCIAS 37
4.5 LIMITAÇÕES DA PESQUISA E AMEAÇA À VALIDADE 47
4.6 SÍNTESE DO CAPÍTULO 47
5 CONCLUSÕES E TRABALHOS FUTUROS 48
5.1 CONCLUSÕES 48
5.2 TRABALHOS FUTUROS 48
REFERÊNCIAS 50
APÊNDICE A - ESTUDOS PRIMÁRIOS SELECIONADOS 52
1. INTRODUÇÃO
Na área de desenvolvimento de software, cada vez mais busca-se entregar valor o mais cedo possível ao cliente. Neste contexto, o uso de metodologias ágeis trouxe consigo algumas características marcantes, tais como: ciclos de desenvolvimento iterativos e incrementais curtos, envolvimento constante do cliente e integração contínua (COHN, 2011). Os testes de software fazem parte do processo de garantir a qualidade do que está sendo entregue. Segundo Myers (2004), os testes de software têm como objetivo garantir que o código da aplicação faça o que ele foi planejado para fazer, buscando encontrar e remover erros de modo a adicionar valor ao sistema. À medida que os sistemas vão crescendo, vão surgindo novas funcionalidades e fica inviável garantir a qualidade apenas com testes manuais, uma vez que eles são naturalmente mais lentos, dado que executam uma ação de acordo com interações feitas por um ser humano, fazendo com que alguns cenários sejam deixados de fora e consequentemente erros possam passar despercebidos (CRISPIN e GREGORY, 2009). Além disso, por se tratarem de uma atividade repetitiva, os testadores podem se entediar de maneira rápida, o que contribui para que erros sejam cometidos e também que bugs sejam ignorados, reforçando que processos manuais são propensos a erros (CRISPIN e
GREGORY, 2009).
No contexto ágil é de suma importância a utilização de testes automáticos, pois eles possibilitam maior escalabilidade (podendo ser executados até mesmo em paralelo), confiabilidade (no sentido de que os testes serão executados sempre da mesma maneira) e maior rapidez, pois fornecem ciclos de feedbacks mais rapidamente (DE FRAGA, 2018). Com uma boa cobertura de testes automatizados torna-se mais fácil identificar mudanças ou efeitos colaterais na aplicação a ser testada (CRISPIN e GREGORY, 2009). Dessa forma, estes testes acabam oferecendo uma redução de custos, pois embora exijam um esforço inicial, à medida que vão sendo executados, esse esforço é compensado (DE FRAGA, 2018). E, como pontuado por Boehm et al. (1981), ao passo que o desenvolvimento de um software vai avançando, maior é o custo relativo para corrigir um defeito encontrado. Aliado a isso, com o uso cada vez mais recorrente de Continuous Integration1(CI) e
Continuous Delivery² (CD), testar continuamente é uma tarefa que só é viável de ser feita com uso de testes automáticos (DE FRAGA, 2018).
Segundo Jablokow (2018), a maioria dos softwares hoje em dia são aplicativos baseados na web, executados a partir de um navegador da Internet,
1Continuous Integration é uma prática de desenvolvimento de software que tem como
objetivo integrar, rotineiramente, códigos no repositório principal, executando criações (builds) e testes automatizados posteriormente.
² Continuous Delivery é uma prática na engenharia de software que visa garantir que o código estará apto para entrar em produção sempre que desejado e de maneira segura.
como Chrome, Internet Explorer ou Firefox. As demandas das empresas modernas faz com que seja fortemente recomendado que cada organização tenha um site ou aplicativo Web, onde a qualidade desempenha um papel importante na maneira como os clientes percebem a empresa e seus produtos. Nesse cenário, testes rigorosos destes sites ou aplicativos se tornam cruciais (ATHMEEYA, 2019).
A automação de testes passou a ser um fator competitivo e diferencial entre as organizações, sendo extremamente importante em contextos ágeis, porém, para que se utilize o máximo dos seus benefícios, é necessário que se escolha as ferramentas corretas. O recomendado por Crispin e Gregory (2009) é que não se utilize ferramentas mais sofisticadas do que você precisa. Outra recomendação apresentada é a de olhar para o problema que está sendo enfrentado e, como um time pode definir a maneira mais simples e eficiente de se resolver o problema (CRISPIN e GREGORY, 2009).
1.1 OBJETIVOS
Visto que existem grandes benefícios na adoção de testes automatizados, principalmente em contextos ágeis, este trabalho tem como objetivo principal realizar um mapeamento sistemático da literatura, de modo a mapear os tipos de frameworks utilizados atualmente para automação de testes web, bem como suas características, os benefícios que eles oferecem e também entender quais os desafios ou limitações que eles apresentam.
1.2 QUESTÕES DE PESQUISA
Visando atingir o objetivo deste estudo, a seguinte pergunta primária de pesquisa (PPP) foi elaborada:
● PPP: Quais são os Tipos de Frameworks Utilizados para Automação de Testes Web em Contextos Ágeis?
De modo a orientar a condução do estudo, incluindo a extração, análise e síntese dos dados, as seguintes perguntas de pesquisa secundárias (PPS) foram definidas:
● PPS1: Quais os benefícios que esses tipos de frameworks agregam? ● PPS2: Quais os principais desafios ou limitações encontrados no uso
desses tipos de frameworks?
1.3 ESTRUTURA DO TRABALHO
Além deste capítulo introdutório que apresenta a contextualização e os objetivos deste trabalho, este trabalho está organizado nos seguintes capítulos:
● Capítulo 2: este é o capítulo de referencial teórico que apresenta os principais conceitos relacionados ao tema deste trabalho.
● Capítulo 3: este é o capítulo de protocolo do mapeamento sistemático, que apresenta os procedimentos utilizados para realização deste trabalho.
● Capítulo 4: apresenta os resultados advindos da aplicação do mapeamento sistemático.
● Capítulo 5: apresenta as considerações finais e também recomendações para trabalhos futuros.
2. REFERENCIAL TEÓRICO
2.1 INTRODUÇÃO
Neste capítulo serão apresentados os principais conceitos que dão fundamento a este trabalho. Nas próximas seções serão detalhados os seguintes temas: testes de software, framework de automação de testes, aplicações web e metodologias ágeis.
2.2 TESTES DE SOFTWARE
Segundo Myers (2004), teste de software é um processo (ou uma série de processos) que tem como objetivo garantir que o código desenvolvido realize o que ele foi planejado para fazer, bem como não faça nada que não seja intencional. Além disso, ainda segundo Meyers, é esperado que o software seja consistente e previsível, de modo que não apresente surpresas para os usuários.
Quando se testa um código/programa, busca-se encontrar e remover erros com o objetivo de adicionar valor ao programa por meio do ganho de qualidade e confiabilidade (MYERS, 2004). Para Sommerville (2003), o processo de testes tem dois objetivos diferentes: mostrar para pessoas envolvidas no processo, tais como desenvolvedores e clientes, que o software atende aos requisitos e encontrar fluxos em que o software não apresenta o resultado esperado. Para atingir o primeiro objetivo se faz necessário o uso de testes de validação, em que é esperado que o sistema aja de maneira correta com a utilização de um grupo de casos de testes que refletem o uso esperado do sistema. Já o segundo objetivo remete a testes de defeitos, que são projetados para expor defeitos. Nada impede porém, que sejam encontrados defeitos com testes de validação e que testes de defeitos mostrem que o programa atende aos requisitos estabelecidos (SOMMERVILLE, 2003). Segundo Dijkstra et al. (1972), os testes não garantem que um programa está livre de erros, porém podem mostrar a presença de erros em um programa.
Para Sommerville (2003), testes fazem parte de um grande processo de verificação e validação. Juntos, os dois processos buscam conferir se o software fornece as funcionalidades esperadas e também se satisfaz as especificações. De maneira simples, Boehm (1979), diferenciou os processos de validação e verificação com duas indagações: “Validação: estamos construindo o produto certo?” e “Verificação: estamos construindo o produto da maneira certa?”. Esses processos têm início assim que os requisitos estão disponíveis e são uma atividade realizada durante todas as etapas de desenvolvimento. Combinados, os dois processos buscam certificar que o software entrega o que ele se propôs a fazer (SOMMERVILLE, 2003).
2.2.1 AUTOMAÇÃO DE TESTES
Os testes podem ser manuais ou automatizados. Nos testes manuais, um humano é quem fica responsável por executar o sistema utilizando alguns dados de teste, de modo que seja possível comparar os resultados obtidos com suas expectativas. Caso exista alguma desconformidade, essa diferença pode ser reportada ao responsável (normalmente os desenvolvedores). Por outro lado, os
testes automáticos são feitos por meio da codificação em um programa, sendo executados sempre que o sistema é testado (SOMMERVILLE, 2003). Embora os testes automatizados nunca irão substituir completamente os testes manuais, pois são limitados a verificar apenas aquilo a que são propostos, o seu uso tem aumentado consideravelmente (SOMMERVILLE, 2003).
Galin (2004) descreve algumas das vantagens de se utilizar testes automatizados:
● Precisão e integridade de desempenho: testes automatizados garantem,
no maior grau possível, que todos os casos de testes são executados de forma completa e precisa. Já nos testes manuais, o testador pode passar por períodos de cansaço ou de baixa concentração, o que podem acabar resultando em erros (GALIN, 2004).
● Precisão do registro de resultados e relatórios: os testes automatizados
são programados para fornecer, com precisão, relatórios de erros encontrados. Por outro lado, na execução manual, erros podem acabar sendo não reconhecidos ou até mesmo não registradas nos relatórios desenvolvidos (GALIN, 2004).
● Abrangência da informação: os dados dos testes automatizados (incluindo os seus resultados) estão mais disponíveis do que os mesmos itens estariam após a realização de testes manuais, pois quando se utiliza testes automatizados, os dados e os resultados são armazenados em banco de dados, relatórios ou outros locais, enquanto nos testes manuais essas informações não são tão fáceis de serem encontradas. Ter esses dados disponíveis pode ser bastante útil para correção e prevenção de erros (GALIN, 2004).
● Poucos recursos humanos necessários para realizar os testes: Uma vez que o processo de testes automatizados já esteja em uso, exige-se menos mão de obra para execução dos testes do que na execução manual (GALIN, 2004).
● Duração mais curta dos testes: além de geralmente os testes automatizados serem mais rápidos de se executar do que os testes manuais, eles ainda podem ser utilizados 24 horas por dia e 7 dias por semana, o que iria exigir equipes de testadores manuais trabalhando durante os três turnos ou até mesmo sendo necessário mais de uma equipe para se comparar com a disponibilidade de uso dos testes automatizados, sendo pouco prático de se aplicar na maioria dos casos (GALIN, 2004).
● Execução dos testes de regressão completos: está ligada diretamente com a vantagem citada acima. Devido à falta de tempo e recursos de mão de obra, a execução manual dos testes de regressão tende a ser aplicada apenas em uma pequena parte do pacote do software. Isso não acontece, porém, com o uso de testes automatizados, o que acaba reduzindo o risco de não detectar algum erro que possa vir a ser introduzido à medida que novas correções sejam feitas no software (GALIN, 2004).
Fewster e Graham (1999) advertem que para se ter os benefícios da automação, os testes que serão automatizados devem ser cuidadosamente escolhidos e implementados.
2.3 FRAMEWORKS DE AUTOMAÇÃO DE TESTES
Um framework de automação de testes é uma plataforma que contém dados de teste, casos de testes, scripts de testes, ferramenta de automação de testes, bem como é capaz de fornecer relatórios e estratégias adequadas para execução de testes, além de manter uma padronização das atividades realizadas nos scripts de teste (TYAGI, 2018)(ISLAM e QUADRI, 2020). É uma plataforma que provê, em um único ambiente de trabalho, integração de recursos de hardware, software, ferramentas e serviços (RANJITHA, 2016). Além disso, os frameworks simplificam o esforço de automação e promovem consistência (BAJAJ, 2018).
2.3.1 TIPOS DE FRAMEWORKS DE AUTOMAÇÃO DE TESTES
Existem vários tipos de frameworks de automação de testes e cada um deles possui características únicas, que podem ser melhor aproveitadas a depender das necessidades e dos contextos dos projetos. Sendo assim, é importante escolher o tipo de framework correto para que se possa ter os maiores ganhos possíveis (UMAR e ZHANFANG, 2019). Para Islam e Quadri (2019), os tipos mais comuns são: Linear Automation Framework, Modular Based Framework, Data-Driven Framework, Keyword-Driven Framework, Behavior Driven Development Testing Framework e Hybrid Testing Framework.
● Linear Automation Framework: Este tipo de framework, também conhecido como “record-and-playback” framework, é um dos mais antigos e mais simples utilizados para testar aplicações web. O testador registra cada ação feita no navegador, como por exemplo entrada do usuário, navegações, verificações, e logo em seguida reproduz o script, de modo que ele execute em ordem sequencial, sem exigir que o testador escreva códigos para criar funções (UMAR e ZHANFANG, 2019). Esse frameworknão é adequado para execução de testes com vários conjuntos de dados devido à sua incapacidade de reutilização, que torna o seu uso mais indicado em aplicações pequenas (ISLAM e QUADRI, 2020). Selenium IDE é um exemplo de ferramenta baseada neste tipo de framework.
● Modular Based Framework: A aplicação sob teste é dividida em funções, módulos ou seções separadas, e cada uma dessas partes é testada de maneira isolada neste tipo de framework. São criados scripts de testes para cada parte e depois combinados para que seja possível construir testes maiores, representando os casos de teste (UMAR e ZHANFANG, 2019). A divisão dos scripts de maneira modular proporciona uma fácil manutenção, uma vez que mudanças na aplicação afetam apenas um componente específico, e também melhora a escalabilidade das suítes de testes automáticos, pois para criação de novos testes, basta combinar os módulos já existentes. Devido ao uso dos dados de testes embutidos nos scripts,
modificações nos dados de testes precisam ser feitas no código dos scripts, o que pode ser um problema a depender do tamanho (RAHATE, 2016).
● Data-Driven Framework: A abordagem utilizada neste tipo de framework é a separação dos dados de testes do script lógico, de modo que dados são armazenados em arquivos de textos, planilhas, arquivos CSV, tabelas SQL entre outros (UMAR e ZHANFANG, 2019). Diferentemente dos dois tipos de frameworks apresentados anteriormente (linear e modular), como os dados
de testes são separados do script, vários conjuntos de dados podem ser utilizados com um mesmo script de teste, sem necessitar alteração (UMAR e ZHANFANG, 2019). Sendo assim, nesse tipo de framework uma quantidade menor de scripts são necessários para cobrir todos os casos de testes. Além disso, a criação dos dados de testes pode ser feita antes da implementação do teste ou até mesmo da aplicação estar pronta para ser testada (RAHATE, 2016). Por outro lado, esse tipo de framework demanda pessoas com boa habilidade de programação para desenvolver os scripts de teste (ISLAM e QUADRI, 2020). TestingWhiz é um exemplo de ferramenta baseada neste tipo de framework.
● Keyword-Driven Framework: Seguindo uma abordagem parecida com o Data-Driven Framework, de modo que os dados de testes são separados dos
scripts de testes, esse tipo de framework dá um passo além: keywords, que
são palavras-chave auto explicativas quanto à ação que deve ser executada na aplicação (RAHATE, 2016), também são armazenadas em um arquivo externo, o que faz esse modelo ser capaz de executar testes independente da ferramenta usada (UMAR e ZHANFANG, 2019). Neste tipo de framework, não é necessária habilidades de automação para manutenção ou criação de novos casos de testes, porém é exigida, ainda mais do que no Data-Driven Framework, habilidade de programação para construção do framework. Além disso, as keywords podem ser reutilizadas por vários casos de testes (RAHATE, 2016). Robot Framework é um exemplo de ferramenta baseada neste tipo de framework.
● Behavior Driven Development Testing Framework (BDD): O objetivo desse tipo de framework é permitir que os testes funcionais automatizados sejam facilmente compreendidos por todas as partes interessadas (stakeholders). Nesta abordagem, os casos de testes são escritos em uma linguagem natural, descrevendo o comportamento de um usuário ao utilizar uma aplicação a ser testada (TYAGI e SIBAL, 2017), que pode ser entendida de maneira clara por pessoas técnicas e não técnicas, permitindo esse trabalho em conjunto e com entendimento comum (ISLAM e QUADRI, 2020)(KAPOOR e SAGAR, 2018). Além disso, o BDD também funciona como uma documentação viva dos comportamentos esperados da aplicação sob teste (CAVALCANTE e SALES, 2019). Cucumber é um exemplo de ferramenta baseada neste tipo de framework.
● Hybrid Testing Framework: Como o nome sugere, este tipo framework é a combinação de dois ou mais frameworks, com o objetivo de aproveitar as vantagens e evitar as fraquezas que os frameworks apresentam de maneira isolada (UMAR e ZHANFANG, 2019)(ISLAM e QUADRI, 2020).
2.4 APLICAÇÕES WEB
Segundo Shklar (2003), aplicações web são aplicações cliente/servidor que normalmente utilizam um navegador da web como cliente e executam um serviço interativo ao conectar-se com servidores pela internet. Enquanto sites web entregam conteúdo de arquivos de maneira estática, aplicações web apresentam conteúdos adaptados dinamicamente com base nos parâmetros de solicitação, no comportamento de usuários rastreados e fatores de segurança (SHKLAR, 2003).
2.5 METODOLOGIAS ÁGEIS
Entre as décadas de 80 e 90, devido aos softwares desenvolvidos serem basicamente sistemas grandes e duradouros, como sistemas aeroespaciais, por exemplo, tinha-se uma ideia de que para se obter o melhor software possível era necessário ter um planejamento cuidadoso e um processo de desenvolvimento de software rigoroso e controlado (SOMMERVILLE, 2003). Porém, para Sommerville (2003), quando se trata de sistemas de pequeno ou médio porte, a abordagem de desenvolvimento dirigido a planos gera uma sobrecarga tão grande que acaba por dominar o processo de desenvolvimento da aplicação. O gasto de tempo é maior em atividades de análise (sobre como o sistema deve ser feito) do que propriamente no seu desenvolvimento.
Em 2001, cerca de 17 desenvolvedores reuniram-se e propuseram um manifesto ágil contendo 4 valores e 12 princípios com o objetivo de ajudar outros profissionais da área a pensar sobre desenvolvimento de software, metodologias e organizações, de maneiras novas e mais ágeis. Neste manifesto eles descreveram que “estamos descobrindo melhores maneiras de se desenvolver software” seguindo os seguintes valores:
● Indivíduos e interações acima de processos e ferramentas.
● Software em funcionamento acima de documentação abrangente.
● Colaboração do cliente acima de negociação de contrato. ● Respostas a mudança acima de seguir um plano.
O manifesto ágil não nega que os itens à direita são importantes, porém os itens à esquerda são mais valorizados. Os 12 princípios utilizados, obtidos pelo documento do manifesto ágil, são listados a seguir:
● A prioridade é satisfazer o cliente por meio de entrega antecipada e contínua de software com valor.
● Mudanças são bem vindas mesmo que no final do desenvolvimento, pois os processos ágeis aproveitam mudanças para dar vantagem competitiva ao cliente.
● Entregar um software funcional com certa frequência, em algumas semanas ou menos, idealmente numa escala mais curta.
● Desenvolvedores e pessoas de negócio devem trabalhar juntas diariamente no decorrer do projeto.
● Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte que precisam e confie neles para fazer o trabalho.
● O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
● O software funcional é a principal medida de progresso.
● Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
● Atenção contínua à excelência técnica e um bom design aumenta a agilidade. ● Manter a simplicidade é essencial: a arte de maximizar a quantidade de
trabalho não feito.
● As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.
● Em intervalos regulares, a equipe reflete sobre como pode se tornar mais eficaz, e então sintoniza e ajusta seu comportamento para tal.
Existem vários métodos ágeis que utilizam esses valores e princípios. A seguir serão detalhados os dois métodos mais utilizados, segundo Sommerville (2003): Extreme Programming (XP) e Scrum.
2.5.1 EXTREME PROGRAMMING (XP)
O método ágil XP tem como objetivo fornecer o software que o cliente precisa, quando ele precisa. Além disso, Extreme Programming enfatiza a satisfação do cliente como um de seus principais motivadores (WATKINS, 2009). O XP procura melhorar os projetos em quatro diferentes áreas, são elas: comunicação, simplicidade, feedback e coragem. A comunicação refere-se ao incentivo aos desenvolvedores e testadores do software para que mantenham uma comunicação efetiva e frequente, tanto com os membros do time quanto com os clientes. Quanto à simplicidade, o XP prega um design simples, claro e compreensível. Embora os clientes não vejam diretamente o código fonte, a ideia é que os desenvolvedores possam se orgulhar das soluções eficazes e elegantes por eles desenvolvidas. Com entregas sendo feitas sempre que possível, os desenvolvedores recebem feedback de outros programadores e também do cliente. Quanto à coragem, os programadores são encorajados a responder positivamente e proativamente às mudanças requisitadas pelos clientes, bem como mudanças advindas do próprio ambiente de trabalho, como de tecnologias, por exemplo (WATKINS, 2009).
Para Watkins (2009), ao utilizar esses 4 príncipios, os desenvolvimentos dos projetos se tornam mais ágeis e responsivos. O princípio da comunicação permite que o sistema de desenvolvimento seja integrado de maneira mais fácil e com menos erros, o que aliado ao princípio do feedback, garante que o software entregue está mais próximo do que o cliente precisa (WATKINS, 2009).
Extreme Programming enfatiza também a importância de testes efetivos e eficientes. O desenvolvimento dos testes deve começar antes mesmo do código ser escrito. À medida que defeitos são encontrados, novos testes podem ser desenvolvidos e adicionados a suíte de testes, de modo a evitar que o mesmo bug apareça novamente enquanto o software vai sendo desenvolvido (WATKINS, 2009).
2.5.2 SCRUM
Para Watkins (2009), Scrum é um método de gerenciamento de projetos ágeis que habilita a criação de times auto-organizados, além de encorajar uma comunicação verbal efetiva entre os membros da equipe e os clientes. O princípio chave do Scrum é reconhecer que no decorrer de um projeto os clientes são propensos a mudar de ideia, sobre o que eles querem e precisam, de maneira frequente. De modo a atender essas mudanças, o Scrum parte do pressuposto que o problema apresentado pelo cliente não está totalmente definido (ou compreendido) e, por conta disso, foca em maximizar a capacidade da equipe de entregar e responder às mudanças de maneira rápida (WATKINS, 2009).
Segundo Sommerville (2003), o Scrum possui três fases distintas: o planejamento geral, onde se define a arquitetura e os objetivos gerais do projeto; a segunda fase diz respeito a um conjunto de ciclos chamados de sprint (unidade de planejamento, normalmente de duas a quatro semanas), de modo que em cada ciclo uma pequena parte do sistema (incremento) é adicionada; a última fase se dá com o fim do projeto, que consiste na avaliação das lições aprendidas do projeto e na produção da documentação necessária (SOMMERVILLE, 2003).
No Scrum existem reuniões diárias em que todos da equipe devem participar. Normalmente tratam-se de reuniões rápidas que os participantes fazem de pé. O objetivo das reuniões é permitir que cada participante tenha a oportunidade de compartilhar informações, como o seus progresso ou impedimentos nas atividades, além do que está planejado para ser realizado no dia seguinte. Assim, todos da equipe ganham uma visão geral do que cada integrante do time está fazendo, além de permitir que sejam geradas ações ou replanejamento do trabalho (SOMMERVILLE, 2003).
2.6 SÍNTESE DO CAPÍTULO
Neste capítulo foram apresentados os conceitos e fundamentos teóricos referentes a testes de software, framework de automação de testes, aplicações web e metodologias ágeis. Ao longo do capítulo também foram abordados os temas de automação testes, tipos de frameworks de automação de testes, além das metodologias ágeis Extreme Programming e Scrum. No próximo capítulo é descrito o protocolo do mapeamento sistemático utilizado neste trabalho.
3.
PROTOCOLO
DO
MAPEAMENTO
SISTEMÁTICO
DA
LITERATURA
3.1 INTRODUÇÃO
Este capítulo descreve o protocolo do mapeamento sistemático da literatura, feito com o objetivo de levantar os principais e mais relevantes estudos relacionados a ferramentas utilizadas para automação de testes web em contextos ágeis. O protocolo seguiu o modelo recomendado por Kitchenham e Charters (2007) e também Cruzes e Dyba (2011).
3.2 PERGUNTAS DA PESQUISA
Para Kitchenham e Charters (2007), especificar as questões de pesquisa é a parte mais importante de qualquer revisão sistemática, pois são elas que conduzem toda a metodologia.
Dessa maneira, esse trabalho tem como objetivo responder a seguinte Pergunta Primária de Pesquisa (PPP): Quais são os Tipos de Frameworks
Utilizados para Automação de Testes Web em Contextos Ágeis?
Para orientar a condução do estudo, assim como a extração, análise e síntese dos resultados, as seguintes perguntas de pesquisa secundárias (PPS) foram definidas:
● PPS1: Quais os benefícios que esses tipos de frameworks agregam? ● PPS2: Quais os principais desafios ou limitações encontrados no uso
desses tipos de frameworks?
3.3 ESTRATÉGIA DE BUSCA
De acordo com Kitchenham e Charters (2007), deve-se encontrar o maior número possível de estudos primários relacionados à questão de pesquisa, usando uma estratégia de pesquisa imparcial. Sendo assim, a estratégia utilizada é destrinchada nas seções seguintes.
3.3.1 FONTES DE BUSCA
Como apontado por Brereton et al. (2007), as bases Scopus, Science
Direct, ACM, Google Scholar e IEEExplore estão entre as melhores quando se trata de assuntos para Engenheiros de Software. Por isso, essas foram as escolhidas para esse trabalho.
3.3.2 TERMOS DE BUSCA
Partindo da Pergunta Primária de Pesquisa (PPP), foram extraídos os termos de busca (palavras-chave), que foram traduzidos para o Inglês, uma vez que
trata-se do idioma mais utilizado para publicação de estudos primários, além também de ser o idioma predominante nas fontes de busca utilizadas. O quadro 1, exibido a seguir, apresenta as palavras-chave dos termos de busca e seus sinônimos (termos relacionados).
Quadro 1. Palavras-chave dos termos de busca e seus sinônimos Fonte: Próprio autor
3.3.3 STRING DE BUSCA
Para se obter o maior número possível de resultados, a string de busca formada utiliza os operadores lógicos OR (ou) e AND (e), onde as palavras-chave são concatenadas através do AND, uma vez que são os pilares da busca, enquanto os sinônimos são agrupados com o OR. Sendo assim, a string de busca formulada foi a seguinte:
Quadro 2. String de busca Fonte: Próprio autor
Cada base utilizada na pesquisa possui sua própria sintaxe de busca, sendo assim, foram feitos alguns ajustes na string para ser utilizada em cada base, com o objetivo de se obter o máximo de resultados pertinentes ao trabalho, excluindo estudos não relacionados.
A string utilizada na SCOPUS foi a seguinte:
TITLE-ABS-KEY (("agile" OR "XP" OR "SCRUM" OR "Extreme Programming") AND
("Web" OR "Website" OR "browser") AND ("test automation" OR "testing
Palavras-chave Sinônimos
agile xp, scrum, extreme programming test automation testing automation, automated test
web website, browser
framework techniques, tools, environment
String de busca
("agile" OR "XP" OR "SCRUM" OR "Extreme Programming") AND ("Web" OR "Website" OR "browser") AND ("test automation" OR "testing automation" OR "automated test") AND ("framework" OR "techniques" OR "tools" OR "environment")
automation" OR "automated test") AND ("framework" OR "tools" OR "techniques" OR "environment"))
O Science Direct só permite no máximo 8 (oito) operadores booleanos, o que inviabilizou o uso da string de busca completa. Sendo assim, foram testadas várias combinações e os resultados obtidos apresentaram pouquíssima diferença entre si, isto é, os resultados estavam englobados um no outro, não valendo a pena quebrar a string original em mais de uma string de busca. Dessa maneira, com objetivo de obter o maior número possível de resultados pertinentes, a string escolhida foi:
("agile") AND ("Web" OR "website") AND ("test automation" OR "testing automation" OR "automated test") AND ("framework" OR "tools" OR "techniques")
Já na ACM Digital Library, a string de busca utilizada foi:
[[All: "agile"] OR [All: "xp"] OR [All: "scrum"] OR [All: "extreme programming"]] AND [[All: "web"] OR [All: "website"] OR [All: "browser"]] AND [[All: "test automation"] OR [All: "testing automation"] OR [All: "automated test"]] AND [[All: "framework"] OR [All: "tools"] OR [All: "techniques"] OR [All: "environment"]]
No Google Scholar, como se trata de um engenho de busca que indexa várias bases, a string de busca original estava retornando uma enorme quantidade de trabalhos e com muitos falsos positivos. O termo “agile” estava retornando um grande número de trabalhos fora do contexto de desenvolvimento de software. Por conta disso, esse termo foi substituído por ("agile method" OR "agile methodology" OR "agile methodologies"), uma vez que são termos mais utilizados nesse contexto. Além disso, este engenho apresenta um limite de 256 caracteres na busca. Levando isso em consideração, a string de busca utilizada foi:
("agile method" OR "agile methodology" OR "agile methodologies" OR "XP" OR "SCRUM") AND ("Web" OR "Website" OR "browser") AND ("test automation" OR "testing automation" OR "automated test") AND ("tools" OR "techniques" OR "framework") -books -thesis
Para excluir resultados de livros e teses de mestrado ou doutorado, os termos “books” e “thesis” foram negados na string. A pesquisa também restringiu o período de busca dos trabalhos para ocorrer entre 2015 e 2020, uma vez que se trata de um dos critérios de exclusão a serem detalhados na seção 3.3.4.2.
Por fim, a string utilizada na IEEE Xplore foi a seguinte:
(("All Metadata":"agile" OR "All Metadata":"XP" OR "All Metadata":"SCRUM" OR "All Metadata":"Extreme Programming") AND ("All Metadata":"Web" OR "All
Metadata":"Website" OR "All Metadata":"browser") AND ("All Metadata":"test automation" OR "All Metadata":"testing automation" OR "All Metadata":"automated test") AND ("All Metadata":"framework" OR "All Metadata":"tools" OR "All Metadata":"techniques" OR "All Metadata":"environment"))
3.3.4 CRITÉRIOS DE SELEÇÃO DOS ESTUDOS
Como apontado por Kitchenham e Charters (2007), os critérios de seleção para inclusão ou exclusão de estudos têm como função identificar os estudos primários que fornecem evidências diretas sobre as questões de pesquisa. Além disso, para reduzir as chances de enviesar a pesquisa, critérios de seleção devem ser decididos durante a definição do protocolo, ainda que possam ser refinados durante o processo de pesquisa.
3.3.4.1 CRITÉRIOS DE INCLUSÃO (CI)
Quadro 3. Critérios de inclusão Fonte: Próprio autor 3.3.4.2 CRITÉRIOS DE EXCLUSÃO (CE)
Quadro 4. Critérios de exclusão Fonte: Próprio autor
*Esse período foi escolhido com o objetivo de obter os trabalhos mais recentes
sobre o assunto.
CI1 Documentos que discorrem sobre ferramentas de automação de testes web CI2 Documentos que discorrem sobre automação de testes em contextos ágeis CI3 Documentos que comparem ferramentas de automação de testes web
CI4 Documentos que relatam os benefícios da utilização de automação de testes web
CI5 Documentos que relatam os desafios da utilização de automação de testes web
CE1 Documentos duplicados (já aceitos) CE2 Documentos que não estejam em Inglês
CE3 Documentos que não estejam disponíveis gratuitamente para download nos ambientes institucionais do CIn/UFPE.
CE4 Documentos que não estejam no período de 2015 a 2020*
3.3.5 PROCESSO DE SELEÇÃO DOS ESTUDOS
O processo de seleção dos estudos foi dividido em quatro fases. Na primeira, os resultados obtidos através do uso da string de busca nas bases citadas anteriormente foram armazenados em planilhas do Google Spreadsheet, onde se armazenou informações importantes de cada resultado, como por exemplo título, link de acesso e ano. Nessa fase, os critérios de exclusão foram aplicados.
A segunda fase teve como objetivo analisar os títulos e resumos de cada resultado remanescente da fase anterior, além de aplicar os critérios de inclusão e exclusão. Em caso de dúvida quanto a validade do artigo para pesquisa, o resultado foi mantido para posterior validação nas próximas fases.
O filtro aplicado na terceira fase foi feito por meio da leitura da introdução e conclusão dos artigos que permaneceram após a segunda fase, além de aplicar os critérios de inclusão e exclusão. Em caso de dúvida quanto à validade do artigo para pesquisa, o resultado foi mantido para validação na próxima fase.
A quarta e última fase serviu para ler os artigos resultantes por completo e avaliar a qualidade de cada um deles seguindo os critérios de avaliação de qualidade citados na próxima seção (3.3.6), de modo a eliminar os considerados com qualidade “baixa”. Além disso, também serviu para atribuir um identificador único para cada artigo e realizar o processo de extração (3.3.7) e síntese dos dados (3.3.8).
3.3.6 AVALIAÇÃO DE QUALIDADE
Segundo Kitchenham e Charters (2007), além dos critérios gerais de inclusão e exclusão, é importante avaliar a "qualidade" (entre aspas, pois não há uma definição acordada de “qualidade”) dos estudos primários. O objetivo desta avaliação é associar uma pontuação a cada artigo, com base em critérios de qualidade previamente estabelecidos, de modo a selecionar os artigos que satisfaçam determinados níveis de pontuação considerados satisfatórios. Sendo assim, foram utilizados os seguintes critérios de qualidade baseados no que foi proposto por Kitchenham e Charters (2007):
● C1: Os objetivos estão claramente estabelecidos?
● C2: O estudo mostra seus resultados de forma clara e não ambígua? ● C3: Os processos, técnicas e tecnologia, são claramente definidos? ● C4: Os métodos de coleta de dados são descritos de maneira clara? ● C5: Os objetivos do trabalho são alcançados?
● C6: Os participantes ou unidades de observação estão adequadamente descritos?
● C7: O estudo utiliza processos, técnicas ou tecnologias atuais? ● C8: O estudo possui valor para a academia ou para a indústria?
● C9: A estratégia de pesquisa se mostra adequada aos objetivos da pesquisa?
● C10: Todas as questões de pesquisa são respondidas?
Para a avaliação, foi utilizada uma escala de 3 (três) valores proposta por Likert (1932), onde são atribuídas respostas gradativas para avaliar o quanto o estudo está de acordo com cada um dos critérios de qualidade descritos acima. Os três valores são:
● Não atende (0): atribuído caso não exista nada no trabalho que atenda ao critério avaliado.
● Dúbio (0.5): atribuído na falta de clareza do critério avaliado. ● Atende (1): atribuído se o critério avaliado for atendido.
Os artigos podem ser classificados em 4 (quatro) faixas de qualidade de acordo com o somatório (N) dos critérios de qualidade avaliados:
Quadro 5. Níveis de qualidade Fonte: Próprio autor
3.3.7 EXTRAÇÃO DOS DADOS
Como recomendado por Kitchenham e Charters (2007), essa etapa tem como objetivo registrar com precisão informações relacionadas às questões de pesquisas, obtidas através dos estudos primários. Para reduzir a chance de enviesar a pesquisa, formulários de extração de dados devem ser definidos e testados quando o protocolo do estudo é definido. Dessa maneira, foi desenvolvido o formulário abaixo (Figura 1), baseado no que foi proposto por Kitchenham e Charters (2007).
Baixa 0 ≤ N ≤ 3
Média 3 < N ≤ 7
Alta 7 < N ≤ 8,5
Figura 1: Formulário de Extração de Dados Fonte: Próprio autor
3.3.8 SÍNTESE E ANÁLISE DOS DADOS
Seguindo o recomendado por Cruzes e Dyba (2011), o processo de síntese e análise dos dados é feito partindo da leitura inicial dos artigos escolhidos, de modo a obter informações como título, autores, ano de publicação, país de origem, dados que descrevem o contexto (assunto, configurações, tecnologias), além das descobertas (resultados, comportamentos, ações). Após isso é feita a etapa de codificação dos dados, ou seja, o processo de examinar e organizar os dados contidos em cada estudo do mapeamento sistemático, o que permite o agrupamento de informações com características semelhantes. Uma vez que os códigos tenham sidos definidos, a próxima fase tem como objetivo juntar os códigos em grupos, de modo que se tenha mais significado e seja possível sintetizar uma grande quantidade de códigos em temas. Por fim, os temas criados são explorados com a finalidade de estabelecer temas mais gerais, bem como identificar relações entre eles.
Formulário de extração de dados
ID: ANO: PAÍS:
TÍTULO: AUTORES: BASE:
Questões de pesquisa
● PPS1: Quais os benefícios que esses tipos de frameworks agregam?
● PPS2: Quais os principais desafios ou limitações encontrados no uso desses tipos de frameworks?
3.4 CONSIDERAÇÕES FINAIS DO CAPÍTULO
Neste capítulo foram apresentados as perguntas de pesquisas, a estratégia de busca que foi utilizada, bem como a string de busca escolhida. Além disso, tanto os critérios de inclusão (CI) quanto os critérios de exclusão (CE) foram explicitados. Os processos de seleção, extração e avaliação da qualidade dos estudos também foram explicados, para que posteriormente pudessem ser explicadas a síntese e a análise dos dados.
4. RESULTADOS E SUMARIZAÇÃO DO MAPEAMENTO
4.1 INTRODUÇÃO
Este capítulo tem como objetivo mostrar os resultados alcançados por meio da execução do mapeamento seguindo as diretrizes definidas no capítulo anterior. Os dados obtidos pelo mapeamento são apresentados, e analisados para responder às perguntas de pesquisa.
4.2 BUSCA
Uma vez definidas as questões de pesquisa no protocolo do mapeamento sistemático, bem como identificadas as palavras-chave e seus sinônimos, a string de busca, desenvolvida através dessa combinação, foi utilizada manualmente nas fontes de buscas escolhidas para essa pesquisa.
Nas bases Scopus e IEEE Xplore, os dados dos estudos (título, nome dos autores, ano de publicação e link) foram extraídos dos próprios sites no formato
comma-separated values (csv). Já nas bases Science Direct e ACM, devido a não existir a opção de extração de dados no formato csv, os mesmos foram exportados dos sites no formato BibTeX e com o uso da ferramenta JabRef foram novamente exportados, mas agora no formato csv. Por fim, o Google Scholar não oferece nenhum mecanismo para exportação dos dados, e por conta disso foi utilizada a ferramenta Publish or Perish, na versão 7 que, integrada com o Google Scholar, forneceu os dados também no formato csv. Uma vez que todos os resultados já estavam no mesmo formato, essas informações foram armazenadas em uma planilha do Google Spreadsheets para ter um maior controle.
O resultado obtido, somando as 5 fontes de busca, foi de 1276 estudos. A quantidade separada por base é apresentada na Figura 2.
Figura 2: Quantidade de estudo por base Fonte: Elaborado pelo autor
Como é possível observar na Figura 2, a maior parte dos estudos foram encontrados no Google Scholar, onde os 716 trabalhos representam 56% do total obtido. Esse resultado é natural devido a configuração do Google Scholar que, diferentemente das outras fontes de estudo, trata-se de um indexador de buscas, e por conta disso, trouxe inclusive trabalhos que foram obtidos nas outras bases.
4.2.1 CRITÉRIOS DE SELEÇÃO DOS ESTUDOS
Os números referentes aos critérios de inclusão ou exclusão, que foram aplicados durantes as etapas 1, 2 e 3, conforme descrito na seção 3.3.5, estão representados na Figura 3.
Figura 3: Estudos totais e excluídos após aplicação dos critérios de seleção de
estudos
Fonte: Elaborado pelo autor
Conforme apresentado na Figura 3, dos 1276 estudos inicialmente obtidos, 502 foram excluídos por não atenderem aos critérios de inclusão ou por conta de algum critério de exclusão, restando então um total de 774. O detalhamento com a quantidade de artigos excluídos por cada critério de exclusão é apresentado na Figura 4.
Figura 4: Quantidade de artigos excluídos por cada critério Fonte: Elaborado pelo autor
4.2.2 SELEÇÃO POR TÍTULO E RESUMO
Aplicando a segunda etapa do processo de seleção dos estudos, conforme descrito na seção 3.3.5, foram lidos os títulos e resumos dos trabalhos encontrados para saber se eles iriam passar para a próxima etapa. Todos os artigos que não possuíam relação com o tema foram descartados. No entanto, em caso de dúvida o
trabalho permaneceu para ser avaliado na etapa posterior. Os resultados desta etapa são apresentados na Figura 5.
Figura 5: Quantidade de estudos iniciais e estudos aceitos após seleção por título e
resumo
Fonte: Elaborado pelo autor
Sendo assim, após a leitura do título e do resumo, o total de artigos a ser analisado passou a ser de 127.
4.2.3 SELEÇÃO POR INTRODUÇÃO E CONCLUSÃO
Nos 127 artigos remanescentes, foi aplicada a terceira etapa do processo de seleção, conforme descrito na seção 3.3.5, de modo a filtrar os artigos por meio da leitura da introdução e conclusão dos trabalhos. Vale ressaltar que, assim como na etapa anterior, em caso de dúvida o artigo não era descartado para ser melhor avaliado na próxima etapa. Os resultados são apresentados na Figura 6, onde é possível perceber que restaram 29 trabalhos após essa etapa.
Figura 6: Quantidade de estudos iniciais e aceitos após seleção por introdução e
conclusão
Fonte: Elaborado pelo autor
4.2.4 SELEÇÃO PELA LEITURA COMPLETA DOS ARTIGOS
A etapa final correspondeu à leitura completa dos artigos remanescentes, com o objetivo de selecionar os estudos finais que responderiam às questões de pesquisa. A Figura 7 mostra que restaram 15 artigos após esse processo. Além disso, é possível observar também que apenas trabalhos da Scopus e Google Scholar conseguiram ser aproveitados por essa pesquisa.
Figura 7: Quantidade de estudos inicias e estudos aceitos após seleção por leitura
completa
Fonte: Elaborado pelo autor 4.2.5 AVALIAÇÃO DE QUALIDADE DOS ESTUDOS
Para finalizar a quarta e última etapa, foram aplicadas avaliações nos estudos de acordo com os critérios de qualidade estabelecidos na seção 3.3.6, onde valores foram atribuídos em cada critério avaliado, à medida que tal critério era satisfeito, de modo a se obter uma nota final após o somatório de cada nota. Esse somatório pode ser encontrado no APÊNDICE B.
Com a aplicação dos critérios de qualidade estabelecidos, dos 15 trabalhos remanescentes, apenas 1 foi eliminado. Trata-se do estudo A13, que obteve a nota mais ‘baixa’ após o somatório de cada critério. A avaliação dos 14 estudos restantes é apresentada na Figura 8.
Figura 8: Avaliação de qualidade dos estudos Fonte: Elaborado pelo autor
A Figura 9 apresenta o somatório de todos os critérios de qualidade utilizados, onde é possível perceber que os critérios C3, C6 e C10 obtiveram as piores notas, enquanto o C1 obteve a maior nota.
O critério C3 (Os processos, técnicas e tecnologia, são claramente definidos?) indica que a maioria dos trabalhos não informaram de maneira clara sobre os processos, técnicas ou tecnologias que utilizaram. É válido pontuar que trata-se de um critério chave, dado que é de extrema importância para essa pesquisa ter essas informações à disposição, de modo que seja possível responder às questões de pesquisa com mais evidências.
A análise do critério C6 (Os participantes ou unidades de observação estão adequadamente descritos?) indica que os estudos se preocuparam mais em descrever a parte tecnológica, deixando de lado a descrição dos usuários envolvidos, bem como o ambiente em que foi aplicado o trabalho. Esse critério se faz importante por facilitar o entendimento e contextualização do cenário em que o estudo foi aplicado.
O critério C10 (Todas as questões de pesquisa são respondidas?) também obteve as menores notas, pois boa parte dos artigos respondeu apenas a uma das questões de pesquisa, normalmente a primeira. Pelo fato da segunda questão de pesquisa ser relacionada a desafios e dificuldades, foi um ponto mais difícil de ser encontrado nos estudos aprovados.
Por outro lado, o critério C1 (Os objetivos estão claramente estabelecidos?) foi o que se destacou com a maior nota. Isso significa que a maioria dos trabalhos apresentou de maneira clara os objetivos do estudo. Vale salientar que todos esses trabalhos passaram por uma longa triagem, durante as etapas de seleção dos estudos, o que contribuiu para uma nota elevada nesse critério.
Figura 9: Somatório de todos os critérios de qualidade utilizados Fonte: Elaborado pelo autor
4.3 VISÃO GERAL DOS ESTUDOS
Uma vez definidos todos os estudos aprovados, é possível ter uma visão geral dos mesmos por meio de informações como a distribuição por data de publicação, por autoria e por países, bem como apresentar os principais temas abordados pelos estudos. Essas dados são destrinchados nas próximas seções.
4.3.1 PUBLICAÇÕES POR ANO
O critério de exclusão CE4 teve como objetivo limitar essa pesquisa aos últimos 5 anos completos, além de incluir 2020 (em andamento), de modo a ter informações sobre o cenário mais atual. Por conta disso, os trabalhos aprovados estão entre os anos de 2015 a 2020. A Figura 10, que traz esse detalhamento, mostra que houve uma queda de publicações entre 2015 e 2017, onde nesse último ano não teve nenhum trabalho publicado. Quanto a essa redução de trabalhos, não foram encontradas evidências que a explicasse. Já 2018 e 2019 foram os anos que apresentaram maiores números de estudos aprovados, com 5 e 4 respectivamente, o que demonstra um certo interesse nesse tema nos últimos anos.
Figura 10: Publicações por ano Fonte: Elaborado pelo autor 4.3.2 AUTORIAS POR PAÍSES
Primeiramente, é válido ressaltar que seguindo o critério de exclusão CE2, apenas trabalhos escritos em inglês foram aceitos. É possível observar, na Figura 11, que o país com maior número de trabalhos aceitos foi a Índia, com 5 estudos no total. Nova Zelândia e Luxemburgo ficaram empatados com 2 trabalhos cada, enquanto os outros países tiverem apenas um trabalho.
Figura 11: Autoria por países Fonte: Elaborado pelo autor 4.3.2 FERRAMENTAS UTILIZADAS NOS ESTUDOS
Ao analisar as ferramentas utilizadas nos trabalhos selecionados, fica clara a predominância do uso do Selenium WebDriver, ferramenta utilizada para automação de testes Web, que esteve presente em 8 dos 14 trabalhos (53%), conforme apresentado na Figura 12. Isso pode ser explicado devido ao fato de se tratar de uma ferramenta gratuita, com suporte a várias linguagens de programação, como
Python, C# e Java, além de dar suporte a múltiplos browsers, como Google Chrome, Firefox, Internet Explorer e Safari [A9]. Em segundo lugar apareceram o Selenium IDE, ferramenta gratuita que é capaz de gerar testes web automáticos a partir da gravação da tela (record and play) e o TestComplete, ferramenta paga que pode ser utilizada para automação de testes desktop, web e mobile, com uma ocorrência cada. Por fim, quatro estudos não informaram a ferramenta utilizada.
Figura 12: Ferramentas utilizadas nos estudos Fonte: Elaborado pelo autor
4.4 MAPEAMENTO DAS EVIDÊNCIAS
Esta seção tem como objetivo apresentar os resultados, associados às questões de pesquisa, obtidos a partir do mapeamento sistemático da literatura.
(PPP): Quais são os Tipos de Frameworks Utilizados para Automação de Testes Web em Contextos Ágeis?
A Figura 13 apresenta a quantidade e a porcentagem de cada tipo de
framework utilizado dentre os estudos aprovados, de modo a responder a Pergunta Primária de Pesquisa (PPP). É possível observar que o Keyword-Driven Framework foi o que obteve o maior número de ocorrências (7). Em seguida aparecem o Hybrid
Testing Framework e Behavior Driven Development Testing Framework com 2 trabalhos cada, enquanto o Modular Based, Data-Driven e Linear ficaram empatados com apenas 1 trabalho cada.
Figura 13: Tipos de frameworks utilizados para automação de testes web em
contextos ágeis
Fonte: Elaborado pelo autor
PPS1: Quais os benefícios que esses tipos de frameworks agregam?
Conforme descrito na seção 3.3.8, seguindo recomendações de Cruzes e Dyba (2011), com base nos estudos selecionados, foi possível extrair dados, bem como identificar códigos que posteriormente viraram temas, como pode ser visto na Tabela 1. Além disso, essa mesma tabela apresenta quais temas/benefícios foram citados pelos estudos.
Tabela 1: Benefícios dos tipos de frameworks Fonte: Elaborado pelo autor
P1T1: Reuso
Os estudos A5, A9, A10 e A15 utilizam o framework do tipo Keyword-Driven e
evidenciam a característica do reuso por meio das keywords (palavras-chaves). Isto
ID Tema Estudos
P1T1 Reuso A1, A2, A3, A5, A9,
A10, A15 P1T2 Pessoas sem habilidade de automação podem
participar do processo A5, A7, A8, A10, A11,A12, A14 P1T3 Manutenabilidade A2, A3, A5, A7, A8,
A9 P1T4 União de pontos fortes e mitigação de fraquezas
ao usar um framework híbrido
A4 P1T5 Desenvolvimento rápido A6
é, uma mesma palavra-chave pode ser reutilizada em vários casos de testes diferentes, como pode ser visto nos transcritos a seguir, obtidos a partir desses trabalhos:
“For building blocks of each test case, custom user keywords are structured in a modular way. Each low, medium and high level keyword can be reused across test cases with minimal duplication. All of these approaches result in reusable and maintainable test assets.“ - A5
“Our results suggest that KDT test design is complex with several levels of abstraction and that this design favours reusability” - A10
“Keyword driven Testing involves a set of keywords which define a sequence of operations. These keywords are then used to create reusable functions mapped to a particular functionality of the application.” - A15
Nos frameworks do tipo Data-Driven, uma vez que os dados dos testes são separados dos scripts de testes, um mesmo cenário pode ser executado várias vezes com diferentes conjuntos de testes, o que favorece o reuso, como pode ser observado no trecho a seguir, obtido a partir do estudo A1:
“Having a test script with embedded test data has its own limitations for building platform independent framework. It has major drawbacks such as small changes in the test data needs test case corrections, it may not be a difficult task for the person who developed it but it will [be] a hectic job for others to handle it..Keeping all these factors it would be more helpful by having the test data in an external data source and using it for test execution, this is nothing but Data driven Approach. A good framework has qualities such as reusable, application-independent and data driven.” - A1
Já o estudo A3 utiliza o framework do tipo Hybrid, em que Data-Driven e Keyword-Driven se fazem presentes, o que consequentemente apresenta os mesmo benefícios citados anteriormente pelos estudos que utilizam um framework apenas do tipo Keyword-Driven ou apenas do tipo Data-Driven.
Por fim, o estudo A2, que apresenta o framework Modular Based, também evidencia o benefício do reuso. Como se trata de uma arquitetura baseada em módulos, sendo cada módulo independente entre si, para criação de cenários de
testes, os mesmos módulos podem ser utilizados para diferentes testes. A seguir é destacado um trecho do estudo:
“The proposed framework is very significant for dynamically changing web applications like “sas.am” and it consists of reusable codes for full regression testing” - A2
P1T2: Pessoas sem habilidade de automação podem participar do processo
Os estudos A5, A7, A8, A10 e A12, que utilizam o framework do tipo
Keyword-Driven, evidenciam que pessoas sem habilidade de automação podem
participar do processo por duas razões: uso de linguagem natural e o fato de que casos de testes são criados em arquivos separados dos scripts de testes. Esses dois motivos fazem com que pessoas sem tanto conhecimento técnico possam participar da criação e edição dos testes automáticos, pois a linguagem natural é algo próximo do dia-a-dia, o que facilita o entendimento. Além disso, por não existir a necessidade de interagir diretamente com os scriptsque irão realizar as ações nos testes, uma vez que são arquivos separados, torna-se mais fácil a participação de pessoas menos técnicas no processo. A seguir são apresentados trechos dos estudos que reforçam este entendimento:
“In less mature Agile organisations like our case study (iProperty Group), testing is typically done by less-technical persons who possess little to no programming knowledge that contribute in specifying test cases. To our knowledge, using natural language is more descriptive and understandable to the less-technical stakeholders rather than programming oriented language.” - A5 “Keyword-Driven Testing aims at separating test design from technical implementation, hence limiting exposure to unnecessary details. Keyword-Driven Testing advocates that this separation of concerns allows tests to be written more easily, to create more maintainable tests and enables experts from different fields and backgrounds to work together at different levels of abstraction using named procedures called keywords.” - A8
“One of the reasons that our partner adopted KDT is that test cases at this testing level were created by different domain experts (business analysts and automation experts) and the adoption of a common language between the experts was imperative.” - A10
“All interviewees agreed on two main benefits of KDT: the low learning curve and its simple syntax. Thanks to its syntax that is close to the natural language, new users can easily start being
