Le test de fonctionnalité des jeux est le bouclier invisible entre votre chef-d’œuvre et un raz-de-marée d’avis une étoile. Votre jeu peut être magnifique, afficher un ray tracing à couper le souffle et tourner à un fluide 120 FPS, mais si une mécanique de base rate, qu’un fichier de sauvegarde se corrompt ou qu’une ligne de quête cruciale refuse de se terminer, il est discrètement cassé. Capturer ces bugs critiques avant vos joueurs, c’est exactement la raison d’être des services de test de jeux vidéo spécialisés. Le test fonctionnel n’est pas une simple ligne de plus ; c’est là que commence la véritable assurance qualité.
Les enjeux du marché actuel n’ont jamais été aussi élevés. Avec un marché mondial du jeu vidéo qui gravite autour de la barre énorme des 188,8 milliards de dollars et une croissance du nombre de joueurs qui s’essouffle, la concurrence pour l’attention est féroce. Lorsqu’il devient plus difficile de conquérir de nouveaux joueurs, fidéliser la communauté que vous avez déjà devient votre priorité absolue. Si un bug graphique tape-à-l’œil peut faire le buzz sous forme de mème amusant sur TikTok, une sauvegarde cassée ou une boucle de progression bloquée pousse instantanément les joueurs à quitter la partie de rage et à supprimer votre application.
Imaginez un joueur qui atteint enfin un combat de boss légendaire, sauvegarde sa progression et se déconnecte pour la nuit. Il revient le lendemain pour apparaître dans une pièce vide : pas de boss, pas de sortie et aucun moyen d’avancer. Le jeu n’a pas planté et il n’y avait aucun artefact visuel. En surface, tout semble normal, mais le jeu a tout simplement oublié ce qu’il était censé faire. C’est exactement cette défaillance silencieuse, destructrice d’expérience, que nous évitons. L’article ci-dessous explique comment nos experts QA y parviennent.
Qu’est-ce que le test de fonctionnalité des jeux ?
Le test de fonctionnalité des jeux est le processus qui consiste à vérifier que chaque fonctionnalité, mécanique et système d’un jeu fait ce que la conception prévoit, aussi bien lorsque les joueurs se comportent de manière prévisible que lorsqu’ils font quelque chose que personne n’avait anticipé. L’International Software Testing Qualifications Board, connu sous le nom d’ISTQB, définit le test fonctionnel comme des vérifications fondées sur l’analyse de ce qu’un composant ou un système est censé faire. Dans un jeu, cette liste de « ce qu’il est censé faire » est longue, allant du déplacement du personnage et de l’ouverture du menu jusqu’à la sauvegarde de la progression, l’achèvement d’une quête et le versement de la récompense.
Il est utile de dire clairement ce que le test fonctionnel n’est pas :
- Il ne mesure pas à quel point le jeu est amusant, ce qui relève du test d’utilisabilité et du playtesting.
- Il ne mesure pas la fréquence d’images, le temps de chargement ni l’utilisation de la mémoire, qui font partie du test de performance.
- Il ne vérifie pas si le jeu tourne sur chaque appareil, ce qui relève du test de compatibilité.
Le test fonctionnel pose une question plus étroite et plus têtue. Le jeu fait-il la bonne chose à chaque fois, dans chaque situation ? Notre page consacrée au processus de test fonctionnel explique comment nous abordons cette question d’un projet à l’autre.
Que couvre la QA fonctionnelle dans un jeu ?
La QA fonctionnelle couvre les systèmes qui soutiennent le gameplay proprement dit. Pour un titre moderne, cinq domaines font le gros du travail :
- Les mécaniques de base et la logique de jeu déterminent le comportement des déplacements, des combats et des collisions.
- La sauvegarde, le chargement et la persistance préservent la progression du joueur après qu’il a fermé le jeu.
- La progression et le verrouillage des niveaux contrôlent ce que les joueurs débloquent et dans quel ordre.
- L’économie en jeu gère la monnaie, les récompenses et les achats.
- Le suivi du déroulé des quêtes et des missions indique où se situe chaque joueur dans une histoire à embranchements.
Le reste de cet article passe en revue ces cinq domaines, car c’est là que se cachent les bugs fonctionnels et là que l’argent se gagne ou se perd.
Les systèmes de jeu qui cassent, et comment nous les testons
Les systèmes ci-dessous partagent un trait qui les rend fragiles : chacun détient une part d’état, mémorise quelque chose et transmet cette mémoire au système suivant. Lorsqu’un maillon interprète mal ce qui précède, la défaillance ne reste pas confinée. C’est pourquoi nous les testons comme une chaîne connectée plutôt qu’isolément. Nous les parcourons à peu près dans l’ordre où un joueur les rencontre, des plus petites actions répétées jusqu’aux plus longues trames narratives.
Tester les mécaniques de base et la logique de jeu
Les mécaniques sont les verbes d’un jeu, les mouvements qu’un joueur effectue pour courir, combattre, grimper, fabriquer et échanger. Lorsque l’une d’elles rate, les joueurs le ressentent aussitôt, car ce sont des actions qu’ils répètent des centaines de fois par heure. Un saut qui parfois ne s’enregistre pas, une épée qui traverse un ennemi de part en part, une porte qui s’ouvre d’un côté mais pas de l’autre : chacun rompt le contrat fondamental entre le joueur et le jeu.
Bien tester les mécaniques, c’est aller au-delà du parcours idéal où tout se produit dans l’ordre attendu. Nous vérifions ce qui se passe lorsqu’un joueur martèle deux boutons à la fois, interagit avec un objet sous un angle inhabituel ou déclenche une action à l’instant précis où une cinématique commence. La logique de jeu a tendance à supposer que les joueurs agissent dans l’ordre. En réalité, pourtant, les joueurs se comportent souvent de manière imprévisible.
Test de sauvegarde, de chargement et de persistance
Les systèmes de sauvegarde semblent simples, mais leur comportement est tout le contraire. Un fichier de sauvegarde doit capturer l’état complet du monde, y compris l’endroit où se tient le joueur, ce qu’il transporte, quelles portes il a ouvertes, quels ennemis il a vaincus et jusqu’où chaque quête a progressé. Si le moindre élément vient à manquer ou s’écrit dans le mauvais ordre, le joueur peut perdre des heures de progression en un instant, ce qui est le chemin le plus rapide vers une demande de remboursement.
Nous testons les sauvegardes aux moments les plus susceptibles de les faire trébucher : en plein combat, en plein dialogue, pendant une cinématique et juste au moment où une sauvegarde automatique se déclenche. Nous chargeons aussi une sauvegarde créée dans un build plus ancien après un correctif, car les mises à jour modifient régulièrement la façon dont les données sont stockées. Une sauvegarde qui fonctionnait la semaine dernière devrait encore fonctionner aujourd’hui.
Tester la progression et le verrouillage des niveaux
La progression est l’échafaudage invisible qui décide de ce qu’un joueur peut atteindre et quand. Les verrous empêchent les joueurs de s’aventurer dans du contenu avant d’être prêts, et ils reposent sur des conditions remplies dans une séquence précise. Les ennuis commencent dès qu’un joueur remplit ces conditions dans un ordre que le concepteur n’avait jamais imaginé.
Nous avons observé un exemple net de progression qui casse lors de l’un de nos tests Bug Crawl gratuits. Dans Plug Head pour iOS, un jeu de puzzle-labyrinthe au rythme soutenu, nos testeurs sont tombés sur une transition abrupte entre les niveaux, qui interrompait la fluidité que les joueurs s’attendent à ressentir. Un seul passage maladroit de ce genre suffit à faire poser la manette, et multiplié par quelques milliers de joueurs, cela finit par apparaître dans les avis de votre boutique.
Test de l’économie en jeu
Tout jeu comportant de la monnaie, du butin ou des achats possède une économie, et les exploits s’y agglutinent comme des fourmis autour d’un pique-nique. Si une récompense peut être réclamée deux fois, qu’un solde peut passer sous zéro ou qu’un plafond de monnaie peut être contourné, un petit groupe de joueurs trouvera l’astuce et fera basculer tout le système.
Pour contrer cela, nous testons les cas limites délibérément. Nous réclamons encore et encore la même récompense de quête, poussons un solde au-delà de son plafond prévu, achetons et revendons en un seul instant et modifions l’inventaire plus vite que le jeu ne l’anticipe. L’objectif est de trouver la faille avant quiconque, car une fois qu’un exploit se répand, revenir en arrière signifie des joueurs frustrés et des notes de correctif embarrassantes.
Test du déroulé des quêtes et des missions
Les quêtes sont là où le test fonctionnel prouve sa valeur, car chacune est en réalité une petite machine à états. C’est un ensemble d’étapes qui doivent se produire dans un ordre valide, le jeu suivant précisément où se situe le joueur à chaque instant. Les quêtes à embranchements, où un choix ouvre certains chemins et en ferme d’autres, multiplient rapidement le nombre d’états possibles. Ratez une seule combinaison, et un joueur peut se retrouver dans une impasse dont l’histoire ne peut plus le sortir.
C’est le mode de défaillance qui bloque même les grands studios : une quête qui attend une conversation que le joueur ne peut plus avoir, un objectif qui ne se marque jamais comme terminé ou un objet qui disparaît du seul endroit où il était nécessaire. Aucun de ces cas ne fait planter le jeu, mais tous l’arrêtent net.
Comment rédiger des cas de test fonctionnels pour un jeu
C’est la partie que la plupart des guides sautent, et c’est pourquoi nous nous y consacrons. Décrire ce qu’il faut vérifier est facile, mais rédiger un cas de test qui attrape un bug à embranchements et à état demande plus de structure. Un cas de test fonctionnel est un scénario court et reproductible, avec une condition de départ, une série d’étapes et un résultat attendu clair. N’importe qui dans l’équipe devrait pouvoir le suivre et aboutir au même résultat.
Prenons une quête à embranchements comme exemple. Imaginez une quête intitulée « Sauver le marchand », que les joueurs peuvent aborder dans plus d’un ordre.
Titre
Terminer « Sauver le marchand » avant de rencontrer l’aubergiste
Condition préalable
Le joueur a atteint le chapitre 2 mais n’a pas parlé à l’aubergiste
Étapes
Se rendre directement au camp de bandits, vaincre les bandits, libérer le marchand, puis revenir en ville
Résultat attendu
La quête reconnaît que le marchand est en sécurité, le journal se met à jour et l’aubergiste propose la récompense de suivi
À surveiller
La quête continue d’attendre une conversation avec l’aubergiste qui ne peut plus avoir lieu, si bien que le journal ne se met jamais à jour et que le joueur est bloqué
La valeur se trouve dans cette dernière ligne. Un cas de test faible ne vérifie que le chemin voulu par le concepteur. Un cas de test solide emprunte délibérément le chemin que le concepteur a oublié.
Pour les systèmes qui détiennent un état, nous cartographions les combinaisons dans une matrice afin que rien ne passe entre les mailles. Une matrice de sauvegarde et de chargement, par exemple, croise le moment de la sauvegarde avec la situation au moment où le joueur recharge.
Pendant un combat
Santé, ennemis et position tous restaurés
Restauré proprement, avec les nouvelles données du correctif appliquées
En plein dialogue
La conversation reprend à la bonne réplique
La conversation reprend sans verser deux fois une récompense
Juste après une sauvegarde automatique
Aucune progression perdue
Aucun conflit entre les anciennes et les nouvelles données de sauvegarde automatique
Chaque cellule est un test distinct. La grille transforme une inquiétude floue, « la sauvegarde fonctionne-t-elle ? », en une liste de contrôle qu’un testeur peut terminer et valider en toute confiance. Nous construisons le même type de matrice pour les quêtes, en croisant chaque choix avec chaque étape ultérieure qui en dépend.
Si vous voulez voir comment le test fonctionnel s’articule avec la performance, la compatibilité et les autres méthodes, notre guide sur les types de techniques de test de jeu couvre l’ensemble de la boîte à outils.
Ce que le test fonctionnel des jeux détecte dans la réalité
Les cas de test ne valent que par les bugs qu’ils font remonter, et sur des projets en production, le schéma est constant. Voici quelques exemples tirés de notre expérience du test de jeux :
- Pour Human Park, une plateforme Web3 basée sur les avatars, nous avons mené très tôt un test fonctionnel manuel sur macOS. Nous avons vérifié l’installation et la désinstallation, les connexions de portefeuille et la personnalisation des avatars, puis signalé les bugs fonctionnels et d’interface trouvés. Nos vérifications ont aidé le studio à stabiliser ses premiers builds et à ouvrir les portes à plus de 30 000 joueurs en accès anticipé.
- Pour Highrise City, une simulation de construction de ville fortement axée sur l’économie et la gestion des ressources, nous avons travaillé la stabilité et le comportement matériel afin que le jeu tienne bien au-delà de la machine du développeur lui-même. Le lancement s’est soldé par 80 % d’avis positifs sur Steam.
- Pour Couple Up ! Love Show Story, une simulation de rencontres à croissance rapide, nous avons examiné le code et la configuration du serveur, puis remis à l’équipe un plan pour stabiliser les performances et réduire les erreurs avant que le nombre de joueurs ne grimpe.
Sur l’ensemble des projets, le fil conducteur reste le même. Les bugs qui comptent le plus ne sont pas les plus spectaculaires, mais les défaillances fonctionnelles discrètes qui bloquent la progression, cassent les sauvegardes ou faussent l’économie ; et ce sont celles-là que les joueurs retiennent.
Quand faire appel à un partenaire de test de fonctionnalité des jeux
Vous pouvez détecter énormément de choses en interne, et vous devriez le faire. Les signaux indiquant qu’il est temps de faire appel à un partenaire dédié sont concrets, par exemple :
- Une logique de quête qui se ramifie plus vite que votre équipe ne peut la suivre à la main
- Un système de sauvegarde qui s’étend sur plusieurs plateformes et versions de correctif
- Un calendrier de sortie qui ne laisse aucune marge pour rejouer chaque chemin avant le jour de la livraison
À ce stade, une QA fonctionnelle structurée cesse d’être un bonus appréciable et devient ce qui se dresse entre votre lancement et vos avis.
Notre équipe a testé plus de 100 jeux sur mobile, PC et console au fil des années, et nous proposons un programme gratuit de bug crawl qui place un build en direct devant de vrais testeurs et renvoie un rapport de bugs honnête. Si vous préférez discuter directement de votre jeu, contactez notre équipe et nous adapterons les tests à votre projet.
Découvrez comment nous avons aidé Highrise City à identifier la cause profonde des problèmes de performance afin d’assurer une sortie sans accroc