INFINITE RUNNER

Ce second projet d'une dimension supérieure m'a permis de consolider mes acquis et d'évoluer en toute autonomie dans la création des tests, documents et gestion. J'ai aussi réutilisé mes acquis et mes expériences antérieures dans l'industrie manufacturière.

Les métiers de qualité industrielle possèdent une base commune avec la qualité informatique. Après une petite adaptation, mes pratiques, outils et compétences me servent dans mon nouveau métier de superviseur en QA test.

 

Ci-dessous le principe de l'organisation de la création des jeux. Initialement, un Game design document (GDD) est produit par l'équipe  de Game design.

L'organisation des différentes formations du centre de formation "Gaming Campus" induit une organisation KANBAN pour le projet.

 

Le thème est un "Infinite Runner" comme on peut en trouver sur les boutiques d'applications de nos téléphones. Ces informations sont la base du cahier des charges. Celui-ci évoluera avec l'avancée des idées, des besoins et des réunions projets.

 

A partir de ces informations, chaque développeur s'approprie le concept pour développer son jeu. Cela a permis d'obtenir trois jeux différents.

 

Pour réaliser une session de tests de chaque jeu, l'équipe QA s'est organisée en appliquant le schéma ci-dessous.

La gestion du projet

Afin de prendre en compte les contraintes de temps des développeurs, j'ai créé un planning prévisionnel en incluant les dates de rendu aux certificateurs.

Ensuite, la contrainte principale de ma formation pour la communication des plans de test, des cas de test, des tests et des rapports est de transmettre les documents  avec les formats de fichiers Excel ou PDF.

L'utilisation de Browserstack (équivalent Selenium) et JIRA n'était pas possible.

Cette contrainte m'a poussé à créer un outil de création de cas de test et de tests avec le SAAS Notion. Ci dessous, un exemple du tableau et l'interface du cas de test incluant une partie test.

Avec ces outils, nous sommes en capacité de transmettre les documents au bon format et d'obtenir un travail homogène entre QA testeurs.

Une fois ces contraintes levées, nous avons commencé la campagne d'analyse des fonctionnalités du concept à partir du GDD initial.

Les jeux développés

STAR RUNNER

Ce jeu est développé par Antoine O. Celui-ci a choisi l'ambiance de StarWars pour donner vie à son jeu. Comme dans la célèbre scène, il faut naviguer sur l'étoile noire en évitant les pièges et les obstacles.

SPACE RUNNER

Développé par Laetitia B. L'ambiance est issue de son inspiration personnelle. Différents blocs apparaissent, certains fixent et d'autres sont mouvants. Arrivé à un jalon de niveaux, le jeu accélère. Simple et efficace.

STARLIGHT RUNNER

Développé par JAO. Ce jeu inclus une ambiance spatiale ans une structure en tube avec l'apparition aléatoire d'astéroïdes et divers bonus. Une boutique a aussi été intégrée pour faire évoluer le vaisseau. Un jeu high tech.

Pour la validation de ma formation, j'ai axé ma campagne de test sur le jeu SPACE RUNNER.

Campagne de test

Démarche de création de la session de test

Le Game Design Document (GDD) est la base d’information m’ayant permis de créer le premier document de ma démarche nommée “Fonctions identifiées pour tout le jeu”.

Principe de création

Ce premier document regroupe l’ensemble des informations collectées lors de la lecture du GDD. Derrière chaque critère, une ou plusieurs fonctions ont été créé dans le code du jeu. Et par conséquence, un test potentiel peut être nécessaire.

💡Le premier but est de généré des blocs de fonctionnalités à tester pour simplifier le scope décrit dans le plan de test et les futurs itérations.

💡Le second but est de facilité le report des données dans un tableau de bord pour les remontés d’informations hiérarchiques.

 

A partir de cette base de données, j’ai identifié les fonctionnalités indispensables à tester en priorité. Le document “Plan de test” résume ces choix dans la partie Scope.

Une fois le périmètre identifié, j’ai créé les cas de test nécessaires à la réalisation de la session de test.

Pour faciliter ma démarche de test, j’ai opté pour l’utilisation du logiciel Notion afin de créer mon propre outil adapté à mes besoins. Je me suis inspiré des logiciels comme JIRA et BrowserStack.

Cette base de données nommée “Test cases” regroupe tous les tests à réaliser pendant la session.

Enfin, pour chaque test ayant un statut “non ok”, j’ai créé une seconde base de données nommée “Bug report”. Un lien est établi entre les différentes bases de données afin de garder le cheminement entre la fonction identifiée jusqu’à la création du bogue. Ce lien prend la forme d’un n° d’identification dans chaque base.

Lien entre les bases de données

Exemple :

💡Le bug n°BUG-9_Vitesse du vaisseau anormalement basse possédant le vidéo Infinite_Runner_2025-02-05_18-19-18 est lié au cas de test n° 24_Vérifier l’exécution du “GameOver”, la quantité de vie est égale à zéro provenant de la fonctionnalité FI-148_Barre de vie = 0, élément fonctionnel de la famille GameOver, sous famille Fin de partie.

Ce cheminement me permet de garder l’historique, la logique et les données de résolution afin d’alimenter un potentiel AMDEC (FMEA).

 

Fonction testée

Les fonctions ci-dessous seront testées dans cette première campagne :

  • L’UI / UX de l’interface durant la phase de jeu
  • Le positionnement de la camera
  • Le visuel des assets (vaisseau, tir, carburant, arrière plan, parcours)
  • Le respect des piliers de fonction du GDD
  • Le respect des boucles du GDD
  • Le déplacement
  • Les interactions
  • La sauvegarde du scores
  • Le respect des conditions de fin de partie
  • Les sons d’interaction

 

32 cas de test sont créés puis testés. 5 tests sont à l'état de NOK dont :

  • 3 niveau Low en lien avec les sons
  • 1 niveau High en lien le non respect du GDD concernant les déplacements
  • 1 niveau Critique en lien une différence de vitesse du vaisseau en fonction du matériel informatique utilisé

Ci-dessous, le rapport de bug transmis au développeur.