UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE P ´OS-GRADUAC¸ ˜AO EM ENGENHARIA EL´ETRICA E COMPUTAC¸ ˜AO Matheus Marabesi TESTABLE: UMA FERRAMENTA GAMIFICADA PARA AUXILIAR O ENSINO DE TESTES UNIT ´ARIOS

UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE P ´ OS-GRADUAC ¸ ˜ AO EM ENGENHARIA EL´ ETRICA E COMPUTAC ¸ ˜ AO

Matheus Marabesi

TESTABLE: UMA FERRAMENTA GAMIFICADA PARA AUXILIAR O ENSINO DE TESTES UNIT ´ ARIOS

Orientador: Prof. Dr. Ismar Frango Silveira

S˜ ao Paulo

2020

UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE P ´ OS-GRADUAC ¸ ˜ AO EM ENGENHARIA EL´ ETRICA E COMPUTAC ¸ ˜ AO

Matheus Marabesi

TESTABLE: UMA FERRAMENTA GAMIFICADA PARA AUXILIAR O ENSINO DE TESTES UNIT ´ ARIOS

Disserta¸c˜ ao de mestrado apresentada ao Programa de P´ os-Gradua¸c˜ ao em Engenharia El´ etrica e Computa¸c˜ ao da Universidade Presbiteriana Mackenzie

como requisito parcial para a

obten¸c˜ ao do t´ıtulo de mestre em Engenharia El´ etrica e Computa¸c˜ ao.

Orientador: Prof. Dr. Ismar Frango Silveira

S˜ ao Paulo, 2020

Bibliotecária Responsável: Maria Gabriela Brandi Teixeira – CRB 8/ 6339

AGRADECIMENTOS

Foi uma longa jornada concluir esse trabalho e n˜ ao foi poss´ıvel fazer-lo sozinho. Ta- milyn Hidemi Itokazo, te agrade¸co pela for¸ca, confian¸ca e principalmente por ser parte ativa elaborando a parte criativa e desenvolvendo a identidade visual do trabalho.

A meus ex companheiros de trabalho Guilherme de Paula e Tiago Paes, que me aju- daram in´ umeras vezes a testar a ferramenta, coletar bugs e que me forneceram feedbacks construtivos.

Agrade¸co ao professor Dr. Ismar Frango Silveira, que me acompanhou e me guiou, a meus colegas de mestrado, em especial, Daniel Ohata que me proporcionou criticas cons- trutivas, aos professores Msc Josivan Silva e Cristiano da Silva Benites que me apoiaram durante a aplica¸c˜ ao da ferramenta.

Deixo aqui o meu agradecimento a todos aqueles envolvidos que fizeram parte dessa

caminha.

RESUMO

Com a constante evolu¸c˜ ao do desenvolvimento de software e sua complexidade, cada vez mais se exige do profissional da ´ area a necessidade de dominar diferentes fases do processo de desenvolvimento de software, o que inclui a fase de testes. Isso gera um impacto na forma¸c˜ ao de novos profissionais, uma vez que os curr´ıculos de forma¸c˜ ao deveriam contemplar esta complexidade.

Nesse sentido, o teste de software possui seu lugar nos cursos de gradua¸c˜ ao, mas a literatura aponta que n˜ ao ´ e dada a devida aten¸c˜ ao e importˆ ancia pelos alunos e pelo curr´ıculo acadˆ emico. Uma das poss´ıveis causas que pode ser citada ´ e a forma de oferta deste conte´ udo, que geralmente faz parte de uma disciplina de Engenharia de software, percebida pelos alunos j´ a como algo tedioso e que n˜ ao ser´ a importante para a sua carreira.

Pensando nesse cen´ ario, esse trabalho prop˜ oe Testable, uma ferramenta gamificada para a aprendizagem de teste unit´ ario, visando aumentar o engajamento dos alunos em rela¸c˜ ao ao conte´ udo. Para validar a ferramenta, uma experimenta¸c˜ ao com alunos de gradua¸c˜ ao e programadores profissionais foi realizada, coletando dados por meio de ques- tion´ ario e captura e an´ alise de dados provenientes do uso da ferramenta.

Palavras-chave: Teste de software, Ferramenta Educacional, Gamifica¸ c˜ ao.

Sum´ ario

1 INTRODUC ¸ ˜ AO 1

1.1 Motiva¸c˜ ao . . . . 1

1.2 Objetivos . . . . 2

1.2.1 Objetivo geral . . . . 2

1.2.2 Objetivos espec´ıficos . . . . 2

1.3 Organiza¸c˜ ao do trabalho . . . . 2

2 SERIOUS GAMES E GAMIFICAC ¸ ˜ AO 4 2.1 Serious games . . . . 4

2.2 Elementos de jogos . . . . 6

2.2.1 Dinˆ amica . . . . 7

2.2.2 Mecˆ anica . . . . 8

2.2.3 Componentes . . . . 10

2.3 Gamifica¸c˜ ao . . . . 11

2.3.1 Como e quando utilizar gamifica¸c˜ ao . . . . 16

2.4 Considera¸c˜ oes parciais . . . . 19

3 TESTE DE SOFTWARE 20 3.1 Aspectos conceituais . . . . 20

3.1.1 Verifica¸c˜ ao e Valida¸c˜ ao . . . . 20

3.2 Aspectos conceituais: Teste unit´ ario . . . . 21

3.3 Teste unit´ ario . . . . 23

3.4 TDD (Test Driven Development) . . . . 24

3.5 Ensino de teste de software . . . . 26

4 REVIS ˜ AO BIBLIOGR ´ AFICA E T´ ECNICA 27 4.1 Metodologia utilizada para a revis˜ ao . . . . 27

4.2 Revis˜ ao de literatura: O ensino de teste de software . . . . 28

4.3 Revis˜ ao de literatura: Gamifica¸c˜ ao e educa¸c˜ ao . . . . 30

4.4 Revis˜ ao de literatura: Gamifica¸c˜ ao no ensino de computa¸c˜ ao . . . . 30

4.5 Considera¸c˜ oes parciais . . . . 33

4.6 Revis˜ ao t´ ecnica . . . . 33

4.6.1 Flexbox Froggy . . . . 34

4.6.2 How HTTPS Works . . . . 35

4.6.3 Regex Crossword . . . . 36

5 CONCEPC ¸ ˜ AO E DESENVOLVIMENTO 38 5.1 Concep¸c˜ ao: Teste unit´ ario . . . . 38

5.2 Concep¸c˜ ao: Transforma¸c˜ ao l´ udica . . . . 41

5.3 Concep¸c˜ ao: Hist´ oria . . . . 42

5.4 Concep¸c˜ ao: Elementos da experiˆ encia gamificada . . . . 43

5.5 Concep¸c˜ ao: Dinˆ amica . . . . 45

5.6 Concep¸c˜ ao: Mecˆ anica . . . . 46

5.7 Concep¸c˜ ao: Componentes . . . . 48

5.8 Concep¸c˜ ao: Conte´ udo . . . . 51

5.9 Arquitetura . . . . 53

5.9.1 Caso de uso . . . . 55

5.9.2 Requisitos . . . . 55

5.9.2.1 Requisitos funcionais . . . . 55

5.9.2.2 Requisito n˜ ao funcionais . . . . 56

5.9.3 Tecnologias utilizadas . . . . 56

5.9.3.1 ReactJs . . . . 57

5.9.3.2 Firebase . . . . 58

5.9.3.3 Git . . . . 59

5.9.3.4 Ferramentas . . . . 59

5.10 Desenvolvimento . . . . 60

5.10.1 Interface do usu´ ario . . . . 61

6 APLICAC ¸ ˜ AO 65 6.1 Comitˆ e de ´ etica . . . . 65

6.1.1 Crit´ erios de inclus˜ ao . . . . 66

6.1.2 Crit´ erios de exclus˜ ao . . . . 66

6.1.3 Riscos e benef´ıcios . . . . 66

6.2 Coleta de dados . . . . 67

6.2.1 Dados da aplica¸c˜ ao . . . . 67

6.2.2 Question´ ario . . . . 68

6.3 Avalia¸c˜ ao dos resultados . . . . 69

6.4 Dados coletados automaticamente . . . . 69

6.5 Dados coletados via question´ ario . . . . 72

6.5.1 Sobre vocˆ e . . . . 72

6.5.2 Motiva¸c˜ ao . . . . 75

6.5.3 Experiˆ encia do usu´ ario . . . . 81

6.5.4 Performance . . . . 84

6.6 Considera¸c˜ oes parciais . . . . 86

7 CONCLUS ˜ AO E TRABALHOS FUTUROS 87 REFERˆ ENCIAS BIBLIOGR ´ AFICAS 94 8 ANEXOS 95 8.1 MANRIQUE TOOLKIT FOR GAMIFICATION DESIGN - CATEGORI- ZADOS POR COR . . . . 95

8.2 QUESTION ´ ARIO . . . . 96

8.3 CRONOGRAMA . . . 101

8.4 TCLE MAIORES DE IDADE . . . 102

8.5 TCLE INSTITUIC ¸ ˜ AO . . . 105

8.6 FOLHA DE ROSTO - PLATAFORMA BRASIL . . . 108

8.7 CARTA DE ENCAMINHAMENTO - PLATAFORMA BRASIL . . . 109

8.8 PROJETO APROVADO - PLATFORMA BRASIL . . . 110

8.9 SEC ¸ ˜ OES TRAQUEADAS . . . 119

Lista de Figuras

1 Tela principal do jogo SICKO. Fonte: (SICKO, 2006). . . . 4 2 Tela do jogo America Army: Uniforme e arma utilizado no jogo foram

desenvolvidos para serem o mais pr´ oximo da realidade poss´ıvel. Fonte:

(MICHAEL; CHEN, 2006). . . . . 5 3 Elemento de jogos dividido em categorias. Fonte: Adaptado de (WER-

BACH; HUNTER, 2012). . . . 6 4 Representa¸c˜ ao da ferramenta MDA em trˆ es elementos. Fonte: (HUNICKE;

LEBLANC; ZUBEK, 2004). . . . 8 5 Componentes da ferramenta MDA. Fonte: (HUNICKE; LEBLANC; ZU-

BEK, 2004). . . . 8 6 Tipos de gamifica¸c˜ ao e sua aplica¸c˜ ao. Fonte: (WERBACH; HUNTER, 2012). 14 7 Exemplo de arquitetura de web em 3 camadas. Fonte: Elaborada pelo autor. 22 8 Foco do teste unit´ ario na arquitetura web 3 camadas. Fonte: Elaborada

pelo autor. . . . 23 9 Ciclo de execu¸c˜ ao do TDD. Fonte: (BECK, 2010). . . . 25 10 Interesse do termo “teste unit´ ario” segundo Google Trends de 2013 ´ a 2018.

Fonte: Google. . . . . 27 11 Tela inicial do Flexbox Froggy. Fonte: (PARK, 2015). . . . 34 12 Tela inicial do How HTTPS Works. Fonte: https://howhttps.works. . . . . 36 13 Tela inicial do Regex Crossword. Fonte: https://regexcrossword.com. . . . 37

14 Instru¸c˜ oes de como jogar Regex Crossword. Fonte: https://regexcrossword.com/howtoplay. 37 15 Personagens da experiˆ encia gamificada, na esquerda Buggy e na direita

Alien. Fonte: Elaborada pelo autor. . . . 43 16 Testable - experiˆ encia gamificada. Fonte: (MANRIQUE, 2013c). . . . 45 17 Dinamica utilizada na ferramenta gamificada. Fonte: Elaborada pelo autor. 46 18 Abordagem sugerida com dois editores de c´ odigo. Fonte: Elaborada pelo

autor. . . . . 47 19 Fluxo de execu¸c˜ ao do c´ odigo escrito pelo usu´ ario na ferramenta gamificada.

Fonte: Elaborada pelo autor. . . . 48 20 Exemplo de arquitetura de arquitetura em camadas. Fonte: (RICHARDS,

2015). . . . 54 21 Diagrama de caso de uso ferramenta Testable. Fonte: Elaborada pelo autor. 55 22 Imagem ilustrativa de como o servi¸co de banco de dados em tempo real

funciona. Fonte: Elaborada pelo autor. . . . 58

23 Tecnologias presentes no reposit´ orio da ferramenta gamificada. Fonte: Ela-

borada pelo autor. . . . . 60

24 Login. Fonte: Elaborada pelo autor. . . . 61

25 Introdu¸c˜ ao. Fonte: Elaborada pelo autor. . . . 62

26 Tutorial. Fonte: Elaborada pelo autor. . . . 62

27 Transi¸c˜ ao do tutorial para a introdu¸c˜ ao ao teste unit´ ario. Fonte: Elaborada pelo autor. . . . 63

28 Introdu¸c˜ ao ao teste unit´ ario. Fonte: Elaborada pelo autor. . . . 63

29 Lista de conquistas adquiridas. Fonte: Elaborada pelo autor. . . . 64

30 N´ umero de visitantes durante o per´ıodo oficial de testes. Fonte: Google analytics. . . . . 70

31 Lingua nativa dos usu´ arios visitantes. Fonte: Google analytics. . . . 70

32 Acesso de usu´ arios atrav´ es de dispositivos m´ oveis e desktop. Fonte: Google analytics. . . . . 71

33 Tempo de carregamento da ferramenta gamificada. Fonte: Google analytics. 71 34 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 1. Fonte: Ela- borada pelo autor. . . . . 72

35 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 2. Fonte: Ela- borada pelo autor. . . . . 73

36 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 3. Fonte: Ela- borada pelo autor. . . . . 73

37 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 4. Fonte: Ela- borada pelo autor. . . . . 74

38 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 5. Fonte: Ela- borada pelo autor. . . . . 74

39 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 6. Fonte: Ela- borada pelo autor. . . . . 75

40 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 7. Fonte: Ela- borada pelo autor. . . . . 76

41 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 8. Fonte: Ela- borada pelo autor. . . . . 76

42 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 9. Fonte: Ela- borada pelo autor. . . . . 77

43 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 10. Fonte: Elaborada pelo autor. . . . 78

44 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 11. Fonte:

Elaborada pelo autor. . . . 78

45 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 12. Fonte:

Elaborada pelo autor. . . . 79

46 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 13. Fonte: Elaborada pelo autor. . . . 80

47 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 14. Fonte: Elaborada pelo autor. . . . 80

48 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 15. Fonte: Elaborada pelo autor. . . . 81

49 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 16. Fonte: Elaborada pelo autor. . . . 82

50 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 17. Fonte: Elaborada pelo autor. . . . 83

51 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 18. Fonte: Elaborada pelo autor. . . . 83

52 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 19. Fonte: Elaborada pelo autor. . . . 84

53 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 20. Fonte: Elaborada pelo autor. . . . 85

54 Gr´ afico de barras com os resultados da quest˜ ao de n´ umero 21. Fonte: Elaborada pelo autor. . . . 86

Lista de Tabelas 1 Diferen¸cas entre Jogo, Gamifica¸c˜ ao e Simula¸c˜ ao. Fonte: (KAPP; BLAIR; MESCH, 2012). . . . 13

2 Decis˜ ao de qual elemento utilizar. Fonte: Kapp, Blair e Mesch (2012). . . . 18

3 N´ umero de trabalhos relacionados por categoria e congresso . . . . 28

4 Descri¸c˜ ao detalhada dos assuntos abordados . . . . 40

5 Representa¸c˜ ao dos componentes criados na ferramenta Figma . . . . 50

6 Tabela de conte´ udo da experiˆ encia gamificada do n´ıvel 1 e n´ıvel 2 . . . . . 51

7 Tabela de conte´ udo da experiˆ encia gamificada do n´ıvel 3 at´ e o n´ıvel 14 . . 52

8 Tabela de conte´ udo da experiˆ encia gamificada do n´ıvel 3 at´ e o n´ıvel 14 . . 53

9 Descri¸c˜ ao detalhada das informa¸c˜ oes automaticamente coletada pela ferra- menta . . . . 68

10 Identificadores da se¸c˜ oes traque´ aveis da ferramenta gamificada. . . 119

1 INTRODUC ¸ ˜ AO

1.1 Motiva¸ c˜ ao

Com a crescente evolu¸c˜ ao da complexidade no desenvolvimento de software, seja no contexto profissional ou acadˆ emico, cada vez mais se faz necess´ aria a aplica¸c˜ ao de testes de software para realizar a verifica¸c˜ ao e valida¸c˜ ao de diferentes aspectos do software.

Entre os diferentes testes existentes no contexto da Engenharia de Software, destacam- se os Testes Unit´ arios, que se dedicam a testar unidades individuais de c´ odigo.

E desej´ ´ avel que testes unit´ arios sejam inicialmente feitos pelo pr´ oprio desenvolvedor.

Em geral, esses testes s˜ ao realizados por unidade de c´ odigo para verificar sua funcionali- dade.

Por´ em, considerando a diversidade de testes encontrados na literatura (SOMMER- VILLE, 2017), e al´ em da execu¸c˜ ao de testes pelo desenvolvedor, toda equipe de software deveria ter um profissional dedicado a essa tarefa. Entretanto esta n˜ ao ´ e a realidade no cotidiano das empresas, assim como no mundo acadˆ emico (BENITTI; ALBANO, 2012).

Segundo os mesmos autores, as matrizes curriculares de cursos de gradua¸c˜ ao da ´ area de computa¸c˜ ao possuem uma carga hor´ aria reduzida a respeito de teste de software, sob a premissa de ser o suficiente para que os alunos estejam preparados para executar adequadamente as tarefas relacionadas a teste de software, o que n˜ ao ´ e necessariamente verdade.

Isso pode levar a um entendimento inadequado por parte dos alunos de que teste de software ´ e apenas um detalhe no processo de Engenharia de Software.

Al´ em disso pode-se mencionar a dificuldade pelos professores em engajar os alunos para o aprendizado do teste de software, ja que isso requer um bom n´ıvel de abstra¸c˜ ao e requisitos pr´ evios.

E por ´ ultimo mas n˜ ao menos importante, as estrat´ egias did´ aticas podem ter um

impacto negativo no engajamento, que motiva pesquisas que envolvam metodologias e

t´ ecnicas com foco no engajamento para o ensino de teste de software, que ´ e o eixo central

deste trabalho.

Nesse sentido, a aplica¸c˜ ao de t´ ecnicas voltadas ao aumento do engajamento, como o uso de jogos s´ erios (serious games), conforme Abt (1970) e gamifica¸c˜ ao (DETERDING, 2011) podem ter impacto positivo nos processos de ensino e aprendizagem.

Os t´ opicos a seguir representam um resumo da motiva¸c˜ ao apresentada nessa se¸c˜ ao:

• Complexidade dos sistemas desenvolvidos atualmente.

• A falta de dedica¸c˜ ao dos desenvolvedores/alunos ` a fase de testes de um software.

• Estrat´ egias did´ aticas comumente levam um baixo n´ıvel de engajamento por parte dos alunos.

1.2 Objetivos

1.2.1 Objetivo geral

Desenvolver uma ferramenta gamificada voltado ao o ensino de testes unit´ arios para alunos do curso de gradua¸c˜ ao na ´ area de computa¸c˜ ao.

1.2.2 Objetivos espec´ıficos

• Realizar revis˜ ao para visualizar o estado da arte no que diz respeito ao ensino de teste de software e ` a utiliza¸c˜ ao de gamifica¸c˜ ao como estrat´ egia.

• Desenvolver uma ferramenta gamificada para ensino de testes de software, especifi- camente o Teste Unit´ ario, para delimita¸c˜ ao de escopo da pesquisa.

• Avaliar e analisar a aplica¸c˜ ao desta ferramenta em uma turma de gradua¸c˜ ao.

1.3 Organiza¸ c˜ ao do trabalho

O texto segue da seguinte forma: no cap´ıtulo 2 ´ e apresentada a defini¸c˜ ao de seri-

ous game e gamifica¸c˜ ao no contexto deste trabalho, o cap´ıtulo 3 ´ e dedicado ao teste de

software, o cap´ıtulo 4 apresenta a metodologia utilizada para o desenvolvimento deste

trabalho e a revis˜ ao bibliogr´ afica da pesquisa realizada, o cap´ıtulo 5 ´ e dedicado ao desen-

volvimento da ferramenta Testable, o cap´ıtulo 6 apresenta a aplica¸c˜ ao da ferramenta e a

an´ alise dos dados obtidos, o cap´ıtulo 7 exp˜ oe a conclus˜ ao e trabalhos futuros a serem rea-

lizados. Finalmente as referˆ encias bibliogr´ aficas utilizadas s˜ ao apresentadas, e em seguida

os apˆ endices e anexos.

2 SERIOUS GAMES E GAMIFICAC ¸ ˜ AO

2.1 Serious games

Jogos s˜ ao conhecidos pela maioria das pessoas como um meio de divers˜ ao, um passa- tempo ou at´ e mesmo um momento para compartilhar com a fam´ılia e amigos.

Apesar de todos os esfor¸cos da academia em mostrar que jogos podem ser usados para outros meios do que o puro entretenimento, ainda existe um conceito pr´ evio por parte da popula¸c˜ ao em geral em defender que jogos s˜ ao meros passatempos. Existem jogos criados especificamente para ensinar e treinar profissionais de diversas ´ areas do conhecimento, ao contr´ ario de jogos de entretenimento, serious games s˜ ao jogos desenvolvidos com o obje- tivo de educar ou treinar ao inv´ es de pura divers˜ ao (MICHAEL; CHEN, 2006) (ADAMS;

DORMANS, 2012).

SICKO (2006) por exemplo, ´ e um jogo que mostra para estudantes de medicina como

´ e o dia a dia em um hospital. O jogo simula pacientes que est˜ ao indo a um hospital com diferentes sintomas, e o papel do jogador ´ e atender todos em um determinado tempo, caso o contr´ ario os pacientes morrem. Isso ajuda os estudantes de medicina a ter uma id´ eia do que um hospital real ´ e, ajudando-os a melhorar a sua tomada de decis˜ ao e permitindo erros sem prejudicar uma vida real.

Figura 1: Tela principal do jogo SICKO. Fonte: (SICKO, 2006).

Serious game foi utilizado tamb´ em pelo ex´ ercito americano para recrutar soldados.

Em 2002 o ex´ ercito americano criou o jogo America’s Army que se provou ser eficiente em reduzir o custo (em 15% do valor total) de se recrutar 80.000 soldados todos os anos. O jogo utiliza o cen´ ario mais realista poss´ıvel, come¸cando pelas roupas que o soldados vestem suas armas e miss˜ oes que o jogador precisa cumprir, mas em alguns casos o realismo ´ e deixado de lado para dar lugar ao entretenimento, como por exemplo se esconder atr´ as de um carro. Apesar de ser uma a¸c˜ ao poss´ıvel no mundo real, n˜ ao ´ e aconselh´ avel, uma vez que em miss˜ oes no Iraque por exemplo esses carros seriam facilmente explodidos (MICHAEL;

CHEN, 2006).

Figura 2: Tela do jogo America Army: Uniforme e arma utilizado no jogo foram desen- volvidos para serem o mais pr´ oximo da realidade poss´ıvel. Fonte: (MICHAEL; CHEN, 2006).

Em linhas gerais essa se¸c˜ ao do trabalho definiu o que ´ e serious games de acordo com os autores (MICHAEL; CHEN, 2006) (ADAMS; DORMANS, 2012) e explorou as diferentes aplica¸c˜ oes de gamifica¸c˜ ao em diferentes ´ areas da sociedade e o impacto positivo que essas aplica¸c˜ oes obtiveram.

Assim como os serious games explorados neste cap´ıtulo, este trabalho possui o obje-

tivo de ensinar teste unit´ ario atrav´ es de uma ferramenta que torne a experiˆ encia agrad´ avel

e o mais perto da realidade poss´ıvel, para isso nas pr´ oximas se¸c˜ oes ser˜ ao explorados os

aspectos que envolvem a gamifica¸c˜ ao, come¸cando pelos elementos de jogos que contem-

plam as subse¸c˜ oes dinˆ amica, mecˆ anica e componentes, em seguida ´ e dedicada uma se¸c˜ ao

com foco na gamifica¸c˜ ao.

2.2 Elementos de jogos

Em linhas gerais elemento de jogos (do inglˆ es game elements ) s˜ ao definidos como um conjunto de componentes existente em um jogo (WERBACH; HUNTER, 2012). O jogo de damas possui alguns componentes de a¸c˜ ao como por exemplo mover as pe¸cas e gerar a dama, possui as pe¸cas para se jogar (objetos) e finalmente h´ a regras bem definidas para se jogar. Para o jogo de damas os componentes identificados podem ser definidos como a¸c˜ ao, objetos e regras.

Os trˆ es componentes principais utilizados em diferentes aplica¸c˜ oes de gamifica¸c˜ ao citado por Werbach e Hunter (2012) s˜ ao: Leaderboards, points e badges (LPB). Por´ em a ressalva deixada por ambos ´ e que a gamifica¸c˜ ao n˜ ao se limita apenas a utiliza¸c˜ ao desses componentes, pois existem outros que podem se encaixar melhor, como por exemplo:

conquistas, n´ıveis e personagens. Uma lista com os componentes listado pelos autores ´ e apresentada na se¸c˜ ao 2.2.3. Isso depende, entre outros aspectos, dos objetivos a serem alcan¸cados. A utiliza¸c˜ ao constante de LPB se d´ a pelo fato da sua facilidade em ser implementada em sistemas j´ a existentes e f´ acil adequa¸c˜ ao.

Este cap´ıtulo aborda trˆ es categorias de elementos de jogos, dinˆ amica, mecˆ anica e componentes. Werbach e Hunter (2012) defendem que essas s˜ ao as principais categorias que se encontram em gamifica¸c˜ ao, o que vai ao encontro do prop´ osito deste trabalho.

Figura 3: Elemento de jogos dividido em categorias. Fonte: Adaptado de (WERBACH;

HUNTER, 2012).

2.2.1 Dinˆ amica

A dinˆ amica, como definido por Werbach e Hunter (2012) ´ e parte mais abrangente dos elementos de jogos, a que possui o maior n´ıvel de abstra¸c˜ ao. E por ser uma etapa de concep¸c˜ ao ´ e frequentemente executada pelos designers que possuem uma vis˜ ao mais criativa dentro dos perfis que envolvem o desenvolvimento de um jogo.

E atrav´ ´ es da dinˆ amica que s˜ ao definidos os t´ opicos mais gerais do jogo como as limita¸c˜ oes do jogador, a linha de hist´ oria do jogo, a progress˜ ao do jogador entre outros.

Entretanto, a dinˆ amica n˜ ao se limita a esses aspectos: os mesmos autores elencam outros elementos de jogos relacionados ` a dinˆ amica, a saber:

• Limita¸c˜ oes (limita¸c˜ oes ou forced trade)

• Emo¸c˜ oes (curiosidade, competitividade, frustra¸c˜ ao, felicidade)

• Narrativa (uma consistente, linha de hist´ oria cont´ınua)

• Progress˜ ao (o crescimento do jogador e seu desenvolvimento)

• Relacionamentos (intera¸c˜ oes sociais gerando sentimentos de camaradagem, status, altru´ısmo)

Hunicke, LeBlanc e Zubek (2004) descrevem uma ferramenta que padroniza os passos de como criar um jogo e estreitar as diferen¸cas entre o design e o desenvolvedor. A ferramenta nomeada MDA (Mechanics, Dynamics, and Aesthetics) ´ e dividida em trˆ es

´

areas: Mecˆ anica, Dinˆ amica e Est´ etica.

Assim como Werbach e Hunter (2012) que mostram uma forma de dinˆ amica sendo a parte mais abstrata, aquela que ir´ a compor a mecˆ anica e os componentes, os auto- res Hunicke, LeBlanc e Zubek (2004) tamb´ em compartilham dessa ideia. A estrutura apresentada pelos autores ´ e ilustrada na Figura 4.

As regras (Rules ) correspondem ` a mecˆ anica, e s˜ ao o conjunto de componentes que

descrevem o jogo no n´ıvel de implementa¸c˜ ao, atrav´ es dos algoritmos e os dados que s˜ ao

utilizados no jogo. O sistema (System) ´ e a parte correspondente a dinˆ amica que descreve o

comportamento das diferentes mecˆ anicas que o jogo pode possuir. E por fim a parte l´ udica

Figura 4: Representa¸c˜ ao da ferramenta MDA em trˆ es elementos. Fonte: (HUNICKE;

LEBLANC; ZUBEK, 2004).

(Fun ) que corresponde a parte est´ etica (ou os componentes) do jogo, e tamb´ em fornece respostas emocionais de acordo com a intera¸c˜ ao do jogador. (HUNICKE; LEBLANC;

ZUBEK, 2004)

A Figura 5 ilustra a correspondˆ encia de cada t´ opico da Figura 4 com os t´ opicos existentes no elementos de jogos definidos na se¸c˜ ao 2.2, a ressalva fica por parte do ´ ultimo t´ opico exibido nomeado Aesthetics, que conforme a defini¸c˜ ao de (WERBACH; HUNTER, 2012) seria Components.

Figura 5: Componentes da ferramenta MDA. Fonte: (HUNICKE; LEBLANC; ZUBEK, 2004).

A dinˆ amica e a mecˆ anica possuem uma linha tˆ enue e s˜ ao frequentemente tratadas como o mesmo assunto, por´ em a mecˆ anica ´ e definida como o comportamento e a¸c˜ oes do jogador (a se¸c˜ ao 2.2.2 trata exclusivamente deste tema). J´ a a dinˆ amica ´ e a apela¸c˜ ao motivacional da experiˆ encia que a mecˆ anica proporciona (BUNCHBALL, 2010). Werbach e Hunter (2012) complementam essa defini¸c˜ ao ressaltando que a dinˆ amica ´ e algo que o jogador n˜ ao possui contato diretamente apesar de fazer parte a experiˆ encia do jogo.

2.2.2 Mecˆ anica

Brown (2014) define arquitetura de software como as decis˜ oes tomadas em um projeto que n˜ ao se pode reverter sem um n´ıvel m´ınimo de esfor¸co, decis˜ oes que requerem um esfor¸co para mudarem e que n˜ ao s˜ ao f´ aceis de mudar em uma tarde.

Assim como a arquitetura de software, a mecˆ anica possui elementos que requerem um

esfor¸co para serem alteradas ou mudadas uma vez que implementadas. Por´ em isso n˜ ao quer dizer que seria imposs´ıvel a altera¸c˜ ao das mecˆ anicas escolhidas em um certo ponto no tempo, apenas que essas mudan¸cas requerem um esfor¸co significativo.

Como um ponto de partida Werbach e Hunter (2012) definiram uma lista sint´ etica com as mecˆ anicas que se destacam, e segundo os autores s˜ ao as mais importantes a se considerar para um sistema de gamifica¸c˜ ao. Deterding et al. (2011) e Stieglitz et al. (2017) definem gamifica¸c˜ ao como a utiliza¸c˜ ao de elementos de jogos, em um outro contexto que n˜ ao seja um jogo (o termo gamifica¸c˜ ao ´ e explorado em maiores detalhes na se¸c˜ ao 2.3).

Os elementos da lista ilustrada a seguir exemplificam alguns elementos de jogos que s˜ ao pass´ıveis de serem aplicados em outro contexto.

• Desafios (quebra-cabe¸cas ou outras tarefas que exigem esfor¸co para resolver)

• Chance (elementos de aleatoriedade)

• Competi¸c˜ ao (um jogador ou grupo ganha, e o outro perde)

• Coopera¸c˜ ao (os jogadores devem trabalhar juntos para alcan¸car um objetivo comum)

• Feedback (informa¸c˜ oes sobre como o jogador est´ a evoluindo)

• Aquisi¸c˜ ao de recursos (obten¸c˜ ao de itens ´ uteis ou colecion´ aveis)

• Recompensas (benef´ıcios para alguma a¸c˜ ao ou realiza¸c˜ ao)

• Transa¸c˜ oes (negocia¸c˜ ao entre jogadores, diretamente ou atrav´ es de intermedi´ arios)

• Turnos (participa¸c˜ ao sequencial por jogadores alternados)

• Estado de vit´ oria (objetivos que tornam um jogador ou grupo vencedor - Estado de empate ou perda s˜ ao conceitos relacionados)

A lista criada pelos autores possui dez t´ opicos elencados entretanto n˜ ao ´ e necess´ ario utilizar todos de uma vez em um processo de gamifica¸c˜ ao (KAPP; BLAIR; MESCH, 2012). Frequentemente essa escolha depende do objetivo da gamifica¸c˜ ao a ser alcan¸cado.

Por outro lado, os autores Adams e Dormans (2012) possuem uma defini¸c˜ ao mais

ampla sobre a mecˆ anica, e a definem como as regras, os processos e os dados que circulam

no jogo, al´ em de definir como a progress˜ ao do jogador acontece e quais condi¸c˜ oes determi- nam vit´ oria ou perda. Em outras palavras, as regras definem o que o jogador pode fazer e como o jogo ir´ a reagir.

2.2.3 Componentes

Por fim, os componentes s˜ ao a ´ ultima parte do todo que s˜ ao os elementos de jogos explorados neste trabalho. Da mesma forma que a dinˆ amica ´ e o modelo mais abstrato dos elementos, os componentes s˜ ao o oposto. Eles s˜ ao a parte mais concreta dos elementos de dinˆ amica e mecˆ anica (WERBACH; HUNTER, 2012).

A intera¸c˜ ao do usu´ ario ´ e feita atrav´ es dos componentes, para descrever o que ´ e poss´ıvel realizar dentro de um sistema gamificado ou um jogo. A lista a seguir ilustra os quinze componentes mais importantes que devem estar presentes em uma gamifica¸c˜ ao. Assim como a mecˆ anica, n˜ ao ´ e necess´ ario possuir todos os componentes ilustrados, isso depende do objetivo a ser alcan¸cado.

• Conquistas (objetivos definidos)

• Avatars (representa¸c˜ ao visual do personagem do jogador)

• Badges (representa¸c˜ ao visual das conquistas)

• Boss Fights (desafios especialmente dif´ıceis no ponto culminante de um n´ıvel)

• Cole¸c˜ oes (conjuntos de itens ou badges para acumular)

• Combate (uma batalha definida, geralmente de curta dura¸c˜ ao)

• Desbloqueio de conte´ udo (aspectos dispon´ıveis apenas quando os jogadores atingem os objetivos)

• Presentear (oportunidades de compartilhar recursos com outras pessoas)

• Leaderboards (exibi¸c˜ oes visuais da progress˜ ao e conquista do jogador)

• N´ıveis (etapas definidas na progress˜ ao do jogador)

• Pontos (representa¸c˜ oes num´ ericas da progress˜ ao do jogo)

• Miss˜ oes (desafios pr´ e-definidos com objetivos e recompensas)

• Gr´ aficos sociais (representa¸c˜ ao da rede social dos jogadores dentro do jogo)

• Times (grupos definidos de jogadores trabalhando juntos para um objetivo comum)

• Bens Virtuais (ativos de jogo com valor percebido ou em dinheiro real)

2.3 Gamifica¸ c˜ ao

Gamifica¸c˜ ao vem sendo aplicada em escala por diversos pesquisadores e professores na academia como uma alternativa ao m´ etodo tradicional de ensino, de forma a aumentar o engajamento dos alunos, como por exemplo se verifica nos trabalhos de Lima et al. (2012), G´ omez- ´ Alvarez, S´ anchez-Dams e Bar´ on-Salazar (2016) e Marques et al. (2015). Um con- junto mais completo de referˆ encias ´ e contemplado na revis˜ ao de literatura apresentada durante o desenvolvimento deste trabalho. De maneira geral o termo gamifica¸c˜ ao vem ga- nhando popularidade por pesquisadores em diferentes ´ areas (MATALLAOUI; HANNER;

ZARNEKOW, 2016).

Para seguir em frente com a proposta de se criar uma ferramenta gamificada, se faz necess´ ario a busca da defini¸c˜ ao do termo gamifica¸c˜ ao, pois esse termo pode ser interpretado de maneira equivocada por pessoas dentro e fora da academia.

Deterding et al. (2011) e Stieglitz et al. (2017) definem gamifica¸c˜ ao como a utiliza¸c˜ ao de elementos de jogo, em um outro contexto que n˜ ao seja um jogo. Como por exemplo a utiliza¸c˜ ao de um jogo de cartas em um contexto educacional para ensinar a hist´ oria da computa¸c˜ ao (SANTOS; FIGUEIREDO, 2017). Neste contexto as cartas s˜ ao o elemento do jogo e a hist´ oria da computa¸c˜ ao o assunto a ser ensinado.

J´ a Kapp, Blair e Mesch (2012) possuem uma defini¸c˜ ao mais abrangente, definem gamifica¸c˜ ao como a utiliza¸c˜ ao de mecˆ anica de jogo, est´ etica e pensamento de jogo para engajar pessoas, motivar a¸c˜ ao, promover educa¸c˜ ao e resolver problemas. Segundo os mesmos autores ´ e necess´ ario diferenciar o que ´ e um jogo, uma gamifica¸c˜ ao e uma simula¸c˜ ao para n˜ ao causar nenhuma confus˜ ao entre as defini¸c˜ oes.

Seguindo com essa linha, as caracter´ısticas de um jogo mencionadas pelos autores s˜ ao

ilustradas na lista a seguir:

• Existe um espa¸co de jogo definido em que os jogadores concordam em se envolver em atividades de jogo

• H´ a um in´ıcio, meio e fim claros para um jogo

• Existe um estado vencedor definido

• Os jogadores sabem quando eles completaram o jogo

• Um jogo normalmente tem v´ arios elementos de jogos

• Os jogos contˆ em desafios, um mecanismo para v´ arias tentativas, algum tipo de sistema de recompensas, um objetivo claro que os jogadores trabalham para alcan¸car e um objetivo final

A gamifica¸c˜ ao ´ e comumente confundida com a aplica¸c˜ ao de jogos, mas possui alguns t´ opicos chave que se diferenciam, como visto na lista a seguir. Na gamifica¸c˜ ao ´ e poss´ıvel utilizar apenas um elemento de jogo (mas n˜ ao ´ e restrito a), como por exemplo as badges para engajar a uma pessoa a alcan¸car um objetivo, enquanto em um jogo ´ e comumente utilizado mais de um (KAPP; BLAIR; MESCH, 2012).

• A inten¸c˜ ao n˜ ao ´ e criar uma unidade independente

• E poss´ıvel usar apenas um elemento do jogo para engajar ´

• A inten¸c˜ ao ´ e usar elementos de jogos para incentivar a se envolverem com o conte´ udo e progredirem em dire¸c˜ ao a um objetivo

Por fim, a simula¸c˜ ao ´ e a que apresenta um maior grau de diferen¸cas entre jogos e gamifica¸c˜ ao, cujo aspectos s˜ ao (KAPP; BLAIR; MESCH, 2012):

• Um ambiente real´ıstico

• Os jogadores podem praticar comportamentos e experimentar os impactos de suas decis˜ oes

A simula¸c˜ ao tem o objetivo prim´ ario de fornecer um ambiente real´ıstico para facilitar

o aprendizado. Como um exemplo, simula¸c˜ ao ´ e um meio utilizado por empresas a´ eras para

diminuir o custo e principalmente para treinar pilotos com pouca experiˆ encia, diminuindo assim a taxa de acidentes e erro de procedimento ao comandar uma aeronave

. Para esse fim o conjunto de software e hardware precisa simular fielmente o que o piloto ir´ a passar no mundo real.

A Tabela 1 resume as diferen¸cas de cada tipo de abordagem baseado na defini¸c˜ ao dos autores Kapp, Blair e Mesch (2012), levando em considera¸c˜ ao os pontos que destacam-se entre Jogo, Gamifica¸c˜ ao e Simula¸c˜ ao.

JOGO GAMIFICAC ¸ ˜ AO SIMULAC ¸ ˜ AO

H´ a um in´ıcio, meio e fim cla- ros para um jogo.

A inten¸c˜ ao ´ e usar elementos de jogos para incentivar a se envolverem com o conte´ udo e progredirem em dire¸c˜ ao a um objetivo.

Um ambiente real´ıstico.

Existe um estado vencedor definido.

Os jogadores podem prati- car comportamentos e ex- perimentar os impactos de suas decis˜ oes.

Os jogadores sabem quando eles ou algu´ em completou o jogo.

Um jogo normalmente tem v´ arios elementos de jogos.

E poss´ıvel usar apenas um ´ elemento do jogo para enga- jar.

Tabela 1: Diferen¸cas entre Jogo, Gamifica¸c˜ ao e Simula¸c˜ ao. Fonte: (KAPP; BLAIR;

MESCH, 2012).

Por outro lado, Werbach e Hunter (2012) identificaram trˆ es tipos de gamifica¸c˜ ao, a interna, a externa e a comportamental e cada uma com um objetivo diferente que visam o mundo corporativo, mas n˜ ao s˜ ao exclusivos ao mesmo.

• Gamifica¸c˜ ao interna: Existem dois atributos distintivos da gamifica¸c˜ ao interna. Os

1

http://www2.fab.mil.br/musal/index.php/projeto-av-hist/62-projeto-av-hist/470-os-primordios-dos-

simuladores-de-voo

jogadores j´ a fazem parte de uma comunidade definida e a segunda ´ e a dinˆ amica motivacional (a motiva¸c˜ ao para jogar)

• Gamifica¸c˜ ao externa: A externa est´ a relacionada com os clientes e o objetivo de alcan¸car uma taxa maior de lucro.

• Mudan¸ca de comportamento: Tem o objetivo de mudar o comportamento de uma popula¸c˜ ao. Como por exemplo melhorar a qualidade de vida ou construir sistemas que ajudem a situa¸c˜ ao financeira das pessoas

Os autores fornecem uma imagem (Figura 6) que ilustra os trˆ es tipos de gamifica¸c˜ ao identificados e como eles est˜ ao relacionados. Da mesma maneira que os termos definidos foram inspirados pelos neg´ ocios, na imagem ´ e poss´ıvel identificar a utiliza¸c˜ ao da palavra communities (comunidades) que pode ser aplicada a outros objetivos que n˜ ao seja uma empresa.

Figura 6: Tipos de gamifica¸c˜ ao e sua aplica¸c˜ ao. Fonte: (WERBACH; HUNTER, 2012).

Alem de definir o que ´ e gamifica¸c˜ ao, ´ e necess´ ario tamb´ em deixar claro o que n˜ ao ´ e

gamifica¸c˜ ao. Werbach e Hunter (2012) ressaltam que ´ e preciso ter em mente que gami-

fica¸c˜ ao n˜ ao tem como objetivo final construir um jogo utilizando todos os elementos de

jogos existente, ou que o resultado final ser´ a um jogo de entretenimento com v´ arios efeitos

de anima¸c˜ ao ou a utiliza¸c˜ ao de motores de jogos complexos que fazem c´ alculos de f´ısica.

Seguindo esse mesmo racioc´ınio, Kapp, Blair e Mesch (2012) ressaltam os motivos errados para se escolher gamifica¸c˜ ao. Dentre eles est˜ ao:

• Jogos s˜ ao legais/divertidos

• Todo mundo est´ a usando gamifica¸c˜ ao

• Todo mundo ama jogos

• E f´ ´ acil de se criar um jogo

Explorando as pesquisas realizadas com gamifica¸c˜ ao (cap´ıtulo 4), cria-se a hip´ otese que o item da lista “Todo mundo ama jogos” pode n˜ ao ter a veracidade esperada, reafirmando assim a opini˜ ao dos autores de que esse n˜ ao ´ e o motivo adequado para utilizar gamifica¸c˜ ao.

O trabalho de Brum e Cruz (2017) por exemplo mostram dados que nem toda es- trat´ egia de gamifica¸c˜ ao atinge cem por cento da percep¸c˜ ao de aprendizagem dos alunos, alguns inclusive alegam que o m´ etodo de se utilizar gamifica¸c˜ ao n˜ ao altera sua percep¸c˜ ao de aprendizagem, e por outro lado alguns necessitam um paralelo do jogo para o mundo real (SILVA et al., 2012a).

No t´ opico “´ E f´ acil de se criar um jogo” ´ e outro argumento que ´ e preciso ser explorado com maior detalhe. A cria¸c˜ ao de um jogo em si pode envolver partes da engenharia de software “cl´ assica” que se contempla diferentes ´ areas, como por exemplo a an´ alise de requisitos, planejamento, design, arquitetura, desenvolvimento, testes entre outros aspectos que s˜ ao mais detalhados por Pressman (2014) e Sommerville (2017). E tamb´ em se faz necess´ ario adicionar alguns campos para que se tenha um jogo completo, como por exemplo gerenciamento de ´ audio, utiliza¸c˜ ao de f´ısica e c´ alculos matem´ aticos, artistas entre outros (ROGERS, 2014). Agregando assim mais complexidade ao desenvolvimento de um jogo o que torna essa tarefa algo n˜ ao trivial de se produzir (BOGOST, 2011).

A literatura nos mostra com dados que a gamifica¸c˜ ao pode ser efetiva (WERBACH;

HUNTER, 2012), em especial no que diz respeito aos aspectos motivacionais. No mundo

corporativo, empresas como Nike, American Express e Microsoft, por exemplo, obtiveram

resultados positivos incluindo gamifica¸c˜ ao em seus neg´ ocios. Al´ em disso, h´ a resultados

encontrados na revis˜ ao da literatura apresentada neste trabalho que nos mostram resul-

tados positivos no ˆ ambito acadˆ emico, indicando que alunos possuem uma percep¸c˜ ao de aprendizagem maior do que com as estrat´ egias tradicionais de ensino.

2.3.1 Como e quando utilizar gamifica¸ c˜ ao

A ideia central do trabalho ´ e a proposta de uma ferramenta gamificada para auxiliar o ensino de testes unit´ arios para alunos da gradua¸c˜ ao. Por´ em existem outras alternativas para atingir esse objetivo, como por exemplo a utiliza¸c˜ ao de simula¸c˜ ao ou a de um jogo completo.

O primeiro passo para saber quando utilizar gamifica¸c˜ ao, ´ e identificar se o objetivo a ser alcan¸cado ´ e de fato um candidato adequado para a gamifica¸c˜ ao.

A utiliza¸c˜ ao da gamifica¸c˜ ao parece uma escolha razo´ avel uma vez analisada a literatura (se¸c˜ ao 4) com diversos trabalhos que a aplicam para aumentar o engajamento dos alunos e mostram resultados, em geral, positivos.

Para confirmar essa primeira hip´ otese, a Tabela 2 criada por Kapp, Blair e Mesch

(2012) ser´ a utilizada. Esta tem o objetivo de auxiliar a escolha entre jogo, gamifica¸c˜ ao

ou simula¸c˜ ao atrav´ es do objetivo a ser alcan¸cado. A coluna do lado esquerdo ilustra o

objetivo a ser alcan¸cado, e a coluna do lado direito sugere o candidato mais adequado

(jogo, gamifica¸c˜ ao ou simula¸c˜ ao).

Objetivo a ser alcan¸ cado Estrat´ egia a ser adotada

Construir habilidade de lideran¸ca Simula¸c˜ ao Realisticamente preparar alunos para um estado futuro Simula¸c˜ ao Proporcionar uma experiˆ encia realista para os alunos no final

de um curr´ıculo

Simula¸c˜ ao

Teste os alunos? desempenho de procedimentos espec´ıficos num formato realista

Simula¸c˜ ao

Treinar os alunos no desempenho de procedimentos espec´ıficos em um formato realista

Simula¸c˜ ao

Proporcionar um ambiente seguro e realista para os alunos praticarem habilidades e cometerem erros

Simula¸c˜ ao

Ensinar habilidades psicomotoras a um aluno Jogo, Simula¸c˜ ao Impactar as atitudes, cren¸cas ou valores de um aluno Jogo (Fantasia, Es-

trat´ egia, Suporte, Role playing, Combi- nar, Explorar)

Testar os alunos? conhecimento de fatos, conceitos e termos Jogo (Teste, Combi- nar, Puzzle, Explorar) Ensinar os alunos a juntarem elementos para formar um todo

coerente ou funcional ou reorganizar elementos num novo padr˜ ao ou sequˆ encia

Construir seu pr´ oprio jogo, Jogo (Cons- tru¸c˜ ao)

Ensinar os alunos como dividir o material em partes consti- tuintes, determinando como as partes se relacionam umas com as outras e com uma estrutura ou prop´ osito geral atrav´ es da diferencia¸c˜ ao, organiza¸c˜ ao e atribui¸c˜ ao

Jogo (Alocar recursos)

Ensinar os alunos a executar ou usar um procedimento atrav´ es da execu¸c˜ ao ou implementa¸c˜ ao

Jogo (Role playing), Simula¸c˜ ao

Ensinar os alunos a construir um significado a partir de mensagens orais, escritas e gr´ aficas, interpretando, exemplifi- cando, classificando, resumindo, inferindo, comparando e ex- plicando

Jogo (Puzzle, Explo- rar)

Ensinar os alunos a recuperar, reconhecer e recuperar conhe- cimentos relevantes da mem´ oria de longo prazo

Jogo (Combinar, Co- letar)

Fazer julgamentos com base em crit´ erios e padr˜ oes atrav´ es da verifica¸c˜ ao e cr´ıtica

Jogo (Estrat´ egia)

Evitar no¸c˜ oes preconcebidas sobre um estado futuro enquanto prepara os alunos para esse estado futuro

Jogo (Fantasia)

Ensinar os alunos a generalizar o conhecimento que j´ a pos- suem para novas situa¸c˜ oes

Jogo (Fantasia)

Motivar os alunos a percorrerem um curr´ıculo Structural Gamifica- tion

Motivar os alunos por meio de conte´ udo atraente Gamifica¸c˜ ao Incentivar os alunos a retornarem regularmente a um curr´ıculo Gamifica¸c˜ ao

Influenciar o comportamento do aluno dentro de um curso Gamifica¸c˜ ao, Jogo (Fantasia)

Impulsionar os alunos a inovar Gamifica¸c˜ ao

Incentivar os alunos a construir habilidades ou adquirir co- nhecimento de forma independente

Gamifica¸c˜ ao

Ensinar aos alunos novos conte´ udos Gamifica¸c˜ ao

Tabela 2: Decis˜ ao de qual elemento utilizar. Fonte: Kapp, Blair e Mesch (2012).

O termo Combinar, utilizado na Tabela 2 ´ e uma tradu¸c˜ ao do termo matching. Segundo Kapp, Blair e Mesch (2012) o termo refere-se a jogos que o jogador deve combinar um certo tipo de item no jogo com outro. Essa mesma mecˆ anica ´ e utilizada no jogo da mem´ oria, o jogador deve virar uma carta e combina-la com a sua correspondente.

Segundo os mesmos autores o termo Coletar possui objetivo de coletar o maior n´ umero de objetos de um determinado tipo no jogo, a mesma mecˆ anica ´ e utilizada no jogo Pacman.

Por fim, Alocar Recursos ´ e o t´ opico onde o equil´ıbrio ´ e a chave para o sucesso. Em

SimCity o jogador precisa balancear as diferentes vari´ aveis no jogo para ter sucesso. O jogador deve balancear a necessidade de construir infraestrutura b´ asica com a necessidade de ter educa¸c˜ ao, sa´ ude, parques e lazer (KAPP; BLAIR; MESCH, 2012).

2.4 Considera¸ c˜ oes parciais

Ao longo deste cap´ıtulo foi explorado o universo dos serious game e gamifica¸c˜ ao, esses dois t´ opicos que, na vis˜ ao de leigos frequentemente s˜ ao interpretados como o mesmo assunto. Por´ em as duas abordagens possuem divergˆ encias e s˜ ao utilizadas para diferentes objetivos. As duas abordagens s˜ ao utilizadas dentro e fora do mundo acadˆ emico de acordo com a literatura apresentada neste cap´ıtulo.

Por um lado existem os serious games s˜ ao jogos criados com foco al´ em do puro entre- tenimento, por outro lado a gamifica¸c˜ ao que utiliza elementos de jogos em um contexto que n˜ ao ´ e um jogo.

Al´ em da distin¸c˜ ao dos dois termos, uma se¸c˜ ao foi dedicada exclusivamente a ex- plora¸c˜ ao dos elementos de jogos que s˜ ao utilizados nas estrat´ egias de gamifica¸c˜ ao, que ´ e a proposta deste trabalho.

O pr´ oximo cap´ıtulo define o teste de software, os tipos de testes existentes na litera-

tura, explora em detalhes o teste unit´ ario e a metodologia de desenvolvimento guiado por

testes.

3 TESTE DE SOFTWARE

3.1 Aspectos conceituais

A tarefa de testar software ´ e a parte em que times de desenvolvimento devem se dedicar exclusivamente, utilizando ferramentas apropriadas para controle de defeitos no software e garantir o funcionamento correto do requisito. Por´ em n˜ ao ´ e o que constatamos na literatura, apesar do tema ser abordado por diversos autores (PRESSMAN, 2014) (SOMMERVILLE, 2017).

A defini¸c˜ ao de teste de software segundo Sommerville (2017) ´ e a tarefa de mostrar que um software faz o que ele se prop˜ oe a fazer, e al´ em disso, descobrir seus defeitos antes de colocar o software em uso. Ainda segundo o mesmo autor, podemos dividir o objetivo de testar um software em duas partes:

• 1) Demonstrar para o cliente e para o desenvolvedor que o software possui os reque- rimentos especificados

• 2) Expor algum comportamento indesejado

Atrav´ es dessas duas defini¸c˜ oes temos uma vis˜ ao geral do que encontramos no processo do teste de software. O primeiro t´ opico visa demonstrar para o cliente que aquilo que est´ a sendo constru´ıdo ´ e exatamente o que foi especificado anteriormente. O cliente neste sentido n˜ ao precisa ser necessariamente uma pessoa, pois se torna frequentemente uma entidade, como por exemplo uma empresa.

J´ a o segundo t´ opico possui um objetivo contr´ ario, expor um comportamento inde- sej´ avel e at´ e poss´ıveis falhas dado um determinado conjunto de dados. Comportamento esse que deve ser tamb´ em expl´ıcito nas especifica¸c˜ oes do software, mesmo que ele seja indesej´ avel.

3.1.1 Verifica¸ c˜ ao e Valida¸ c˜ ao

A tarefa de verifica¸c˜ ao e valida¸c˜ ao ´ e uma vis˜ ao um pouco mais abrangente do teste

de software, mas que tem rela¸c˜ ao direta com o t´ opico 1 da se¸c˜ ao anterior.

Verifica¸c˜ ao se refere a tarefa que garante que o software implementa corretamente as especifica¸c˜ oes. Valida¸c˜ ao se refere a diferentes tarefas que garantem que o software constru´ıdo est´ a de acordo com as necessidade do cliente (os requisitos) (PRESSMAN, 2014) (SOMMERVILLE, 2017).

Segundo Sommerville (2017) e Pressman (2014), se faz necess´ ario ter os comporta- mentos esperados e os n˜ ao esperados na documenta¸c˜ ao do sistema em quest˜ ao, por´ em, a literatura mostra que al´ em dos testes, requisitos de software sofre por ser um assunto que requer uma abstra¸c˜ ao de sistema por parte de quem a exerce, o que pode ser custoso para quem n˜ ao possui experiˆ encia pr´ evia (SILVA et al., 2012b).

Isso deixa uma lacuna n˜ ao apenas em um aspecto do ciclo de desenvolvimento de software, mas em dois: a de teste e a de requerimentos. O que leva a hip´ otese de que um est´ a diretamente conectado ao outro para a entrega de um software que atenda as expectativas do cliente.

Os requisitos ditam o que deve ser escrito pelo programador, quais s˜ ao os resultados e quais s˜ ao as expectativas esperadas pelo cliente. Em seguida a fase de testes utiliza essa informa¸c˜ ao para conferir o que foi desenvolvido, garantindo assim a veracidade de que o software est´ a fazendo o que ele se prop˜ oe a fazer. A precis˜ ao dos requisitos de software ´ e imprescind´ıvel para a cria¸c˜ ao e execu¸c˜ ao do teste, uma vez que o requisito esteja errado, o teste gerado para verificar tamb´ em estar´ a errado.

3.2 Aspectos conceituais: Teste unit´ ario

Antes de focar especificamente nas etapas do teste unit´ ario, se faz necess´ ario uma explana¸c˜ ao breve sobre os componentes de arquitetura existentes em um software no momento de escrita deste trabalho, pois esses componentes afetam diretamente o enten- dimento do ciclo TDD e por consequˆ encia a escrita do teste unit´ ario. O objetivo desta se¸c˜ ao ´ e dar um exemplo de uma arquitetura de um software web que possui teste unit´ ario.

Um software web, seja escrito na linguagem de programa¸c˜ ao PHP, Java, Python ou NodeJs, por exemplo, consiste geralmente de trˆ es componentes fundamentais:

• Servidor web

• Aplica¸c˜ ao (Framework na linguagem de programa¸c˜ ao escolhida)

• Banco de dados

O servidor web ´ e a primeira parte que interage com o usu´ ario, ao abrir o navegador e digitar um endere¸co qualquer na barra de pesquisa, um ciclo ´ e iniciado at´ e o usu´ ario obter a resposta. O navegador por si tenta identificar qual servidor ´ e respons´ avel pelo endere¸co digitado, e ao encontrar um, uma requisi¸c˜ ao ´ e enviada para o servidor para fazer o seu tratamento. Por fim, a aplica¸c˜ ao se encarrega de executar a l´ ogica necess´ aria para atender a requisi¸c˜ ao.

A aplica¸c˜ ao por sua vez ´ e a respons´ avel por interpretar os dados enviados pela re- quisi¸c˜ ao do servidor web, e executar as regras definidas pelos requisitos do software. ´ E na aplica¸c˜ ao que toda l´ ogica necess´ aria para atender os requisitos do software s˜ ao satisfeitos, assim como fazer a uni˜ ao de diferentes partes de um software como o servidor web e o banco de dados.

E nesta fase que o banco de dados ´ ´ e acionado, mas essa n˜ ao ´ e uma etapa obrigat´ oria, o acionamento s´ o ocorre se alguma informa¸c˜ ao que esteja no banco de dados seja necess´ aria.

A aplica¸c˜ ao faz acesso ao banco de dados e resgata essas informa¸c˜ oes para enviar ao usu´ ario. E com as informa¸c˜ oes, uma resposta ´ e despachada para o servidor web como resposta. Por sua vez o usu´ ario recebe em seu navegador a resposta de todo esse processo, conforme ´ e ilustrado na Figura 7.

Figura 7: Exemplo de arquitetura de web em 3 camadas. Fonte: Elaborada pelo autor.

2

https://developers.google.com/web/updates/2018/09/inside-browser-part2

O foco do teste unit´ ario est´ a somente na aplica¸c˜ ao, e abstrai qualquer elemento externo a isso, seja o banco de dados ou o servidor web. Para levar em conta testes que levam em considera¸c˜ ao todos os componentes da arquitetura ´ e utilizado outro tipo de teste, como o teste de aceita¸c˜ ao do usu´ ario e o teste funcional.

Figura 8: Foco do teste unit´ ario na arquitetura web 3 camadas. Fonte: Elaborada pelo autor.

A Figura 8 ilustra o foco do teste unit´ ario que se concentra somente na aplica¸c˜ ao, outros fatores n˜ ao s˜ ao levados em considera¸c˜ ao.

3.3 Teste unit´ ario

Teste unit´ ario ´ e o tipo de teste que ´ e criado e executado pelo programador no momento

em que ´ e escrito o c´ odigo do software, esse tipo de teste ´ e o oposto do teste de caixa preta

e caixa branca que frequentemente ´ e executado por um profissional dedicado a esta tarefa,

e que n˜ ao escreve o c´ odigo em quest˜ ao. Sommerville (2017) define teste unit´ ario como o

processo de testar diferentes componentes de um programa, como por exemplo m´ etodos

e classes.

3.4 TDD (Test Driven Development)

Teste unit´ ario (do inglˆ es Unit Test) se popularizou atrav´ es da metodologia TDD (em portuguˆ es: Desenvolvimento Guiado por Testes) onde o programador come¸ca a escrever o c´ odigo do teste antes do c´ odigo do software de fato (JANZEN, 2005). Segundo Beck (2010) TDD ´ e um pouco nebuloso, TDD ´ e uma consciˆ encia da lacuna entre decis˜ ao e feedback durante a programa¸c˜ ao.

Beck (2010) faz men¸c˜ ao ` a lacuna entre o feedback e a programa¸c˜ ao visando a difi- culdade dos programadores ao possuir uma resposta r´ apida no momento em que est˜ ao escrevendo o c´ odigo. Frequentemente o processo de escrita pelo programador segue trˆ es passos b´ asico: O primeiro ´ e a escrita do c´ odigo, o segundo o teste e o terceiro a refatora¸c˜ ao caso algo esteja errado ou exista a necessidade de mudan¸ca no c´ odigo.

Aqui cria-se a hip´ otese de que com a evolu¸c˜ ao das interfaces gr´ aficas e a evolu¸c˜ ao dos fluxos para a realiza¸c˜ ao de tarefas nos sistemas, o programador se vˆ e ` a frente de executar passos extras para chegar ao ponto em que seu c´ odigo possa ser testado, tardando assim o feedback se o c´ odigo est´ a funcionando conforme o esperado e impactando diretamente na entrega tardia das altera¸c˜ oes necess´ arias no software.

O mantra do TDD definido por Kent Beck segue trˆ es fases distintas:

• Vermelho - Escrever primeiramente o c´ odigo do teste, pensando em como o mesmo deve se comportar

• Verde - Fazer o teste passar com a menor altera¸c˜ ao poss´ıvel

• Azul - Refatorar, remover qualquer c´ odigo duplicado e fazer pequenas melhorias de

padr˜ oes

Figura 9: Ciclo de execu¸c˜ ao do TDD. Fonte: (BECK, 2010).

A primeira fase do TDD (vermelho) ´ e a primeira etapa a ser considerada pelo pro- gramado a ser feita quando est´ a se desenvolvendo com teste unit´ ario, para alguns resulta estranho o fato de escrever o c´ odigo de teste, antes do c´ odigo de “produ¸c˜ ao”.

C´ odigo de produ¸c˜ ao ´ e um termo utilizado para o c´ odigo que ir´ a efetivamente cons- truir o algoritmo desejado para realizar determinada tarefa. A barreira aqui est´ a na mudan¸ca de paradigma, que talvez para quem possua mais experiˆ encia em programa¸c˜ ao seja mais complexo. Pois com os anos de programa¸c˜ ao acumulado v´ıcios s˜ ao acumulados e desenvolvidos tornando a experiˆ encia da utiliza¸c˜ ao de um novo paradigma custosa.

Por outro lado anos de experiˆ encia podem ajudar o programador a fazer essa mudan¸ca, com a experiˆ encia vem o dom´ınio de uma linguagem de programa¸c˜ ao e por consequˆ encia a tarefa de escrever testes se torna menos complexa, pois o foco ser´ a a escrita do c´ odigo de teste, sem ser necess´ ario fazer consultas externas para sanar uma d´ uvida de sintaxe.

Em seguida entra a segunda etapa do ciclo, a escrita do c´ odigo de produ¸c˜ ao que fa¸ca o teste passar com a menor altera¸c˜ ao poss´ıvel. Se faz importante destacar: “a menor altera¸c˜ ao poss´ıvel”, pois esta etapa foca exclusivamente em ter o teste escrito pela etapa anterior passar. Essa etapa ´ e o que Beck (2010) define como baby step.

Baby step ´ e o ato de fazer uma altera¸c˜ ao pequena que atinja o objetivo assim como os passos de um bebˆ e, que s˜ ao curtos mas que faz o bebˆ e andar e atingir seu objetivo.

Particularmente a fase do bay step ´ e uma das t´ ecnicas mais valiosa utilizando TDD, alte-

rando a menor parte do c´ odigo necess´ aria para o teste passar fornece para o programador um momento de auto reflex˜ ao enquanto est´ a programando.

A experiˆ encia nesta etapa tamb´ em pode causar um efeito indesejado no ciclo, j´ a que programadores mais experientes tendem a utilizar uma abstra¸c˜ ao elevada. Mesmo sem a necessidade do mesmo. Esse comportamento ´ e denominado over engineering.

Finalmente a terceira e ´ ultima parte do ciclo ´ e a refatora¸c˜ ao. Refatorar ´ e o termo utilizado para descrever a atividade de alterar o c´ odigo existente de um sistema sem alterar seu comportamento externo, e fazendo melhorias para evitar erros (FOWLER et al., 1999). Apesar de ser uma t´ ecnica utilizada frequentemente por programadores, refatorar c´ odigo existente em sistemas que n˜ ao possuem testes automatizados se torna uma tarefa custosa e com o risco elevado. Pois fica invi´ avel garantir que a refatora¸c˜ ao feita n˜ ao produz efeitos colaterais em diferentes partes do sistema.

Nesse momento do ciclo devemos alterar, se necess´ ario, a estrutura do c´ odigo de produ¸c˜ ao para se adequar ao objetivo a ser alcan¸cado. Frequentemente ´ e essa a etapa que elementos fixos introduzidos no c´ odigo pela etapa anterior s˜ ao alterados para vari´ aveis.

3.5 Ensino de teste de software

Teste unit´ ario guia o programador a escrever seu c´ odigo em pequenas fun¸c˜ oes/m´ etodos para que seja poss´ıvel realizar o teste em pequenas unidades do software ao inv´ es do software como um todo. Entretanto, o interesse pelo t´ opico n˜ ao ´ e constante: analisando as buscas pelo termo, Google Trends mostra alguns picos de interesse na linha do tempo.

Teste unit´ ario n˜ ao possui a aten¸c˜ ao necess´ aria, mesmo utilizando um termo mais abrangente como “teste unit´ ario” na ferramenta de busca mais utilizada no Brasil e no mundo.

O pr´ oximo cap´ıtulo analisa o panorama do ensino de Testes de software no contexto

da educa¸c˜ ao em Computa¸c˜ ao.

Figura 10: Interesse do termo “teste unit´ ario” segundo Google Trends de 2013 ´ a 2018.

Fonte: Google.

4 REVIS ˜ AO BIBLIOGR ´ AFICA E T´ ECNICA

Nesse cap´ıtulo s˜ ao exibidos em detalhes os passos utilizados na revis˜ ao da literatura, assim como os congressos escolhidos e a faixa de tempo determinada para a pesquisa de trabalhos relacionados ao assunto deste trabalho.

4.1 Metodologia utilizada para a revis˜ ao

Uma revis˜ ao da literatura dos congressos WEI - Workshop sobre Educa¸c˜ ao em Com- puta¸c˜ ao, CLEI - Conferencia Latinoamericana de Inform´ atica, SIGSE - Special Interest Group on Computer Science Education no espa¸co de 5 anos (de 2013 at´ e 2017) foi con- duzida para entender o que foi publicado sobre o assunto e quais s˜ ao os espa¸cos que n˜ ao foram explorados. Ap´ os essa an´ alise manual, de consulta dos anais de cada congresso, os artigos foram divididos nas seguintes categorias: Teste e engenharia de software, Educa¸c˜ ao e engenharia de software, educa¸c˜ ao, Gamifica¸c˜ ao, Educa¸c˜ ao e gamifica¸c˜ ao. Essas catego- rias foram selecionados pois possuem uma conex˜ ao direta com o tema proposto por este trabalho.

A tabela a seguir mostra o total de artigos publicados (de 2013 at´ e 2017) de acordo

com as categorias aqui apresentadas, nota-se que a categoria Educa¸c˜ ao e gamifica¸c˜ ao no

congresso WEI e a categoria Teste e Engenharia de software no congresso CLEI s˜ ao as

mais populares.

Categoria CLEI WEI SIGSE Teste e engenharia de software 8 3 1 Educa¸c˜ ao e engenharia de software 3 8 0

educa¸c˜ ao 1 13 0

Gamifica¸c˜ ao 1 0 0

Educa¸c˜ ao e gamifica¸c˜ ao 4 25 0

Tabela 3: N´ umero de trabalhos relacionados por categoria e congresso

O trabalho presente est´ a situado entre duas categorias das apresentadas at´ e aqui, a Teste e engenharia de software e Educa¸c˜ ao e Gamifica¸c˜ ao. Na tabela apresentada e na literatura pode-se identificar uma lacuna em unificar essas duas ´ areas do conhecimento, de forma que os alunos ao utilizarem a ferramenta se sintam motivados a utilizar a pr´ atica de teste de software e em espec´ıfico testes unit´ arios.

4.2 Revis˜ ao de literatura: O ensino de teste de software

O ensino de teste de software nos cursos de gradua¸c˜ ao na ´ area de computa¸c˜ ao e inform´ atica possui uma carga hor´ aria menor se comparado a outros t´ opicos. Isso pode refletir no mercado de trabalho, uma vez que na pr´ atica times de desenvolvimento n˜ ao se dedicam como o esperado a fase de teste de um software (BENITTI; ALBANO, 2012) (MOREIRA; COUTINHO, 2012).

Benitti e Albano (2012) apresenta os curr´ıculos de referˆ encia nacionais, dentre eles CEEInf 1999, SBC 2003, SBC 2005 e internacionais IEEE 2004, ACM, AIS e IEEE 2006.

Dos curr´ıculos nacionais aqui apresentados, todos mencionam o assunto Teste de software como parte da disciplina de Engenharia de software ou como parte de outras disciplinas.

Ainda segundo os autores, n˜ ao existe um detalhamento sobre cada item que deve ser abordado neste assunto.

J´ a os curr´ıculos internacionais como o ACM, fazem a sugest˜ ao de teste de software ser uma mat´ eria exclusiva, mas deixam os t´ opicos a serem abordados a cargo da institui¸c˜ ao.

Para entender melhor o que as universidades oferecem a respeito de teste de software,

uma pesquisa feita pelos mesmos autores contou com a an´ alise de 9 institui¸c˜ oes que juntas

possuem 18 cursos na ´ area de inform´ atica. Foram encontradas 28 disciplinas que possuem teste de software em sua matriz curricular e deste montante, 11 possuem uma disciplina espec´ıfica para teste de software. As 17 restantes possuem teste de software como um subt´ opico de outra disciplina. Os autores chamam a aten¸c˜ ao para as 11 universidades que possuem teste de software como uma disciplina espec´ıfica e que esse n´ umero demonstra que as institui¸c˜ oes est˜ ao se preocupando em se aprofundar mais no que se desrespeito a teste de software, mas que ainda n˜ ao se atingiu o mesmo patamar que as defini¸c˜ oes internacionais possuem.

Moreira e Coutinho (2012) sugere ent˜ ao uma ferramenta para fomentar a importˆ ancia do teste de software e transformar a experiˆ encia do aluno no processo de aprendizagem do planejamento do teste. iTestLearning tem o objetivo de ensinar ao aluno o planejamento do teste a partir da especifica¸c˜ ao do projeto. Esse processo ´ e o que precede a execu¸c˜ ao do teste em si.

Moreira e Coutinho (2013) mostram que os resultados alcan¸cados pela ferramenta iTestLearning foram satisfat´ orios, onde foi notado um aumento consider´ avel nos itens Satisfa¸c˜ ao, Confian¸ca, Relevˆ ancia e Aten¸c˜ ao. O crit´ erio satisfa¸c˜ ao teve o resultado de 77,8%, O aspecto de confian¸ca obteve 94,4%, o aspecto relevˆ ancia obteve um total de 88,23% e o aspecto de aten¸c˜ ao obteve uma m´ edia de 64,8%.

J´ a os itens relacionados ` a Experiˆ encia do Usu´ ario (Competˆ encia, Divers˜ ao, Desafio, Intera¸c˜ ao Social e Imers˜ ao) obteve uma m´ edia abaixo do esperado, um total de 68,3%.

Os itens que conseguiram maior percentuais foram divers˜ ao, desafio e competˆ encia. E os que obtiveram menor valor foram: Intera¸c˜ ao social e imers˜ ao. Os autores atribuem esse percentual baixo ao jogo n˜ ao ter nenhuma intera¸c˜ ao com outros alunos e a falta de aspectos gr´ aficos que permita a imers˜ ao do aluno.

Por fim a ´ ultima forma de avalia¸c˜ ao realizada pelos alunos teve foco na aprendizagem, onde os autores ressaltam que a m´ edia foi de 70%. Nesta avalia¸c˜ ao entretanto os autores ressaltam a possibilidade de outras avalia¸c˜ oes para o item Contribui¸c˜ ao para a disciplina que obteve o percentual de 66,7%, abaixo do esperado.

A avalia¸c˜ ao foi aplicada em 18 alunos da disciplina de Introdu¸c˜ ao a engenharia de software da turma de Sistemas de Informa¸c˜ ao da Universidade Federal do Amazonas.

Al´ em disso aspectos te´ oricos sobre teste de software foram passados para os alunos, antes

de apresentar a ferramenta iTestLearning.

4.3 Revis˜ ao de literatura: Gamifica¸ c˜ ao e educa¸ c˜ ao

Embora a preocupa¸c˜ ao sobre o ensino de teste de software seja clara at´ e aqui, existe o lado dos alunos, no momento da aprendizagem. A preocupa¸c˜ ao ultrapassa as fronteiras da engenharia de software e chega at´ e a educa¸c˜ ao b´ asica, onde a preocupa¸c˜ ao dos professores

´ e de se adaptar ao aluno e ao seu momento tecnol´ ogico. Segundo (BRUM; CRUZ, 2017), os nativos digitais, s˜ ao aqueles que j´ a nasceram em meio ` as tecnologias digitais e que se diferenciam dos Imigrantes digitais que precisam se adaptar ` as mudan¸cas tecnol´ ogicas, e faz-se necess´ ario a mudan¸ca do conte´ udo passado para os alunos. Brum e Cruz (2017) defendem a utiliza¸c˜ ao da gamifica¸c˜ ao para reduzir essa diferen¸ca entre os nativos digitais (alunos) e os imigrantes (professores). Um experimento aplicado na mat´ eria de rob´ otica teve um resultado positivo mostrando que os alunos se mantiveram engajados, unidos, com maior dedica¸c˜ ao e maior comprometimentos nas tarefas aplicadas.

Para chegar a tal conclus˜ ao os autores aplicaram um formul´ ario anˆ onimo com quatro quest˜ oes, onde os alunos comparavam a mat´ eria sem a gamifica¸c˜ ao e ap´ os a utiliza¸c˜ ao do mesmo. No total 21 alunos responderam o question´ ario, e foi poss´ıvel constatar que 76,2%

acreditaram se dedicar mais na mat´ eria e 57,1% revisaram as tarefas antes de entreg´ a-las, 76,2% acreditaram ter aprendido mais durante esse per´ıodo. Um contraponto interessante nessa pesquisa ´ e que 19% dos alunos acreditam que n˜ ao houve interferˆ encia nenhuma em seu aprendizado e 4,5% declararam que n˜ ao foi uma experiˆ encia positiva (BRUM; CRUZ, 2017). Em trabalhos futuros ´ e poss´ıvel investigar qual o motivo que levou esses alunos a tal conclus˜ ao.

4.4 Revis˜ ao de literatura: Gamifica¸ c˜ ao no ensino de computa¸ c˜ ao

Nesta se¸c˜ ao trabalhos que est˜ ao utilizam gamifica¸c˜ ao no ensino de computa¸c˜ ao s˜ ao apresentados.

Mat´ erias oferecidas por universidades que fazem parte da engenharia de software

tamb´ em apresentam o impacto positivo na aprendizagem dos alunos ao utilizar gami-

fica¸c˜ ao. O ActGame, ´ e um jogo educacional que foi desenvolvido como uma alternativa