LittleFrenchy

Par blof Blog créé le 17/02/11 Mis à jour le 16/06/13 à 00h33

blog d'un ptit francais travaillant chez DICE

Ajouter aux favoris
  
Signaler
QA

 

Pour commencer cette série d'articles sur la Quality Assurance dans le jeu video, j'ai décidé d'exposer en premier ce qu'on nomme le "Black-box testing" (ou test de la boite noire en francais, merci Wikipedia). Je présume que beaucoup d'entre vous connaissent les differents process de cycles de developpement, et a quel moment intervient la QA. C'est pourquoi je ne m'attarderai pas sur cet aspect, ou peut-etre y reviendrai-je dans un prochain article (la QA en Waterfall etant differemment impliquee dans le developpement qu'en mode SCRUM). Sachez seulement que le Black-box testing commence aux alentours de la pre-alpha. Ah oui et le disclaimer obligatoire: ce qui suit detaille le Black-box testing en general, mais dans dans l'industrie, chaque QA org. l'adapte selon ses besoins.

Black-box testing for n00bs

Dans le process du Black-box testing, on test une fonctionnalité d'un jeu en particulier, mais on ne teste pas le code lui-meme. Le testeur a le role de l'utilisateur final. Il utilise les memes moyens d'interaction que le joueur normal. Il n'a donc pas la possibilite d'interagir avec le code en temps réel, de faire du code injection par exemple, mais il est capable de jouer au jeu de facon non-linéaire, en god mode si besoin, en ayant acces a tous les niveaux des le départ etc... C'est pour cela qu'on utilise des test kits, qui peuvent produire de l'info "brute" comme les memory dumps. Un exemple: le son provoqué par une rafale d'une mitraillette tirée en exterieur doit etre différent du meme évenement  en interieur. Le tester le signale a travers un "bug raised" avec pour destinataire la dev team. 

Test Plan/Test-case/Test Script mes amis

Avant qu'un tester ne puisse tester (spoiler alert!), les test cases doivent etre écrits. Au départ, un test plan est drafté par le QA Manager. Ce plan est validé par la Dev team et il integre les test cases . Ce sont les leads qui définissent les test cases de facon detaillée, avec plus ou moins d'interactions avec la dev team. Un test case va se focaliser sur une fonctionnalité en particulier, et peut donc inclure plusieurs test scripts. Ce sont ces scripts qui seront executés par le black-box tester. Exemple: en mode difficile, 2 achievements doivent etre recus par le joueur a la fin du jeu, or 1 seul achievement est recu. Le tester va tester plusieurs facons d'obtenir ces achievements. S'il ne reussit pas a obtenir le 2eme achievement, le tester doit donc a ce moment precis "lever" (raise en anglais) un bug a travers l'utilitaire de tracking (DevTrack, DevTest, perforce ou autres). Le test case doit definir le resultat attendu (expected results) par l'action (finir le jeu induit l'obtention de 2 achievements) des les specs du jeu ecrites.


Regression time !

Un des moments les plus passionants pour un tester est la phase de regression testing (sarcasm inside). Dans un cycle de dev, les builds se suivent (et parfois se ressemblent...) a un rythme effrene. Les nouvelles "versions" du jeu sont soumises a la QA, avec pour objectifs que 1- les bugs trouves avant cette nouvelle build aient été corriges et 2- que de nouveaux bugs n'aient pas été introduits.

Un bug qui avait été auparavant leve par la QA, doit obligatoirement passer par une phase de regression testing. En tous cas pour les bugs signales comme critiques (criticals).

Et chez EA?

EA suit a peu pres cette description. Je pourrai evidemment entrer plus dans les details, mais ce 1er article ferai surement 26 pages de long. Dans tous les cas, chez EA Europe, le Blackbox testing en temps que tel est tres developpe, notamment grace a notre centre de test situe en Roumanie. Les testers roumains sont excellents et sont reconnus parmi nos autres test centers. Au niveau mondial, EA possede un centre en Louisiane, et sous-traite egalement ailleurs.

En ce qui concerne la planification de l'utilisation des ressources (test centre resource planning), ceci depend reellement du Studio. Entre Criterion et DICE, les dev ne sont pas les memes et ont leurs propres habitudes. Criterion va par exemple pousser assez tot le BBT et maximiser les ressources dispos lors de la "peak season" (entre avril et octobre) alors que DICE va utiliser le meme nombre de testers pour une duree plus longue et va pousser a plus tard dans le cycle de dev (entre alpha et beta en general).

Voila pour cette 1ere partie, qui introduit l'aspect general du game testing. Je reviendrai plus tard sur le "white-box testing".

J'attends vos commentaires, ou questions si je peux y repondre !

 

Ajouter à mes favoris Commenter (4)

Commentaires

blof
Signaler
blof
Attention, je parlais du Black-box testing, qui est different du white-box testing, ou la il y a besoin de connaitre la prog et le hardware.
Pour la QA, je te conseillerai de bien savoir parler Anglais, de bien savoir t'exprimer a l'ecrit et a l'oral, d'avoir une excellente culture du jeu video, et d'etre curieux.
Pour etre honnete, la QA a beaucoup change ces dernieres annees, elle s'est vraiment professionalisee: Du simple QA tester, tu peux monter au Senior QA Tester, Project Lead, etc ... Tu peux aussi travailler sur la compliance, mais ca, j'y reviendrai dans un prochain article.
benbass
Signaler
benbass
Gracias. Mais ça m'étonne que ce job ne demande pas forcement un peu d'étude en programmation.

Sinon un petit conseil pour mettre toutes les chances de mon coté ? Quelquechose que je peux travailler par moi meme pour m'améliorer?
J'ai deja une premiere année de licence info en poche et je fais un p'tit projet en C (devoir de ma 2Ieme année) pour faire bien. J'ai un entretien le mois prochain pour cette école : http://www.creajeux....ations/testeur/ . C'est une petite formation de 3 mois qui m'a l'air pas mauvaise. C'est court et je pense que c'est toujours de petites notions en plus qui vont bien dans le CV.

Merci encore. :)
blof
Signaler
blof
Pas de pb, voici qques tentatives de réponses:
- le code injection permet a un hacker potentiel de prendre le contrôle du programme, et de la machine si le programme en question accède a la machine et/ou server avec des droits root ou "super user". Ce type d'attaque est très utilise pour le online également. Pour ce qui nous intéresse ici, le BB tester n'a pas accès a cela et donc ne peut pas tester le soft a 100%. L idée était de définir les limites du BB Testing.
- pour résumer, lors de la reproduction du bug, les dumps permettent au tester de produire l état de la mémoire en temps reel au développeur a travers différents types de rapports. Avec ces références, le dev peut alors savoir ou exactement se trouve le bug et le corriger plus facilement.
- chez EA Europe on a une dizaine, vingtaine voire parfois beaucoup plus de SKUs a tester en même temps (1 SKU = 1 build du jeu pour une plateforme, pour une région donnée). Ce qui donne énormément de boulot pour la QA interne mais aussi externe dans les centre de tests. Je donne l'exemple des derniers jeux sortis: NFS Hot Pursuit, Harry Potter DH, Family Game Night 3, EA Create, BF BC2 Vietnam, Crysis 2, Bulletstorm, NFS Shift 2, etc ...
On différencie également la partie "creuse" (Novembre a Mars) de la peak season (Avril a Octobre). Le moyen de mesurer la perf d'un tester est le "defect find rate" (nombre de bugs "de qualite" trouves par jour). Un tester junior commence avec des objectifs assez simples, mais doit vite monter en charge pour respecter les objectifs de la QA en général. En BBT, les day shifts sont remplaces par les night shifts dans les centres de test, ce qui permet une couverture large de la journée de travail. En moyenne, un tester fait environ 40h/45h/semaine en période creuse, et peut monter a 7/7j en période de finalisation du jeu et soumission aux 1st parties.
benbass
Signaler
benbass
Han tu tombes à pic l'ami. J'ai pour objectif de bosser dans le quality-assurance du JV. :)


J'envoie les questions si ça ne te dérange pas , j'ai un peu de mal sur le vocabulaire technique.

2ieme §: "Il n'a donc pas la possibilite d'interagir avec le code en temps réel, de faire du code injection par exemple..."
Du code injection ? Si tu as un lien vers une explication ou si tu peux détailler en quelques lignes.

"C'est pour cela qu'on utilise des test kits, qui peuvent produire de l'info "brute" comme les memory dumps."
Memory dump ? J'ai la page wikipédia devant les yeux mais je ne comprend pas vraiment. C'est pour retrouver des infos sur la mémoire même une fois le prog' fini?
Et donc , comme dans ton exemple , tu peux écouter le son des fusils sans même être sur le jeu ?

Derniere question. Au niveau des horaires , je sais que dans le rush avant la sortie du jeu vous bossez autant que la dev team. Mais tout le reste du temps , vous bossez à l'heure ("teste ce script pendant X heures et dis nous les bugs que tu as trouvé) ou comme un "informaticien lambda" (ex: Remonter X bugs pour la semaine prochain , si tu dois y passer 80H tu le feras)?


Voila , en tout cas merci beaucoup pour ces articles ! Ca ma donne la foi de faire ce metier. Est-ce un signe du destin ? :lol:

Édito

Je suis Quality Control Release Manager chez DICE. Je travaille actuellement sur Battlefield 4 et d'autres titres non annonces.

Vous pouvez me suivre sur twitter par ici: https://twitter.com/bl0f 

Archives

Catégories