Le but ultime de « Lost Judgment » est de « tester automatiquement pour tout le monde ». Présentation des efforts interdépartementaux de « l'équipe d'automatisation des tests (provisoire) » qui ont apporté une contribution significative au développement [CEDEC2022]

La « CEDEC 2022 » (Computer Entertainment Developers Conference 2022) s'est tenue pendant trois jours, du 23 août (mardi) au 25 août (jeudi) 2022. Cet article décrit la session tenue le deuxième jour, « Tests automatisés pour le développement et l'assurance qualité ! À propos des efforts de « l'équipe d'automatisation des tests (provisoire) » qui a évolué avec la participation des testeurs d'assurance qualité de « LOST JUDGMENT » » Nous livrerons le contenu de.

Les intervenants de cette session sont Naoki Sakagami (ingénieur QA, 1re division) de Sega, Kenzo Kadowaki (contrôle qualité, département des opérations de projet) et Takashi Kokawa (ingénieur de construction, département de technologie de développement).

Dans le domaine du développement de jeux, l'importance de « l'automatisation des tests » pour maintenir la vitesse et la qualité du développement augmente de jour en jour. Dans cette conférence, nous parlerons d'une étude de cas dans laquelle un département de développement et un département QA (assurance/contrôle qualité) ont formé et contribué à une « équipe d'automatisation des tests (provisoire) ».JUGEMENT PERDU : Souvenirs non jugés» a été introduit du point de vue du développement et de l’assurance qualité.

Les besoins de l'époque. L’équipe est en chantier depuis plusieurs années.

Le titre abordé dans cette conférence est « LOST JUDGMENT : Unjuged Memories » sorti en 2021. Le genre est celui de l'action à suspense juridique, et la partie action, le grand nombre d'appareils compatibles, le grand nombre de langues prises en charge et le système de développement dans plusieurs endroits seront particulièrement importants dans cette conférence.

De plus, la fonction "Fully Automatic Bug Removal System" présentée lors de la conférence CEDEC de l'année dernière et le "Anywhere Replay System" ont également été utilisés dans cette conférence.

En connectant le jeu version Windows et l'outil de débogage, les données lues manuellement peuvent être générées sous forme de script dans le langage de programmation "Python" et des données de relecture peuvent être créées. Tout ce que vous avez à faire est d'appuyer sur un bouton et vous pouvez facilement créer une routine qui répète automatiquement une lecture spécifique.

Tout d’abord, il a expliqué la raison de l’introduction de l’automatisation des tests. Le service d'assurance qualité s'inquiète depuis longtemps de l'augmentation du travail de test en raison du développement multiplateforme, des limites de temps et de coûts requis, des calendriers sous pression en raison de retards inattendus et des rapports de défauts des utilisateurs après la sortie. sentiments à propos de la venue.

Si j'avais eu suffisamment de temps, j'aurais peut-être pu résoudre ces problèmes. Cela a conduit à l’idée que l’automatisation des tests pourrait être efficace pour résoudre ces problèmes, ce qui a conduit au département QA.

Alors, comment avez-vous débuté dans le département de développement ? Le département de développement travaille déjà sur l'automatisation des tests et travaille sur l'automatisation des tests, qui sera publiée en 2020.Ryu ga Gotoku 7 Où se trouvent la lumière et les ténèbres» Au moment du développement, une « équipe d'automatisation des tests (nom provisoire) » a été formée.

À ce stade, les seuls membres de l’équipe sont le service de développement et les ingénieurs en automatisation. La raison pour laquelle elle est appelée « (provisoire) » est qu'il ne s'agit pas d'une équipe reconnue par l'organisation et qu'elle devrait être dissoute une fois que les tests automatisés se seront généralisés.

Bien que l’équipe ait pu fonctionner dans une certaine mesure avec uniquement les ingénieurs de développement et d’automatisation, des problèmes sont apparus. Même si des tests automatisés peuvent être créés, leur maintenance et leur fonctionnement sont limités en raison des contraintes de temps liées à leur tâche principale de développement. On pensait également que le département de développement, à lui seul, manquait de connaissances en matière d'assurance qualité et de conception de tests.

Ensuite, le département QA a présenté une proposition concernant l’automatisation, et ce n’était qu’un carrefour menant à la formation d’une équipe inter-organisationnelle.

Du point de vue d'un ingénieur automation, même si le département QA travaillait sur l'automatisation des tests depuis un certain temps, il y avait encore peu de résultats directs. Quant au département de développement, ces dernières années, il a souvent travaillé directement sur des projets et coopéré avec l'automatisation des tests.

Formons une équipe. Les « différences d’environnement » font obstacle à la phase de préparation

Lors de la formation de l'équipe d'automatisation des tests, les trois départements de développement, d'assurance qualité et d'ingénieurs en automatisation ont travaillé ensemble pour s'y préparer. Premièrement, il a été déterminé que « l'environnement », « l'équipement », les « ressources humaines » et « l'apprentissage » étaient nécessaires à la préparation préalable à l'AQ.

Concernant l'environnement, il fallait d'abord confirmer si l'automatisation des tests était possible dans le même environnement que le service de développement. Nous avons discuté de la question de savoir si l'automatisation des tests, qui avait été réalisée auparavant dans le département de développement, pouvait être réalisée de la même manière dans le département d'assurance qualité physiquement distant et avons demandé des préparatifs.

Une fois l’environnement en place, la prochaine chose dont nous avions besoin était les ressources humaines. Plutôt que de recruter du nouveau personnel pour l'équipe d'automatisation des tests, nous avons sélectionné parmi les testeurs QA des membres possédant d'excellentes connaissances en programmation.

Vient ensuite l’équipement. Dans cet environnement, il était nécessaire de sécuriser des équipements spécialisés pour l’automatisation des tests. Parallèlement, des tests manuels par QA étaient prévus, donc partager le même équipement pour ces différents objectifs pourrait poser des problèmes en termes de fonctionnement, de stockage des données, de mises à jour des programmes, etc.

Enfin, parlons de l'apprentissage des membres. Afin de l'automatiser, il était naturellement nécessaire de créer des scripts, j'ai donc dû d'abord apprendre Python pour cela. Cela peut être complété par l'apprentissage d'ouvrages de référence, etYakuza 7Il dit que l'apprentissage par le biais d'essais d'un environnement automatisé qui était réellement exploité en « technologie d'amélioration » a été très utile.

Ensuite, les préparatifs effectués par le service de développement ont été expliqués. Tout d’abord, le service QA fournira des commentaires sur l’apprentissage.

Nous fournissons des commentaires sur une base mensuelle concernant les scripts créés au cours de l'apprentissage, tels que le fonctionnement des guichets automatiques. Nous avons arrêté de créer des tests qui seraient plus rapides avec des tests manuels, comme des tests qui peuvent être complétés après quelques tentatives ou des opérations trop complexes à automatiser, et avons partagé le point sur le fait que puisque le jeu est encore en développement, il est nécessaire de garder avec les changements.

Nous avons également partagé notre prise de conscience sur la mesure dans laquelle les fonctions de débogage peuvent être utilisées dans les tests automatisés.

Ensuite, nous commencerons à préparer l'environnement d'automatisation des tests qui sera géré par le service QA. "Ryu ga GotokuL'environnement de test automatisé du studio comprenait déjà des fonctions permettant de signaler automatiquement les bugs et les rapports de crash, ainsi qu'une fonction permettant de visualiser les résultats des tests à l'aide d'une fonction de collecte de journaux.

Nous avons construit un système qui pourrait être utilisé tel quel dans le service d’assurance qualité, mais un certain nombre de problèmes sont survenus.

Les départements de développement et d'assurance qualité utilisaient des environnements très différents, notamment les ordinateurs qu'ils utilisaient, et la différence de vitesse de communication avec le serveur était particulièrement importante. Dans le cas de « LOST JUDGMENT : Unjuged Memories », la capacité du paquet et du vidage est de plusieurs dizaines de gigaoctets, nous voulions donc éviter de ralentir la communication.

La société a déclaré qu'elle se concentrait sur la vérification et la prise de mesures pour remédier à cette différence de vitesse de communication. En premier lieu, le mécanisme d'envoi d'erreurs dans cet environnement consiste à télécharger automatiquement un dump complet (en unités de dizaines de Go) sur le serveur. Dans l'environnement de développement, le système fonctionnait sans problème même si des erreurs se produisaient fréquemment lors des tests automatisés, mais on craignait que des mises à jour fréquentes ne soient pas possibles dans l'environnement d'assurance qualité.

En guise de contre-mesure, nous avons construit un système qui génère deux vidages lorsqu'une erreur se produit : un mini vidage (en unités de plusieurs centaines de Mo) et un vidage complet. Seuls les minidumps sont automatiquement téléchargés sur le serveur, et les dumps complets peuvent être téléchargés manuellement lorsque le développeur a besoin de données.

Après des tests plus approfondis, nous avons pu télécharger un dump complet sans aucun problème, même depuis l'environnement QA. Par conséquent, ce système de mini-dump a été reconverti en système de transmission d’erreurs à partir d’un environnement domestique où la ligne était mince.

Une fois l’environnement configuré de cette manière, l’étape suivante consiste à considérer le flux de travail pour les opérations de test automatisées. Dans le workflow opérationnel de test, qui était effectué uniquement par le service de développement, lorsqu'une erreur survenait, un ticket appelé "Send Error" était automatiquement enregistré dans le système de gestion des tickets (Redmine) pour le distinguer d'un bug.

Sur la base de ce ticket, nous analysons les dumps, les logs, les vidéos, etc. et décidons s'il faut le corriger immédiatement ou le changer en ticket "bug", mais ce n'est pas le développeur lui-même qui analyse ces dumps et logs considérés comme difficiles.

Par conséquent, le flux de travail opérationnel du service QA reste le même jusqu'à l'enregistrement des tickets de soumission d'erreur, mais le flux d'analyse a été modifié de l'analyse des vidéos, etc. à la vérification si elles peuvent être reproduites dans les mêmes conditions que le test automatisé correspondant. .

Si nous parvenions à reproduire le problème, nous créions un ticket de bug, et si nous ne parvenions pas à le reproduire mais qu'il persistait, nous demandions aux membres de l'automatisation des tests du département de développement d'enquêter.

Sur la base de ces considérations, le flux de travail automatisé des opérations de test pour l’ensemble de l’équipe a été solidifié. L'équipe d'automatisation des tests du côté du service de développement et l'équipe d'automatisation des tests du côté du service d'assurance qualité rapportent et partagent chacune des informations avec le même service, tout en rapportant et en partageant également des informations au-delà des limites du service de temps en temps pour consolider davantage les commentaires. en allant.

La dernière étape des préparatifs du département de développement consistait à concevoir des cas de test. Les cas de test généralement traités dans les tests incluent les « cas normaux », tels que la fin d'un scénario de jeu, et les « cas anormaux », qui impliquent des éléments aléatoires.

"LOST JUDGMENT: Unjuged Memories" est multiplateforme et multilingue, de sorte que le nombre de combinaisons de tests normaux augmente de façon exponentielle. Sachant que la création de scripts pour les anomalies est difficile et nécessite certaines compétences, nous avons décidé de nous concentrer sur les tests automatisés pour les tests normaux et de laisser les anomalies à l'équipe de tests manuels.

De cette manière, les départements d'assurance qualité et de développement ont effectué les préparatifs, et les ingénieurs en automatisation ont également coopéré aux préparatifs. On dit qu'ils ont été capables de se coordonner à plusieurs reprises et d'effectuer un suivi dans divers domaines pour fournir un soutien en termes d'apprentissage et de conception de flux de travail.

Il est désormais temps de le mettre en service. Faciliter la communication est également un enjeu important

Maintenant que votre équipe est prête à démarrer, il est temps de préparer un plan de couverture des tests automatisés. Les développeurs seront en charge des « drames pour la jeunesse », qui nécessitent que les mini-jeux soient terminés avec précision, et l'assurance qualité sera en charge des autres mini-jeux, en tenant compte de leur adéquation.

En ce qui concerne l'exploitation, le service QA travaille d'abord avec le service de développement pour créer des scripts pour l'automatisation des tests. Un cycle de tests automatisés a également été mis en place.

Concernant la partie enquête 3 du cycle, il existe plusieurs branches en fonction des résultats des tests. En raison de la reproduction manuelle de la zone problématique, si le problème se produit même manuellement, la conclusion est qu'il s'agit d'un problème du côté du jeu.

S'il ne peut pas être reproduit, il s'agit d'un défaut du côté du script de test automatisé, alors corrigez-le. Si quelque chose qui fonctionnait jusqu'à la veille ne fonctionne plus, vérifiez si cela est dû à un changement dans les spécifications du jeu ou si le changement. était intentionnel. Mener des enquêtes et se renseigner auprès du service de développement.

Cette partie de la recherche a été approfondie dans la conférence ainsi que dans la vidéo. La vidéo provient d'une action d'enquête appelée "voler" dans le jeu, dans laquelle le joueur se dirige vers la destination tout en se cachant pour ne pas être vu par l'ennemi.

Les résultats des tests automatisés sont enregistrés sur une page de résultats claire et mise à jour quotidiennement. Si nous pouvons confirmer que le nombre de réussites pour le test concerné est nul, une vérification manuelle de la reproductibilité sera effectuée.

De plus, concernant la communication pendant l'exploitation, comme il s'agit d'une première pour le département QA, nous utiliserons « Microsoft Teams » comme outil permettant la communication et la consultation en temps réel même si la base est éloignée, ainsi que la web conférence. .

À titre d'exemple de communication, en plus d'un exemple de consultation avec le service de développement en temps réel avec une vidéo jointe, un cas a également été présenté dans lequel une équipe d'automatisation des tests (provisoire) a été amenée à servir de pont entre le service QA. et le département de développement. En plus d'automatiser les tests, cela a également facilité une communication régulière entre les départements, contribuant ainsi à un meilleur sentiment d'unité dans le projet.

Ensuite, il a expliqué comment cela fonctionne dans le département de développement. Pendant l'exploitation, le service de développement a mis un accent particulier sur « l'amélioration du système de test automatisé », « le support multiplateforme et multilingue » et « la prise en charge du développement multi-sites ».

En ce qui concerne la prise en charge multiplateforme et multilingue, plus de 100 modèles peuvent être créés avec seulement quelques combinaisons. De plus, chaque modèle avait son propre scénario principal, des mini-jeux, etc., ce qui rendait difficile la gestion de la taille du jeu.

Ce problème a été résolu en faisant varier les combinaisons en fonction des conditions. Bien qu'il soit impossible de tester toutes les combinaisons, en essayant des combinaisons dans lesquelles les conditions de combinaison de plate-forme et de sous-titres/langue audio ne sont pas similaires aux autres modèles et sont légèrement différentes, nous pouvons maintenant trouver la combinaison qui est proche du maximum dans la limite. il peut être couvert.

Pour la prise en charge du développement multisite, voirRyu ga Gotoku 7 Où se trouve la Lumière et les Ténèbres International« Des problèmes ont été identifiés lors du développement.

``Ryu ga Gotoku 7'' était multiplateforme et multilingue, mais en raison des mises à jour quotidiennes des packages dans l'environnement de test, il y avait des problèmes fréquents tels que l'impossibilité de démarrer la version française. En raison de problèmes tels que le décalage horaire, la lenteur des communications au fil des jours était inefficace.

Profitant de cette réflexion, nous avons mené un test automatisé pour « LOST JUDGMENT » qui ne nécessitait qu'un changement de langue. Le temps de confirmation et les pertes de retouche ont été considérablement réduits.

La précision des tests automatisés a également été améliorée. En fin de compte, de bonnes choses arrivent

Après préparation et exploitation, quel type de résultats cette équipe d’automatisation des tests (provisoire) a-t-elle réellement produit ? Tout d’abord, le service d’assurance qualité a rendu compte des résultats.

Tout d’abord, l’avantage était que les derniers résultats des tests automatisés répétés la nuit étaient disponibles au moment même où les travaux commençaient, ce qui a grandement amélioré l’efficacité du travail.

Ils ont également remarqué qu'un certain temps de préparation est nécessaire pour améliorer l'efficacité par la suite et que chaque test présente des caractéristiques différentes en fonction des avantages des tests automatisés.

En attribuant l'automatisation aux pièces auxquelles il n'est pas possible d'accéder manuellement, les personnes peuvent être libérées et affectées à des pièces qui doivent être vérifiées davantage manuellement. Si vous pouvez comprendre les caractéristiques et les attribuer, il y aura de grands avantages.

Grâce à ces expériences, j'ai pu effectuer les tâches suivantes au sein du département QA :

• Ils disposent désormais du même environnement de test que le service de développement, et sont également capables de créer des scripts en Python.
• En comprenant les résultats des tests automatisés, vous pouvez choisir l'action appropriée.
• Le service QA est désormais en mesure de considérer le contenu des tests qu’il souhaite automatiser.

Du point de vue du département de développement, des changements ont tout d'abord été apportés à l'équipe d'automatisation des tests (nom provisoire), y compris une expansion du personnel et de l'environnement. Concernant l'historique des tests automatisés par cette équipe, les travaux précédents "YEUX DE JUGE : Le testament de Dieu de la mort», le pourcentage d’erreurs détectées par les tests automatisés a presque doublé.

En comparant ce ratio avec les titres précédents, même le jeu d'action complexe « LOST JUDGMENT » a atteint le même niveau d'efficacité que le RPG « Ryu ga Gotoku 7 ».

De plus, nous avons atteint un taux clair de près de 100 % dans la plage couverte par le test automatisé. Le support linguistique a été complété et la précision du test automatique lui-même s'est clairement améliorée, par rapport au travail précédent "JUDGE EYES: The Testament of the Grim Reaper", qui comportait certaines parties instables, il a pu maintenir Des résultats 100% clairs chaque jour, j'ai pu le confirmer.

Ce que nous avons appris de l'automatisation des tests

A la fin de la conférence, les résultats de cette étude de cas ont été résumés. La portée de la couverture a été élargie en améliorant les compétences des testeurs d'assurance qualité, et le fait que les tests automatisés se soient révélés extrêmement efficaces pour le multiplateforme et le multilingue, ce qui constituait le plus grand défi, sera d'une grande aide dans le développement de nouveaux titres dans le futur.

Quant aux enjeux futurs, l'efficacité du système ayant été confirmée, ils souhaiteraient augmenter le nombre de tests automatisés dans une perspective d'assurance qualité. De plus, dans ce cas, l'équipement n'était géré que par le côté développement, mais comme il existe une pénurie indéniable d'équipement, l'entreprise espère augmenter le nombre d'équipements utilisés par le département d'assurance qualité à l'avenir.

De plus, le studio « Ryu ga Gotoku » a établi une feuille de route pour l'automatisation des tests. Les objectifs sont divisés en trois catégories principales : l'évolution des tests automatisés eux-mêmes, l'évolution de l'environnement et l'évolution des opérations. Dans ce cas, on pense que l'évolution des opérations a fait de grands progrès.

Cependant, tel n’est pas le but. À l’avenir, ils espèrent que les concepteurs de jeux, les artistes, le personnel du son et d’autres membres du personnel seront capables de créer des tests automatisés, tout comme les testeurs QA qui sont désormais capables de créer des tests automatisés.

Quels types de changements et d'évolution se produiront dans le domaine du développement où les « tests automatisés par tous » sont devenus une réalité ? Dans quelle mesure la qualité des jeux s’améliorera-t-elle lorsque le temps sera sécurisé grâce à la promotion de l’automatisation des tests ? Nous ne pouvons détourner les yeux des activités et des réalisations futures de l'équipe d'automatisation des tests (nom provisoire).