Evolução do Jogo ItestLearning para o Ensino de Testes
de Software: Do Planejamento ao Projeto
Carla I. M. Bezerra
Federal University of Ceará Fortaleza – CE, Brazil Campus do Pici, Bloco 942-A,
Zip Code 60455-760 55 85 3366-9797
carlabezerra@great.ufc.br
Emanuel F. Coutinho
Federal University of Ceará Fortaleza – CE, Brazil Campus do Pici, Bloco 942-A,
Zip Code 60455-760 55 85 3366-9797
emanuel@virtual.ufc.br
Ismayle S. Santos
Federal University of Ceará Fortaleza – CE, Brazil Campus do Pici, Bloco 942-A,
Zip Code 60455-760 55 85 3366-9797
ismaylesantos@great.ufc.br
José Maria Monteiro
Federal University of Ceará Fortaleza – CE, Brazil Campus do Pici, Bloco 942-A,
Zip Code 60455-760 55 85 3366-9797
monteiro@lia.ufc.br
Rossana M. C. Andrade
Federal University of Ceará Fortaleza – CE, Brazil Campus do Pici, Bloco 942-A,
Zip Code 60455-760 55 85 3366-9797
rossana@great.ufc.br
ABSTRACT
The lack of both practical activities and the participation of computing students in real software development projects make the teaching of software testing a challenge. In this scenario, educational games are interesting to help the learning because they simulate real situations of software projects. The game ItestLearning was originally designed to help the learning of concepts related to the testing planning. Then, this paper presents the evolution of the game ItestLearning to contemplate the teaching of design activities for tests, as well as the results of its evaluation, which was conducted in three different disciplines of Computer Science courses. These results indicated evidences that this game contributes to the learning of software testing.
RESUMO
A falta de atividades práticas e da participação de estudantes de Computação em projetos de desenvolvimento de software reais torna o ensino de teste de software um desafio. Neste cenário, jogos educativos são interessantes para ajudar na aprendizagem porque simulam situações reais de projetos de software. O jogo ItestLearning foi originalmente projetado para ajudar o aprendizado de conceitos relacionados ao planejamento de testes. Então, este trabalho apresenta a evolução do jogo ItestLearning para contemplar o ensino de atividades de projeto de testes, assim como os resultados de sua avaliação, realizada em três diferentes disciplinas de cursos de Computação. Os resultados indicaram evidências de que este jogo contribui para o aprendizado de teste de software.
Descritor de Categorias e Assuntos
K.3.2 [Computer and Information Science Education]: Computer science education.
Termos Gerais
Theory, Design, Verification.
Palavras Chaves
Testes de Software, Jogos Educacionais, Avaliação.
1. INTRODUÇÃO
Segundo Myers [1], o teste de software pode ser definido como o processo de executar um programa com o objetivo de encontrar defeitos. Logo, esse processo é parte fundamental do desenvolvimento de aplicações, sendo considerada uma das principais estratégias para assegurar a qualidade de produtos de software.
Dado à relevância das atividades relacionadas ao processo de teste de software, os currículos de referência da Sociedade Brasileira de Computação (SBC) e da Association for Computing Machinery (ACM) abordam assuntos relacionados a este tema, sendo o curso de Engenharia de Software aquele que mais explora a área de teste de software [2]. Contudo, apesar dessa importância, o teste de software recebe pouca atenção nos currículos de graduação, sendo poucas as horas dedicadas ao seu ensino [3]. Além disso, os cursos oferecidos enfrentam dificuldades no ensino de testes de software, como: falta de atividades práticas, dificuldade para motivação, falta de tempo para a transmissão do conhecimento e dificuldades para ensinar as habilidades de elaboração e execução de casos de teste [4].
Jogos têm sido utilizados no auxílio do ensino de diversas áreas do conhecimento [5, 6, 7]. Quando utilizados como ferramentas educacionais, podem permitir a experimentação de situações reais que seriam vivenciadas em um ambiente profissional de desenvolvimento de software [8, 9, 10]. Contudo, os resultados da
revisão sistemática conduzida por Pietruchinski et al. [11] trazem evidências de que embora a área de Engenharia de Software tenha sido uma das mais beneficiadas com pesquisas relacionadas a jogos educacionais, ainda existe uma carência por pesquisas relacionadas a jogos educativos.
Na literatura existem alguns jogos que auxiliam o aprendizado da atividade de testes de software [3, 12, 13]. Contudo, nenhum dos trabalhos encontrados foca nas atividades de planejamento e projeto de testes. No planejamento de testes são definidos os objetivos dos testes e as atividades para alcançar tais objetivos, enquanto que no projeto de testes tem-se a especificação de como o software deve ser testado [14].
Logo, dado a importância dessas atividades e os benefícios dos jogos educacionais, é interessante que haja um jogo educacional para apoiar o aprendizado dessas atividades, confrontando algumas das dificuldades no ensino de testes.
Existem diversos tipos de jogos educacionais, tais como jogos de simulação, aventura, quebra-cabeças, experimentais e motivacionais [15]. Dado o objetivo de apoiar o aprendizado das etapas de planejamento e projeto de testes, decidiu-se desenvolver um jogo educacional de computador do tipo simulação. Este tipo de jogo produz diversas situações da vida real com objetivo de formação, análise ou previsão, combinando as características de um jogo (competição, regras, jogadores) com as da simulação (incorporação de recursos do mundo real) [16].
A versão inicial do jogo, chamado ItestLearning, e sua avaliação foram apresentadas respectivamente por [17] e [18]. Essa versão contemplava apenas as atividades de planejamento de testes de software. O objetivo deste artigo é descrever a evolução deste jogo para a fase de projeto. Uma nova avaliação do jogo também é apresentada, seguindo um modelo específico de avaliação para jogos educacionais descrito por Savi et al. [19].
Este artigo está organizado da seguinte maneira: na Seção 2 são apresentados os principais conceitos relacionados a teste de software; na Seção 3 são descritos os trabalhos relacionados; na Seção 4 é apresentada a evolução do jogo desenvolvido para o ensino de teste; na Seção 5 é descrita a avaliação do ITESTLEARNING; na Seção 6 é realizada uma discussão sobre pontos fortes e sugestões de melhoria do jogo; por fim, a conclusão e trabalhos futuros são apresentadas na Seção 7.
2. TESTE DE SOFTWARE
De acordo com o IEEE [20] o teste de software é a “verificação dinâmica do funcionamento de um programa utilizando um conjunto finito de casos de teste, adequadamente escolhido dentro de um domínio de execução, em geral, infinito, contra seu comportamento esperado”. Essa definição é interessante por destacar que o teste envolve a execução do programa, que o teste exaustivo (com um conjunto infinito de casos de testes) é inviável na prática e que ele compara o comportamento real do sistema contra um comportamento esperado.
Neste cenário, cabe apresentar a diferença entre caso de teste e procedimento de teste. A especificação de casos de testes documenta as entradas, saídas esperadas e as condições de execução para um dado teste [21], enquanto que os procedimentos de testes são as sequências de instruções para configuração,
execução e avaliação dos resultados de um dado caso de teste [22].
Os testes podem ser classificados quanto ao objetivo. Testes funcionais verificam se o comportamento do sistema está de acordo com as especificações. Testes de usabilidade analisam dentre outras coisas o quão fácil é para o usuário usar o software. Testes de desempenho verificam os requisitos de desempenho do software. Outros tipos de testes e mais detalhes podem ser encontrados em [20].
Além da classificação quanto ao objetivo, os testes podem ser classificados quanto ao nível. Segundo Muller et al. [14] existem quatro níveis de testes: i) Unidade, no qual procura-se defeitos em partes do software que podem ser testadas separadamente; ii) Integração, onde estão os testes caracterizados por testar as interfaces entre os componentes; iii) Sistema, no qual os testes verificam o comportamento de todo o sistema; e iv) Aceitação, que abrange os testes que são frequentemente feitos pelo usuário final e que tem por objetivo estabelecer a confiança no sistema. Apesar da relevância da atividade de testes, é importante ressaltar que sua execução é bastante onerosa porque requer tempo, conhecimento, planejamento, infraestrutura e pessoal especializado [1]. Dessa forma, ferramentas que auxiliem esta atividade, tais como o Selenium [23], o JMeter [24], o Mantis [25] e o TestLink [26] são de grande importância para reduzir os custos envolvidos.
Com o objetivo de guiar a execução dos testes deve ser utilizado um processo de teste. Segundo Müller et al. [14], em geral, os processos de testes apresentam as seguintes atividades:
Planejamento e controle. O planejamento consiste em
definir os objetivos dos testes especificando as atividades para alcançar esses objetivos. A atividade de controle consiste em comparar constantemente o progresso atual contra o planejado. O planejamento pode ser documentado em um documento chamado “Plano de Testes”, que deve conter dentre outras coisas: recursos, cronograma, itens que serão testados, equipe, e riscos;
Análise e Modelagem (Projeto). Nesta atividade, os
objetivos gerais do teste são transformados em condições e modelos de teste tangíveis. Um dos principais resultados dessa etapa é o documento de especificação dos casos de testes, onde são descritos os casos e procedimentos de testes;
Implementação e execução. Esta é a atividade onde os
procedimentos ou roteiros de teste são implementados pela combinação dos casos de teste. Além disso, o ambiente de testes é preparado e os testes são executados;
Avaliação do critério de saída e relatórios. Nesta
atividade a execução do teste é avaliada mediante os objetivos definidos para produzir um relatório de testes e verificar se são necessários mais testes; e
Atividades de encerramento de testes. Durante esta
atividade são coletados os dados de todas as atividades para consolidar a experiência da execução dos testes. Em se tratando do jogo apresentado neste artigo, o foco foi direcionado para a fase de planejamento e projeto de testes de software, conforme é apresentado em detalhes na Seção 4.
3. TRABALHOS RELACIONADOS
Vários jogos têm sido propostos na literatura para apoiar o ensino de Engenharia de Software [8, 9]. Contudo, com relação ao ensino da disciplina teste de software, foram identificados na literatura poucos jogos educacionais [2, 3, 12, 13] os quais são descritos a seguir.
BugHunt é uma aplicação web onde o aluno inicialmente tem acesso aos objetivos e a uma série de guias para ajuda [12]. Então, o aluno passa por um conjunto de lições sobre testes caixa-preta, caixa-branca, automação e eficiência de testes. Esta aplicação possui também um conjunto de exercícios e as respectivas soluções. Ao final, um sumário é exibido.
O U-Test é um jogo de simulação com foco em teste de unidade, abordando teoria e prática [13]. O jogador assume o papel de um testador responsável pela escrita de testes de unidade para um sistema hipotético. Seu objetivo é aplicar técnicas para a seleção de dados de entrada para o teste de unidade. As regras do jogo são impostas pela interface e o feedback é exibido ao final de cada desafio.
Silva et al. [2] propuseram o Jogo da Equipe de Teste de Software (JETS), visando simular interações de uma equipe de teste de software em uma empresa. O jogo é constituído de quatro fases, onde o estudante assume um cargo diferente dentro de uma equipe de testadores (Testador de Software, Analista de Teste, Arquiteto de Teste e Líder da Equipe de Teste). O jogo possui um mecanismo de pontuação, porém não foi apresentada no artigo nenhuma avaliação.
Diniz e Dazzi [3] propuseram a utilização de um jogo como estratégia de ensino e aprendizagem, o Jogo das 7 Falhas. O Jogo das 7 Falhas é do tipo single-player onde o jogador assume papel de testador em uma equipe de teste de software de uma empresa fictícia. O objetivo deste jogo é identificar as sete falhas existentes em cada funcionalidade testada, correlacionando-as com uma classe de equivalência ou um valor-limite, no menor tempo possível. O resultado da avaliação quantitativa e qualitativa apresentada por Diniz e Dazzi [3] sugere que este jogo pode ser uma eficiente técnica de ensino a ser utilizada no ensino de teste de caixa-preta.
Conforme apresentado nesta seção, nenhum dos jogos encontrados na literatura focam no planejamento e projeto do teste de software, sendo este o diferencial do ItestLearning. Vale ressaltar que o ItestLearning é um jogo de simulação, possui um feedback imediato e um sumário consolidado ao final, assim como um mecanismo de pontuação.
4. O JOGO DIGITAL PARA O ENSINO DE
TESTE DE SOFTWARE
O jogo denominado ItestLearning 1 [17, 18] provê um ambiente para a realização do planejamento de teste de software através de uma breve descrição de um projeto hipotético. Dessa forma, a evolução do jogo ItestLearning, apresentada neste artigo, simula o projeto de casos de testes a partir de requisitos, estórias do usuário ou casos de uso.
O público alvo do jogo são alunos de cursos de graduação da área de computação/informática, os quais possuem disciplinas com conteúdo relacionado ao teste de software. Para o uso deste jogo como meio de aprendizado é necessário que o jogador possua conhecimentos prévios de Engenharia de Software.
4.1. TECNOLOGIA DO JOGO
A metodologia adotada para o desenvolvimento do jogo iniciou-se com a elaboração do Game Design Document (GDD), documento que descreve a dinâmica e interface do jogo, refinado em diagramas de atividade e classe para a programação. A linguagem de programação utilizada foi Java, utilizando o framework Java Server Faces. Para isso, a arquitetura foi baseada no padrão MVC (Model-View-Controller - Modelo-Visão-Controlador), que tem como objetivo separar a lógica de negócio da interface do usuário, e controlar o fluxo da aplicação. Como servidor web foi utilizado o Tomcat, como banco de dados o PostgreSql e XHTML na camada de visão. Foram utilizados ainda os frameworks Hibernate, para persistência dos dados, e o Primefaces, suíte de componentes JSF (Java Server Faces) customizados.
A Figura 1 exibe a arquitetura definida para o jogo, assim como os relacionamentos entre seus componentes em alto nível. Três camadas foram definidas para esta arquitetura: interface do usuário, controle da aplicação e banco de dados. Na interface do usuário é possível acessar a aplicação através de qualquer navegador web, independente do dispositivo. As requisições dos usuários são repassadas à camada de controle da aplicação, assim como os dados, e direcionados para os devidos responsáveis, consequente processamento, e acesso ao banco de dados quando
1
iTestLearning - https://sistemas.quixada.ufc.br/iTestLearning/
necessário. Por fim, o fluxo de dados retorna à interface do usuário, exibindo o resultado do processamento.
4.2. MODELAGEM E EXECUÇÃO DO
JOGO
O jogo é single-player (jogo para somente um jogador), onde o jogador realiza o planejamento e projeto de teste de software a partir da especificação de projeto. A Figura 2 exibe um diagrama de atividades para a representação das ações entre jogador e sistema. As primeiras atividades do diagrama estão relacionadas à fase de planejamento já apresentada em [17, 18]. Para o prosseguimento para fase de projeto de testes, o jogador precisa atingir uma pontuação mínima na fase de planejamento.
O jogo inicia com a fase de planejamento, onde o jogador poderá escolher o nível de dificuldade do jogo (fácil, médio, difícil), podendo selecionar o projeto para iniciar o jogo. Os projetos a serem selecionados no jogo são sistemas fictícios que podem variar de acordo com o nível de dificuldade. O nível de dificuldade influencia nas etapas das fases de forma a desafiar o jogador.
A primeira fase simula as atividades de planejamento de testes, e é composta por seis etapas. Todas as etapas da fase de planejamento são definidas com base em Silva [27]. As etapas são descritas conforme o seguinte:
Etapa 1: o jogador deve escolher os itens do projeto a serem testados (de acordo com a descrição do projeto);
Etapa 2: o jogador define quais tipos de teste serão realizados durante o processo de teste (Interface, Usabilidade, Segurança, Estresse, etc.);
Etapa 3: o jogador definirá por quais níveis de teste o projeto passará (Unidade, Integração, Sistema, Aceitação, etc.);
Etapa 4: serão definidos os critérios de aceitação que farão com que um teste executado seja aprovado ou não (de acordo com a descrição do projeto);
Etapa 5: o jogador deve escolher quais ferramentas serão utilizadas no processo de testes (Selenium, JMeter, Marathon, Mantis, etc.); e
Etapa 6: o jogador indica quais artefatos podem ser gerados no processo de teste de software (Plano de Teste, Especificação de Casos de Testes, Relatório de Testes, etc.). A Figura 3 apresenta algumas etapas da fase de planejamento, com a pontuação adquirida até o momento pelo jogador. Em se tratando de sistema de pontuação, ressalta-se que o jogador só poderá seguir para a próxima fase quando concluir a atual. Como detalhado anteriormente, cada etapa da fase de planejamento possui vários itens. A cada item marcado corretamente o jogador ganha pontos e a cada marcação de um item não correto o jogador perde pontos. Ao final da fase de planejamento é exibido uma tela com um feedback contendo todo o planejamento feito pelo jogador e um planejamento recomendado para o projeto.
A fase de projeto de testes é a extensão da versão inicial do jogo ItestLearning. O principal objetivo desta fase é selecionar os casos de testes válidos de acordo com a descrição de um determinado evento. O início desta etapa ocorre após a finalização da fase de planejamento, seu acesso é dependente de uma obtenção de 70% ou mais de acertos. Esse percentual é definido com base na média de respostas da fase de planejamento do jogo. Os eventos e a dificuldade desta fase estarão relacionados ao projeto escolhido. O nível de dificuldade tem fundamental importância nesta fase, pois a partir da seleção do nível feita ao início do jogo será submetida ao jogador uma diferente perspectiva da narrativa do evento.
Cada projeto apresenta no mínimo três eventos relacionados a ele que deverão ser realizados durante essa fase conforme apresentado na Figura 4. Caso o projeto escolhido seja do nível fácil o jogador deverá selecionar os casos de testes válidos baseados em casos de uso. Nos níveis médio e difícil as descrições serão feitas em cima de estórias de usuário e em nível de requisitos, respectivamente.
A relação entre o nível de dificuldade e o formato do requisito é que o nível mais fácil possui um maior detalhamento na forma de
casos de uso, facilitando o jogador a definir os casos de testes. Já no nível médio o jogador possui como base o requisito na forma de estórias de usuário, com menos detalhamento do que no nível fácil. O nível difícil está representado na forma de especificação de requisitos simples sem formato, o que torna a dificuldade para o jogador ainda maior.
A dinâmica da fase de projeto de testes funciona de modo semelhante à fase de planejamento do jogo. O evento será apresentado ao jogador através de uma narrativa mostrada de acordo com o nível de dificuldade que está sendo aplicado como explicado anteriormente. A partir da leitura desta descrição é necessário escolher quais casos de testes, representados pelas alternativas, serão válidos para aquele evento. É importante ressaltar, que foi definido um padrão simples para projetar os casos de testes do jogo de forma a não deixar as opções extensas e facilitar a seleção delas. Após a seleção, o jogador deverá avançar e então lhe será apresentado um novo evento com uma nova descrição e casos de teste a serem analisados. O aluno deve ter atenção durante a execução da fase de projeto de testes utilizando todos os recursos disponíveis, pois não será possível a troca das alternativas depois do avanço de um evento para outro. A pontuação desta etapa será calculada em cima da mesma obtida na primeira fase do jogo podendo aumentar ou até mesmo reduzir o desempenho geral do jogador.
Ao final da fase de projeto de testes, após o jogador ter selecionado os casos de testes que considerou válido para cada evento apresentado, ele poderá ter a visualização da sua pontuação geral. Da mesma forma que a fase de planejamento é fornecida uma tela com um feedback, onde é possível visualizar os casos de testes que foram marcados para os eventos que foram feitos e verificá-los com um resultado sugerido da fase. Neste momento, o jogo poderá ser encerrado ou gravar nome e
pontuação no ranking, tudo isso feito através dos ícones presentes. Tanto na fase de planejamento de testes como na fase de projeto de testes é possível o aluno executar o jogo com o mesmo projeto ou com outro projeto para melhorar sua nota no ranking. A Figura 5 exibe a tela final da fase de projeto, após a seleção dos casos de testes pelo usuário, com os casos selecionados pelo jogador e os casos válidos.
Figura 4. Fase de projeto de testes. Figura 3. Fase de planejamento de testes.
5. AVALIAÇÃO DA EVOLUÇÃO DO JOGO
ITESTLEARNING
Nesta seção é descrita a avaliação do jogo ItestLearning para validar a fase de projeto juntamente com a fase de planejamento. São apresentadas a metodologia de avaliação utilizada e a análise dos resultados após a aplicação da metodologia.
5.1. METODOLOGIA DE AVALIAÇÃO
O jogo apresentado neste trabalho foi avaliado seguindo uma metodologia de avaliação específica para jogos educacionais. Essa metodologia foi elaborada por Savi et al. [19], e propõe um modelo para a avaliação da qualidade de jogos educacionais baseado no modelo de avaliação de treinamento de Kirkpatrick [28], nas estratégias motivacionais do modelo ARCS (Attention, Relevance, Confidence, Satisfaction) [29], na área de experiência do usuário e na taxonomia de objetivos educacionais de Bloom [30].
O modelo de avaliação define componentes que devem ser avaliados, que são motivação, experiência do usuário e aprendizagem. Estes componentes são divididos em subcomponentes: Motivação é dividida em satisfação, confiança, relevância e atenção; Experiência do Usuário é dividida em competência, diversão, desafio, interação social e imersão; e Aprendizagem divide-se em aprendizagem de curto termo e de longo termo.
Ao utilizar este modelo para a avaliação de um determinado jogo educacional, Savi et al. [19] indica que o modelo precisa ser
revisado em termos da relevância dos itens e, se for necessário, adaptado ao contexto e/ou tipo de jogo e/ou objetivo de avaliação específico. Neste trabalho, o modelo de avaliação foi adaptado retirando a categoria interação social, devido ao jogo não estar orientado a esta característica. Também foram renomeadas duas das perguntas do questionário original para que estivesse voltada ao conteúdo do jogo.
O formato de resposta da avaliação para os itens da escala é baseado no tipo Likert de 5 pontos, variando de -2 (discordo fortemente) até +2 (concordo fortemente). A interpretação dos dados está diretamente ligada ao formato de resposta dos itens. Quanto mais próximo a média estiver de +2, melhor avaliada foi a característica do jogo [19].
A mesma metodologia apresentada para avaliação já havia sido aplicada ao jogo ItestLearning [15]. No entanto, a aplicação dessa avaliação foi limitada porque avaliou apenas a fase de planejamento, já que não tinha sido implementada a fase de projeto, e além disso, essa avaliação foi conduzida em uma única disciplina de Engenharia de Software.
A avaliação apresentada nesse trabalho engloba a fase de planejamento e projeto de testes de software do iTestLearning. O jogo foi aplicado em três disciplinas. Duas delas na Universidade Federal do Ceará (UFC) – Campus Quixadá: Engenharia de Software do curso de Sistemas de Informação, e Verificação e Validação do curso de Engenharia de Software, com a participação de 15 e 12 alunos respectivamente. A outra disciplina onde o jogo foi aplicado foi Engenharia de Software do curso de Ciências da Computação da UFC, Campus Fortaleza, com a participação de 12 alunos.
Figura 5. Casos de teste do usuário e casos de teste válidos.
Primeiramente foram apresentados conceitos introdutórios do Planejamento de Testes e Projeto de Testes e posteriormente foi aplicado o jogo em sala de aula. Foi escolhido um dos projetos do nível fácil para que todos os alunos executassem o mesmo projeto com o mesmo nível de dificuldade. Como o jogo é web, cada aluno executou o jogo individualmente e posteriormente preencheu o questionário de avaliação online2. O questionário online utilizou a metodologia de avaliação apresentada adaptada ao contexto do jogo.
5.2. ANÁLISE DOS RESULTADOS
As respostas do questionário de avaliação do jogo pelos alunos foram consolidadas na planilha fornecida pelo modelo de avaliação [31]. Uma análise qualitativa e quantitativa dos resultados foi realizada, gerando gráficos de frequência que indicam a porcentagem de notas atribuídas para cada item. Para cada componente foram gerados gráficos para análise dos resultados. Para fim de uma melhor visualização, os gráficos das Figuras 5, 6 e 7 exibem valores percentuais apenas para as respostas com frequência acima de 5%, apesar de que os demais estão representados graficamente.
Para o cálculo da pontuação utilizou-se a média aritmética simples da soma dos valores das escalas +1 e +2 de cada um dos
2
Questionário Online de Avaliação do iTestLearning - http://zip.net/bhmZSk
subcomponentes. Assim é possível calcular a pontuação para cada subcomponente individualmente. Para o cálculo da pontuação do componente, o mesmo procedimento foi realizado, utilizando todos seus subcomponentes. Esse resultado é apresentado em pontos percentuais.
A Figura 5 apresenta a Motivação. O jogo apresentou um resultado positivo na maioria dos itens avaliados, obtendo-se 73% de pontuação com as escalas +1 e +2, reforçando que a maioria dos alunos concordou com as características avaliadas relacionadas à motivação do jogo.
Ainda em relação à Figura 5, o subcomponente satisfação foi atendido com 60,2% de pontuação do total de respostas dos alunos, demonstrando a satisfação por concordarem que terão oportunidades de utilizar na prática o que aprenderam com o jogo. Mesmo assim, foi o critério pior avaliado da Motivação.
O subcomponente confiança foi o que obteve maior pontuação nos seus itens com atendimento de 76,9%, demonstrando que os alunos sentiram confiança durante as fases do jogo. O subcomponente relevância obteve uma porcentagem de concordância média de 73,05%, indicando que o funcionamento do jogo está adequado ao aprendizado, que o conteúdo do jogo é relevante para o ensino de planejamento, e que o jogo está conectado a outros conhecimentos que o aluno já possuía. Ainda na Figura 5, o subcomponente atenção também recebeu o percentual mais alto de concordância, com média de 76,9%, o que indica que os alunos permaneceram atentos com as variações no
jogo, e tiveram interesse no desenvolvimento das atividades. Pela análise é possível concluir que a Motivação do jogo foi atingida, no entanto o quesito de satisfação necessita de melhorias. A Figura 6 apresenta os resultados das respostas dos alunos relacionadas à escala de Experiência do Usuário. Neste componente foi obtida uma média de 49%, onde apenas um item foi atendido. Por ordem decrescente de percentual de concordância obteve-se: imersão (75,6%), desafio (56,4%), interação social (51,2%), diversão (30,75%) e competência (30,7%). A imersão obteve o maior percentual de concordância. Os itens de percepção do tempo e preocupações do dia a dia praticamente coincidiram com a avaliação. Por outro lado os itens com menores percentuais foram diversão e competência, relacionados ao ritmo monótono e atendimento dos objetivos do jogo por meio de habilidades próprias. O ritmo adequado do jogo deve ser ajustado.
Por fim, foram avaliados itens relacionados à aprendizagem do aluno, conforme a Figura 7. A maior parte dos subcomponentes recebeu um percentual de concordância acima de 70%. Pode-se concluir que o jogo foi eficiente na aprendizagem devido a sua facilidade de uso e que a experiência do jogo irá contribuir para experiência profissional do aluno. O subcomponente pior avaliado foi o relacionado à aprendizagem na disciplina, com 51,3%. Essa pontuação é um pouco contraditória em relação ao subcomponente relacionado à eficiência para a aprendizagem, que
obteve 66,6%. Os demais subcomponentes foram bem avaliados, indicando uma aprendizagem positiva.
Concluindo esta avaliação, por ordem decrescente de importância para os alunos: Motivação com 73%, Aprendizagem com 70% e Experiência do Usuário com 49%. Percebe-se que ajustes relacionados ao usuário são necessários em relação aos subcomponentes competência, diversão, desafio, interação social e imersão. Muitos desses elementos estão associados à interação do usuário com a aplicação e relação direta com a interface do jogo.
Comparando as três turmas entre si (Figura 8), percebeu-se que Motivação em vários aspectos foram semelhantes e todos foram positivos. Design do jogo, conteúdo e satisfação foram bem semelhantes. Destacaram-se itens relacionados à variação do jogo, funcionamento adequado e confiança com as maiores distorções entre turmas. Porém no componente Experiência do Usuário descrito na Figura 6, dos sete subcomponentes, três foram negativos: ritmo adequado, habilidade própria no atendimento dos objetivos e eficiência. E foram os únicos itens com pontuação negativa de toda a avaliação. Porém as médias foram entre 0 e -0.5, indicando que não foram tão mal avaliados, sendo potenciais pontos de melhoria. Por fim, o componente Aprendizagem de maneira geral foi positivo em todas as turmas. O subcomponente mais baixo foi associado ao aprendizado na disciplina, e o mais alto relacionado à interface e controle do jogo.
6. DISCUSSÃO DOS RESULTADOS
Informações qualitativas sobre pontos fortes do jogo e sugestões de melhoria foram coletadas durante as avaliações dos alunos. Em relação aos pontos fortes indicados pelos alunos, alguns pontos podem ser destacados. O ponto mais citado foi à questão da interface intuitiva e fácil interação do jogo com o usuário. Essa afirmação acaba corroborando com o item de Design do jogo na avaliação quantitativa. O segundo ponto considerado forte pelos alunos foram as questões, tanto no formato quanto entendimento. O aprendizado também foi destacado como o terceiro ponto mais citado. A questão de aprendizagem também foi um ponto forte considerado na avaliação quantitativa. Outros aspectos citados como ponto forte foram: representação de situações reais das atividades de testes, desafio para os casos de testes, abrangência do conteúdo, níveis de dificuldade adequados e plataforma web. Algumas sugestões de melhoria foram identificadas pelos alunos. Excluindo erros ortográficos e defeitos da aplicação, identificados pelos alunos, a sugestão de melhoria mais citada no jogo foi a melhoria da interface, seguido do mecanismo de pontuação e
elaboração das questões. Segundo os alunos, a pontuação pode ser melhor distribuída entre as questões do jogo. Outras melhorias sugeridas foram: inclusão de animações, melhorar o design de telas, deixar a aplicação mais dinâmica, inserir um tutorial, deixar o ranking obrigatório e diversificar as questões e as respostas. Em relação à inclusão de animações e a dinamicidade da aplicação, os alunos sugeriram que devem ser incluídos elementos como personagens e sons que possibilitem essa maior interação com o jogador, de forma à possibilitar uma melhor experiência com o usuário.
A Figura 9 exibe apenas os itens que mais se destacaram na avaliação. Alguns itens comentados pelos alunos foram bem pontuais, tais como: utilização contínua de checklist deixa o jogo monótono, o ranking deve ser obrigatório para aumentar a motivação dos alunos, melhorar a forma como o jogo é finalizado (interface e feedback), e balancear as respostas em termos de respostas verdadeira e falsas.
De maneira geral, os alunos exercitaram as etapas de planejamento e projeto de testes, por meio da ferramenta,
0,67 0,75 0,25 0,58 -0,17 0,00 0,00 1,00 1,08 0,17 0,58 -0,17 -0,17 -0,08 0,67 0,73 0,47 0,73 -0,47 -0,27 -0,33 -1,00 -0,50 0,00 0,50 1,00 1,50 Temporariamente esqueci as minhas preocupações do dia-a-dia, fiquei totalmente concentrado no jogo. Eu não percebi o tempo passar enquanto jogava, quando vi o jogo acabou. Me senti mais no ambiente do jogo do
que no mundo real, esquecendo do que estava ao meu redor.
Este jogo é adequadamente desafiador para mim,
as tarefas não são muito fáceis nem muito difíceis.
O jogo evolui num ritmo adequado e não fica monótono –
oferece novos obstáculos, situações
ou variações de atividades.
Consegui atingir os objetivos do jogo por
meio das minhas habilidades.
Tive sentimentos positivos de eficiência no desenrolar do jogo
Experiência do Usuário - Turmas 1, 2 e 3
Figura 8. Avaliação da experiência do usuário entre as três turmas. Figura 7. Avaliação do jogo na escala aprendizagem do jogo.
utilizando conceitos existentes em testes de software.
7. CONCLUSÕES E TRABALHOS
FUTUROS
Este trabalho apresentou uma evolução do jogo digital de simulação ItestLearning para contemplar o ensino de atividades de projeto de testes de software. Também foi apresentada uma avaliação de todas as fases do jogo, planejamento e projeto de testes de software em três disciplinas de diferentes cursos relacionados à computação.
O jogo foi avaliado conforme um modelo específico para jogos educacionais. Conclui-se que os alunos permaneceram atentos às variações do jogo, a facilidade de uso está adequada, e a experiência do jogo irá contribuir para experiência profissional do aluno. Sendo assim, por ordem decrescente de importância para os alunos, os componentes obtiveram os seguintes resultados: Motivação (73%), Aprendizagem (70%) e Experiência do Usuário (49%). Pontos fortes do jogo destacados pelos alunos foram: interface intuitiva, elaboração das questões, fácil interação, representação de situações reais das atividades de testes, desafio para os casos de testes, abrangência do conteúdo, níveis de dificuldade adequados e plataforma web. Como pontos de melhoria destacaram-se: melhoria do mecanismo de pontuação, inclusão de animações, melhorar design de telas, dinamismo, ranking obrigatório e diversificar questões e respostas.
Como continuação desse trabalho pretende-se estender o jogo para incluir as atividades relacionadas à execução dos testes. Inicialmente será implementada a execução de testes funcionais de modo a aplicar os casos de testes selecionados na fase de projeto em protótipos executáveis por projetos. Pretende-se assim, possibilitar ao aluno simular todas as atividades de testes de software, de modo a aproximá-lo de um ambiente real de desenvolvimento de software. Também será investigado um mecanismo de interação entre aluno e professor, que permita um feedback ao aluno mais personalizado e uma abordagem mais adequada para a pontuação do jogo. Para validar essas modificações, serão realizadas outras avaliações do jogo com turmas de cursos de computação como, Engenharia de Software, Ciências da Computação e Sistemas de Informação.
8. AGRADECIMENTOS
Os autores agradecem aos alunos do curso de Sistemas de Informação do Campus Quixadá pelo desenvolvimento e evolução
do iTestLearning. Também agradecemos a Universidade Federal do Ceará por financiar o projeto que originou este trabalho.
9. REFERÊNCIAS
[1] Myers, G. (2004). The Art of Software Testing. John Wiley & Sons, 2th edition.
[2] Silva, T. G.; Müller, F. M.; Bernardi. G. (2011a) Panorama do Ensino de Engenharia de Software em Cursos de Graduação Focado em Teste de Software: Uma Proposta de Aprendizagem Baseada em Jogos. In RENOTE - Revista Novas Tecnologias na Educação, ISSN 1679-1916. [3] Diniz, L. L., Dazzi, R. L. S. (2011) Jogo Digital para o
Apoio ao Ensino do Teste de Caixa-Preta. In: X Simpósio Brasileiro de Qualidade de Software (SBQS), Curitiba. [4] Wangenheim, C. G.; Silva, D. A. (2009) Qual conhecimento
de engenharia de software é importante para um profissional de software? In Anais do Fórum de Educação em
Engenharia de Software, Fortaleza
[5] de Andrade, A. F., Madeira, C. A. G., & Melo, H. H. A. (2013). Batalha de Vetores Virtual: uma proposta de jogo pedagógico para o ensino de biociências. XVIII Conferência Internacional sobre Informática na Educação (TISE). Porto Alegre, Brasil.
[6] dos Reis, S. C., Panciera, R. J., Gomes, A. F., & Menezes, V. P. (2013). Da pesquisa à ação: conectando pressupostos teóricos e pedagógicos no desenvolvimento de um jogo de Inglês interdisciplinar em 3D. XVIII Conferência
Internacional sobre Informática na Educação (TISE). Porto Alegre, Brasil.
[7] Furtado, A., Vallerius, D., & Barone, D. (2013). O Jogo Digital como Motivador do Interesse pela Literatura Brasileira em Alunos do Ensino Médio. XVIII Conferência Internacional sobre Informática na Educação (TISE). Porto Alegre, Brasil.
[8] Monsalve, E. S., Werneck, V. M. B., Leite, J. C. S. P. (2010) SimulES-W: Um Jogo para o Ensino de Engenharia de Software. In: III Fórum em Educação de Engenharia de Software (FEES), Salvador.
[9] Gonçalves, R. Q., Thiry, M., Zoucas, A. (2011) Avaliação da Aprendizagem em Experimentos com Jogo Educativo de Engenharia de Requisitos. In: X Simpósio Brasileiro de Qualidade de Software (SBQS), Curitiba.
[10] Silveira, J. L.; Thiry, M.; Zoucas, A. C. (2013) SPI City: Jogo Educacional para Apoiar o Ensino de Melhoria de Processo de Software. In: XII Simpósio Brasileiro de Qualidade de Software - SBQS, 2013, Salvador, BA. p. 51-65.
[11] Pietruchinski, M. H.; Neto, J. C.; Malucelli, A.; Reinehr, S. (2011) Os jogos educativos no contexto do SBIE: uma revisão sistemática de Literatura. Anais do Simpósio Brasileiro de Informática na Educação – SBIE.
[12] Elbaum, S., Person, S. e Dokulil, J. (2007) Bug hunt: making early software testing lessons engaging and affordable. In: 29th International Conference on Software Engineering (ICSE'07), Minneapolis, p. 688 – 697.
[13] Silva, A. C. (2010) Jogo Educacional para Apoiar o Ensino de Técnicas para Elaboração de Testes de Unidade. Dissertação de Curso de Mestrado, Computação Aplicada, UNIVALI, São José.
[14] Müller, T.; Graham, D.; Friedenberg, D. e Veendendal, E. (2007) Base de Conhecimento para Certificação em Teste - Foundation Level Syllabus. ISTQB - Comissão Internacional para Qualificação de Teste de Software.
[15] Dempsey, J.; Rasmussen, K; Lucassen, B. (1994) Intructional Gaming: implication for instructional technology. Annual Meeting of Association for Educacional Communications and Technology, Nashville.
[16] Jones, K. (1995) Simulations: a handbook for teachers and trainers. London: Third Edition Routledge.
[17] Farias, F., Moreira, C., Coutinho, E., Santos, I. S. (2012) iTest Learning: Um Jogo para o Ensino do Planejamento de Testes de Software. In: V Fórum de Educação em
Engenharia de Software (FEES 2012), Natal.
[18] Bezerra, C. I. M., Coutinho, E. (2013) Avaliação do Jogo iTestLearning: Um Jogo para o Ensino de Planejamento de Testes de Software. In: WEI - XXI Workshop sobre Educação em Computação (WEI 2013), Maceió. [19] Savi, R.; Wangenheim, C., Borgatto, A., (2011a). “Um
Modelo de Avaliação de Jogos Educacionais na Engenharia de Software”. Anais do ITESTLEARNINGV Simpósio Brasileiro de Engenharia de Software (SBES 2011), São Paulo.
[20] IEEE (2004). SWEBOK - Guide to the software engineering body of knowledge. IEEE Computer Society.
[21] IEEE (1998). IEEE Standard for Software Test Documentation, IEEE Std 829-1998, IEEE Computer Society.
[22] IEEE (1990). IEEE Standard Glossary of Software Engineering Terminology, IEEE Std.610.12-1990, IEEE Computer Society
[23] Selenium (2014). Ferramenta que automatiza testes funcionais ou de aceitação. Disponível em
http://docs.seleniumhq.org/. Último acesso em agosto de 2014.
[24] JMeter (2014). Ferramenta que automatiza a execução de testes de desempenho. Disponível em
https://jmeter.apache.org/. Último acesso em agosto de 2014. [25] Mantis (2014). Ferramenta para o registro de Bugs (defeitos). Disponivel em http://www.mantisbt.org/. Último acesso em agosto de 2014.
[26] TestLink (2014). Ferrramenta para documentação de casos de testes. Disponível em http://testlink.org/. Último acesso em agosto de 2014.
[27] Silva, A. R. (2011b) “Uma Metodologia de Testes em Software para Micro e Pequenas Empresas Estruturada em Multicritério”. Dissertação de Curso de Mestrado, Informática Aplicada, UNIFOR, Fortaleza.
[28] Kirkpatrick, D. L. (1994) “Evaluating Training Programs - The Four Levels”. Berrett-Koehler Publishers, Inc. [29] Keller, J. M. (1987) Development and use of the ARCS
model of motivational design. Journal of Instructional Development, v. 10, n. 3, p. 2–10.
[30] Bloom, B. S. (1956) Taxonomy of educational objectives: The classification of educational goals Handbook I, cognitive domain. New York; Toronto.
[31] Savi, R.; Wangenheim, C., Borgatto, A. (2011b) "Análise de um modelo de avaliação de jogos educacionais". Disponível em: https://sites.google.com/site/savisites/avaliacaode-jogos-educacionais.
