Il y a quelques semaines de cela, Ryan Bartley, Product Manager chez Stadia est intervenu pendant la conférence Breakpoint2 de Backtrace, pour expliquer ce qu’avait mis en place les équipes de Google pour améliorer le parcours des testeurs et de l’ingénierie de l’assurance qualité afin d’améliorer le processus de certification sur Stadia. Voici une traduction libre du transcript.
Bonjour et bonsoir à toutes les personnes qui regardent cette présentation, où que vous soyez. Cette session est intitulée « Exploiter l’informatique dématerialisée » et suivra la progression de l’expérience des développeurs sur Stadia et la façon dont nous nous sommes concentrés sur l’automatisation, la centralisation et la simplification de nos outils ont amélioré la capacité de nos partenaires à lancer du contenu sur la plate-forme.
Je m’appelle Ryan Bartley et je suis chef de produit chez Stadia. Je me concentre sur l’expérience des développeurs, en particulier en ce qui concerne les tests des certificats techniques et le pipeline de contenu au sens large.
Au cours de cet exposé, je vous ferai part des principaux enseignements tirés du lancement initial de Stadia pour améliorer les tests et la certification, je vous expliquerai pourquoi le parcours de l’utilisateur testeur est essentiel à cette amélioration et comment l’infrastructure de jeu en nuage permet de doubler, voire de tripler les cycles de certification et de test.
À la fin, il devrait y avoir un peu de temps pour une session questions-réponses si des personnes ont des questions.
Passons maintenant à l’expérience de la certification au lancement et à la manière dont cette expérience a mis en évidence des problèmes qui ont fait l’objet de nos améliorations.
L’un des aspects les plus intéressants au sujet de Stadia réside dans le fait que nous rencontrons les joueurs là où ils se trouvent, ce qui signifie que toute machine capable de communiquer avec Internet peut potentiellement devenir une plate-forme de jeu surpuissante.
Stadia a été lancé avec plus de 20 jeux. Ce fut un moment passionnant pour tous ceux qui voulaient essayer le cloud gaming et pour nos partenaires développeurs qui ont pu partager leurs jeux avec les joueurs sur des appareils qu’ils possédaient déjà. Mais cela a demandé beaucoup de travail. Chaque jeu a nécessité plus de trois certifications complètes pour être lancé.
Si vous ne savez pas ce qu’est la certification, il s’agit en fait d’un ensemble d’exigences finales, ou STRS comme nous les appelons, auxquelles un jeu doit se conformer pour être lancé sur notre plateforme.
Aujourd’hui, une certification typique prend environ cinq jours ouvrables. Avec plus de 20 jeux et trois certifications complètes, vous pouvez imaginer que nous avons passé énormément de temps à tester et retester.
Nos concepteurs UX et notre équipe de recherche ont donc audité l’ensemble de nos parcours utilisateurs en matière de développement et de validation, de l’accueil à la phase de test, en passant par le lancement d’un jeu et même le débogage, afin d’établir un aperçu complet de l’expérience et de déterminer les améliorations qui auraient le plus d’impact.
Nous avons constaté que nos outils étaient fragmentés et que les développeurs et testeurs partenaires devaient devenir des experts de notre infrastructure pour pouvoir les utiliser efficacement, naviguant dans une quantité énorme d’interfaces de bas niveau et de lignes de commande pour accomplir les tâches les plus simples.
De plus, certains de nos parcours utilisateurs obligeaient nos partenaires à naviguer entre plusieurs outils pour faire leur travail. Tout cela a entraîné une frustration et une confusion compréhensibles.
En bref, j’ai voulu mettre en évidence un parcours utilisateur classique pour tester la conformité de la certification au lancement, afin que vous puissiez avoir une meilleure idée de l’origine de certaines de ces frustrations.
La première étape de presque tous les tests consistait souvent à générer une grande commande de lancement du système d’exploitation Linux afin de configurer correctement l’instance pour le test et toutes ces configurations étaient un peu différentes.
Une fois le jeu lancé, l’utilisateur devait alors configurer et surveiller un ensemble de graphiques ou trouver et extraire un ensemble de journaux système pendant qu’il jouait au jeu ou effectuait ses tâches. Enfin, l’utilisateur devait copier manuellement ces journaux à l’aide de divers outils de ligne de commande, puis les exécuter à l’aide d’un autre outil de ligne de commande pour savoir s’ils passaient ou non le test.
Pour un public comme celui de l’assurance qualité qui n’est pas aussi technique que celui des développeurs, ce processus était coûteux à maîtriser. L’ensemble des étapes, souvent manuelles et complexes, est devenu un véritable casse-tête et ces mêmes développeurs ont eu l’impression de devoir créer des raccourcis et des automatismes pour leur permettre de faire leur travail, ce qui a alourdi la charge de la certification.
En outre, le lancement du jeu vers nos points de terminaison était beaucoup plus difficile pour les développeurs et les testeurs en raison d’un certain nombre de facteurs. En cas de problème, ils ne pouvaient pas facilement imiter ou résoudre les problèmes que nous observions en tant que joueur.
Tout cela mis à part, au même moment, nous avons commencé à recevoir des signaux très positifs de plusieurs équipes, grandes et petites, selon lesquels notre infrastructure est devenue un atout considérable quand les gens ont commencé à travailler à domicile en mars 2020. Bungie et Ubisoft, en particulier, ont exploité notre infrastructure en nuage pour intensifier leurs propres efforts de test, en raison de la facilité avec laquelle il était possible de tester la dernière version depuis n’importe quel ordinateur connecté dans le monde.
Nous savions donc que nous avions quelque chose de spécial qui pouvait vraiment aider les équipes à intensifier leurs efforts, mais en même temps, il était évident que nos outils entravaient une grande partie de ces progrès. Cette jonction entre les bons et les mauvais côtés qui entourent les tests nous a fait réaliser que le testeur pouvait en fait être le dénominateur commun de la plate-forme. Et qu’en simplifiant le parcours de test, nous pourrions augmenter la qualité et l’efficacité du lancement de contenu sur la plateforme pour tout le monde.
Alors, pourquoi le parcours utilisateur des tests plutôt que celui du développeur ou du producteur ? Pour comprendre cela, je vais faire un grand pas en arrière et regarder le cycle de vie d’un jeu depuis une altitude de trente kilomètres (au moins).
Les partenaires développent leur jeu généralement sur Windows, puis ils le transposent sur différentes plateformes en utilisant des couches de conversion. Alors qu’ils se préparent au lancement, ils commencent à finaliser le jeu en fonction des exigences particulières de la plate-forme. Enfin, le jeu est commercialisé et lancé. L’itération de ce cycle se produit de manière continue, car le contenu va et vient entre ces étapes.
Nous appelons ce processus de préparation de haut niveau pour le lancement d’un jeu le « pipeline de contenu ». Et ce que nous avons réalisé, c’est que ces transitions, mais aussi les allers-retours entre les phases, étaient largement contrôlés par la capacité de nos partenaires à tester et stabiliser ces changements.
Chaque étape nécessite une quantité importante de tests par les différentes parties de l’équipe. Si les partenaires ne peuvent pas tester le jeu sur la plateforme, les changements commencent à remonter plus tôt dans le processus, ce qui conduit à un produit global moins stable.
En outre, nous avons constaté que les tests ne sont pas seulement effectués dans le cadre de l’assurance qualité, mais qu’ils couvrent tous les rôles associés à la création du jeu. Pour le dire autrement, chaque personne devient un testeur au cours de la production. Par exemple, les développeurs testent constamment et itèrent sur ces tests et ces changements en les transmettant à la QA lorsqu’ils estiment que les choses sont prêtes. Le service d’assurance qualité effectue alors des tests de plusieurs façons différentes, comme la jouabilité, la stabilité, la conformité, en marquant les changements positifs en cours de route. Les producteurs, les concepteurs de jeux, les responsables de la mise en production et même les dirigeants ont tous besoin d’accéder aux résultats de ces différents tests pour que le contenu soit acheminé de manière transparente. Même les ingénieurs des stades et les opérations de certification des Stadia testent les jeux à différents stades.
Mais lorsque le test du contenu exige une telle quantité d’expertise sur l’infrastructure de la plate-forme, vous commencez à éliminer qui peut tester quoi, ce qui entrave non seulement l’efficacité du pipeline de contenu, mais aussi la capacité de fournir la meilleure expérience possible. Nous pensons que c’est l’un des principaux facteurs qui a conduit à de multiples certifications au lancement. Nos partenaires ne pouvaient pas tester efficacement leur jeu et s’en remettaient à notre certification interne pour trouver les points à corriger.
C’est à ce moment-là que nous avons su que l’investissement dans le parcours utilisateur de l’assurance qualité produirait des résultats significatifs sur un plus large éventail de parcours utilisateur.
Pour être un peu plus précis, nous savions d’abord que les objectifs de la QA étaient alignés sur la compréhension et le reflet de la qualité du jeu pour les autres groupes d’utilisateurs. Nous avons donc pensé qu’améliorer leur capacité à le faire ne ferait qu’augmenter la qualité du résultat. De plus, les équipes d’assurance qualité constituent de loin le plus grand groupe d’utilisateurs. Même pour les très petites équipes de développement qui ne disposent pas d’un service d’assurance qualité spécialisé, il incombe généralement aux développeurs et aux producteurs d’agir en tant que tels.
Ensuite, les équipes d’assurance qualité ne sont généralement pas aussi techniques que les développeurs, de sorte que les améliorations de la configuration et de l’automatisation requises pour permettre un parcours efficace de l’utilisateur profiteraient probablement à tous les autres types d’utilisateurs. De même, la QA génère une tonne de données liées au jeu qu’elle utilise pour aider les autres équipes à prendre les décisions nécessaires.Les résultats de conformité, les journaux de bogues, les vidages de pannes, etc. Ainsi, l’automatisation et la mise à l’échelle de l’accès à ces données profiteraient inévitablement à tous les utilisateurs qui en ont besoin.
Enfin, il est clair qu’ils partagent de nombreuses similitudes et synergies avec d’autres groupes d’utilisateurs, mais ce qui est encore plus intéressant, c’est qu’à bien des égards, ils sont essentiellement des miroirs de nos propres opérations de certification internes. En d’autres termes, les investissements consentis pour les aider à faire leur travail se répercutent sur nos propres efforts internes. En nous concentrant sur le parcours de l’assurance qualité, nous savions que nous pouvions créer une expérience transparente pour les développeurs, avec la même priorité accordée à la facilité que nos joueurs attendaient. Pour ce faire, nous avons mis sur pied un projet intitulé « Développer de n’importe où, collaborer de partout ».
Ce projet a donné lieu à un ensemble de fonctionnalités, toutes centrées sur ce que nous appelons le « Hub de test », qui permet d’accroître l’efficacité de votre équipe pour développer du contenu et partager des informations, facilitant ainsi le test et la certification de votre jeu.
Je vais passer en revue chaque fonctionnalité en détail, mais je voulais d’abord mettre en évidence le cerveau de cet ensemble de fonctionnalités, Test Hub.
Test Hub crée un moyen unifié pour tous les utilisateurs de Stadia de tester leurs jeux sur n’importe quel terminal de Stadia. C’est également là que les partenaires se rendent pour déboguer les problèmes, avec des journaux complets et un retour d’information pendant et après la session. La création d’un point d’entrée unique nous a permis de concentrer nos efforts sur l’ensemble des problématiques que les testeurs essayaient de résoudre pour leurs équipes, à savoir une configuration de lancement simple, une vue configurable des données, des calculs automatiques de strates et la possibilité de partager ces données après l’exécution, ce qui permet à chacun des rôles dont nous avons parlé précédemment d’extraire l’ensemble de données exact dont il a besoin pour tester son jeu et préparer la certification.
Test Hub centralise et organise tous les outils qui étaient si disparates au lancement autour d’une base vraiment solide sur laquelle on peut continuellement s’appuyer pour ajouter de plus en plus d’informations et de fonctionnalités utiles.
Nous allons maintenant nous plonger dans chaque outil en particulier pour vous montrer comment ils ont augmenté l’efficacité de nos partenaires.
Tout d’abord, nous allons commencer par le démarrage depuis n’importe où. En fait, il s’agit de la configuration initiale dont vous avez besoin pour tester votre contenu. Cette fonctionnalité supprime l’obstacle que les utilisateurs avaient à l’origine pour tester leur contenu sur les points d’accès des joueurs. Pour ce faire, les partenaires devaient à l’origine mettre en place des configurations étendues et appliquer constamment des modifications pour lancer leur jeu comme un joueur. Et cela ajoutait beaucoup de complications pour les équipes de développeurs, car il fallait une énorme connaissance de notre infrastructure pour établir ces configurations. Comme je vais le montrer dans une seconde, avec une simple sélection, les développeurs peuvent maintenant faire un lancement directement sur n’importe lequel de notre catalogue croissant de clients, simplement en se connectant avec leur compte de développeur. Cela s’est avéré particulièrement utile pendant la pandémie, car les testeurs ont pu se connecter simplement à leur propre chromecast ou android et commencer à jouer en toute sécurité et instantanément à la nouvelle version de la veille, tout comme un joueur.
Laissez-moi maintenant vous montrer comment cela fonctionne. Quel que soit l’outil que vous préférez, Visual Studio, la ligne de commande ou le portail des partenaires Stadia, vous bénéficiez d’une expérience cohérente dans tous ces outils, de sorte que vous pouvez travailler là où vous êtes le plus à l’aise. Une fois que vous êtes prêt à lancer le jeu, vous pouvez sélectionner le point d’accès que vous préférez et récupérer le jeu sur ce point d’accès après vous être connecté. À ce stade, nous commençons automatiquement à collecter les données d’exécution du jeu dès que l’exécutable du jeu commence à être diffusé, tout ce que nous pouvons capturer, en temps réel dans Test Hub, et stocker le reste pour des exécutions ultérieures du jeu. Cela permet aux partenaires de lancer n’importe quoi n’importe où et de capturer les données pertinentes en cours de route.
Ensuite, nous allons parler de la visualisation du jeu en direct. Lorsque votre jeu est en cours d’exécution, cette vue contient toutes les données de configuration et toutes les informations en direct dont un utilisateur aurait besoin pour surveiller ou contrôler son jeu. Nous avons également mis au point un mécanisme de diffusion en continu des informations des journaux les plus importants afin que vous puissiez disposer de toutes les données de jeu dont vous avez besoin en un seul endroit. Si bon nombre des fonctionnalités actuelles ne sont pas nouvelles, elles étaient à l’origine réparties entre plusieurs outils différents, ce qui rendait la tâche très difficile aux équipes qui souhaitaient évaluer la qualité et la conformité sans vraiment comprendre tous nos outils à la fois.
En outre, nous rendons les configurations de mise en page accessibles pour que vous et votre équipe puissiez choisir facilement l’ensemble exact de ces données afin de réduire votre taux de rotation global pendant le développement.
Ensuite, nous aborderons la vue des données historisées qui permet de mettre en œuvre une grande partie des fonctions de collaboration dont votre équipe peut bénéficier. Une fois votre jeu terminé, plusieurs artefacts tels que les logs, les ressources et les données de configuration de votre instance sont gelés et peuvent être partagés par votre équipe. C’est également là que vous accédez à plusieurs de vos résultats relatifs aux exigences de certification dont nous avons parlé précédemment. Si vous vous souvenez bien, toutes les strs originales nécessitaient de nombreuses lignes de commande pour vérifier la conformité de nos exigences. Cet ensemble de fonctionnalités élimine le besoin d’utiliser la ligne de commande pour nos strs, ce qui facilite grandement la connaissance et l’anticipation de la situation exacte de votre équipe dans le processus de conformité. Cet ensemble de données en constante augmentation est immédiatement stocké et accessible par votre équipe, s’intégrant dans chacun de vos flux existants de génération de bogues et de gestion des actifs.
Et enfin, il y a une autre fonctionnalité qui se trouve à côté de celles-ci, appelée canaux, qui permet de mettre en place un certain nombre de fonctionnalités vraiment importantes pour les tests de jeu évolutifs.
A savoir, la diffusion sécurisée et instantanée de votre contenu à une liste modérée d’utilisateurs. Oui, vous avez bien entendu, il est possible de diffuser votre contenu à tout groupe d’utilisateurs de votre choix sans avoir à passer par la certification. Ceci est utile pour de nombreux types de tests, tels que les tests alpha-bêta et des jeux en cours de réalisation que vous pouvez diffuser à votre équipe de test pour tester les fonctionnalités dans un environnement réel ou diffuser le jeu à la presse avant son lancement. L’une des nouveautés que nous souhaitions apporter à cette fonctionnalité était la possibilité de capturer toutes les données d’exécution que nous collectons actuellement dans l’environnement de développement. Nous pensons que cela permettra à votre équipe d’intensifier ses efforts de test tout en lui fournissant les données dont elle a besoin pour effectuer des ajustements.
Maintenant que tous ces outils sont disponibles depuis deux trimestres, nous avons pu voir comment ils ont amélioré la capacité de nos partenaires à certifier du contenu sur la plateforme. Notre mesure initiale de certifications complètes et finales par lancement était bien supérieure à trois certifications par lancement. Ce chiffre est maintenant réduit à seulement 1,67 certification par lancement, ce qui représente une diminution considérable du taux d’échec de la certification. Mais je pense que cela ne donne pas une idée précise de l’ampleur de nos améliorations. Lorsque vous êtes certifié, il existe également un processus qui vous permet de demander des dérogations à ces exigences, ce qui vous permet d’obtenir une dérogation temporaire ou, selon le type de jeu, une dérogation permanente à ces exigences. À l’époque du lancement, nous accordions bien plus de 10 dérogations par lancement et aujourd’hui, nous oscillons autour d’une moyenne de seulement quatre dérogations totales par lancement.
En outre, nous avons trouvé une autre mesure importante pour raconter cette histoire : le nombre de dérogations demandées après la première certification complète et finale. Cette mesure nous a montré comment nos partenaires utilisaient notre équipe de certification interne comme une équipe d’assurance qualité en matière de conformité, en leur donnant une liste de ce qu’ils devaient accomplir pour pouvoir effectivement publier leur contenu. Le nombre initial de dérogations après la première certification est passé d’environ 10 à moins de deux dérogations par lancement, ce qui signifie que nous avons considérablement réduit la proportion de dérogations demandées par les partenaires en raison de la complexité de nos outils. Ils disposent désormais des informations dont ils ont besoin au moment où ils en ont besoin, de manière plus facile et plus accessible, de sorte qu’ils ne dépendent plus autant de notre équipe interne d’experts en tests pour leur dire ce qui ne va pas dans leur jeu.
Mais nous ne faisons que commencer. Nous espérons que vous puissiez voir la valeur de cet ensemble de fonctionnalités au-delà du seul cas d’utilisation de la certification et nous avons également entendu vos réactions à la sortie de toutes les fonctionnalités dont je viens de parler et nous planifions déjà plusieurs mises à niveau de ces fonctionnalités.
Il s’agit de continuer à développer les contrôles et l’onglet de test afin de les rendre plus accessibles à tous les parcours d’utilisateurs et de vous permettre de vous concentrer sur les données les plus importantes pour votre rôle, de collecter automatiquement encore plus d’artefacts, de rendre ces artefacts faciles à trouver et à partager, puis de rendre les jeux encore plus faciles d’accès à partir de plus d’endroits.
Et enfin, comme je l’ai dit plus tôt, l’intégration des fonctions de capture d’exécution de jeu avec la fonctionnalité de canal, permettant à votre équipe d’obtenir plus facilement les données dont elle a besoin, quel que soit l’endroit où elle teste son contenu.
J’espère que vous avez apprécié de suivre avec moi aujourd’hui ce processus et de découvrir comment Stadia a pu améliorer ses capacités de diffusion de contenu sur la plateforme en s’appuyant nativement sur la technologie du cloud. Encore une fois, pour récapituler, nous avons considérablement facilité les tests, la certification et la préparation du contenu pour sa diffusion sur la plate-forme dans tous les parcours des utilisateurs.
Nous pensons que l’accès instantané à votre contenu et la possibilité de collaborer en toute sécurité autour des données changent la façon dont nos partenaires construisent leurs jeux et, comme vous pouvez le voir dans les sorties prévues en 2022, nous avons plus d’une centaine de titres prévus, ce qui témoigne de la satisfaction des partenaires à l’égard des nouveaux ensembles d’outils actuels.
Enfin, je vous expliquerai en détail comment vous et vos partenaires pouvez utiliser ces outils le plus efficacement possible lors du prochain sommet des développeurs Google for Games, qui aura lieu dans quelques semaines.
Je vous remercie de votre temps et n’hésitez pas à poser votre candidature à stadia.dev si vous et votre équipe pensez pouvoir utiliser efficacement ces outils.
Cette intervention témoigne de l’énorme travail fourni par les équipes de Google pour améliorer la vie des développeurs sur Stadia. La plateforme est encore très jeune et les ingénieurs de Google doivent sans cesse s’adapter aux retours fournis par leurs utilisateurs (ici les développeurs et éditeurs de jeux vidéos), proposer de nouvelles fonctionnalités pour devenir la plateforme de demain. Stadia est un énorme work in progress qui ne va pas s’arrêter. En témoigne d’ailleurs les nombreux sujets techniques qui seront prochainement abordés lors du Google for Games Development Summit et dont vous retrouverez bientôt les transcripts sur ce blog.