Débugger: mettre en place une procédure de référencement des bugs

Suite à une discussion sur l'avancement du forum, il était fait état d'un manque de tutoriels autre que de programmation concernant le jeu. Travaillant dans les jeux vidéos, je vous propose un léger tutoriel concernant une partie importante d'un projet : le débug.

Avant de parler à proprement parler de débug, il faut d'abord le situer dans le développement d'un projet.

Un projet se divise en 4 phases :

1. La pré production
2. La production
3. L'alpha version
4. La beta version

Je ne vais pas m'attarder sur les 2 premières phases mais plutôt m'intéresser aux versions alpha et beta d'un projet.

La version alpha est l'étape de finalisation du projet, c'est à ce moment qu'on décide de finir le développement et de stopper les nouveautés. Le but d'une version alpha et d'avoir le jeu fonctionnel quel que soit le nombre de bugs et de ne plus avoir à ajouter de composants (recherches, construction, etc., etc.). Pour qu'un projet soit alpha, il faut donc qu'il soit “terminé”. Par exemple, pour les jeux commerciaux, c'est à ce moment qu'on décide d'enlever telle ou telle arme d'un FPS car trop long à développer, qu'on enlève telle ou telle map car elle présente une trop grande instabilité. Une fois le jeu “terminé”, j'entend donc par là la conception, il entre en version beta.

La version beta est la version finale du jeu + les bugs. Il faut donc la debugger, et c'est à ce moment qu'arrive les testeurs. Le debug a logiquement pour but de n'enlever ni composant, ni options, mais de ne rien ajouter non plus, il faut juste éliminer tout bug possible présent dans le jeu. C'est uniquement une fois l'effacement de tous les bugs connus terminé que le jeu pourra être nommé gold. Jouable et complet, on pourra peut être se permettre de rajouter et d'améliorer le jeu, en évitant au maximum d'ajouter de bugs.

Comme dit dans le chapitre précédent, les testeurs entrent en jeu dans la version beta du jeu, et se doivent d'avoir un comportement critique et pro plutôt que de chercher à s'amuser. Ils doivent aussi faire preuve de mémoire et d'imagination. Leur rôle sera important car ils devront procéder comme suit :

1. Jouer normalement pendant un moment au jeu, se souvenir des bugs pour les signaler.
2. Commencer à tâter les points sensibles du jeu, trouver les failles.
3. Demander aux développeurs la manière dont fonctionne le moteur du jeu pour pouvoir l'exploiter au maximum.
4. Ensuite commence à proprement dit le test, et comme suit :
   1. Le testeur joue et trouve un bug
   2. Il trouve comment le reproduire facilement
   3. Si le bug ne se reproduit pas à 100% il note le nombre d'occurrences qu'il a eu pour le nombre d'essais (6/8)
   4. Prend des screenshots ou copie colle les messages d'erreurs
   5. Signale le bug au créateur
   6. Détermine la sévérité (gravité) du bug

Si cette procédure est correctement suivis, normalement, tous les bugs du projet seront référencées. Le testeur, s'il tient correctement son rôle, devient primordial pour la version beta d'un jeu.

Si vous vous lancez dans un projet de création de jeu, il ne faudra pas compter le mener à son terme sans générer environs 500 bugs pour un projet léger ou 1000 si les testeurs sont pointus.

Dans le monde des développeurs professionnels pour des journées de +/- 8H on considère qu'un programmeur génère un peu moins de 1 bug par jour de développement. On parle bien ici des bugs livrés aux testeurs après avoir déjà éliminé tous les bugs sur sa machine. Un programmeur inexpérimenté, qui teste peu, génèrera évidement plus de bugs. Après quelques jours de travail et la mise en tests de vos premiers modules, vous pourrez vite calculer le taux qui s'applique à votre projet. Si vous générez 20 bugs par jour de travail, il faut tester plus avant de livrer!

Affin de pouvoir gérer tous les bugs, et les suivre, il est vivement conseillé de mettre en place un suivi des bugs (bugtracker en anglais).

La base de suivi des bugs est un élément simple à créer et super efficace. Elle a pour but de suivre l'état de tous les bugs pour savoir quel est l'avancement du debug et donc quand approche la fin du projet.

Il existe des produits tout fait et gratuit comme Mantis : http://www.mantisbt.org/download.php Avec un peu d'investissement pour l'installer et faire ses premiers pas, vous verrez qu'ils offrent de nombreux atouts. Voici quelques avantages :

• L'outil est fait pour ça il est le fruit d'une longue réflexion sur le problème
• vous ne perdrez pas de temps à programmer votre bugtracker, vous pourrez plutôt programmer votre jeu
• Ces outils sont très répandus et investir un peu de temps pour les maîtriser vous servira probablement sur un autre projet ou une autre équipe qui l'utilise aussi.
• Même si votre projet devient conséquent, des outils comme Mantis, tiennent la charge et le volume d'informations, ils comportent de nombreuses fonctionnalités comme l'upload de fichiers, l'envoi d'email, la gestion de statistiques, etc.

Sinon, vous pouvez partir sur une solution maison. Il vous suffit de créer une base de donné simple que les testeurs devront remplir. Pour cela, il vous faudra la concevoir comme suit, les explications suivront :

tbl_basedebug

| id_bug
| nom_testeur
| severite_bug
| reproductibilite
| explications
| etat

Une fois cette base crée, il vous faut créer le formulaire pour la remplir, pour cela :

id_bug : automatique (auto-incrément) nom_testeur : liste déroulante avec tous les noms des testeurs inscrits severite_bug : liste déroulante avec 3 sévérités : S1, S2 et S3 reproductibilité : zone de texte que les testeurs rempliront explications : champ de texte multilignes pour toutes les explications du bug etat : liste déroulante avec : 'ouvert', 'réouvert', 'fixé' puis 'fixé et vérifié'.

Puis une simple page php pour modifier et lire les bugs.

Une fois cela mis en place, les testeurs et développeurs doivent tenir certaines règles :

Quand un testeur trouve un bug, il ouvre la page du formulaire et rempli les champs suivants :

• Nom du testeur
• Reproductibilité
• Explications

La case explications est très importante, le testeur doit mettre exactement ce qu'il a fait, comment le faire facilement, ce qu'il s'est passé, ce qu'il devrait se passer et y mettre les messages d'erreur qu'il a eu si c'était le cas.

Lors de la création du bug, le champ état doit passer automatiquement en 'ouvert'

A ce moment, les développeurs ouvrent le bugs, choisissent la priorité du bug et se parlent entre pour qui doit le corriger.

Une fois le bug corrigé, ils le passent en 'fixé'.

Lorsqu'un testeur voit l'un de ses bugs fixé, il le reteste, s'il se reproduit, il le passe en 'réouvert', sinon en 'fixé et vérifié'.

Le bug est donc corrigé.

Avec cette méthode travail, les testeurs doivent être en totale harmonie avec les développeurs et suivre la base de bugs très précisément.

Les développeurs pourront voir le nombre de bugs restants, les traiter et communiquer sur chaque bug très clairement. Il faut aussi que les testeurs sachent exactement ce qu'attendent d'eux les développeurs et qu'ils rentrent vraiment tout les bugs qu'ils voient, jusqu'au simple pixel en trop sur une image. Et aussi suivre tous les bugs fixés pour voir s'ils le sont vraiment, ne pas en oublier un seul.

Plus il y a de bugs, plus il y en aura de corrigés, plus la qualité du jeu sera importante.

Pour optimiser encore plus le test et donc, le debug, vous pouvez par exemple améliorer la base de bugs avec plus de champs utiles :

• La version sur laquelle la correction du bug est présente
• Un menu déroulant avec tout les endroits du jeu (pour localiser plus précisément)

Ensuite, vous pouvez répartir les taches des testeurs, chacun teste un morceau spécial du jeu.

Sinon, il faut penser au stress-test, qui consiste à ce que tout le monde effectue un maximum d'actions sur le serveur en même temps, pour voir s'il y a des bugs liés, par exemple, aux piles SQL.

__

Et voilà, j'espère que cela va vous servir. C'est le genre de process que nous utilisons, la base de bugs étant beaucoup plus importante ! Tant niveaux champs descriptifs que nombre de bugs.

Elle s'avère très efficace et motivante, quand le nombre de bugs descend, c'est que la fin est proche !

A vos jeux, prêts, développez !!!!!!!!!!

Tutoriel composé par Shudrum