Test (jeu vidéo)

• Position invalide : un objet ne devrait pas pouvoir être là où il est.
  • Objet hors limites pour n'importe quel état : un objet se trouve dans un endroit normalement inaccessible (ex : un personnage marche sur la surface de l'eau).
  • Objet hors limites pour un état spécifique : un objet est dans une position inaccessible mais qui pourrait être valide dans un autre contexte (ex : un PNJ apparaît dans une cinématique alors qu'il ne devrait pas).
• Représentation graphique invalide : le rendu graphique de certains objets ou aspects du monde est incorrect (ex : un personnage se met à nager alors qu'il est sur terre).
• Changement de valeur invalide : un problème avec un compteur (ex : prendre une balle ne retire aucun point de vie).
• Stupidité artificielle : l'intelligence artificielle ne répond pas aux attentes, c'est-à-dire que les Personnages Non-Joueurs (PNJ) cassent l'illusion d'intelligence par certaines de leurs actions (ex : le PNJ marche contre un mur ou bloque le passage).
• Bugs d'information : des problèmes liés aux informations connues par le joueur.
  • Manque d'informations : le joueur devrait connaître certaines informations pour comprendre le jeu mais ne les possède pas (ex : une cinématique ne fonctionne pas).
  • Accès à l'information invalide : le joueur connaît plus d'informations que prévu par accident (ex : en voyant à travers un mur).
  • Informations dans le désordre : le joueur reçoit les informations dans le mauvais ordre (ex : quand il y a plusieurs moyens d'obtenir une information, le joueur voit son personnage découvrir la même chose plusieurs fois).
• Bugs d'actions : des problèmes liés aux actions dans le jeu.
  • Action impossible : des actions que le jeu devrait permettre mais qui sont impossibles (ex : impossible de ramasser un objet).
  • Action non autorisée : des actions possibles lorsque le jeu est en pause ou pendant une cinématique, ou encore un script qui se lance au mauvais moment (ex : la cinématique se déclenche avant l'arrivée du personnage).

• Position invalide dans le temps : des mouvements impossibles (ex : téléportation) ou une absence de mouvements attendus (ex : un PNJ est coincé).
• État du contexte invalide dans le temps : des objets restent dans le même état trop longtemps (ex : immobilité).
• Occurrence des événements invalide dans le temps : des événements se produisent trop fréquemment ou trop rarement (ex : un événement considéré comme rare se produit plusieurs fois d'affilée).
• Événements interrompus : des actions dans le jeu se terminent de façon abrupte (ex : un personnage parle mais la bande-son s'arrête sans raison).
• Problèmes de réponse de l'implémentation : problèmes liés au matériel (ex : latences).

Des études[7] ont montré la possibilité de détecter les problèmes à l'exécution. En effet, les programmes de jeux vidéo présentent des similarités : ils sont orientés objet et possèdent une boucle de jeu[8].

On sait qu'un tour de boucle change atomiquement l'état du jeu. Au lancement, la boucle est démarrée et attend en entrée l'intervention du joueur. À chaque action de l'utilisateur, les données sont traitées, l'état du jeu est modifié et le résultat est renvoyé au joueur. Lorsque la phase de jeu est terminée, la boucle est détruite.

En surveillant l'environnement d'exécution, il est possible de détecter dynamiquement des problèmes lors d'un tour de boucle à travers des contraintes et des conditions. Ainsi, les problèmes qui auraient pu passer inaperçus aux yeux d'un testeur sont détectés, et peuvent ensuite être corrigés.

Il est également possible, selon certaines études[2], de corriger à l'exécution les problèmes qui ont été détectés. Lorsqu'une condition n'est pas respectée, la valeur qui viole cette contrainte peut être modifiée dynamiquement pour régler le bug. Par contre, rien n'indique que cette correction ne va pas entraîner des régressions, c'est-à-dire déclencher d'autres violations. Le pire cas possible est que chaque réparation provoque un bug qui est ensuite réparé automatiquement mais provoque un nouveau problème, et ainsi de suite, créant une boucle de réparations infinie.

Mayet[2] peut être caractérisé comme un moniteur d’exécution développé et utilisé par Chris Lewis et Jim Whitehead. Il regarde l’exécution d’un système et peut réaliser des actions basées sur l’exécution courante. Il peut ainsi corriger des comportements indésirables durant l’exécution du système en fonction de règles de sécurité précédemment définies. L’expérience requise pour prédire les différentes défaillances du système est proche de celle nécessaire pour faire des tests unitaires.

Ce système reste malgré tout limité, en effet il se concentre généralement sur la réparation d’états logiques. Il est incapable de détecter et de réparer un bug graphique, ceci correspond à la catégorie « représentation graphique invalide » de la classification[6] des bugs. Il y a également la possibilité de déclencher une cascade de réparations : réparer un résultat va violer une autre règle, et ainsi de suite… Des bugs peuvent encore survenir, mais Mayet s’assure que ceux-ci soient acceptables pour l’utilisateur.

C'est un système de tests automatiques consistant à créer un solveur[9] qui est capable de trouver un moyen de finir un jeu. La création d’un solveur est proche de la représentation des données et des opérations logiques du moteur de jeu. Le solveur est implémenté en suivant l’algorithme de parcours en largeur. Il va explorer chaque état du jeu, jusqu'à atteindre le but attendu. Chaque état est représenté par un nœud dans l’arbre, et chaque événement est une branche permettant d’accéder à un nouvel état. Tout d’abord, il va lister tous les événements de la scène, puis il va en choisir un afin d’atteindre un nouvel état du jeu. Le processus est répété jusqu'à ce qu’un objectif soit atteint ou que la recherche devienne trop profonde.

LeChimp[10] est un serveur de tests fonctionnels utilisé par les développeurs du studio GamesFromWithin. Il exécute régulièrement le jeu sur un nombre fixe d'images, et s’assure que tout se charge et s’exécute correctement. Puis, il exécute de manière aléatoire différentes actions, comme si un singe jouait au jeu. Cela permet de découvrir des bugs que personne n’a remarqué durant les essais.

Alfredo Nantes, Ross Brown et Frédéric Maire ont fait des recherches à propos d’un framework de test semi-automatique pour les jeux vidéo[11]. Celui-ci repose sur l’utilisation d’un agent qui va permettre de détecter un bug visuel (inspection de l’environnement) ou de mesurer la difficulté d’une partie du jeu (inspection du divertissement).

Shadow Map est une technique qui s'appuie sur ce framework. Par exemple, l’agent est capable de détecter l’aliasing d’une scène. D’abord l’agent extrait les ombres de la scène. Ensuite il exécute des algorithmes de détections de contours et de coins afin de faire ressortir les ombres souffrant d’aliasing.

On distingue plusieurs phases de jeu où interviennent les testeurs : ils commencent par la version alpha du jeu, c’est-à-dire la première version, pour terminer avec la version bêta, la dernière version test[13].

Rôle

Le rôle du testeur qualité consiste à faire la chasse aux bugs[12]^,[14] et incohérences, ainsi que donner son opinion sur des points de gameplay[15]. Pour détecter les problèmes, le testeur qualité doit élaborer des tests fonctionnels et techniques. Même sur des passages où il n’y a pas de bug, le testeur peut proposer des améliorations et évaluer la difficulté du jeu[14].

Tester n’est pas jouer, c’est un processus long, fastidieux et répétitif qui nécessite de passer des heures sur des types de jeux qui ne plaisent pas forcément. Il s’agit de trouver les manipulations susceptibles de faire planter le jeu, en essayant des combinaisons incongrues et en imaginant des comportements imprévisibles du joueur[12].

Après correction des bugs, c’est au testeur de recommencer le jeu et de vérifier que les bugs détectés ont bien été supprimés[12]^,[14]. Il doit également assurer la stabilité des différentes versions du jeu[14].

Le testeur qualité doit posséder un bon sens de l’observation pour détecter rapidement des problèmes techniques ou de design. Il doit avoir de la persévérance pour faire et refaire certaines scènes jusqu'à trouver et savoir reproduire un bug spécifique. Enfin, ce métier nécessite de la communication pour décrire un bug de manière claire et concise pour celui qui devra corriger ce problème[12].

Méthodique, le testeur doit répertorier les bugs dans une base de données[14] et utiliser des logiciels de capture ou de communication de données[13].

Parcours

Le métier de testeur qualité ne nécessite pas de formation spécifique[12]. Cependant, un cursus en informatique ou une formation dans une école spécialisée dans le jeu vidéo reste un atout[16].

Le métier de testeur est plutôt un tremplin vers d’autres métiers du jeu vidéo[17], permettant de monter en grade au sein du service des tests et de diriger une équipe de testeurs. Le testeur peut également devenir game designer, passer en production ou encore gérer des projets[12].

Il faut distinguer les rédacteurs des pigistes[15]. Les rédacteurs sont rattachés à un magazine tandis que les pigistes produisent des articles de tests à la demande. Le journaliste spécialiste du jeu vidéo peut exercer son métier pour la presse écrite ou la presse en ligne[13]. De plus, il n’écrit pas seulement des tests mais également des rubriques annexes comme des solutions et astuces[15].

Rôle

Il peut être envoyé en reportage afin d'assister à une présentation d'un nouveau jeu vidéo et d'écrire un article objectif afin d'informer les lecteurs. Il doit alors prendre des informations auprès des créateurs et des développeurs du jeu afin de fournir des détails précis et concrets aux lecteurs du magazine[13].

Le journaliste spécialisé dans les jeux vidéo doit être passionné de jeux vidéo[13] et être capable de finir rapidement tout type de jeu[18]. Il doit être bon en Français et posséder des qualités d’écriture et de rédaction[13]. Il doit aussi être ouvert d’esprit et suffisamment curieux pour se tenir au courant de l’actualité et des nouveautés[13]^,[18].

Le sens de la communication et du contact est une qualité nécessaire car il est souvent amené à se déplacer dans des salons et des présentations de jeux vidéo. Parfois obligé de terminer des articles dans des délais très serrés, il est nécessaire au journaliste d’être résistant au stress[13].

Parcours

Il n'y a pas de diplôme particulier pour devenir journaliste spécialisé dans le domaine des jeux vidéo[13].

• (en) Jeffrey C. Mogul et Palo Alto, « Emergent (mis)behavior vs. complex software systems », EuroSys '06 Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems, ACM New York,‎ 2006 (ISBN 1-59593-322-0, DOI 10.1145/1217935.1217964)
• (en) Emerson Murphy-Hill, Thomas Zimmermann et Nachiappan Nagappan, « Cowboys, ankle sprains, and keepers of quality: how is video game development different from software development? », ACM,‎ mai 2014, p. 1-11 (ISBN 978-1-4503-2756-5, DOI 10.1145/2568225.2568226)
• (en) Jussi Kasurinen et Kari Smolander, « What do game developers test in their products? », ACM,‎ 2014 (ISBN 978-1-4503-2774-9, DOI 10.1145/2652524.2652525)
• (en) Fábio Petrillo, Marcelo Pimenta, Francisco Trindade et Carlos Dietrich, « What went wrong? A survey of problems in game development », ACM, vol. 7, n^o 13,‎ février 2009 (ISSN 1544-3574, DOI 10.1145/1486508.1486521)
• (en) Chris Lewis, Jim Whitehead et Noah Wardrip-Fruin, « What went wrong: a taxonomy of video game bugs », FDG '10 Proceedings of the Fifth International Conference on the Foundations of Digital Games, ACM New York,‎ 2010 (ISBN 978-1-60558-937-4, DOI 10.1145/1822348.1822363)
• (en) Simon Varvaressos, Kim Lavoie, Alexandre Blondin Massé, Sébastien Gaboury et Sylvain Hallé, « Automated Bug Finding in Video Games: A Case Study for Runtime Monitoring », ICST '14 Proceedings of the 2014 IEEE International Conference on Software Testing, Verification, and Validation, IEEE Computer Society Washington,‎ 2014 (ISBN 978-1-4799-2255-0, DOI 10.1109/ICST.2014.27)
• « Qu'est-ce qu'une boucle de jeu ? », sur Microsoft Developer Network (consulté le 16 décembre 2014)
• (en) Chris Lewis et Jim Whitehead, « Repairing Games at Runtime or, How We Learned to Stop Worrying and Love Emergence », Software, IEEE, IEEE,‎ 2011 (ISSN 0740-7459, DOI 10.1109/MS.2011.87)
• (en) Cyril Marlin, « Automated Testing: Building A Flexible Game Solver », sur Gamasutra, 2011 (consulté le 16 décembre 2014)
• (en) Noel, « LeChimp vs. Dr. Chaos », sur Games From Within, 2007 (consulté le 16 décembre 2014)
• (en) Alfredo Nantes, Ross Brown et Frederic Maire, « A Framework for the Semi-Automatic Testing of Video Games », A Framework for the Semi-Automatic Testing of Video Games,‎ 2008
• « Testeur de jeux vidéo: les coulisses d'un vrai métier », sur L'Etudiant (consulté le 16 décembre 2014)
• « Découvrez le métier de testeur de jeux vidéo », sur digischool (consulté le 16 décembre 2014)
• Syndicat National du Jeu Vidéo, « Référentiel des métiers du jeu vidéo » (consulté le 16 décembre 2014)
• « Bêta-testeur », sur jeuxvideo.com (consulté le 16 décembre 2014)
• « Les métiers des jeux vidéo », sur lesmétiers.net (consulté le 16 décembre 2014)
• « Testeur/Testeuse de jeux vidéo », sur cidj.com (consulté le 16 décembre 2014)
• « Journalistes/testeurs », sur jeuxvideo.com (consulté le 16 décembre 2014)
• EGM 160 novembre 2002 All Work ans All Play p.70-75
• Stef Leflou, Métier : testeur de jeux, octobre 2002, Jeux vidéo Magazine n°25, p.134-137.

• Portail du jeu vidéo