Suite à une discution sur l'avancement du forum, il était fait état d'un manque de tutoriaux 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.
I. Le débug, qu'est-ce que c'est ?
Avant de parler à proprement parler de débug, il faut d'abord le situer dans le dévellopement d'un projet.
Un projet se divise en 4 phases :
La version alpha est l'étape de finalisation du projet, c'est à ce moment qu'on décide de finir le dévellopement 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évelloper, 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 le 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.
II. Le but des testeurs
Comme dit dans le chapitre précédent, les testeurs entre en jeu dans la version beta du jeu, et se doivent d'avoir un comportement critique et pro plutot 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 :
III. Comment suivre correctement les bugs ?
A mon avis (car ca n'a jamais été vérifié), il faudra compter dans les environs de 500 bugs pour un projet léger. 1000 si les testeurs sont pointus.
Or, il faut savoir gérer tous les bugs, et les suivres. C'est à ce moment que rentre en jeu la base de bugs.
La base de bug 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 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évellopeurs doivent tenir certaines règles :
a. Quand un testeur trouve un bug :
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'
b. Ensuite les dévellopeurs ouvrent le bug
A ce moment, les dévellopeurs 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é'.
c. Quand un bug meurt ...
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é.
IV. Une totale harmonie
Avec cette methode travail, les testeurs doivent être en totale harmonie avec les dévellopeurs et suivre la base de bugs très précisément.
Les dévellopeurs 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évellopeurs et qu'ils rentrent vraiment tout les bugs qu'ils voyent, 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.
V. Pour aller plus loin
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écisement)
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évellopez !!!!!!!!!!
I. Le débug, qu'est-ce que c'est ?
Avant de parler à proprement parler de débug, il faut d'abord le situer dans le dévellopement d'un projet.
Un projet se divise en 4 phases :
- La préproduction
- La production
- L'alpha version
- La beta vesion
La version alpha est l'étape de finalisation du projet, c'est à ce moment qu'on décide de finir le dévellopement 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évelloper, 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 le 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.
II. Le but des testeurs
Comme dit dans le chapitre précédent, les testeurs entre en jeu dans la version beta du jeu, et se doivent d'avoir un comportement critique et pro plutot 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 :
- Jouer normalement pendant un moment au jeu, se souvenir des bugs pour les signaler.
- Commencer à tâter les points sensibles du jeu, trouver les failles.
- Demander aux dévellopeurs la manière dont fonctionne le moteur du jeu pour pouvoir l'exploiter au maximum.
- Ensuite commence à proprement dit le test, et comme suit :
- Le testeur joue et trouve un bug
- Il trouve comment le reproduire facilement
- Si le bug ne se reproduit pas à 100% il note le nombre d'occurences qu'il a eu pour le nombre d'essais (6/8)
- Prend des screenshots ou copie colle les messages d'erreurs
- Signale le bug au créateur
- Détermine la sévérité (gravité) du bug
- Le testeur joue et trouve un bug
III. Comment suivre correctement les bugs ?
A mon avis (car ca n'a jamais été vérifié), il faudra compter dans les environs de 500 bugs pour un projet léger. 1000 si les testeurs sont pointus.
Or, il faut savoir gérer tous les bugs, et les suivres. C'est à ce moment que rentre en jeu la base de bugs.
La base de bug 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 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évellopeurs doivent tenir certaines règles :
a. Quand un testeur trouve un bug :
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'
b. Ensuite les dévellopeurs ouvrent le bug
A ce moment, les dévellopeurs 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é'.
c. Quand un bug meurt ...
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é.
IV. Une totale harmonie
Avec cette methode travail, les testeurs doivent être en totale harmonie avec les dévellopeurs et suivre la base de bugs très précisément.
Les dévellopeurs 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évellopeurs et qu'ils rentrent vraiment tout les bugs qu'ils voyent, 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.
V. Pour aller plus loin
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écisement)
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évellopez !!!!!!!!!!
Placeholder
