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 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, 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

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. 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. 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 ; 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é) ; 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 ; en général, les jeux vidéo connaissent des dates de sortie non flexibles, par exemple à l'occasion des fêtes. Si la gestion du temps imparti est mauvaise, les développeurs ne pourront pas mener au bout leurs phases de tests ; dans un logiciel, les tests utilisateurs permettent d'identifier puis de retirer les obstacles à la productivité de l'utilisateur. Dans le jeu vidéo l'obstacle est nécessaire : le test utilisateur (playtest) permettra (entre autres) d'adapter l'obstacle aux compétences du joueur, et non pas de le retirer.

Les jeux vidéo auront donc une préférence pour les tests d'utilisabilité et les .

Classification des bugs dans les jeux vidéo

Il n'y a pas de classification officielle et standard des bugs présents dans les jeux vidéo, mais il existe une taxonomie 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

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 de fusil 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

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

vignette|droite|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 sur l'automatisation des tests ont été avancées.

Détection de bugs

Des études 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.

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

Il est également possible, selon certaines études, 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 Mayet Mayet 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 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 C'est un système de tests automatiques consistant à créer un solveur 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 LeChimp 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's, 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 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. 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