I. Le serveur de livraison

Afin de s'assurer d'avoir le moins de surprises possible lors du déploiement en production, il est important pour le client livré de fournir un environnement de livraison ayant les mêmes caractéristiques que l'endroit ou sera déployé l'application finale. Il s'agit du serveur de pré-production, dit "préprod".
La livraison s'effectue le plus souvent par FTP sur un serveur qui idéalement:

• tourner sur le même OS que la prod, donc pas de Linux pour une prod Windows et vice-versa
• fournir les mêmes autorisations sur les dossiers/fichiers (les scripts de manipulation de fichiers doivent pouvoir accéder aux mêmes choses qu'en prod)
• faire tourner les mêmes versions mineures des logiciels utilisés (PHP, MySQL, Apache ou IIS, AMFPHP, etc...)
• donner les mêmes possibilités d'administration des URLs (redirections, .htaccess, erreurs 404, etc...)
• donner l'accès aux même conditions d'URL (ne pas tester dans un sous-répertoire d'un nom de domaine un site qui tournera à la racine d'un domaine). Par exemple, tester un projet qui tournera sur http://www.monprojet.com sur une préprod qui serait http://preprod.monclient.com/monprojet peut donner des surprises au déploiement.

!NOTE AUX DÉVELOPPEURS! Comme ce dernier point n'est pas toujours possible, il est important dans ses développements de privilégier les chemins d'accès relatifs (../xml/config.xml) aux chemins d'accès absolus (/xml/config.xml). De la même manière, je conseille de toujours partir sur la base d'un seul fichier de configuration, commun à tous les codes de l'application (PHP, Flash, JS, sur front-office comme sur back-office), qui sera le seul nécessitant une modification lors du déploiement sur l'environnement de production. Ca simplifiera la vie à tout le monde!

II. Configurer son ordi pour une recette

1. Un ordinateur stable

Ca peut paraître bête à dire, mais si on utilise un ordinateur qui plante tout le temps (je serais mesquin, je dirais "un PC par exemple" :-P), on ne saura jamais si c'est l'application ou l'environnement qui plante. Avoir un système propre et stable est donc la première étape d'une recette.

2. Un navigateur configuré pour "recetter"

Personnellement, j'utilise Chrome au quotidien, selon moi plus adapté au surf de tous les jours car rapide et léger. Je n'ai pas besoin d'une quelconque extension tant mes besoin ne sont vraiment pas exceptionnels en matière de surf. De plus, la mise à jour est transparente, autant pour le browser lui-même que pour le player Flash, et je suis donc sûr d'être sur la dernière version disponible en permanence. De plus, le Flash player est interne à Chrome, ce qui me permet d'installer une version différente pour mes autres navigateurs.

Pour le travail, notamment sur Flash, j'utilise par contre Firefox, pour ses nombreuses extensions dédiées au développement, que nous verrons plus loin. Il peut-être bien pratique d'installer un navigateur uniquement pour le débugage: si vous utilisez Firefox en tant que navigateur principal, je crois qu'il est possible d'en installer plusieurs instances.
Un navigateur destiné à la recette doit être configuré pour ne pas utiliser de cache: on n'imagine même pas le nombre d'heures passées en discussions stériles entre développeurs et testeurs uniquement parce que ce n'était pas la même version qui était testée... Les navigateurs sont parfois capricieux à vider leur cache, qui se répand dans les méandres du disque dur. Alors pour vous épargner ce temps en étant sûr de ne pas avoir affaire au cache, vous pouvez utiliser un plug-in qui va le désactiver. Pour ma part, il s'agit de la Web Developer Toolbar de Firefox.

3. Le player DEBUG

Une erreur Flash ne remonte pas lorsque le player classique est utilisé. Il est donc important d'avoir installé le player DEBUG afin de les retourner au développeur lorsque l'on rapporte un bug. Etant donné que ces même erreurs interrompent complètement l'exécution du code, il donnera au développeur une précieuse information, bien plus utile que "ca ne fait plus rien"... Les versions debug des players sont disponibles à l'addresse: http://www.adobe.com/support/flashp...
Si vous utilisez le même navigateur pour la recette et votre usage quotidien, s'il s'agit de Firefox, vous pouvez installer la bien pratique extensions Flash Switcher. Vous pouvez ainsi utiliser une version debug pour une recette, et une version "normale" pour le reste...

4. Un proxy

Pour les applications communiquant avec un serveur, il peut être bien utile pour le développeur de savoir si un message réseau est parti, s'il est revenu, et quel est le contenu de ce retour. Fournir cette information lors de la déclaration du bug est un gain de temps évident pour sa résolution.
Pour ma part, j'utilise Charles: pas cher, entièrement en Java donc dispo pour toutes plateformes, il installe également un plug-in Firefox qui active/désactive le proxy facilement... Il existe aussi des extensions Firefox qui font cela, ainsi que d'autres logiciels standalone.
Un proxy permet également de voir si des ressources (images, fichiers XML ou autres...) on été demandées par le Flash, mais pas trouvées sur le serveur (erreurs 404 ou 500).

5. Une console de traces

Les développeurs insèrent souvent des messages de trace, ne serait-ce que pour vérifier que le code passe bien par là où il doit passer. Afin de lire ces messages, en plus du player DEBUG, il faut vous munir d'une console où les afficher. Elles ne manquent pas, que ce soit sous forme d'extension pour navigateur ou en standalone. Pour ma part, j'utilise SOS, développé par les excellents PowerFlasher (je suis un fan absolu de FDT).
Le testeur ne sais pas toujours à quoi correspondent les différentes traces, mais cela permet à un développeur de demander si tel ou tel message s'est affiché dans la console, cela permettant de clarifier et accélérer les échanges qui mèneront à la résolution du bug. Evidemment un message du type "EH MERDE, CA MARCHE PAS" qui apparait dans la console peut être pertinent à remonter au développeur!

III. Echanger avec le développeur

1. Avoir un outil de suivi de bugs

Il peut prendre plusieurs formes. La plus fréquente est un BugTracker. En ce qui me concerne, lorsque mes clients n'en ont pas, je leur propose Mantis. En PHP, simple d'accès et de configuration, il est pour moi un des meilleurs compromis efficacité/simplicité. De grosses structures utilisent souvent JIRA, pour ma part, je le trouve un peu nébuleux, mais il s'avère efficace lorsqu'il est bien configuré, et que le projet l'est également. J'ai également entendu dire beaucoup de bien d'un tracker en mode hébergé, nommé SifterApp.
Un BugTracker permet non seulement de remonter un bug au développeur, mais également de suivre toute son évolution: qui l'a reporté, les compléments d'information nécessaires, les captures d'écran, la résolution (ou non) de celui-ci, etc...
Lorsqu'aucun BugTracker n'est disponible, les remontées de bugs se font trop souvent sur un document Excel ou PowerPoint. Autant le dire tout de suite: C'EST LA PIRE RECETTE POSSIBLE!

• sur Excel, aucune capture d'écran n'est possible, et à moins d'écrire une tartine difficilement lisible dans une case, il est compliqué de donner des infos détaillées sur le bug
• sur PowerPoint, le bug est souvent une grosse capture d'écran, avec une flèche pointant vers le bug quand on a de la chance, suivie d'une phrase trop courte par manque de place

Dans les deux cas, il est surtout impossible ou extrêmement laborieux d'échanger avec le développeur. Cela se fait souvent par mail ou IM, avec pour référence "Le document du 17 Février, page 14", sachant que 2 documents similaires ont pu être échangés depuis, avec ou sans répétition des précédents.
Si ce support devait absolument être utilisé, certaines règles sont essentielles à respecter afin de limiter les dégats:

• donner un numéro unique à chaque bug, et organiser le document de reporting par ordre de numéro de bug (facilite la recherche dans le document)
• pour chaque document échangé, le dernier en date fait foi. Cela veut dire qu'il doit contenir tous les bugs restant à résoudre, ou qui nécessitent l'attention du dev.
• chaque bug doit faire l'objet d'une description détaillée (voir ci-dessous), avec copie d'écran annotée si nécessaire.
• mettre la date du document dans le nom du fichier, au format <année>_<mois>_<jour>: cela permet un classement alphabétique cohérent quand on affiche une liste de fichiers sur son ordi.

En l'absence de tracker, une option a été trouvée avec un de mes clients et elle s'avère limiter les dégats sous la forme d'une feuille de calcul sur GoogleDocs (ou tout autre outil de collaboration en ligne). Sans atteindre le confort, la puissance et donc l'efficacité d'un tracker, cela permet malgré tout une réactivité améliorée par rapport à un échange de mails, si le document est bien organisé et comporte toutes les infos nécessaire (voir ci-dessous).

2. Déclarer un bug

Il s'agit là de la partie la plus anodine, et en même temps la plus importante d'une recette. Afin d'optimiser la durée et le nombre d'échanges, un bug doit être déclaré de la manière la plus complète. Souvent, un BugTracker demande un certain nombres des informations utiles dans des zones de saisie dédiées, facilitant ainsi la clarté du bug. Dans tous les cas, il est nécessaire d'avoir pour chaque bug:

• un numéro, trés important pour les échanges, il identifie de manière commune le bug, pour le testeur comme pour le dev. Il permet d'éviter les noms du genre "Le bug du bouton rouge qui cliquait pas comme il faut"
• un titre clair et concis. Voire ci-dessus un exemple de nom à éviter!
• une catégorie. Souvent, elle est liée à l'endroit ou à l'écran sur lequel se situe le bug. Quand ce champ n'est pas prévu, il peut apparaître sous forme de "tag" avant le nom du bug, par exemple: (Editeur de niveau) Bouton SAVE inopérant.
• une description détaillée. Elle doit contenir les effets du bug: un bouton qui ne fait rien, un graphique qui ne s'affiche pas ou part en sucette, une couleur qui n'est pas la bonne, bref la différence entre le comportement attendu et le comportement effectif.
• une priorité. Pour un développeur, un bug est un bug. Selon la méthode de travail qu'il utilise ou le mode de raisonnement qu'il suit, ses priorités peuvent être différentes des vôtres. Si vous avez besoin que certains soient résolus avant d'autres, faites le savoir.
• une sévérité. Ca peut être "Bloquant", "Majeur", "Mineur", "Anecdotique", "Amélioration", etc...
• un scénario. Une des parties les plus importantes. Le développeur doit savoir comment reproduire le bug avant de pouvoir le résoudre. Le testeur doit donc bien reconstituer l'ensemble des manipulations effectuées pour arriver à ce bug, quitte à reprendre le parcours depuis le lancement de l'application. A noter cette phrase tellement vraie: "Quand un chef de projet reproduit un bug, il est déçu car cela veut dire qu'il reste un bug. Quand un développeur reproduit un bug, il est content car cela veut dire qu'il va pouvoir le résoudre".
• une reproductibilité. C'est la facilité que l'on a à reproduire le bug. Un testeur ne doit pas remonter un bug tant qu'il ne s'est pas battu bec et ongles pour le reproduire. La reproductibilité sera de type "Toujours", "Fréquent" ou "Non reproduit"... Les bugs relevant de cette dernière possibilité étant bien évidemment les plus difficiles et donc les plus longs à résoudre. Souvent d'ailleurs, si on arrive pas à le reproduire au bout d'un certain nombre d'essais, on le considère comme inexistant par la force des choses.
• une cause probable. C'est là qu'interviennent les outils cités plus haut qui permettent au testeur de faciliter et donc d'accélérer le travail du codeur. Il peut s'agir d'un message réseau qui n'a pas eu de réponse, ou dont la réponse contient une erreur (message d'erreur PHP par exemple), d'une ressource non trouvée (image, fichier XML, etc...), d'un message d'erreur remonté par Flash (player DEBUG), ou simplement remonté par le codeur dans ses traces (console de trace).
• un statut (voire ci-dessous).

3. Suivi d'un bug

Afin que tout le monde parle le même langage durant la recette, pouvoir suivre les bugs est important, ne serait-ce que pour éviter des échanges informatifs superflus. Le suivi donnera non-seulement un état des lieux de la recette, mais évitera aussi, par exemple, de redéclarer un bug que l'on pensait résolu, alors que le développeur n'a même pas commencé à le regarder, ou qu'il l'a résolu et pas livré... Ce suivi se fait généralement par deux moyens:

a. Un statut pour le bug

Il permet de savoir quel est l'état de traitement de celui-ci. Les états courants, dans l'ordre classique, sont les suivant:

• déclaré. Le bug vient d'être déclaré par le testeur.
• accepté / refusé / incomplet. Le développeur a lu le bug. Il le prend en charge, le refuse en expliquant la raison (ça peut aller de "Mauvaise interprétation du CDC" - les testeurs ne sont pas toujours les demandeurs/concepteurs - jusqu'à "Hors de périmètre de la mission" - dans le cadre d'une amélioration par exemple - ou une impossibilité de reproduire, ou qu'il s'agit d'un doublon avec le bug N°__), ou bien il demande plus d'informations pour pouvoir ensuite accepter / refuser le bug.
• en cours. Dans certain process, le développeur notifie le testeur quand il commence à travailler sur le bug. Très honnêtement, il est rare qu'un dev utilise ce statut, ne serait-ce que parce qu'il oublie de le faire...
• résolu. Le développeur notifie le testeur qu'il a résolu le bug, mais que ce fix n'est pas encore deployé sur la plateforme de test.
• deployé. La résolution du bug est disponible sur l'environnement de test.
• retourné. Le bug a été testé, mais pas considéré comme résolu. Le testeur retourne alors ce bug au développeur, avec les informations détaillées qui lui font dire qu'il n'est pas encore fixé.
• fermé. La résolution du bug est validée par le testeur.

L'état d'un bug peut-être notifié par un code couleur, facilitant ainsi la vue d'ensemble d'une recette par ses différents intervenants. Cela est encore plus utile dans le cadre d'un document de reporting qui n'est pas un tracker.
Le processus de travail est principalement centré sur ce statut, car il permet à chaque partie de savoir où il doit intervenir pour faire avancer la situation du bug: les testeurs doivent intervenir sur les statuts "incomplet" (pour le complèter) et "deployé" (pour le tester), les devs sur "déclaré" (pour l'accepter), "accepté" (pour le traiter), "résolu" (pour le déployer) et "retourné" (pour l'accepter).

b. Des commentaires

Cela constitue la colonne vertébrale du bug et représente la partie "échanges" du bug. Dans le cadre d'un BugTracker, les commentaires de chaque intervenant permettent de retracer la vie du bug, et donc de savoir ce qui a mené à son état actuel. En dehors d'un tracker, il s'agit le plus souvent de mails, et ce qui pose problème alors et qu'on aborde souvent plusieurs bugs dans un même mail. Si les échanges par mails étaient le seul moyen, essayez de ne faire qu'un mail par bug, et de spécifier dans le titre de celui-ci le numéro du bug (par exemple (BUG #__) Demande d'infos), permettant ainsi le regroupement de plusieurs mail parlant du même bug, pour ainsi reconstituer cette colonne vertébrale.

IV. Conclusion

Donner la touche finale à un projet n'est pas évident.
La livraison peut se révéler parfois un véritable parcours du combattant avant un déploiement en production, et les conseils ci-dessus peuvent aider à la rendre bien plus douce, et surtout rendre l'échange testeur/développeur bien plus qualitatif, ce qui permet de préserver les nerfs, le temps et donc l'argent de tout le monde, pensez-y!