Lições Aprendidas na Aplicação de Critérios de Testes Funcionais Tradicionais e Adaptados em um Jogo Comercial Desenvolvido para a Plataforma Móvel

Lições Aprendidas na Aplicação de Critérios de Testes Funcionais Tradicionais e Adaptados em um Jogo Comercial Desenvolvido para a Plataforma Móvel (Versão Full) Luana M. de A. Lobão Instituto de Desenvolvimento Tecnológico, Manaus, Amazonas [email protected]

Marcos G. A. Da Costa Instituto de Desenvolvimento Tecnológico Manaus, Amazonas [email protected]

Abstract — The industry of digital games is one of the markets of fastest growing around the world. Much of this growth is related to the rise of entertainment market focused on mobile platforms, such as smartphones (more than 70% of game consumers use the mobile platform). With all this growth, the quality of this software product needs to be verified and validated. Aiming to contribute with practical experience in modelling test scenarios for games, this paper describes how to apply classic functional test criteria (causeeffect graph, state transitions and use case-based) and functional test criteria adapted to digital games (flow diagram and combinatorial testing) in the testing process of an action digital game for mobile platform developed in the software industry. The results suggest that the combination between test criteria is one of the best practices to be adopted. It is also possible analyze which criteria is best suited to model specifics features of a digital game. Tecnológico e Experimental Keywords—Software Testing Process; Game Testing; Test Criteria; Test Case Generation;

I. INTRODUÇÃO As plataformas móveis têm se apresentado como a plataforma que mais cresce com o passar dos anos no contexto da computação atual. Muito desse crescimento está associado com a facilidade e a praticidade no uso de serviços pelo dispositivo móvel. É possível usar aplicações móveis em vários contextos, seja na área de negócios (ex.: escolas, hospitais, bancos, etc), como na área de entretenimento (ex.: videos, filmes, jogos, etc). Em paralelo ao crescimento das plataformas móveis, um dos mercados que mais cresce atualmente é o de jogos digitais. Atualmente, o Brasil tem ocupado um papel importante no cenário da indústria de jogos digitais, sendo considerado o quarto mercado consumidor do mundo em jogos, e com o passar dos anos, entre os tipos de jogos desenvolvidos no país (para PCs, Web, dispositivos móveis), os que são direcionados para a plataforma móvel vêm causando forte impacto no aumento das vendas [14].

Andreza M. F. V. De Castro Instituto de Desenvolvimento Tecnológico Manaus, Amazonas [email protected]

Arilo C. Dias-Neto Instituto de Computação Universidade Federal do Amazonas Manaus, Amazonas [email protected]

Tendo em vista tal crescimento, é importante assegurar a qualidade desse tipo de produto antes de ir para as mãos de seus consumidores. É essencial que os aspectos funcionais de um jogo digital em um dispositivo móvel sejam testados antes que o produto final chegue ao mercado. Para testar tais aspectos, critérios clássicos de testes funcionais podem ser aplicados, tais como grafo causa-efeito, transição de estados e baseados em casos de uso [6]. No entanto, a literatura técnica oferece diversas estratégias de testes adaptadas a jogos digitais. Neste contexto, o principal objetivo desse artigo é fazer um estudo comparativo entre a aplicação de critérios de testes funcionais tradicionais e critérios de testes adaptados para jogos digitais. Ainda será investigado como a junção desses critérios de modelagem de casos de teste podem ser eficientes quando executados em conjunto em um processo de testes de um produto de jogo digital. Este artigo está organizado da seguinte forma: a Seção II apresenta o referencial teórico sobre desenvolvimento e testes para jogos digitais. Na Seção III é descrito um estudo de caso que visou a aplicação dos critérios de teste em um jogo digital chamado Wake Woody Infinity. Na Seção IV serão discutidos os resultados obtidos com o estudo de caso e as lições aprendidas a partir da experiência de aplicação de critérios de testes diversificados em jogos digitais e, finalmente, a Seção V apresenta as conclusões do estudo realizado, além de trabalhos futuros. II. REFERENCIAL TEÓRICO A. Desenvolvimento de Jogos Digitais Um jogo pode ser definido como uma atividade ou ocupação voluntária, exercida dentro de certos e determinados limites, dotado de um fim em si mesmo, que é acompanhado de um sentimento de tensão e de alegria e de uma consciência de ser diferente da vida cotidiana [8], governado ou definido por regras [11]. Como o foco desse trabalho é Jogos Digitais, para complementar o conceito dos pesquisadores citados acima, foi

definido o conceito que diz que o jogo digital é um software especial, pois conta com vários elementos em sua construção, além de possuir requisitos não funcionais relacionados como, por exemplo, o divertimento do jogador [11]. Estudos apontam que a maioria dos projetos de desenvolvimento de jogos não usa uma metodologia de desenvolvimento de software (ex.: Scrum, XP, Cascata, etc) e como consequência, muitos acabam fracassando sem antes virar um produto [2] [4]. Isso se deve ao fato de que a natureza de desenvolvimento de jogos é complexa, pois toda a sua etapa de criação e produção é multidisciplinar, ou seja, existem profissionais que fazem o enredo da história, outros o som, a arte, outros definem a jogabilidade e outros cuidam do desenvolvimento do algoritmo [3].

literatura técnica. Assim, um desafio constante nos projetos de software seria a seleção de técnicas e critérios de teste que mais se adequam as características do software a ser testado [7]. No entanto, cada categoria de software pode requerer um conjunto diferenciado de critérios para a geração de testes ou a adaptação dos critérios tradicionais. Isso dificulta a aplicação das técnicas de teste e resultam na necessidade de investir em pesquisas científicas a fim de entender a escalabilidade dos critérios de teste funcional às diferentes categorias de software existentes. O objeto do estudo proposto neste artigo é a área de jogos digitais e a análise e aplicação de critérios de teste funcional para garantir a qualidade deste tipo de software.

O desenvolvimento de jogos é geralmente composto por três etapas/fases [9]: Pré-produção (onde são definidos todo o conceito, roteiro, conteúdo e o gameplay (jogabilidade) do jogo; Produção (onde são desenvolvidos o material artístico do jogo e o desenvolvimento dos algoritmos); Pós-produção (onde são feitos os testes alfa, beta e ouro do jogo). Ao passar nestes testes, o jogo está pronto para ser publicado.

Teste para jogos digitais pode ser definido como um conjunto de processos que possuem atividades e técnicas que, quando planejadas e executadas, podem servir para: explorar áreas e cenários do jogo; verificar se uma regra definida está bem implementada; validar os estados do personagem principal conforme sua evolução na fase; procurar por um tipo de problema que seja característico de uma plataforma ou framework de desenvolvimento, e; validar se o jogo está divertindo ou não [12].

Na fase de pré-produção (foco deste artigo), é feita uma etapa crucial para o desenvolvimento do jogo, chamada de Game Design. Esta é responsável por gerar os requisitos do jogo. As principais características como gameplay (jogabilidade), controles, interfaces, comandos, desenhos, história, inimigos, etc, são especificadas. Durante o Game Design é gerado um documento chamado Game Design Document (GDD), também conhecido como Design Bible (DB), que é utilizado pelo time de design e desenvolvimento do projeto de jogo para modelar e especificar os elementos do jogo [9].

Assim como o teste para projetos de software de caráter geral, o planejamento de teste feito para jogos digitais leva em consideração uma série de regras definidas em um documento chamado de Game Design Document (GDD). Esse documento funciona como um documento de requisitos que define as regras, personagens, cenários, missões, mecânicas, dentre muitas outras características inerentes ao jogo. Portanto, a documentação e definição desses elementos e regras é de extrema importância para a execução dos testes. Todos esses elementos precisam funcionar bem para que o gameplay do jogo seja atraente e divertido [12] [10].

O escopo desse artigo trata de problemas relacionados ao gameplay do jogo, ou seja, do uso de critérios de teste funcional para encontrar falhas relacionadas à jogabilidade. No livro intitulado “Game QA & Testing” [10], os autores defendem que falhas relacionadas ao gameplay e suas mecânicas são as que mais causam desconforto (nível de severidade maior) aos usuários de jogos, pois esses são os elementos com os quais os usuários mais interagem durante a experiência de jogar. Portanto, os elementos que descrevem as mecânicas do gameplay do jogo precisam ser modelados para que o testador consiga aplicar técnicas e critérios de teste para geração ou execução automática de casos de teste.

O presente artigo mostra o uso de cinco critérios diferentes para testes funcionais em jogos digitais: três dos critérios aplicados são critérios de teste tradicionais da técnica funcional e os outros dois são critérios de testes adaptados para jogos [12].

B. Critérios de Testes Funcionais para Jogos Digitais Os testes de software podem ser classificados de acordo com a técnica para geração de testes utilizada, que são funcionais (caixa-preta), estruturais (caixa-branca) ou baseadas em defeitos. Este artigo possui como foco a aplicação da técnica de teste funcional, que é baseada na especificação do software para a modelagem de casos de teste [6]. A técnica de teste funcional possui diversos critérios para a geração de testes, como por exemplo particionamento em classes de equivalência, análise do valor limite e grafo causa-efeito, além de outras propostas publicadas na literatura técnica. Em [1], é apresentado um mapeamento sistemático sobre os 20 principais critérios de geração de testes funcionais disponibilizados na

C. Critérios Tradicionais (TT) Foram adaptados 3 critérios de teste funcional tradicionais para a criação dos casos de teste: grafo causa-efeito (também conhecido como tabela de decisão), transição de estados e uma adaptação do critério baseados em casos de uso [6]. Estes critérios foram escolhidos pelo fato de a organização de software onde o experimento foi executado já possuir um processo de teste que utiliza esses critérios para modelar os casos de teste [5]. Por serem critérios largamente conhecidos na literatura técnica, não serão descritos com detalhes neste artigo. Na Seção III.B pode ser vista a aplicação desses critérios no estudo de caso proposto. D. Critérios adaptados para Jogos:Test Flow Diagram (TFD) O Test Flow Diagrams (TFD) é um critério de teste funcional adaptado para jogos digitais [12]. Esse critério utiliza diagramas que modelam a perspectiva do usuário final para executar os testes. Basicamente, os fluxos são desenhados com uma linha que liga um estado do jogo a outro e com uma seta

indicando a direção do fluxo. Cada fluxo possui um número único, um evento e uma ação. O caractere dois pontos (“:”) separa o número e o nome do evento, e a barra (“/”) indica a ação que ocorrerá no jogo a partir do evento feito pelo usuário (Figura 1).

Figura 1. Componentes do TFD.

Nesse critério, os elementos são chamados de eventos, ações ou estados. Os eventos são operações que são iniciadas pelo usuário, assim como mecanismos internos do jogo. As ações são os comportamentos transitórios ou temporários que podem ser causados no sistema a partir de um evento, como por exemplo efeitos visuais, sons, comportamentos do personagem principal ou algum feedback automático do jogo. Os estados representam um comportamento definitivo no jogo, ou seja, caso algum evento feito pelo usuário encadeie uma ação no jogo que acabe gerando um estado inconsistente, então teremos uma falha. O critério TFD é formado por três etapas: (1) Preparação, (2) Alocação e (3) Construção. A preparação consiste em identificar os requisitos que podem ser inseridos e modelados a partir de fluxos de estados. Esse processo de preparação pode ser suportado por todo e qualquer documento de especificação do jogo, como o seu GDD, telas de navegação (wireframes), dentre outros. A segunda etapa, a Alocação, tem como objetivo estimar o número de TFDs necessários para cobrir e mapear os elementos, requisitos ou funcionalidades escolhidos para o teste. Por fim, a etapa de Construção é a parte mais prática do planejamento, pois é onde os TFDs previamente pensados são colocados em uma ferramenta de modelagem. Nessa etapa, o testador deve modelar os estados e fluxos pensando como o usuário irá jogar o jogo. Terminada a construção do diagrama, os caminhos de execução dos casos de teste podem ser enumerados. Mais detalhes sobre este critério para geração de testes funcionais em jogos estão descritos em [12]. E. Critérios adaptados para Jogos: Test Combinatorial in Pair (TC) O segundo critério de teste funcional que também foi adaptado para jogos é conhecido como Test Combinatorial in Pair (TC). Esse critério faz a geração de casos de teste baseada na observação de que a maioria das falhas são ocasionadas pela interação de, no máximo, dois fatores. Ele garante que todos valores utilizados para teste serão combinados pelo menos uma vez com todos os valores dos outros parâmetros inseridos, gerando o menor número de casos de teste possível. Em jogos,

esse critério de teste é utilizado para garantir uma maior cobertura nos eventos que podem ocorrer no gameplay, permitindo jogar, por exemplo, todos os modos de jogo de forma combinada com todas as características possíveis dos personagens [12]. Para a execução desse critério, utiliza-se parâmetros de entrada que, por sua vez, possuem valores. Parâmetros são utilizados para modelar os elementos do jogo que serão incluídos nos testes, como: os modos do jogo, as configurações, opções de customização e ações dos personagens no jogo, dentre outros. Valores são as escolhas possíveis para cada um desses parâmetros e podem ser classificados em: enumerados, de intervalos ou limites. Os valores enumerados são aqueles cujas opções não possuem relação numérica ou sequencial entre si, como os modos de jogo; os de intervalos são os valores que podem ser escolhidos dentre um intervalo numérico, como o volume do áudio; e os limites são fronteiras do jogo que desejam ser testadas, como checkpoints, por exemplo [12]. Após a seleção do conjunto de parâmetros e valores, para a execução do algoritmo de combinação é feita uma tabela que combina os parâmetros, valores entre si e suas dimensões – números de valores que o parâmetro possui. A dimensão de uma tabela é medida pela quantidade de valores de cada um de seus parâmetros e pode ser escrita como a dimensão de um parâmetro elevado à quantidade de parâmetros que possuem aquela dimensão, em ordem decrescente. Por exemplo, uma tabela que possui um parâmetro de três valores e dois parâmetros de quatro valores pode ser descrita assim: . Isso significa dizer que seriam necessários , ou 48, casos de teste para testar todos os pares possíveis. Para exemplificar esse critério, pode-se usar como exemplo um jogo aonde um guerreiro deve vencer os inimigos para salvar uma cidade. O jogador pode escolher entre os guerreiros branco e vermelho e uma espada ou um bastão como arma. Além disso, o jogo possui os níveis fácil, médio e difícil. Com essas informações é possível extrair três parâmetros: tipo de personagem, que pode ser branco ou vermelho; arma, que pode ser espada ou bastão; e nível do jogo, que pode ser fácil, médio e difícil. Através da combinação dos valores de cada parâmetro, a Tabela 1 é construída, permitindo todas as combinações em par possíveis entre as colunas Personagem e Arma, Arma e Nível e Personagem e Nível, na menor quantidade de linhas de tabela possíveis. TABELA 1. EXEMPLO DE TABELA DE CASOS DE TESTE GERADA A PARTIR DO CRITÉRIO TC. Personagem Branco Vermelho

Arma Espada Espada

Nível Fácil Fácil

Branco

Bastão

Médio

Vermelho

Bastão

Médio

Branco

Espada

Difícil

Vermelho

Bastão

Difícil

Cada linha da tabela representa um caso de teste que deverá ser executado, ou seja, para testar a primeira linha deve-se

executar o jogo com o guerreiro branco carregando uma espada no nível fácil. Como a tabela possui um parâmetro de três valores e dois parâmetros de dois valores, a sua dimensão é , ou seja, esse critério diminui de 12 para 6 casos de testes que cobrem todos os valores. Para facilitar a criação da tabela de casos de teste do TC, a ferramenta ALLPAIRS Test Case Generation Tool1 [12] pode ser utilizada. Ela recebe uma tabela com todos os parâmetros e valores que deseja-se testar e retorna a tabela de casos de teste gerada. A próxima seção descreve o estudo realizado para aplicação e avaliação dos critérios de testes funcionais em jogos digitais.

ações ou metas que o jogador deve cumprir para que consiga passar de nível. Cada nível no sistema do jogo indica a quantidade de vezes que os pontos das manobras devem ser multiplicados para gerar a pontuação corrente. Por exemplo, se o Woody está no nível X1, toda a pontuação que o jogador obtiver no jogo será multiplicado por 1. Caso o jogador esteja no nível X5, toda e qualquer pontuação que o jogador obtiver no jogo será multiplicada por 5, e assim sucessivamente. Na Figura 2 é possível ver a imagem com elementos da mecânica do gameplay do jogo.

III. ESTUDO COMPARATIVO ENTRE CRITÉRIOS DE TESTES FUNCIONAIS PARA JOGOS O estudo realizado neste trabalho visou a aplicação e comparação dos critérios de teste de apoio a testes funcionais em jogos digitais descritos na seção anterior para testes em um jogo comercial desenvolvido para a plataforma móvel. Essa temática foi escolhida por conta da falta de estudos práticos no ambiente da indústria que usam critérios e técnicas de forma sistemática na validação desta categoria de jogos. O estudo prático foi concentrado na validação do gameplay do jogo em questão, pois é nesse elemento que o jogador interage com as regras e mecânicas do jogo. Assim, falhas que afetam o gameplay e a experiência do usuário em um jogo podem ser consideradas de médias a críticas [10]. A. Características do Jogo Testado O jogo testado é classificado como jogo de ação desenvolvido para a plataforma móvel, onde a principal característica é exigir atenção e habilidade de quem está jogando [13]. Seu nome é Wake Woody Infinity2. O jogador precisa ter atenção e domínio sobre os controles e comandos. Nesse jogo, o personagem principal Woody (controlado pelo jogador) conta com três tipos de comandos: um tap 3 na tela do celular para dar um salto; dois taps na tela do celular para dar saltos duplos; e um tap&hold (lê-se “tap and hold”) que é caracterizado por um tap seguido de uma ação em que o usuário mantém o dedo pressionado na tela (hold), isso faz com que o Woody mergulhe até que o usuário retire o dedo da tela. O jogador precisa fazer o personagem passar por obstáculos que causam danos e atrasos, e obstáculos que causam morte, além de pegar coletáveis que são elementos de jogo que dão alguma vantagem ao Woody. O jogo é ainda classificado como Infinity Runner, e sua característica “infinita” é baseada em tempo e em níveis. Com relação ao tempo, o sistema do jogo inicia a corrida com 15 segundos, que são decrementados a medida que o Woody avança na fase. Esse tempo é reiniciado quando o Woody colide com um elemento chamado “checkpoint”. Com relação aos níveis, o sistema de jogo trabalha com uma sistemática de missões. Cada nível possui três missões atreladas a ele, que são 1 ALLPAIRS Test Case Generation Tool http://www.satisfice.com/tools.shtml 2

https://wakewoody.com/ 3 Tap é a ação de pressionar ou tocar na tela do dispositivo.

Figura 2. Mecânica do Jogo Wake Woody Infinity.

B. Preparação e Projeto para o Estudo A primeira etapa realizada antes de iniciar a modelagem dos casos de teste foi a “Identificação do gameplay” do jogo, ou seja, o design de sua jogabilidade [13]. Esse termo serve para identificar os requisitos ou aspectos estruturais e funcionais de um jogo. Com a identificação do gameplay, foi possível o planejamento dos testes, ou seja, a estruturação de atividades para que a execução fosse feita. Dessa forma, o estudo contou com as seguintes características:  Plataforma testada: Android.  Versão do Jogo: 1.2.  Elementos funcionais do gameplay a serem testados: o

Estados do personagem: Iddle (estado inicial), Spinning (estado após comando do jogador), Damage (estado após colisão com obstáculo que causa dano), Dead (estado após colisão com obstáculo que causa morte) e Collectible effect (estado após a coleta de elementos);

o

Interação do personagem com os obstáculos.

o

Pontuações a partir de manobras do personagem ou coleta de moedas.

o

Elementos coletáveis que ajudam a evolução do personagem no jogo (ex.: Time Freeze, Magneto, 2xCoins).

o

Elementos power-ups (também conhecidos como consumíveis) que também ajudam na evolução do personagem no jogo (Continue, Head Start, 2sPts).

o

Modos do Jogo, como Som e Vibração.

o

Níveis do jogo (missões).

 Elementos não funcionais que afetam diretamente o gameplay do jogo: o

Interrupções no dispositivo (ligações, mensagens, mensagem de bateria, etc.)

C. Execução do Estudo 1) Aplicação dos critérios de teste funcional tradicionais (TT) Os critérios de teste funcional tradicionais utilizados para a criação do conjunto de casos de teste foram: grafo causa-efeito (também conhecido como tabela de decisão), transição de estados e uma adaptação do critério baseado em casos de uso. Todos os critérios foram aplicados com base nas regras descritas no GDD do jogo.

Por fim, o critério de geração de teste funcional baseado em casos de uso foi adaptado para o processo de teste do jogo Wake Woody Infinity a partir do GDD que descreve textualmente as regras válidas para o jogo e alguns cenários de exceção. A equipe de teste usou o princípio do critério de casos de uso que usa um ator (aqui representado pelo jogador ou Woody) que executa uma série de cenários válidos e inválidos durante a execução do jogo. As principais regras utilizadas a partir desse princípio foram: pontuações a partir de manobras do personagem ou coleta de moedas, uso dos elementos powerups (Continue, Head Start, 2sPts), modos do jogo (Som ou Vibração), evolução nos níveis do jogo (missões).

O critério de geração de teste funcional baseado no grafo de causa-efeito levou em consideração o comportamento do jogo quando uma funcionalidade era combinada com alguma interrupção. Na Tabela 2, é possível ver um pequeno exemplo de conjunto de casos de teste gerados a partir desse critério utilizando a regra de colisão do Woody com elementos coletáveis combinados com as interrupções ou ações de background que podem ocorrer com o dispositivo móvel. As colunas da tabela correspondem a alguma regra de negócio do jogo que define uma única combinação de condições. Essa combinação resulta na execução das ações associadas. TABELA 2. EXEMPLO DO CRITÉRIO DE TABELA DE DECISÃO APLICADO AO JOGO. Figura 3. Exemplo do critério de transição de estados aplicado. Coletáveis x Interrupções Coletar Time Coletar Causas / Regras  Freeze Magneto Receber chamada de voz F V Bateria fraca do smartphone F V Coletar Magneto F F Travar o smartphone F F Ações (Efeitos) Bloquear o efeito do coletável 2xCoins e ativar o efeito do coletável Magneto. Ir para background e após evento de interrupção voltar X X ao jogo com o efeito do coletável ativo

Coletar 2xCoins F F V V

X

X

O critério de geração de teste funcional baseado na transição de estados levou em consideração os estados que o Woody poderia assumir durante o jogo (iddle, spinning, damage, dead e collectible effect) e as eventuais ações ou eventos que possibilitam a transição de um estado para o outro dentro do jogo, como por exemplo ações do jogador ou eventos relacionados à interação (colisão) do Woody com algum outro objeto na cena do jogo. Um dos exemplos da aplicação desse critério pode ser visto na Figura 3. Exemplificando uma regra, para que o Woody vá do estado iddle para o estado dead ele precisa colidir com uma bomba (transição). Da mesma forma, os outros estados e transições podem ser interpretados.

2) Aplicação do critério de teste Test Flow Diagram (TFD) A aplicação do critério de geração de testes funcionais TFD se deu a partir da execução das três fases mencionadas do modelo. A fase de preparação foi feita com a análise de todos os elementos do gameplay selecionado. A partir dessa seleção, foi feita a fase de alocação, ou seja, a criação de cenários a partir das funcionalidades selecionadas. Essa fase serve para dimensionar a quantidade de fluxos que o TFD terá ou a quantidade de TFDs, se considerar que um fluxo equivale a um TFD. O resultado desse processo de alocação foi a estimativa de 27 fluxos que representavam os possíveis comportamentos que poderiam acontecer com o jogador durante a interação dele com o gameplay. Após essa etapa de alocação, foi feita a fase de construção com o auxílio da ferramenta Bizagi Modeler. Dos 27 fluxos citados, foram instanciados 31 casos de testes, considerando os cenários possíveis para cada comportamento mapeado. Além desses 31 casos de teste, foram considerados mais 10 casos de teste que validavam os níveis do jogo, ou seja, as missões que o usuário precisava concluir durante o jogo. Um exemplo de TFD criado para o jogo está apresentado na Figura 4. Esse TFD mostra o fluxo de morte do jogador. Nesse TFD, o estado inicial é representado pela tela inicial do jogo. Após o evento Press “PlayButton” ser executado pelo jogador, a ação a ser realizada é iniciar o gameplay, chamada de “GamePlayStartsAfter5Seconds”.

Figura 4. Esquema do TFD na funcionalidade de morte do jogo testado.

Após esse fluxo, foi modelado que o próximo evento que poderia ocorrer era a morte do jogador, seja pelo tempo ou por bomba. O nome escolhido para o evento levou em consideração a característica de cada possível morte. No entanto, a ação dos dois era a mesma, ou seja, após a animação de quais missões foram concluídas, apareceria a tela de game over. Assim, foi considerado nesse fluxo que o estado final era a tela de game over. 3) Aplicação do critério de Test Combinatorial (TC) Levando em consideração os requisitos a partir dos elementos funcionais e não funcionais selecionados, a tabela de parâmetros e valores ficou conforme a Tabela 3. Dentre todos os parâmetros de configuração que podem ser ajustados no jogo, o som e a vibração influenciavam durante a corrida. Sendo assim, eles foram considerados nos testes. Seus valores podem ser ligados ou desligados. TABELA 3. PARÂMETROS E VALORES DO JOGO TESTADO. Elementos Som Vibração Imã (Magneto) Time Freezer Double Coins (2xCoins) HeadStart Points Multiplier Continue Subir de Nível Morte Manobra Interrupção

Possíveis Valores Y ou N Y ou N Nível 1, Nível 2, Nível 3 Nível 1, Nível 2, Nível 3 Nível 1, Nível 2, Nível 3 Y ou N Y ou N Y ou N Y ou N Bomba ou Tempo Spin, Underwater, Yo-Yo, Legendary Ligação, Mensagem, Home, Bloqueio ou Bateria

Os três elementos coletáveis do jogo (imã, time freezer e double coins) iniciam no primeiro nível e podem evoluir até o nível 3 por meio de compra do usuário pela loja, aumentando o seu tempo de execução no jogo e, no caso do imã, o alcance em pegar moedas. Por isso, foram considerados todos os níveis como valores possíveis para cada um deles. TABELA 4

foi gerada.

Os parâmetros do tipo consumíveis (HeadStart, Points Multiplier e Continue) são comprados na loja e podem ser utilizados ou não durante o jogo, assumindo esses como sendo os valores do parâmetro. Note que o parâmetro consumível não leva em conta se o usuário possui ou não os consumíveis, mas sim se ele vai ou não usá-los no jogo. Outros parâmetros considerados foram as ações que o usuário podia executar durante uma corrida. O parâmetro Subir de nível diz se o usuário cumpriu a última missão de um nível durante a corrida e automaticamente foi elevado para o próximo nível e pode ser falso ou verdadeiro. O parâmetro Morte informa a maneira que o usuário perdeu a corrida: por tempo, quando seu tempo chegou a zero; ou pelo objeto bomba. O parâmetro Manobra lista todas as manobras que o usuário pode executar durante uma corrida: Spin (um pulo com giro), Underwater (quando o usuário mergulha uma vez), Yo-Yo (quando o usuário realiza outro pulo durante uma manobra) e Legendary (quando o usuário executa seguidas manobras do tipo Underwater). O último parâmetro considerado foi relacionado à interrupção que pode acontecer durante o jogo. Interrupções podem ser ligações, mensagens de texto, mensagem de bateria fraca, notificações de outros aplicativos, dentre outros, que podem ocasionar falhas na execução do jogo. Após a seleção dos parâmetros e criação da tabela, foi necessário criar um arquivo texto (entradawoody.txt) com os dados da tabela. Esse arquivo então foi inserido no diretório da ferramenta ALLPAIRS e utilizando o DOS do Windows o comando allpairs entradawoody.txt > combinatorio-geral.txt foi executado, gerando o arquivo de saída combinatorio-geral.txt. Para uma melhor visualização do resultado, o arquivo combinatorio-geral.txt foi copiado para o Excel e a a

TABELA 4. COMBINAÇÃO EM PAR GERADA PELA FERRAMENTA ALLPAIRS. Case

Som

Vibração

Imã

Time Freezer

Double Coins

HeadStart

Points Multiplier

Continue

Subir de Nível

Morte

1

Y

Y

Nível 1

Nível 1

Nível 1

Y

Y

Y

Y

2

N

N

Nível 2

Nível 2

Nível 2

N

N

N

N

3

Y

N

Nível 3

Nível 2

Nível 3

Y

N

Y

4

N

Y

Nível 2

Nível 1

Nível 1

N

Y

5

Y

Y

Nível 1

Nível 3

Nível 2

N

6

N

N

Nível 3

Nível 3

Nível 3

Y

7

Y

N

Nível 2

Nível 1

Nível 3

8

N

Y

Nível 1

Nível 2

9

N

Y

Nível 2

10

Y

Y

11

~Y

N

12

N

13

Manobra

Interrupção

Pairings

Bomba

Spin

Ligação

66

Tempo

Underwater

Ligação

66

Y

Tempo

Spin

Mensagem

50

N

N

Bomba

Underwater

Mensagem

41

N

Y

N

Bomba

Yo-Yo

Home

44

Y

N

Y

Bomba

Legendary

Home

41

Y

Y

N

N

Tempo

Yo-Yo

Bloqueio

29

Nível 1

N

N

Y

Y

Tempo

Legendary

Bloqueio

28

Nível 3

Nível 2

Y

Y

Y

Y

Tempo

Spin

Bateria

22

Nível 3

Nível 1

Nível 3

N

N

N

N

Bomba

Underwater

Bateria

20

Nível 1

Nível 2

Nível 1

Y

Y

N

Y

Tempo

Underwater

Home

11

~N

Nível 3

Nível 3

Nível 1

~N

~N

~Y

Y

Bomba

Yo-Yo

Bloqueio

9

Y

N

Nível 1

Nível 1

Nível 2

~Y

~N

~Y

N

~Bomba

Legendary

Bateria

8

14

~N

~Y

Nível 3

Nível 3

Nível 3

~N

~Y

N

N

Bomba

Spin

Ligação

6

15

~N

~Y

Nível 1

Nível 1

Nível 2

~Y

~Y

~N

~Y

~Tempo

Yo-Yo

Mensagem

4

16

~N

~Y

Nível 2

Nível 2

Nível 2

~N

~N

Y

~Y

~Tempo

Underwater

Home

3

17

~Y

~N

~Nível 2

~Nível 2

Nível 1

~N

~Y

~N

~N

~Bomba

Yo-Yo

Bateria

4

18

~Y

~Y

Nível 2

Nível 2

Nível 3

~Y

~N

~Y

~Ñ

~Tempo

Legendary

Ligação

3

19

~Y

~Y

Nível 3

Nível 3

Nível 2

~Y

~Y

~Y

~N

~Bomba

Underwater

Bloqueio

4

20

~Y

~N

Nível 1

Nível 1

Nível 3

~N

~Y

~N

~N

~Bomba

Legendary

Mensagem

2

21

~N

~N

~Nível 3

~Nível 3

~Nível 1

~Y

~N

~N

~Y

~Tempo

Yo-Yo

Ligação

1

22

~Y

~N

~Nível 2

~Nível 2

~Nível 2

~N

~N

~N

~N

~Bomba

Spin

Home

1

23

~N

~Ñ

~Nível 1

~Nível 1

~Nível 3

~N

~N

~N

~N

~Tempo

Spin

Bloqueio

1

Cada linha da tabela gerada representa um caso de teste cujos parâmetros devem possuir os valores presentes nas células. Todos os valores que começam com um til (~) são coringas, ou seja, podem ser substituídos por qualquer um dos valores do parâmetro da coluna correspondente. Como a tabela possui a dimensão de , seriam necessários 69.120 casos de teste para que todos os pares fossem cobertos. Com o uso do critério apresentado, essas combinações puderam ser realizadas em apenas 23 casos de teste. Como o objetivo era o teste de gameplay, cada caso de teste foi criado de forma que o testador jogasse uma corrida com todos os valores dos parâmetros informados na tabela e observasse o comportamento dos elementos do jogo. Além desses 23 casos de teste, foram acrescentados mais 10 para a validação referente a cada nível do jogo, aonde o testador deveria passar das missões com o intuito de verificar a evolução desses níveis. Na próxima seção são analisados os resultados obtidos a partir deste experimento. IV. ANÁLISE DOS RESULTADOS DO EXPERIMENTO A. Análise das Métricas Coletadas Para análise dos critérios de geração de testes funcionais avaliados neste estudo, foram utilizadas algumas métricas que

visam apresentar indicadores de eficácia e eficiência sobre o comportamento de tais abordagens. Os resultados das métricas coletadas podem ser vistos na Tabela 5. TABELA 5. MÉTRICAS COLETADAS POR CRITÉRIO DE TESTE FUNCIONAL. Métricas Features testadas Nº de casos de teste Nº de falhas reportadas Esforço (em hs) para o projeto de teste Esforço (em hs) para execução dos testes Nº de falhas reportadas / Nº casos de teste Nº de casos de teste / Features testadas Nº de falhas reportadas / Features testadas Esforço (em horas) para o projeto de teste / Nº de casos de teste Esforço (em horas) para execução dos testes/ Nº de casos de teste

9 45 21

Test Flow Diagram (TFD) 9 41 16

Test Combinatorial in Pair (TC) 9 33 15

40h

32h

6h

24h

9h

15h

0,46

0,39

0,45

5

4,56

3,67

2,33

1,78

1,67

0,89

0,78

0,18

0,53

0,22

0,45

Teste Tradicional

Analisando os resultados e levando em consideração as falhas encontradas, tem-se a distribuição das falhas entre os critérios de teste avaliados conforme a Figura 5. Ao todo, cinco falhas foram encontradas com a utilização de todos os critérios. Duas falhas foram encontradas em comum pelos critérios TFD e TC. Também duas falhas foram encontradas em comum pelos critérios do TFD e TT. As falhas comuns entre os critérios TT e TC foram três. Analisando as falhas individualmente identificadas pelos critérios, observa-se que o critério TFD revelou 7 falhas, o critério TC revelou 5 falhas e o conjunto de critérios TT foi quem mais revelou falhas, 11 ao total.

B. Lições Aprendidas Muitas lições aprendidas foram observadas na execução desse estudo. As principais lições estão relacionadas às boas práticas percebidas durante a aplicação dos critérios de teste tradicionais e adaptados para jogos digitais. Dessa forma podese destacar:  A combinação entre os critérios é uma ótima solução para teste, pois houveram falhas diferentes encontradas em cada critério.  TFD é mais eficiente ao mapear e testar fluxos de conexão, telas, navegação, fluxos de funcionalidades dos botões.  Nos testes combinatórios, é possível perceber que parâmetros não interferem entre si, o que pode facilitar futuros testes.  É ideal usar o mínimo de parâmetros possível na TC. Quanto mais parâmetros na tabela, a dimensão aumenta e com isso o número de casos de teste também.

Figura 5. Distribuição das Falhas reveladas por critério de teste.

A Tabela 6 descreve um resumo das características destas falhas identificadas por cada agrupamento de critérios de teste, para facilitar o entendimento da cobertura provida por cada critério. As falhas reveladas na Tabela 6 foram agrupadas de acordo com as características funcionais e comportamentais do jogo informadas na seção III.B para facilitar a análise da cobertura das funcionalidades por critério de teste utilizado. Os agrupamentos podem ser vistos na Tabela 7. Durante a execução desse experimento e analisando os dados mostrados na Tabela 6 e Tabela 7, pode-se notar que o critério TFD revelou mais falhas referentes às categorias F, E, B, G, possuindo uma melhor cobertura com relação ao critério TC, ambos adaptados para jogos. No entanto, os critérios TT revelaram falhas das categorias B, D, E, F, G, H, sendo o conjunto de critérios que mais revelou falhas e teve melhor cobertura, comparando com os critérios de teste para jogos. Com o uso dos critérios tradicionais (TT), foi possível mapear e explorar mais funcionalidades do aplicativo, por isso a maior quantidade de falhas. Do ponto de vista do esforço, o critério TC foi quem requereu menos esforço para projetar e gerar os casos de teste. No entanto, na fase de execução, esse critério é o segundo mais trabalhoso, perdendo apenas para TT. Isso acontece pelo fato desse critério gerar uma quantidade grande de combinações necessárias para satisfazer um caso de teste. O critério TT precisou de mais esforço para gerar e executar casos de teste se comparada com os critério TC e TFD. O critério TFD também obteve um tempo considerável em geração de casos de teste. No entanto, foi o critério que precisou de menos esforço na execução dos testes.

Além disso, vários pontos fracos e pontos fortes do uso de cada critério foram mapeados. Para os critérios TT, seus pontos fracos seriam: Não é tão natural perceber casos de teste semelhantes ou duplicados; Apesar de ser fácil fazer a alteração dos casos de teste caso haja erro no planejamento, é difícil e não natural estabelecer quais os casos de teste que serão afetados pela mudança, portanto o retrabalho em analisar quais os outros casos de teste afetados pela mudança em um é maior do que o percebido no TFD; Planejamento de casos de teste é mais demorado, pois é planejado e previsto todos os possíveis exceções que podem ocorrer durante o jogo, e cada uma vira um caso de teste diferente. Por outro lado, seus pontos fortes são: Caso haja erro no planejamento é simples fazer as modificações nos casos de teste; Maior cobertura no sentido de explorar mais as funcionalidades . Para o critério TC, seus pontos fracos são: Quanto maior a quantidade de parâmetros, mais difícil será a execução dos casos de teste; Caso haja erro no planejamento dos testes, toda a execução será perdida. Já seus pontos fortes são: Garante a cobertura em par de todos os parâmetros inseridos; Reduz a quantidade de casos de teste; Planejamento do caso de teste é mais rápido. Por fim, para a o critério TFD, seus pontos fracos são: Não é possível mapear os comportamentos de som de forma natural (ex: falhas relacionadas ao som das manobras foram reveladas pelo critério TT); Não é possível combinar ações de forma natural e menos poluídas; Dependendo da quantidade de estados do jogo, é possível que a modelagem dos fluxos fique complexa. Por outro lado, seus pontos são: Planejamento em forma de diagrama visual com a UI oficial do jogo; Não é preciso especificar de forma textual o passo a passo do caso de teste; Caso haja erro no planejamento, é simples modificar o TFD e consertar o erro de planejamento, e apenas aquele fluxo é perdido sem interferir nos outros já criados; Execução dos testes é mais rápida.

TABELA 6. RESUMO DE FALHAS ENCONTRADAS.

TFD (7)

TC (5)

TT (11)

TFD ∩ TC (2) TFD ∩ TT (2) TC ∩ TT (3) TFD ∩ TC ∩ TT (5)

                     

Som da interação do personagem com os objetos da cena Som do narrador Tempo de execução dos power-ups Colisões Multiplicador de pontos a partir do nível Pontos de manobras Tracking de missões Som da contagem inicial Indicador dos coletáveis Interrupções Mudança no visual de alguns elementos em cena Animação de tela Colisões Tracking de missões Uso de Power-ups Mensagens de manobras Multiplicador de pontos a partir do nível e a partir do power-up de 2xPts Tracking de missões Tempo de execução dos power-ups Avanço de nível a partir da conclusão de missões Uso de power-up Mensagens de pontuação TABELA 7. AGRUPAMENTO DAS FALHAS

Categorias

Falhas encontradas

A.

Estados do personagem



n/a

B.

Interação do personagem com os obstáculos

C.

Pontuações

      

Colisões Mudança no visual de alguns elementos em cena Animação de tela Colisões Pontos de manobras Mensagens de manobras Mensagens de pontuação

D.

Elementos coletáveis



Indicador dos coletáveis

E.

Elementos power-ups

F.

Modos do Jogo (Som/Mudo e Vibração/Sem Vibração)

G.

Níveis do jogo

H.

Interrupções no aparelho celular

         

Tempo de execução dos power-ups Uso dos power-ups Multiplicador de pontos a partir do power-up de 2xPts Som da interação do personagem com os objetos da cena Som do narrador Som da contagem inicial Multiplicador de pontos a partir do nível Tracking de missões Avanço de nível a partir da conclusão de missões Interrupções

V. CONCLUSÕES E TRABALHOS FUTUROS Esse artigo descreveu o estudo sobre os critérios de teste funcional tradicional e critérios de teste especializados a jogos digitais aplicadas em um jogo comercial. O objetivo principal foi analisar a efetividade de cada critério com relação ao esforço necessário para aplicação da técnica de teste funcional além de analisar quais as categorias de falhas que cada critério revela. Esse estudo revelou que apesar da combinação dos critérios serem uma ótima opção para o processo de modelagem e

execução de testes, cada critério possuiu um desempenho diferente, se destacando das demais em determinada tarefa. Por exemplo, os Critérios Tradicionais (TT) ofereceram mais cobertura de funcionalidades. Já o critério Test Flow Diagram (TFD) foi o mais eficiente em executar casos de teste. Por fim, o critério Test Combinatorial (TC) foi o mais eficiente em mapear e planejar casos de teste. Como trabalhos futuros, pretende-se criar um framework que combine os pontos fortes de cada critério tradicional de teste e dos critérios adaptados para jogos. A partir disso, executar o framework teórico em mais gêneros de jogos

digitais (Ação, Aventura, Estratégia, RPG, Esporte, Simulação, Tabuleiro e Quebra-Cabeças), e fazer um comparativo sobre qual critério melhor se adequa a determinado gênero de jogo. REFERÊNCIAS [1]

[2] [3] [4]

[5]

[6] [7]

[8] [9]

[10] [11]

[12] [13]

[14]

Arantes, G. F.; Leitão-Jr, P. S.; Vincenzi, A. M. R. and Lucena, F.N. “Functional Software Testing: A Systematic Mapping Study”. In: Eighth International Conference on Software Engineering Advances, 2013, pp 11-17, ISBN: 978-1-61208-304-9. Bethke, E. “Game Developer's Guide to Design and Production”. Wordware Publishing Inc., Plano, Texas, 2002. Blow, J. “Game Development: Harder thank you think”. Queue, ACM, New York, USA, v. 1, n. 10, 2004, pp. 28-37. Callele, D.; Neufeld, E. and Shneider, K. “Requirements engineering and the creative process in the video game industry. In: 13th IEEE International Conference on Requirements Engineering. DC, USA: IEEE Computer Society, 2005. Collins, E. and Lucena, V. “Iterative Software Testing Process for Scrum and Waterfall Projects with Open Source Testing Tools Experience”. In Proceedings of the 22nd IFIP International Conference on Testing Software and Systems (ICTSS'10), 2010, pp. 115-120. Delamaro, M.; Jino, M. e Maldonado, J. “Introdução ao Teste de Software”. Elsevier Acadêmico, 1ª edição, 2007. ISBN: 8535226346. Dias-Neto, A. and Travassos, G. “Supporting the Combined Selection of Model-based Testing Techniques”. IEEE Transactions on Software Engineering, v. 40, 2014, pp. 1025–1041. Huizinga, J. “Homo Ludens”. 4ª ed. São Paulo: Perspectiva, 1993. Leite, P. e Mendonça, V. “Diretrizes para Game Design de Jogos Educacionais”. Proceedings of SBGames, Art & Design Track, Full Papers, 2013. Levy, L., and Novak, J. “Game QA & Testing”. 1st edition. Delmar: Cengage Learning, 2009. Salen, K. and Zimmerman, E. “Rules of Play: Game Design Fundamentals”. Hardcover: 688 pages Publisher: The MIT Press, Language: English, 2003. Shultz, C.; Bryant, R. and Langdell, T. “Game Testing All In One”. United States: Thomson/Course Technology, 2005. Villas, R. “Mercado de Jogos”. In: Azevedo, E. (Ed.), Desenvolvimento de Jogos 3D e Aplicações em Realidade Virtual, pp. 1-28. Elsevier: Campus. Rio de Janeiro, 2005. BNDES “Relatório Final – Mapeamento da Indústria Brasileira e Global de Jogos Digitais”, http://www.bndes.gov.br/SiteBNDES/bndes/bndes_pt/Galerias/Arquivos /conhecimento/seminario/seminario_mapeamento_industria_games0420 14_Relatorio_Final.pdf, acessado em abril de 2014.