Utilisateur:Omar.chahbouni/Brouillon

• Gérer mon brouillon
• Demander une relecture (voir les demandes)
• Publier mon brouillon

Cette page est un brouillon appartenant à Omar.chahbouni

Conseils de rédaction

• → N'hésitez pas à publier sur le brouillon un texte inachevé et à le modifier autant que vous le souhaitez.
• → Pour enregistrer vos modifications au brouillon, il est nécessaire de cliquer sur le bouton bleu : « Publier les modifications ». Il n'y a pas d'enregistrement automatique.

Si votre but est de publier un nouvel article, votre brouillon doit respecter les points suivants :

• Respectez le droit d'auteur en créant un texte spécialement pour Wikipédia en français (pas de copier-coller venu d'ailleurs).
• Indiquez les éléments démontrant la notoriété du sujet (aide).
• Liez chaque fait présenté à une source de qualité (quelles sources  – comment les insérer).
• Utilisez un ton neutre, qui ne soit ni orienté ni publicitaire (aide).
• Veillez également à structurer votre article, de manière à ce qu'il soit conforme aux autres pages de l'encyclopédie (structurer – mettre en page).

• → Si ces points sont respectés, pour transformer votre brouillon en article, utilisez le bouton « publier le brouillon » en haut à droite. Votre brouillon sera alors transféré dans l'espace encyclopédique.

Les logiciels à fonctionnalités émergentes sont une catégorie spécifique de logiciels où les informations retournées par le système ne sont pas prévisibles. La plupart des jeux vidéos font partie de cette catégorie car la clé de leur succès est de surprendre le joueur.

Actuellement, les techniques de tests automatiques ne fonctionnent pas dans le domaine du jeu vidéo. En effet, la plupart des techniques de tests automatiques fonctionnent quand le développeur connaît toutes les données en entrée, et les sorties correspondantes. Mais ces sorties sont par définition inconnues (dans le cas contraire, nous n’aurions pas un logiciel à fonctionnalités émergentes). Même si nous pouvions énumérer toutes les entrées et sorties possibles, notre capacité à faire des tests qui couvrent tout ces états décroît exponentiellement. Les ingénieurs vont être de moins en moins capables de prédire les résultats d’un système, et leur capacité à vérifier et valider un logiciel va grandement diminuer. Il y a également des questions (notamment au niveau du design) qui ne peuvent pas correspondre à un test unitaire (ex : "est-ce que 90% des joueurs finissent le jeu en moins de 5 minutes ?").

L’état de l’art actuel sur les tests des jeux vidéos est de recruter des centaines de testeurs humains qui vont jouer à différentes versions du jeu durant tout le processus de développement afin de détecter les différents bugs et permettre aux développeurs de les corriger.

Classification des bugs dans les jeux vidéo

Il n'y a pas de classification officielle et standard des bugs présents dans les jeux vidéo, mais il existe une taxonomie qui permet de classer les bugs en deux catégories : les bugs intemporels, qui peuvent apparaître à n'importe quel moment dans le jeu, et les bugs temporels, qui nécessitent de connaître l'état précédent du jeu pour reconnaître le bug.

Bugs intemporels

• Position invalide : un objet ne devrait pas pouvoir être là où il est.
  • Objet hors limites pour n'importe quel état : un objet se trouve dans un endroit normalement inaccessible (ex: un personnage marche sur la surface de l'eau).
  • Objet hors limites pour un état spécifique : un objet est dans une position inaccessible mais qui pourrait être valide dans un autre contexte (ex: un PNJ apparaît dans une cinématique alors qu'il ne devrait pas).
• Représentation graphique invalide : le rendu graphique de certains objets ou aspects du monde est incorrect (ex: un personnage se met à nager alors qu'il est sur terre).
• Changement de valeur invalide : un problème avec un compteur (ex: prendre une balle ne retire aucun point de vie).
• Stupidité artificielle : l'intelligence artificielle ne répond pas aux attentes, c'est-à-dire que les personnages non-joueurs (PNJ) cassent l'illusion d'intelligence par certaines de leurs actions (ex: le PNJ marche contre un mur ou bloque le passage).
• Bugs d'information : des problèmes liés aux informations connues par le joueur
  • Manque d'informations : le joueur devrait connaître certaines informations pour comprendre le jeu mais ne les possède pas.
  • Accès à l'information invalide : le joueur connaît plus d'informations que prévu par accident (ex: en voyant à travers un mur).
  • Informations dans le désordre : le joueur reçoit les informations dans le mauvais ordre (ex: quand il y a plusieurs moyens d'obtenir une information, le joueur voit son personnage découvrir la même chose plusieurs fois).
• Bugs d'actions :
  • Action impossible : des actions que le jeu devrait permettre mais qui sont impossibles (ex: impossible de ramasser un objet).
  • Action non autorisée : des actions possibles lorsque le jeu est en pause ou pendant une cinématique, ou encore un script qui se lance au mauvais moment (ex: la cinématique se lance avant l'arrivée du personnage).

Bugs temporels

• Position invalide dans le temps : des mouvements impossibles (ex: téléportation) ou une absence de mouvements attendus (ex: un PNJ est coincé).
• Etat du contexte invalide dans le temps : des objets restent dans le même état trop longtemps (ex: immobilité).
• Occurrence des événements invalide dans le temps : des événements se produisent trop fréquemment ou trop rarement (ex: un événement rare se produit plusieurs fois d'affilée).
• Evénements interrompus : des actions dans le jeu se terminent de façon abrupte (ex: un personnage parle mais la bande-son s'arrête sans raison).
• Problèmes de réponse de l'implémentation : problèmes liés au matériel (ex: latences).

Détection et correction automatique des bugs

Dans le développement de logiciel classique, il est très courant d'utiliser des tests automatiques. Dans le but d'accélérer la phase de tests dans le développement de jeux vidéo, des approches sur l'automatisation des tests ont été avancées.

Fonctionnement d'une boucle de jeu

Détection de bugs

Des études ont montré la possibilité de détecter les problèmes à l'exécution. En effet, les programmes de jeux vidéo présentent des similarités : ils sont orientés objet et possèdent une boucle de jeu.

On sait qu'un tour de boucle change atomiquement l'état du jeu. Au lancement, la boucle est démarrée et attend en entrée l'intervention du joueur. A chaque action de l'utilisateur, les données sont traitées, l'état du jeu est modifié et le résultat est renvoyé au joueur. Lorsque la phase de jeu est terminée, la boucle est détruite.

En surveillant l'environnement d'exécution, il est possible de détecter dynamiquement des problèmes lors d'un tour de boucle à travers des contraintes et des conditions. Ainsi, les problèmes qui auraient pu passer inaperçus aux yeux d'un testeur sont détectés, et peuvent ensuite être corrigés.

Correction de bugs

Il est également possible, selon certains études, de corriger à l'exécution les problèmes qui ont été détectés. Lorsqu'une condition n'est pas respectée, la valeur qui viole cette contrainte peut être modifiée dynamiquement pour régler le bug. Par contre, rien n'indique que cette correction ne va pas entraîner des régressions, c'est-à-dire déclencher d'autres violations. Le pire cas possible est que chaque réparation provoque un bug qui est ensuite réparé automatiquement mais provoque un nouveau problème, et ainsi de suite, créant une boucle de réparations infinie.

Outils

Mayet

Mayet peut être caractérisé comme un moniteur d’exécution développé et utilisé par Chris Lewis et Jim Whitehead. Il regarde l’exécution d’un système et peut réaliser des actions basées sur l’exécution courante. Il peut ainsi corriger des comportements indésirables durant l’exécution du système en fonction de règles de sécurité précédemment définies. L’expérience requise pour prédire les différentes défaillance du système est proche de celle nécessaire pour faire des tests unitaires.

Ce système reste malgré tout limité, en effet il se concentre généralement sur la réparation d’états logiques. Il est incapable de détecter et de réparer un bug graphique, ceci correspond à la catégorie “représentation graphique invalide” de la taxonomie des bugs précédente. Il y a également la possibilité de déclencher une cascade de réparations : réparer un résultat va violer une autre règle, et ainsi de suite… Des bugs peuvent encore survenir, mais Mayet s’assure que ceux ci soient acceptables pour l’utilisateur.

Flexible Game Solver

La création d’un solveur est proche de la représentation des données et des opérations logiques du moteur de jeu. Le solveur est implémenté en suivant l’algorithme de parcours en largeur. Il va explorer chaque état du jeu, jusqu’à atteindre le but attendu. Chaque état est représenté par un noeud dans l’arbre, et chaque événement est une branche permettant d’accéder à un nouvel état. Tout d’abord, le solveur va lister tous les événement de la scène, puis il va en choisir un afin d’atteindre un nouvel état du jeu. Le processus est répété jusqu’à ce qu’un objectif soit atteint ou que la recherche deviennent trop profonde.

LeChimp

LeChimp est un serveur de tests fonctionnels utilisé par les développeurs du studio GamesFromWithin. Il exécute régulièrement le jeu sur un nombre fixe de frames, et s’assure que tout se charge et s’exécute correctement. Puis, il exécute de manière aléatoire différentes actions, comme si un singe jouait au jeu. Cela permet de découvrir des bugs que personne n’a remarqué durant leur essai.

Différences avec le logiciel classique

Les jeux vidéos sont des logiciels particuliers, et doivent donc aussi respecter les contraintes concernant les fonctionnalités demandées, le budget et le temps tout en fournissant une qualité au moins acceptable. Cependant, ils n’ont pas les mêmes objectifs et priorités que les logiciels traditionnels. En effet, les développeurs de jeux vidéos cherchent plutôt à divertir et amuser l’utilisateur. Il s’agit aussi d’un domaine qui touche les émotions du joueurs et tout en se voulant créatif et cherche à lui procurer de la satisfactions. Il ne s’adresse donc pas au même publique. Du fait des différences constatées entre le jeu vidéo et le logiciel classique, l’ensemble des tests sera donc différent.

On peux souligner quelques différences majeures:

• Un jeux vidéo ne connaît pas de maintenance, car une fois le produit mise en vente, il ne peut y avoir de retour: en général, il est mis sur le marché dans un support qui ne peut être modifié (cartouche,CD, DVD, Blu-Ray). Au contraire, un logiciel classique, lui se doit d'être maintenu. Cela change donc l’approche envers les tests, car si le produit est “mal” testé (contient "trop" de bugs), cela peut avoir des conséquences désastreuses.

En bref, un jeu a une durée de vie courte et ne demande pas de maintenance, contrairement aux logiciels traditionnels.

• Les tests ne se concentrent pas sur les mêmes parties selon que c’est un jeu vidéo ou un logiciel. En effet le jeu vidéo va préférer l'expérience utilisateur (le jeu doit être intuitif, maniable, amusant)à l'aspect technique (stabilité, sécurité).
• Les tests ne sont pas tous connus à l'avance. Il ne peut donc s'agir de tests automatisés. En effet certains tests guident le développement dans le sens où le produit est testé par des utilisateurs et juge le produit (le produit est il amusant? agréable à utiliser? Les règles du jeu sont elles faciles à comprendre?). En fonction des avis des utilisateurs, des améliorations seront apportées.

De plus ces tests sont moins chers à réaliser.

• Les jeux vidéos auront donc une préférence pour les tests d'utilisabilité et les "tests d'exploration" (en).

Causes probables de bugs

Les bugs peuvent être causés par de nombreux facteurs. A la fin du développement d'un jeu, il est fréquent d'utiliser des "documentations postmortems" (en) qui recensent ce qui s’est bien déroulé (les bonnes pratiques, les améliorations apportées, etc.) durant le développement du jeu mais aussi les problèmes rencontrés. Aussi, la littérature spécialisée décrit bien les problèmes couramment rencontrés. Certains de ces problèmes peuvent être à l'origine de bugs:

Le périmètre

Si une équipe de développement n’a pas établi un périmètre clair et réaliste avant de commencer son projet, sa structure risque de changer et peut ainsi poser des problèmes. Ainsi des fonctionnalités non prévues initialement peuvent ainsi être rajoutées pendant la phase de développement et rendre le projet plus volumineux (moins maintenable?). Aussi, il est essentiel de tracer un périmètre suivant son expérience: un projet trop compliqué et ambitieux peut s'avérer être problématique. Le jeu Gabriel Knight 3, par exemple, était un projet ambitieux pour une équipe inexpérimentée.

Le temps

Ce problème est lié au point précédent. Il est en effet important d'établir un périmètre clair et réalisable dans le temps imparti. En général les jeux vidéos connaissent des “deadlines” non flexibles: date de sortie d’un jeu coïncidant avec une date de fête par exemple. Si le temps n’est pas convenablement géré, il se peut que les développeurs ne dispose pas d'assez de temps pour repérer des problèmes et de les corriger. Par exemple, le jeu Rainbow Six a connu le même problème: une mauvaise gestion du temps n'a pas laissé assez de temps aux développeurs de réaliser pleinement leur phase de test. Ils ont cependant eu de la chance car ils n'ont pas repéré des bugs importants nécessitant plus de temps de correction. Aussi une mauvaise gestion du temps, rajoute une pression aux développeurs, les pousse à travailler plus, dormir moins, ce qui peut affecter leur capacité à produire un travail de qualité.

La technologie

En général, les jeux vidéos sont les leaders dans l'informatique graphique. Cependant il y a des risques lorsque l'équipe travail sur des plateformes nouvelles, car d'une part ils peuvent en avoir une mauvaise connaissance et d'autre part la plateforme elle-même peut contenir des problèmes. Par exemple, Age of Empire II, The Age of Kings, a rencontré des problèmes car les développeurs utilisaient l'API DirectPlay de Microsoft qui contenait elle-même des bugs et qui était mal documentée.

La communication

Il est important que les différents acteurs d'un projet ai une bonne communication, afin que chacun comprennent les attentes et traitent au plus vite les problèmes rencontrés avant que ceux-ci ne prennent une certaine ampleur. La communication peut être perturbé par l'éloignement géographique des équipes travaillant sur un projet, la différence entre les domaines de spécialités (artistes, programmeurs, etc.) des acteurs du projet ou encore par les canaux de communication utilisés. En 2002 les problèmes rencontrés par Microsoft et Turbine illustre ainsi la situation: les équipes des deux entreprises étaient séparés d'environ 5000 Kilomètres et par 3 heures de décalage horaire. Les deux entreprises n'étaient en plus pas spécialisé dans le même domaine. De plus les emails étaient parfois ignorés, et la base de donnée comportant les bugs rencontrés (RAID - Repetitive Application Issue Database) n'était pas utilisé de manière efficace.

Métiers du test dans les jeux vidéo

Il existe deux catégories de testeurs de jeux vidéo : les testeurs qualité et les journalistes.

Testeur qualité

On distingue plusieurs phases de jeu où interviennent les testeurs : ils commencent par la version alpha du jeu, c’est-à-dire la première version, pour terminer avec la version bêta, la dernière version test.

Rôle

Le rôle du testeur qualité consiste à faire la chasse aux bugs et incohérences, ainsi que donner son opinion sur des points de gameplay. Pour détecter les problèmes, le testeur qualité doit élaborer des tests fonctionnels et techniques. Même sur des passages où il n’y a pas de bug, le testeur peut proposer des améliorations et évaluer la difficulté du jeu.

Tester n’est pas jouer, c’est un processus long, fastidieux et répétitif qui nécessite de passer des heures sur des types de jeux qui ne plaisent pas forcément. Il s’agit de trouver les manipulations susceptibles de faire planter le jeu, en essayant des combinaisons incongrues et en imaginant des comportements imprévisibles du joueur.

Après correction des bugs, c’est au testeur de recommencer le jeu et de vérifier que les bugs détectés ont bien été supprimés. Il doit également assurer la stabilité des différentes versions du jeu.

Enfin, le testeur doit déceler les fautes d’orthographe ou de syntaxe dans les textes, les fautes de raccord grossières ainsi que les incohérences et les anomalies tant dans le scénario que dans la bande son

Profil

Le testeur qualité doit posséder un bon sens de l’observation pour détecter rapidement des problèmes techniques ou de design. Il doit avoir de la persévérance pour faire et refaire certaines scènes jusqu'à trouver et savoir reproduire un bug spécifique. Enfin, ce métier nécessite de la communication pour décrire un bug de manière claire et concise pour celui qui devra corriger ce problème.

Méthodique, le testeur doit répertorier les bugs dans une base de données et utiliser des logiciels de capture ou de communication de données.

Parcours et rémunération

Le métier de testeur qualité ne nécessite pas de formation spécifique. Cependant, un cursus en informatique ou une formation dans une école spécialisée dans le jeu vidéo reste un atout

Le métier de testeur est plutôt un tremplin vers d’autres métiers du jeu vidéo, permettant de monter en grade au sein du service des tests et de diriger une équipe de testeurs. Le testeur peut également devenir game designer, passer en production ou encore gérer des projets.

Journaliste testeur

Il faut distinguer les rédacteurs des pigistes. Les rédacteurs sont rattachés à un magazine tandis que les pigistes produisent des articles de tests à la demande. Il peut exercer son métier pour la presse écrite ou la presse en ligne. De plus, le journaliste spécialiste du jeu vidéo n’écrit pas seulement des tests mais également des rubriques annexes comme des solutions et astuces.

Rôle

Il peut être envoyé en reportage afin d'assister à une présentation d'un nouveau jeu vidéo et d'écrire un article objectif afin d'informer les lecteurs. Il doit alors prendre des informations auprès des créateurs et des développeurs du jeu afin de fournir des détails précis et concrets aux lecteurs du magazine.

Profil

Pour devenir journaliste spécialisé dans les jeux vidéos, il faut être passionné de jeux vidéo et être capable de finir rapidement tout type de jeu. Le journaliste doit être bon en Français et posséder des qualités d’écriture et de rédaction. Il doit aussi être ouvert d’esprit et suffisamment curieux pour se tenir au courant de l’actualité et des nouveautés.

Le sens de la communication et du contact est une qualité nécessaire car il est souvent amené à se déplacer dans des salons et des présentations de jeux vidéo. Parfois obligé de terminer des articles dans des délais très serrés, il est nécessaire au journaliste d’être résistant au stress.

Parcours et rémunération

Il n'y a pas de diplôme particulier pour devenir journaliste spécialisé dans le domaine des jeux vidéo.

Le rédacteur étant rattaché à un magazine, il touche un salaire fixe tous les mois tandis que le pigiste est payé en fonction du volume produit.