Test (jeu vidéo)

Un article de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche

Le test dans le monde du jeu vidéo, domaine particulier du test logiciel, est une pratique consistant à évaluer les fonctionnalités d'un jeu vidéo. Ce test peut être effectué lors du développement du jeu dans le but de rechercher d'éventuels dysfonctionnements ou améliorations nécessaires (effectué par des testeurs en version alpha ou en bêta-test ouvert ou fermé). Différentes techniques permettent de repérer la présence de bugs pour les corriger. Des tests sont également effectués par des journalistes sur les jeux vidéo lors de la commercialisation pour en évaluer la qualité et le contenu.

Particularité du test lié au jeu vidéo[modifier | modifier le code]

Les techniques de tests automatiques ne fonctionnent pas dans le domaine du jeu vidéo car la plupart des jeux vidéo font partie des logiciels à fonctionnalités émergentes[1],[2], une catégorie spécifique de logiciels où les informations retournées par le système ne sont pas prévisibles. En effet, la clé du succès d'un jeu vidéo est de surprendre le joueur.

De ce fait, les tests sont difficiles à mettre en place dans les jeux vidéo car ils nécessitent de connaître toutes les données en entrée ainsi que les sorties correspondantes, or ces sorties sont par définition imprévisibles. Même si l'on pouvait énumérer toutes les entrées et sorties possibles, la capacité des développeurs à faire des tests qui couvrent tous ces états décroît exponentiellement. Les ingénieurs sont de moins en moins capables de prédire les résultats d’un système, et leur capacité à vérifier et valider un logiciel va grandement diminuer.

Il y a également des questions (notamment au niveau du design) qui ne peuvent pas correspondre à un test unitaire (ex : « est-ce que 90 % des joueurs finissent le jeu en moins de 5 minutes ? »).

La méthodologie actuelle des tests de jeux vidéo oblige structurellement à recruter des centaines de testeurs humains qui vont jouer à différentes versions du jeu durant tout le processus de développement afin de détecter les différents bugs et permettre aux développeurs de les corriger.

Différences avec les tests du logiciel classique[modifier | modifier le code]

Les jeux vidéo sont des logiciels particuliers, et doivent donc aussi respecter les contraintes concernant les fonctionnalités demandées, le budget et le temps tout en fournissant une qualité acceptable. Cependant, ils n’ont pas les mêmes objectifs et priorités que les logiciels traditionnels[3],[4]. En effet, les développeurs de jeux vidéo cherchent plutôt à divertir et amuser l’utilisateur. Il s’agit aussi d’un domaine créatif qui touche les émotions du joueur et cherche à lui procurer de la satisfaction. Du fait des différences constatées entre le jeu vidéo et le logiciel classique, l’ensemble des tests sera donc différent.

On peut souligner quelques différences majeures :

  • La maintenance dans les jeux vidéo paraît moins importante du fait de la durée de vie courte des jeux[3]. Il n'est donc pas primordial pour l'équipe de développement de mettre en place l'architecture et les tests nécessaires pour faciliter la maintenance dans l'avenir, tandis qu'il s'agit d'une priorité dans les logiciels traditionnels[4].
  • Les tests dans le jeu vidéo ne se concentrent pas sur les mêmes parties que dans un logiciel. En effet, le jeu vidéo va préférer l'expérience utilisateur (le jeu doit être intuitif, maniable, amusant) à l'aspect technique (stabilité, sécurité)[4].
  • Pendant la phase de développement d'un jeu vidéo, il est normal de voir apparaître des changements tardifs sur le produit, c'est pourquoi il est difficile d'automatiser des tests et d'en prévoir le résultat[4].
  • En général, les jeux vidéo connaissent des dates de sortie non flexibles, par exemple à l'occasion des fêtes[3]. Si la gestion du temps imparti est mauvaise, les développeurs ne pourront pas mener au bout leurs phases de tests[5].

Les jeux vidéo auront donc une préférence pour les tests d'utilisabilité et les "tests d'exploration" (en)[4].

Classification des bugs dans les jeux vidéo[modifier | modifier le code]

Il n'y a pas de classification officielle et standard des bugs présents dans les jeux vidéo, mais il existe une taxonomie[6] qui permet de classer les bugs en deux catégories : les bugs intemporels, qui peuvent apparaître à n'importe quel moment dans le jeu, et les bugs temporels, qui nécessitent de connaître l'état précédent du jeu pour reconnaître le bug.

Bugs intemporels[modifier | modifier le code]

  • 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).

Bugs temporels[modifier | modifier le code]

  • 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).

Détection et correction automatique des bugs[modifier | modifier le code]

Fonctionnement d'une boucle de jeu

Dans le but d'accélérer la phase de tests dans le développement de jeux vidéo, des approches[7] sur l'automatisation des tests ont été avancées.

Détection de bugs[modifier | modifier le code]

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.

Correction de bugs[modifier | modifier le code]

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.

Outils[modifier | modifier le code]

Mayet[modifier | modifier le code]

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.

Flexible Game Solver[modifier | modifier le code]

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[modifier | modifier le code]

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.

Shadow Map[modifier | modifier le code]

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.

Métiers du test dans les jeux vidéo[modifier | modifier le code]

Il existe plusieurs catégories de testeurs de jeux vidéo sur le marché français : les testeurs qualité et les journalistes[12].

Testeur qualité[modifier | modifier le code]

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].

Journaliste testeur[modifier | modifier le code]

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].

Notes et références[modifier | modifier le code]

Annexe[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (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,‎ (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,‎ , p. 1-11 (ISBN 978-1-4503-2756-5, DOI 10.1145/2568225.2568226)
  • (en) Fábio Petrillo, Marcelo Pimenta, Francisco Trindade et Carlos Dietrich, « What went wrong? A survey of problems in game development », ACM, vol. 7, no 13,‎ (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,‎ (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,‎ (ISBN 978-1-4799-2255-0, DOI 10.1109/ICST.2014.27)
  • (en) Chris Lewis et Jim Whitehead, « Repairing Games at Runtime or, How We Learned to Stop Worrying and Love Emergence », Software, IEEE, IEEE,‎ (ISSN 0740-7459, DOI 10.1109/MS.2011.87)
  • (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,‎
  • 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.