Les studios de jeux en tant que service utilisent des bots d'IA pour les tests de régression, pas pour trouver ce qui rend un jeu amusant

Les jeux en tant que service publient des mises à jour de contenu chaque semaine ou toutes les deux semaines, et chacune de ces mises à jour doit subir des tests de régression par rapport à l'ensemble du jeu existant avant sa mise en ligne. Ce calcul — une cadence de contenu constante multipliée par une surface de test héritée qui grandit — est ce qui a poussé les studios vers les bots de test automatisé au cours des deux dernières années, et non une ambition générale de remplacer les testeurs humains. Le résultat est un pipeline d'assurance qualité qui se scinde en deux : les machines absorbent le travail de régression répétitif, et les réductions d'effectifs tombent presque entièrement dans cette catégorie.

Ce que font réellement les bots

Les outils de test automatisé désormais utilisés en production dans les studios de taille moyenne et grande se répartissent en deux grandes catégories. La première regroupe des agents scriptés ou d'apprentissage par renforcement qui jouent une build de bout en bout, suivant des chemins connus ou explorant des espaces d'états, signalant plantages, blocages, collisions cassées et chutes de fréquence d'images sans qu'un humain n'ait besoin de refaire le même niveau pour la quarantième fois. Les outils Automated QA d'Unity et la startup danoise Modl.ai vendent tous deux des versions de cela aux studios qui ne veulent pas le construire en interne. La seconde catégorie est le test de régression visuelle : comparaison automatisée de captures d'écran par rapport à une référence connue comme correcte, détectant les ruptures d'interface et de HUD, l'apparition soudaine de textures et les bugs de rendu qu'un correctif de contenu a introduits sans que personne ne le remarque jusqu'à ce qu'un joueur en fasse une capture d'écran sur les réseaux sociaux.

Les grands studios ont construit des versions internes des deux. Activision Blizzard et Epic ont parlé publiquement de l'utilisation de suites de régression pilotées par bots pour couvrir la portion d'assurance qualité qui est purement mécanique — la build plante-t-elle, le niveau se charge-t-il, la nouvelle arme enregistre-t-elle correctement les coups — en les exécutant pendant la nuit sur des centaines de configurations avant qu'un humain ne touche même la build.

Pourquoi cela réduit les effectifs à un endroit précis

Le travail pour lequel les bots de test de régression sont bons est exactement celui qui exigeait autrefois les effectifs d'assurance qualité les plus importants : exécuter la même suite de tests contre chaque build, chaque plateforme, chaque localisation linguistique, encore et encore, pour détecter les défaillances mécaniques qu'introduit la cadence de contenu. C'est un travail intrinsèquement répétitif, ce qui le rend justement automatisable, et explique précisément pourquoi le réduire se traduit par une véritable baisse d'effectifs plutôt qu'une histoire de productivité qui ne change pas les effectifs.

Ce que les bots ne savent pas bien faire, et ce que les studios n'essaient explicitement pas d'automatiser, c'est le test subjectif et adversarial : si une nouvelle arme paraît trop puissante, si un changement de matchmaking améliore réellement la qualité des parties, et — de manière cruciale — trouver l'exploit qu'un joueur créatif découvrira dès la première semaine, sur lequel aucun chemin de bot scripté ne tomberait jamais. Ce travail exige une sorte de pensée adversariale et intuitive sur la façon dont un humain va essayer de casser le jeu, ce qui est une compétence véritablement différente de celle consistant à exécuter la même passe de régression mille fois. Les studios qui ont adopté les tests de régression automatisés rapportent avoir redéployé, et non éliminé, le personnel humain d'assurance qualité restant précisément vers ce travail d'équilibrage et de chasse aux exploits.

La nuance perdue dans les titres «l'IA remplace l'assurance qualité»

C'est une histoire différente du repli du modèle économique des jeux en tant que service largement couvert cette année, où des studios de taille moyenne se sont complètement retirés des jeux en tant que service parce que l'économie pour les faire vivre ne fonctionnait pas. Il s'agit ici spécifiquement du pipeline de test pour les studios qui exploitent toujours des jeux en tant que service et doivent livrer du contenu à une cadence fixe sans que la facture de tests de régression ne croisse linéairement avec chaque nouvelle fonctionnalité ajoutée. La réduction d'effectifs est réelle, mais elle se concentre dans des rôles qui étaient déjà la partie la plus mécanique et la moins différenciée de l'assurance qualité — le genre de travail qui, on peut le soutenir, était depuis toujours un candidat à l'automatisation une fois l'outillage suffisamment mûr pour être fiable.

Comment un studio plus petit devrait réellement adopter cela

Si vous exploitez un titre en tant que service et envisagez des tests automatisés, l'ordre des étapes compte plus que le choix de l'outil. Commencez par des bots de test de fumée qui détectent les plantages bloquants pour la build et les échecs de chargement avant qu'un correctif quotidien ou hebdomadaire ne sorte — c'est l'automatisation à la plus forte valeur et au plus faible risque, car un échec à ce stade bloque carrément la sortie. Ajoutez ensuite la comparaison de régression visuelle, spécifiquement autour des changements d'interface et de HUD, puisqu'il s'agit de vérifications fréquentes et peu complexes que les bots gèrent de manière fiable. Gardez vos testeurs humains concentrés sur les tests d'équilibrage et la chasse aux exploits tout au long du processus — n'essayez pas d'automatiser cela en premier, car l'outillage pour les tests subjectifs et adversariaux est loin d'être aussi mature que l'automatisation de la régression, et le traiter comme résolu laissera de véritables problèmes d'équilibrage et de sécurité atteindre les joueurs.

Les tests de localisation méritent une mention à part car ils se situent entre les deux catégories. Vérifier qu'un texte traduit ne déborde pas d'une zone d'interface, que les mises en page de droite à gauche s'affichent correctement, et qu'un correctif n'a pas silencieusement supprimé un fichier de langue sont toutes des vérifications mécaniques qu'un bot peut exécuter dans chaque langue prise en charge sur chaque build — un travail qui consommait auparavant des heures d'assurance qualité disproportionnées précisément parce qu'il augmentait à la fois avec le volume de contenu et le nombre de langues en même temps. Cela en fait l'une des meilleures cibles d'automatisation précoce pour un studio plus petit avec un budget d'assurance qualité limité, car cela libère les testeurs humains de la partie la plus fastidieuse du test de localisation, tout en laissant la décision la plus difficile — si une traduction sonne vraiment naturelle pour un locuteur natif — aux personnes, là où elle doit rester.