Avaliando a Viabilidade do BlackBox em Sala de Aula: Um Jogo Sério para Ensino de Teste Funcional de Software

Avaliando a Viabilidade do BlackBox em Sala de Aula: Um

Jogo Sério para Ensino de Teste Funcional de Software

Nayara Ribeiro1_{, Rosiane Vasconcelos}1_{, Davi Viana}2 _{e Luis Rivero}1, 3

1_{Centro Universitário do Norte – UNINORTE}

Manaus – AM – Brasil

2_{Programa de Pós-Graduação em Ciência da Computação – PPGCC}

Universidade Federal do Maranhão – UFMA São Luís – MA – Brasil

3_{Universidade Federal do Amazonas – UFAM}

Manaus – AM – Brasil

ribeiro.nayara@yahoo.com.br, rosyannev@gmail.com, luisrivero@ufam.com.br, davi.viana@lsdi.ufma.br

Abstract. Concepts about functional testing techniques (which evaluate the outputs of the software with regards to their inputs) are addressed in computer courses to evaluate the quality of the developed software. Despite the existence of educational games for teaching software testing, few specifically consider concepts related to functional testing, or have few phases to play. Considering the difficulties of using the existing games, this paper presents the BlackBox game for the teaching functional testing. When evaluating the game with 39 students, it presented a positive use experience. In addition, clues were identified about associating concepts with the game missions and improvement opportunities.

Resumo. Conceitos sobre técnicas de teste funcional (que avaliam as saídas do software com relação às suas entradas) são abordados em cursos de computação para avaliar a qualidade do software desenvolvido. Apesar da existência de jogos educacionais para o ensino de teste de software, poucos consideram conceitos sobre teste funcional de forma específica, ou possuem poucas fases. Considerando as dificuldades de utilização dos jogos existentes, neste artigo é apresentado o jogo BlackBox para o ensino de teste funcional. Ao avaliar o jogo com 39 alunos, o mesmo apresentou uma experiência de uso positiva. Além disso, foram identificados indícios sobre a associação dos conceitos com as missões do jogo e oportunidades de melhoria.

1. Introdução

O teste de software é uma das atividades aplicadas durante o ciclo de desenvolvimento de um sistema que tem como objetivo encontrar os defeitos presentes nele [Silva et. al., 2016]. Os custos das atividades de produção de um sistema de software estão fortemente ligados às atividades de teste, daí vê-se a importância de ter bons métodos de ensino para estas atividades [Oliveira, 2013]. A não identificação e correção de uma falha em um sistema de software traz prejuízos financeiros às empresas. Além disso, pode afetar a confiabilidade dos clientes que, após sofrerem a frustração de utilizarem

um sistema com falhas, optarão por empresas que se mostrem de maior confiança [Oliveira, 2013].

Para muitos profissionais de computação, o primeiro contato com o teste de software é em ambiente educacional onde o ensino-aprendizagem em geral é por meio tradicional através das aulas expositivas centradas no professor [Paludo e Raabe, 2010]. Uma alternativa que auxilia na ausência da prática com métodos tradicionais de ensino é o uso de jogos educacionais. Estes jogos, além de apresentarem um potencial de aprendizagem ligado à motivação intrínseca da atividade lúdica, permitem que se crie um ambiente controlado, abordando especificamente as habilidades que se buscam desenvolver nos alunos [Pietruchinski et al. 2011]. Desta forma, os jogos permitem o engajamento do estudante, reforçam e aprofundam os conceitos na prática [Thiry et al. 2006]. O uso de jogos nas atividades de ensino vem sendo discutido na literatura. Pietruchinski et al. (2011) apontam que diversos jogos foram desenvolvidos com o objetivo de auxiliar no ensino de determinados conteúdos de informática na educação, engenharia de software e outras subáreas dentro da computação. Atualmente na subárea de teste de software existem jogos como Bug Hunt, gTest Learning e o Utest que abordam conceitos sobre testes em geral. Porém, dentro os jogos listados, apenas o Utest está disponível para uso e possui apenas um cenário para a prática, o que comprova a carência de recursos que possam contribuir com a aprendizagem dos alunos referente à técnica de teste funcional.

Diante do exposto acima, desenvolveu-se o BlackBox, um jogo sério que visa auxiliar o ensino de teste funcional através de uma história com cenários lúdicos de modo a motivar o aluno durante o processo de aprendizagem. Para obter indícios da eficácia de uso do jogo em um ambiente acadêmico e a opinião dos usuários sobre seu uso, foi executado um estudo de viabilidade aplicando as técnicas MEEGA e CEQ com alunos do curso de Ciência da Computação. Este artigo apresenta os resultados obtidos da avaliação inicial do jogo e oportunidades de melhoria identificadas.

O restante deste artigo está organizado como segue: As Seções 2 e 3 apresentam conceitos sobre teste e trabalhos relacionados, respectivamente. Na Seção 4 é descrito o jogo BlackBox e a seu desenvolvimento. Já a Seção 5 apresenta a avaliação do ponto de vista do aluno. Finalmente, a Seção 6 apresenta as considerações finais deste trabalho.

2. Fundamentação Teórica

Dentre as técnicas que podem ser utilizadas para testar um software, podem ser citadas [Neto, 2013]: (a) Teste Estrutural ou Caixa Branca que trabalha diretamente com o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos; e (b) Teste Funcional ou Caixa Preta, que é realizado focando no lado externo do software ou na interface. No teste funcional são fornecidas entradas e se visualizam as respostas produzidas pelo software. Desta forma, os detalhes de implementação não são investigados, somente as funções do sistema são relevantes. As técnicas de Teste de Caixa Preta são divididas em [Neto, 2013]:

 Classes de Equivalência: tem por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste de cada classe, pois em princípio todos os elementos dessa mesma classe devem se comportar de maneira

equivalente. Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados ou uma condição lógica;

 Análise do Valor Limite: devido ao grande número de erros que ocorrerem nos extremos da distribuição de valores do domínio de entrada e não no meio, a análise de valor limite explora os limites dos valores de cada classe de equivalência para preparar os casos de teste;

 Grafo de Causa e Efeito: Este critério testa e verifica o efeito combinado de dados de entrada. As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma tabela de decisão e, a partir desta, são derivados os casos de teste e suas saídas.

3. Trabalhos Relacionados

Segundo Savi et al. (2011), um dos grandes desafios enfrentados no ensino de computação é a necessidade de uso de métodos que permitam tornar o processo de ensino mais efetivo. A forma tradicional de ensino excessivamente centrada no professor, faz com que falte ao aluno a oportunidade de aplicar os conceitos na prática. Nesse contexto, existe uma categoria de jogos destinados explicitamente para a aprendizagem que vem sendo comumente chamada de jogo sério. O diferencial dessa categoria reside no fato do jogo ser projetado com o objetivo da aprendizagem sobre determinados conceitos, informações ou habilidades [Silva et al., 2016].

Dentre os jogos sérios encontrados referentes ao ensino de teste funcional podem ser citados: (a) Bug Hunt, (b) gTest Learning e (c) Utest. O Bug Hunt é um tutorial contendo um conjunto de orientações que são fornecidas ao aluno, onde o mesmo busca progredir através de uma série de lições, aplicando várias estratégias de teste para encontrar falhas no programa. Cada lição constitui um objeto de aprendizagem, um conjunto particular de objetivos, um desafio único e um elemento distinto para incentivar a exploração de diferentes estratégias de descobertas de falhas. Cada estudante trabalha em lições individuais onde o progresso é medido pelo número de falhas detectadas pelo conjunto de testes do aluno e como o aluno as realiza em relação aos outros colegas participantes. Uma vez concluído o tutorial, o estudante recebe um resumo geral do desempenho [Elbaum et al, 2007].

O gTest Learning é um jogo single-player onde o jogador é desafiado a derrotar inimigos através de pequenos questionários. O nível de dificuldade é balanceado através dos inimigos, sendo quatro inimigos por fase. O diálogo sempre acontece antes das perguntas serem feitas pelos inimigos. Logo após finalizar o diálogo, são feitas as perguntas ao jogador. Existem itens a serem coletados que dão dicas para o jogador sobre as perguntas do estágio. No final do jogo, é exibido o ranking [Silva et al., 2016].

Finalmente, o Utest é um jogo de simulação para apoio ao ensino do teste de software, com foco específico em teste de unidade, abordando questões teóricas e práticas. O cenário do jogo é um jornal com anuncio de vaga de emprego. O jogador inicia respondendo perguntas referentes a teste de software em formato de entrevista de trabalho. Após responder grande parte das perguntas com êxito, o jogador está apto para ser contratado e então se inicia o desafio onde se tem que encontrar os dados de entrada, classes de equivalências e valor limites no cenário proposto. O jogo permite ao jogador

assumir o papel de um testador responsável por escrever teste de unidade para funções já escritas de um sistema hipotético. Como resultado ao seu desempenho o jogador é apresentando através da pontuação obtida no decorrer do jogo [Silva et al., 2016].

A Tabela 1 apresenta as características dos jogos apresentados. Dentre estes, apenas o Utest possui um enredo voltado para teste funcional e está disponível para uso, porém apresenta apenas um único cenário, tornando-se pouco para que os alunos possam praticar as técnicas de teste funcional. Tendo em vista estes problemas, foi proposto o BlackBox que será descrito na próxima seção.

Tabela 1. Características em jogos sérios para ensino de teste funcional

Jogo Diferentes _Cenários Contexto _{Lúdico Funcional} Teste Disponibilidade

Bug Hunt X

gTest Learning X X

Utest X X X

BlackBox X X X X

4. BlackBox

O BlackBox é um jogo individual para desktop onde são solucionadas missões usando conhecimentos de teste funcional. A história do jogo se passa em uma agência de espionagem do governo que busca recrutar um espião de sistemas. Porém, a agência na verdade é uma organização criminosa comandada por bandidos invasores de sistemas que usam o jogador para seus fins maléficos. O jogador deve então usar seus conhecimentos para impedir que os vilões alcancem seus objetivos. Durante as duas primeiras missões, o bandido se passa por uma recrutadora misteriosa; e na terceira missão, ele se revela, informando qual é seu plano para dominar o mundo.

Para desenvolver o jogo, foi considerado o trabalho de An et al. (2013) que propõe um conjunto de requisitos de usabilidade e pedagógicos que devem ser implementados por jogos educacionais. Estes requisitos (por exemplo: usar linguagem adequada, ter uma interface atraente, apresentar o tema de forma lúdica, variar o grau de dificuldade, fornecer incentivos para continuar o jogo, etc.) foram usados pela equipe de desenvolvimento para guiar a criação do jogo aliado à história descrita acima.

A Figura 1 representa as três telas do jogo onde ocorre a história citada acima. A Figura 1-A, mostra a tela inicial após a escolha do avatar onde ocorre a recepção do jogador com o bandido disfarçado. Na Figura 1-B mostra o momento em que o jogador recebe um comunicado que está trabalhando para uma falsa agência, acabando com a farsa dos bandidos. Por fim, na Figura 1-C se inicia a revelação do bandido ao jogador. O jogo tem três missões (cenários) os quais são apresentados de forma evolutiva, ou seja, para conhecer a próxima missão é necessário concluir a atual.

Ao acessar uma missão, o jogador recebe algumas informações sobre seu objetivo, conforme representado na Figura 2-A. Por exemplo, o Elemento 1 mostra a descrição dos dados da missão de onde o jogador deverá extrair as informações necessárias para descobrir a solução correta. O Elemento 2 indica as informações relacionadas com o contexto de teste funcional (Classes de Equivalências, Valores Limites, Casos de Teste). Finalmente, no Elemento 3 é apresentado o problema que o jogador deve resolver. Por exemplo, na Figura 2-A o jogador deve identificar quais são as saídas dos casos de teste e selecioná-las de acordo com as suas respectivas entradas. Ao solucionar uma missão do jogo (Figura 2-A), o jogador é direcionado para outra tela

representada pela Figura 2-B. Nesta tela, o Elemento 4 apresenta um questionamento relacionando as informações sobre a fase do teste com o objetivo da missão, onde o jogador deverá escolher a alternativa correta que lhe fará ter sucesso na missão. Vale ressaltar, que o jogador pode escolher um avatar para representa-lo no início do jogo (sendo ele menino ou menina). Este avatar acompanha o enredo do jogo e suas fases como apresentado no Elemento 5 da Figura 2.

Figura 1. (A) Tela de recepção ao jogador após a escolha do avatar. (B) Tela onde o jogador recebe um comunicado que está sendo enganado. (C) Tela onde o bandido se releva ao jogador divulgando seu plano maligno.

Figura 2. (A) Tela da primeira missão do jogo. (B) Seleção de resposta para avançar no jogo.

Dependendo do seu desempenho em cada missão, o jogador pode visualizar mensagens de sucesso ou fracasso. Na tela de sucesso, ou seja, se o jogador conseguir identificar a seleção correta, é apresentada uma animação com a seguinte mensagem: “Missão Completa”. Por outro lado, se o jogador errar, o jogo apresenta animações com as seguintes mensagens: “Missão Falhou”, “Reprovado/Reprovada”, “Demitido/Demitida” ou “Game Over”. Apenas a primeira missão permite que o jogador avance para a segunda missão mesmo errando a escolha de seleção. Isto foi pensado para encorajar o aluno a continuar jogando. Nas demais missões, caso o jogador erre, terá mais duas tentativas para responder corretamente, caso contrário, o jogo é encerrado apresentando algumas das mensagens de fracasso citadas acima e o aluno é convidado a jogar novamente. Finalmente, quando o aluno consegue finalizar todas as missões ele é levado a tela final do jogo com uma animação de honra ao mérito como reconhecimento pelo seu bom trabalho.

5. Avaliação do BlackBox

5.1. Planejamento e Execução

Para avaliar a viabilidade de uso do BlackBox em sala de aula, o mesmo foi utilizado em uma turma com 39 alunos cursando a disciplina Programação Avançada de Sistemas no 7º período do curso de Ciência da Computação do Centro Universitário do Norte (UNINORTE) que possuíam conhecimento introdutórios (leitura de livros, participação de seminários e realização de exercícios de fixação) sobre técnicas de teste de software. Na disciplina devia ser desenvolvida uma aplicação móvel e, para este fim, eram aplicados conceitos sobre análise e projeto de software, programação orientada a objetos e teste de software para garantia da qualidade. O jogo BlackBox foi aplicado como meio de reforçar os conteúdos da disciplina ministrada em relação ao teste funcional de software, e formas de identificar defeitos em um programa.

Para esta avaliação foi elaborado um questionário que contou com duas partes: (1) avaliação de aspectos educacionais, experiência do usuário e engajamento; e (b) percepção dos alunos sobre o jogo e o aprendizado. Na primeira parte, utilizou-se o Modelo de Avaliação de Jogos Educacionais - MEEGA [Savi et al., 2011] com objetivo de avaliar a motivação e experiência do usuário na utilização do jogo. Este modelo fornece um questionário para avaliar a motivação de uso de jogos educacionais através dos seguintes aspectos: a) Atenção; b) Relevância; c) Confiança; d) Satisfação. Além disso, o MEEGA permite avaliar a experiência do usuário em termos de: e) Imersão; f) Desafio; g) Divertimento; h) Competência. Para complementar a avaliação pelo modelo MEEGA, o GEQ - Game Engagement Questionnaire [Brockmyer et al., 2009] foi empregado para avaliar o sentimento do aluno ao utilizar o jogo, medindo os aspectos: a) Absorção (alteração do estado de consciência); b) Fluxo (sentimento de diversão); c) Presença (estar em estado normal de consciência/estar dentro do jogo). O GEQ permite avaliar aspectos relacionados ao engajamento do jogador ao utilizar um jogo. Para ambos os questionários, foi utilizada a seguinte escala como sugerido por Savi et al. (2011): -2: discordância forte; -1: discordância; 0: nem concorda, nem discorda; 1: concordância; 2: concordância forte.

Na segunda parte, foram aplicadas três questões abertas: a) “Do que você gostou no jogo?”; b) “Do que você não gostou no jogo”; c) “O que você mudaria para melhorar o jogo?”, para coletar pontos positivos, negativos e melhorias futuras para o jogo, que teve como objetivo colher dados mais detalhados sobre a opinião dos alunos referente às duas etapas anteriores. Além disso, para avaliar o aprendizado do ponto de vista do aluno ao utilizar o jogo, empregando as questões: a) “Você conseguiu lembrar alguns tipos de técnicas de teste ao jogar? Sim/Não. Quais?”; b) “Explique as técnicas de teste que você viu no jogo. Descreva e faça exemplos de casos de teste”. Com isso, observou-se observou-se o jogo fez o aluno treinar as técnicas de teste funcional vistas em sala de aula.

Para que pudessem estar aptos a utilizar o BlackBox, os alunos participaram de aulas sobre teste funcional, conteúdo abordado na disciplina Programação Avançada, antes do uso do jogo. No dia da avaliação, os alunos foram direcionados a um laboratório onde o jogo estava instalado, e cada um posicionou-se em um computador individualmente, sem poder consultar o colega ao lado. Os alunos assinaram um Termo de Consentimento Livre e Esclarecido (TCLE) dando seu consentimento para participação na avaliação do jogo, a qual ocorreu em duas etapas: a) uso do jogo; b) resposta do questionário. Foi tomado nota do início e fim do tempo de utilização do jogo por cada aluno. A Figura 3 mostra a organização do laboratório e o momento em

que os alunos estavam interagindo com o jogo. A seguir, são narrados os resultados alçados com base em cada uma das etapas apresentadas anteriormente.

Figura 3. Imagens da aplicação do jogo com os alunos no laboratório.

5.2. Análise dos Resultados

O tempo médio de utilização do jogo foi de 20 minutos aproximadamente, tendo como tempo mínimo 9 minutos e máximo de 31 minutos, levando em consideração que, em ambos, os alunos terminaram o jogo com êxito, concluindo que é viável sua utilização em uma aula de 1 hora.

Com relação aos resultados utilizando o modelo MEEGA, na categoria de Motivação, foram avaliados os aspectos Atenção, Relevância, Confiança e Satisfação. A Figura 4 mostra o percentual relacionado a cada item desses aspectos. Considerando a média de concordância dos itens para cada aspecto, 79% dos alunos afirmam terem tido algo que chamou sua atenção no jogo, 78% acreditam que o jogo é relevante, 76% se sentiram confiantes durante a utilização e 79% afirmam terem ficado satisfeitos com o que praticaram e aprenderam.

Figura 4. Gráfico de avaliação do modelo MEEGA, categoria Motivação.

Com relação aos aspectos da experiência do usuário, foram avaliados os seguintes aspectos no MEEGA: Imersão, Desafio, Divertimento e Competência. A Figura 5 apresenta o percentual relacionado a cada item desses aspectos. Considerando a média de concordância dos itens para cada aspecto 75% dos alunos se sentiram mergulhados no jogo, 64% alegam que o jogo foi desafiador, 72% se divertiram ao utilizarem o jogo e 85% afirmam que tiveram competência suficiente para utilizá-lo. Considerando os resultados do MEEGA de um modo geral, mais da metade dos alunos avaliaram o jogo positivamente.

Utilizando o GEQ e medindo os aspectos Absorção, Fluxo e Presença, foram obtidos os resultados da Figura 6. Dentre os resultados obtidos, 74% dos alunos afirmaram não estar assustados com o jogo, 87% negaram sentir-se acabados e 49% confirmaram que jogaram mais do que planejaram. Estes resultados indicam que existem oportunidades de melhoria para chamar mais a atenção do jogador e envolve-lo com a história de espionagem.

Figura 5. Gráfico de avaliação do modelo MEEGA, categoria Experiência do Usuário.

Figura 6. Gráfico de avaliação do modelo GEQ.

Com relação à avaliação da identificação dos conceitos vistos em sala de aula, foi observado que 51% dos alunos conseguiu identificar a técnica de teste funcional de software. Considerando os conceitos que foram exemplificados pelos alunos no questionário aplicado após o uso do jogo: 28% dos alunos explicou ou exemplificou conceitos sobre classes de equivalência, 5% explicou ou exemplificou conceitos sobre

valores limite e 13% explicou ou exemplificou conceitos de casos de teste. Além disso, ao verificar o tempo de jogo, observou-se que 6 alunos (aproximadamente 15%) desistiram de concluir o jogo com êxito (não concluíram a fase 3). Estes resultados indicam que é necessário fazer alterações no jogo para relacionar os conceitos sobre teste funcional de software e entender que dificultou a conclusão do jogo.

Para entender melhor os aspectos que impactaram positiva ou negativamente na percepção dos alunos, foram analisadas as respostas às questões abertas do questionário, procurando identificar comentários que explicassem o motivo para as notas atribuídas ao itens do questionário. Alguns comentários (Participante XX = PXX) positivos e negativos são apresentados a seguir:

“O modo de como ele muda os problemas, ele exige leitura por isso prendeu minha atenção, achei bem dinâmico” – Positivo P01.

“Gostei das histórias que parecem envolver de certa forma o jogador” – Positivo P24.

“Gostei bastante das missões e do modo como foi inserido a resolução dos problemas utilizando conceito aprendido dentro de sala” – Positivo P02.

“Suspense que jogo proporciona sobre o que irá acontecer em seguida” – Positivo P36.

“Da tela não ser do tamanho da tela do pc, o jogo não possui sons” – Negativo P03.

“De ter poucas missões. O jogo é bom e faz querer mais” – Negativo P36. “...número de tentativas insuficientes, muito texto...” – Negativo P12.

Os pontos positivos citados pelos participantes reforçam os resultados obtidos nos questionários do MEEGA e GEQ. Já, os pontos negativos indicam o que poderia ser melhorado, como o tamanho da tela do jogo pequena em relação à tela do computador, a falta de som e poucas missões.

6. Considerações Finais

Este artigo apresentou o BlackBox, um jogo sério como apoio na aprendizagem das técnicas de teste funcional de software. O jogo foi desenvolvido abrangendo conceitos sobre classes de equivalência, análise do valor limite e geração de casos de teste. Após o uso do jogo, foi aplicado um questionário que obteve resultados positivos em termos de motivação, experiência do usuário e sentimento do aluno ao utilizar o jogo.

Apesar de 33 dos 39 alunos terem conseguido concluir o jogo, os conceitos citados pelos alunos no questionário pós-avaliação apresentaram lacunas quanto aos conceitos aplicados no BlackBox. Consequentemente, é necessário realizar um levantamento junto com a parte pedagógica de ensino a fim de encontrar pontos que possam agregar aprendizagem ao jogo afim de que os alunos possam aprender jogando.

Como trabalho futuro pretende-se incluir alguns dos pontos de melhorias citados pelos alunos nas respostas às questões abertas: (1) incluir efeitos sonoros para ajudar a capturar ainda mais a atenção do jogador além de complementar com as animações que aparecem durante o jogo; (2) incluir mais missões para que o jogo possa durar um pouco mais; (3) incluir um nível de seleção de dificuldades, pois ajudará o aluno

escolher qual o nível deseja jogar; (4) melhorar o design das telas, pois para alguns alunos as telas que contém efeitos foram as que mais chamaram a atenção e as que mais causaram um nível de satisfação elevado enquanto jogavam; e (5) dar feedback em respostas erradas, pois alguns alunos não entendiam o que tinham errado e desistiram de jogar. Com estas alterações espera-se ajudar a capturar a atenção em um nível maior além de proporcionar mais prazer e satisfação ao aluno enquanto joga.

Devido à avaliação do jogo ter sido realizado em apenas uma turma de uma universidade, os resultados não podem ser generalizados. Desta forma, tem-se como trabalho futuro replicar a avaliação realizada em outras turmas usando a nova versão do jogo. Espera-se, desta forma, que o jogo possa ser eficaz na utilização como auxílio no ensino e aprendizagem das técnicas de teste funcional em ambientes acadêmicos, a fim de motivar o aluno em seus estudos e contribuir com o ensino de computação no Brasil.

Referências

An, D. Y., da Silva, C. D., Ribeiro, D. M. G., da Rocha, P. B. R., Maltinti, C., Nunes, V. B., and Fávero, R. (2013). Digita-um jogo educativo de apoio ao processo de alfabetização infantil. In Brazilian Symposium on Computers in Education (pp. 154-163).

Brockmyer, J. H., Fox, C. M., Curtiss, K. A., McBroom, E., Burkhart, K. M., and Pidruzny, J. N. (2009). The development of the Game Engagement Questionnaire: A measure of engagement in video game-playing. Journal of Experimental Social Psychology, 45(4), 624-634.

de Oliveira, B. (2013) “Testeg - Um software educacional para o ensino de teste de software”. Universidade Federal de Lavras. (Trabalho de Conclusão de Curso)

Elbaum, S., Person, S., Dokulil, J. and Jorde, M. (2007). “Bug hunt: Making early software testing lessons engaging and affordable”. In Proceedings of the 29th international conference on Software Engineering (pp. 688-697). IEEE Computer Society.

Neto, A. (2007) “Introdução a teste de software”. Engenharia de Software Magazine, 1, 22.

Paludo, L. and Raabe, A. (2010) “Análise de Jogos Educativos de Computador para Gerência de Projetos de Software”. In Workshop sobre Educação em Computação (Vol. 1, pp. 867-876).

Pietruchinski, M., Neto, J., Malucelli, A and Reinehr, S (2011) “Os jogos educativos no contexto do SBIE: uma revisão sistemática de Literatura” In: Anais do XXII Simpósio Brasileiro de Informática na Educação. Vol. 1. No. 1.

Savi, R., Wangenheim, C. and Borgatto, A. (2011) “Um Modelo de Avaliação de Jogos Educacionais na Engenharia de Software”. Anais do XXV Simpósio Brasileiro de Engenharia de Software (SBES 2011), São Paulo.

Silva, C., Junior, I., Teixeira, M. and Aquino, C. (2016) “gTest Learning: Um Jogo para Ensino Básico de Teste de Software”. Congresso Regional sobre Tecnologias na Educação – Recife-PE.

Thiry, M., Zoucas, A. and Gonçalvez, R. (2010) “Promovendo a Aprendizagem de Engenharia de Requisitos de Software através de um Jogo Educativo”. In: Anais do XXI Simpósio Brasileiro em Informática na Educação, João Pessoa. pp 1-10.