Tester n’est pas jouer !

LinkedInWhatsAppFacebookX
Tester n'est pas jouer !

« Ha tu es testeur ? Cool tu joues toute la journée !”

No God Please! No! No!

Combien de fois ai-je entendu cette phrase après avoir dit mon métier. Toi aussi ami testeur tu connais cela et pour les autres, certains d’entre vous l’ont probablement déjà dit ou pensé.

Seulement les apparences sont trompeuses et l’habit ne fait pas le moine. Tester n’est pas joueur, le testeur n’est pas (que) un joueur, loin de là, (du moins dans ses heures de travail :p). Il est venu le temps d’expliquer cela.

De quel type de testeur est-il sujet ?

Il faut d’abord clarifier de quel type de testeur on parle, car il y a parfois confusion, quand on généralise entre deux types de testeurs. Il ne faut pas confondre le testeur-critique pour la presse et le testeur de production, d’Assurance Qualité (Quality Assurance, QA) et de Contrôle Qualité (Quality Control, QC). Dont j’explique la différence dans un autre article.

Ici on va parler catégorie qui travaille au sein de l’industrie du jeu vidéo. Le rôle principal du testeur au sein des studios n’est pas de juger un jeu selon différents critères, mais dans les grandes lignes, de veiller que tout fonctionne comme cela est attendu. Ainsi il reporte les bugs entraînant des problèmes techniques ou qui affectent des fonctionnalités (qui ne fonctionnent par exemple pas comme cela est prévu par les designers). Il vérifie également qu’une fois que ces bugs sont annoncés comme corrigés, qu’ils le sont bien.

La différence entre tester et jouer

« Oui mais pour tester il faut jouer, donc tester c’est jouer ! »

Oui et non. Certes pour tester il faut « jouer » au jeu, parfois même y faire de la progression, parcourir des niveaux, faire des matchs, etc,… . Cependant manette en main, dans leur globalité, les actions du testeur sont différentes de celles du joueur.

Des objectifs abordés différemment

Dans une partie, le joueur est dans la recherche de progression dans le jeu (avancer du scénario, accomplir une quête, prendre des niveaux,…) et son attention est principalement concentrée sur cela. Si le testeur est amené un moment ou un autre à accomplir les mêmes actions, son attention n’est pas portée uniquement son objectif. Il prête attention à tout ce qui est mis en œuvre, il observe, scrute. Est-ce que les graphismes, les animations, le son, les éléments d’affichages, les actions fonctionnent.

Actions répétées et improbables

Comme parfois il y a plusieurs manières d’accomplir un objectif, le testeur va être aussi amené à parfois refaire une même action, un même objectif plusieurs fois.

Il va même devoir faire des actions, en apparence assez improbables, voir débiles, parce que derrière l’une d’entre elle se cache peut-être un joueur qui va la faire et un bug. Et on a beau essayer de toute envisager, les joueurs sont très imaginatifs. Oui, on te connaît Jean-Claude, qui fait en jeu ce que personne n’a jamais tenté, par hasard ou non.

Un gameplay technique plus que ludique

Ainsi le gameplay du testeur est plus dans une perspective technique que ludique. D’autant qu’il utilise souvent des outils (des cheats de développement) pour simplifier ses tâches, que les joueurs n’ont pas, ce qui peut changer l’expérience du jeu. Imaginez par exemple que vous devez tester le level design d’une zone d’un soul-like (donc tout ce qui est décor et environnement), mais que les ennemis, voir un boss sont là. L’enfer non ? Aussi bon soit-il, le testeur aurait sans doute besoin du double de temps pour tester cela, sans un cheat de développement, qui rend son personnage immortel ou tue d’un coup tous les ennemis. Dans ce cas, si le testeur est sur le jeu comme le sera le joueur, son expérience est différente et dans un but différent.

Si on doit résumer cette partie, on pourrait dire que le testeur ne va pas chercher une sensation, un ressenti, un accomplissement mais une validation technique. Quand le joueur de son côté a une progression dans le jeu et vit une expérience, le testeur se place dans un contexte bien défini pour vérifier un point précis.

Tester n’est pas qu’être sur le jeu

Bien, maintenant vous avez compris qu’un testeur ne joue pas. Mais comme beaucoup, vous vous dites sans doute qu’il reste la grande majorité de sa journée manette en main.

Une fois encore, la réalité est bien différente. Dans son expérience, le joueur est en jeu lors de ses parties logique). Le testeur de son côté ne passe pas tout son temps sur le jeu. Tester c’est aussi passer du temps dans des bases de données de bugs (en rentrer de nouveau, en mettre à jour,…), mais aussi dans les plans de tests (des documents listant les éléments qui vont à être à tester, voire les tests à performer), la documentation du jeu (pour connaître les fonctionnalités du jeu et comment elles doivent fonctionner).

Sans oublier les interactions avec d’autres équipes ou membres de la production, pour rapporter des problèmes, trouver des réponses, les meetings. Le temps consacré à cela est loin d’être négligeable puisqu’il constitue non loin des ¾ du temps du testeur.

Tester est plus que jouer

C’est donc pour toutes ces raisons que le testeur, aussi joueur soit-il en même temps s’éloigne en bien des aspects du joueur et que tester est éloigné de jouer. Je ne l’ai pas abordé, mais bien entendu, le testeur fait souvent aussi des retours sur le jeu, sous un angle plus joueur. Toutefois, dans l’ensemble de ce qui constitue son quotidien, il n’en reste pas moins différent du joueur.

Pour aller plus loin

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Retour en haut