Après plusieurs mois de silence, je suis de retour sur le blog. Désolé pour ce silence qui a fait penser à certains que le projet était tombé à l'eau. La vérité c'est que ces derniers mois ont été très très tendus car nous avons accumulé les galères, et que du coup je n'ai pas trop eu le temps de venir blogger. Toutes ces galères sont maintenant derrières nous et on devrait très très bientôt reprendre la communication « institutionnelle » avec de nouveaux screens (vous verrez que le jeu a pas mal changé visuellement ), le premier trailer et l'annonce (enfin !) de la version console HD sur laquelle nous sommes en train de travailler.
Je vais vous raconter dans ce post comment nous avons identifié la boîte qui travaille actuellement avec nous sur le QA, quelles sont qualités d'un bon testeur, ce qu'est un bon bug, et je vais vous donner quelques exemples de bugs qui nous ont été remontés récemment.
Rappelons que le QA (Quality Assurance) est la phase qui démarre soit après l'alpha soit après la bêta et qui a pour objectif d'identifier les bugs. Certains développeurs, notamment indépendants, sont tentés de faire du QA en interne sans testeur professionnel. A mon avis c'est tout à fait possible tant qu'on a un gameplay relativement simple et tant qu'il n'y a pas d'exigences type « compliance » de la part du first party (je reviendrai là-dessus un peu plus tard). Malheureusement nous ne rentrons pas dans ces catégories.
QA nous voilà
Pour faire simple, on peut distinguer 3 types de tests :
- - Tests de gameplay : il s'agit de vérifier que le gameplay fonctionne correctement tout au long du jeu, qu'il n'y a pas de bugs de collisions, de s'assurer que si vous gagnez 100 crédits à la première course, ceux-ci vont bien être enregistrés...bref tout ce qui est relatif au jeu à proprement parler.
- Tests de localisation : Il s'agit de vérifier que les traductions sont bonnes, que l'orthographe est respecté et que l'affichage des mots soit maîtrisé (que l'on n'ait pas par exemple de retour à la ligne au milieu d'un mot).
- - Tests de compliance : voilà pourquoi il est impératif que vos testeurs aient une solide expérience de votre plateforme de jeu. Il faut savoir que lorsque vous êtres sur console, il y a une grammaire à respecter : TRC chez Sony, TCR chez Microsoft et Lotcheck chez Nintendo. Pour vous donner une idée cela va du bouton de la manette qui est imposé pour faire « back » dans les menus à la manière de mentionner le bouton start dans le jeu. Il faut aussi savoir qu'une fois votre gold finale soumise, le first party va la tester de son côté. Officiellement les first parties ne laissent rien passez tant au niveau du gameplay que de la compliance, officiellement...
Merci internet et merci la mondialisation
Nous n'avions pas une grande expérience de l'outsourcing QA, personnellement je suis passé par certaines sociétés lors de ma phase « mobile » au Japon, mais mon carnet d'adresse à la rubrique console et PC était vide. Je me suis alors mis à la recherche de la perle rare sur Internet. Aujourd'hui grâce à des sites comme gamasutra, gamedev ou gameindustry, on a rapidement accès à des listes de sous-traitants. Je me suis constitué une short-list d'une dizaine de prestataires qui ont l'expérience de « ma » console. D'après mes observations, il y a aujourd'hui trois pôles qui se dégagent :
- Le Canada
- La Chine où certaines société occidentales (dont Canadiennes) ouvrent des filiales
- L'Europe de l'est, notamment la Roumanie et la Bulgarie.
Le QA est une activité qui va avoir de plus en plus tendance à se concentrer sur des pays en développement car c'est une activité qui n'exige pas une main d'œuvre très qualifiée et même les développeurs et éditeurs qui ont des département QA en interne ont tendance à outsourcer deplus en plus.
Après de nombreux mails et devis, j'ai fini par opter pour la société Quantic Lab qui est située à Cluj en Roumanie. J'ai eu tout de suite un bon feeling avec Stefan Seicarescu et Marius Popa qui ont tout de suite cerné mes attentes et qui, contrairement à certains, ne m'ont pas fait des estimations sur la base de milliers d'heures (bonjour la facture !). En outre Quantic Lab a l'expérience d'avoir travaillé sur TNT Racers qui a un gameplay totalement différent de Fuel Overdose mais qui présente certaines similitudes avec notre jeu. Enfin, et il serait malhonnête de taire ce point, Quantic Lab m'a proposé un tarif horaire plutôt avantageux. Il faut savoir que pour des tests de gameplay on les tarifs se situent entre 8 et 14 euros de l'heure aujourd'hui, et qu'il faut plusieurs centaines d'heures de test pour un jeu comme Fuel Overdose. Les tests de loc et de compliance sont pus chers car ils exigent d'être faits par des testeurs plus seniors.
La différence entre un bon testeur et un mauvais testeur...
Les NDA signés, les contrats signés, il me reste à préciser à Quantic Lab ce qui soit être testé et ce qui ne doit pas l'être. C'est un point ultra important car si vous savez que la compliance n'a pas été suffisamment travaillée de votre côté, ça ne sert à rien de la faire tester, donc avant chaque session de test il faut préciser ce qui doit être testé : quels modes de jeux, quels véhicules, quels éléments de gameplay, si multi, combien de joueurs max...
Ca y est la version est chez Quantic Lab, les premiers bugs commencent à tomber en temps réel.
A ce moment là on est un peu schyzo : d'un côté on est content de voir des bugs tomber car on est rassuré de voir des testeurs faire correctement leur boulot, et d'un autre on commence à criser car chaque bug identifié exigera du temps de développement pour être fixé. En fait pas tout à fait, car le producer peut décider que ce qui est reporté comme étant un bug n'en est pas un ou car il est trop mineur.
Par exemple, supposons que j'ai le bug suivant : le véhicule n'a pas la même couleur dans l'écran de sélection et dans la séquence in-game. Je peux dans ce cas là soit demander au développeur de fixer le bug, soit décider de l'ignorer car je peux considérer que la différence de de couleur est minime et marquer le bug en « will not fix », ou considérer que les filtres graphiques de chaque map modifient les couleurs des véhicules et marquer ce bug avec un « not a bug ».
Maintenant on va se placer dans le cas d'un bug qui devra être fixé, et je vous le mets en version originale :
Observed:
While playing the game it can be observed that if the player uses any weapons after he got killed, the environment will be displayed in black and white.
Expected:
The color of the environment should not change after getting killed and re-spawned.
Steps to reproduce:
1. Boot the title
2. Start a free race
3. Select any character, map, vehicle
4. Advance to gameplay
5. Get killed and use any weapons while at the explosion animation screen
6. Observe the mentioned issue
Voilà ce qui pour moi constitue un bon bug reporté par un bon testeur. La description du bug est très claire (l'écran de jeu devient noir et blanc lorsque que l'on tire pendant l'animation de destruction), le testeur explique le comportement qu'il y aurait dû y avoir si il n'y avait pas eu de bug, et surtout il explique comment reproduire le bug à coup sûr. Cette dernière information est capitale pour Jérôme qui est à Tokyo et qui devra fixer ce bug, et plus un bug est renseigné plus il sera simple pour le développeur de le fixer. Cela peut paraitre simple de prime abord mais avant de taper ces quelques lignes il y a un gros travail derrière. Par exemple, le testeur dit « Select any character, map, vehicle », cela signifie qu'il a fait plusieurs tests pour vérifier que ce bug n'était pas relatif à un véhicule, à un personnage ou à une course en particulier.
A contrario, voici un bug qui méritait plus de précisions de la part du testeur:
Observed:
After the car explodes or the player selects the manual respawn by pressing the
XXX (je fais exprès de masquer le nom du bouton), the car respawns and hangs in the air for a while before it falls down to the ground. There are certain situations where the car respawns next to the edge of the track by facing the margin. It is harder to continue the game when the player needs to turn in the right direction to be able to continue the course.
Expected:
The car should respawn in the middle of the track by facing the right (onward) direction.
Steps to reproduce:
1. Boot the title
2. Start the game
3. Select the Championship game mode
4. Select any of the characters and cars
5. Select the Championship 1 game
6. During gameplay press the XXX button to respawn
7. Observe the issue as described
Le soucis avec ce bug est qu'il n'est pas très bien renseigné. Le testeur nous indique qu'à certains endroits de la course de championship 1 (déjà on n'est pas trop sûr de comprendre de quelle course il parle) il arrive qu'on soit respawné dans des endroits non safe de la map. Ce qui est un bug très important car lorsque votre véhicule respawne (que vous ayiez explosé auparavant ou que vous ayiez délibérément appuyé sur le bouton de respawn) il faut que le jeu vous place dans un endroit safe du circuit (généralement au milieu de la route).
Le problème içi c'est que la description est très vague, on ne sait pas dans quelles zones du circuit cela se produit exactement. Avec aussi peu de détails, Jérôme risque de devoir passez beaucoup de temps à identifier les zones en question pour mieux cerner le bug.
N'importe quel testeur amateur peut trouver des bugs sur une version alpha ou beta. Ce qui est beaucoup plus compliqué c'est d'identifier dans quelles conditions ce bug se reproduit et de l'expliquer clairement.
Voilà je pense avoir fait le tour de cette première session de QA. Nous sommes actuellement en plein milieu de notre deuxième phase qui concerne le multi, avec beaucoup de boulot et un gros mal de crâne en perspective.
A priori le prochain post concernera la bande son du jeu ou comment constituer une (bonne) bande son quand on a pas les moyens de se payer Hans Zimmer... à moins que vous ne vouliez que j'aborde un thème en particulier ?
Skander Djerbi