Aucun projet ne se passe bien, vous aurez toujours des couacs plus ou moins importants. L’idée est évidemment de les minimiser au maximum et d’apprendre à les gérer. Quand vous êtes junior (mais certains « séniors » n’y arrivent pas), malgré votre formation, votre stage, votre capacité à analyser un problème, le résoudre vite mais bien n’est pas encore au point.
C’est normal, on apprend tous les jours (moi le premier).

Je vais donc commencer par les crises que je rencontre tous les jours, les problèmes de mise en ligne. Je ne vais pas détailler dans ce billet les best-pratice d’une mise en ligne (validation DEV, PREPROD, PROD etc). Imaginez simplement qu’un problème apparait, 2 grands type de bugs : mineur et majeur.

Mineur ( problème d’affichage sur certains navigateurs, liste déroulante qui bloque (sur une page de niveau N-5) ).

Généralement, même un chef de projet junior gardera son calme sur ce type de bugs. On constate soi-même l’erreur, on essaie de le reproduire, on le transmet à son développeur en expliquant la manipulation pour y arriver. On peut ouvrir un ticket sur un système de bugtracking (Mantis par exemple). Cela fera partie ainsi de la todo. Il faut juste veiller ensuite à ce que la todo soit traitée dans des délais raisonnables.

Majeur (inscription en base ne fonctionne pas, statistiques ne passent pas, mise en ligne de rubriques, contenus non finalisées)

Ce genre de bugs vous donne déjà plus de stress, s’il a été remonté par le client et que 5 minutes après, vous avez votre boss qui vient vous voir (et qui a reçu un appel téléphonique entre temps) , vous savez à ce moment là que la situation n’est pas propice à la blague .

Malgré tout, le point clé est de garder son calme afin de rester méthodique et être rapide.

Et c’est toujours la même procédure qu’un bug mineur, à savoir : reproduire le bug, analyser en même temps que vous naviguez les flux http (avec un logiciel comme Service Capture), identifier la page, le champ texte qui pose problème. A ce stade là, dans 75% des cas, vous aurez compris pourquoi ça ne fonctionne pas et indiqué à votre développeur ce qu’il faut corriger. Dans l’heure, le bug pourra être résolu de façon plus ou moins propre.

MAIS si vous êtes dans les 25%, allez prendre un verre car votre journée n’est pas finie. Allez voir votre développeur, reproduisez le bug avec lui. Si besoin, faites intervenir plusieurs personnes. Selon la situation, il faudra vous adapter, faire des choix (impossible à corriger, mise en ligne du backup).

Ce que j’ai essayé de faire comprendre à travers ce billet, c’est qu’être réactif pour résoudre une crise liée à une mise en ligne suppose :

1. avoir toujours sous la main un backup (soit une sauvegarde manuelle de la version en ligne, soit via SVN) pour faire un rollback en catastrophe, veiller à faire les mises en ligne avec votre développeur (malheureusement pas toujours respecté et ensuite très compliqué pour vous de connaitre les fichiers qui ont été passés etc).
2. ne pas véhiculer le stress de la partie commerciale (le client) à votre développeur, d’où l’intérêt de lui préparer la manipulation pour refaire le bug, et veiller à ce que ça soit le CP technique qui discute avec lui, faire comprendre que c’est urgent mais ne pas s’énerver (on fait ce genre de mise au point après l’incident, pour éviter que cela se reproduise).
3. restez méthodique.

Des bugs, vous en aurez tous les jours. Vous allez rapidement vous apercevoir qu’il y a toujours les mêmes solutions aux mêmes problèmes. Et en gestion technique, je vous laisse deviner tout ce qu’on voit passer. Cela permet de relativiser.

Apprenez à les gérer, l’important n’est pas toujours votre capacité à comprendre le bug (mais au moins le reproduire niveau fonctionnel), mais bien faire le tampon avec le client qui a tendance à s’affoler pour rien, et votre développeur.

Et bien, c’est simplement le fait d’effectuer des tests de votre site avant ouverture au grand public. Vous pouvez soit la faire en cours de développement, soit à la fin : tout dépend de la nature des projets.

Trop souvent sous estimée, elle est pourtant la garantie de la qualité du résultat final. La recette technique va s’attacher à vérifier le bon enregistrement en bdd des champs, au bon format, vérifier la sécurité de votre application, l’optimisation, vérifier le passage des statistiques. La recette fonctionnelle va être la partie plus créative ou simplement de wording; le bon lissage des typographies etc.

Plusieurs problèmes se posent pour faire une « bonne recette » :

1. Trouver le temps : vous en avez rarement
2. Déterminer qui recette quoi, quand : pour une recette efficace, il est important de ne pas laisser une personne tester un site toute seule. Prévoyez au minimum 2 personnes
3. Déterminer la manière dont les retours de cette recette seront transmis à vos équipes
   • Un simple document word qui identifie une liste de bugs à la suite : généralement très brouillon et peu organisé. Recette.doc
   • un fichier excel qui identifie les bugs avec différents paramètres (où se situe le bug, quelle priorité, statut, commentaires etc). Ce document permet déjà de mieux organiser quelles serontt les personnes qui corrigeront les bugs. Recette.xls
   • Un système de bug tracking comme Request Tracker ou Mantis.

J’ai volontairement pris des exemples simples en suivant les 3 types de traitements possibles : doc word, doc excel, bug tracker.

Une fois les bugs potentiels constatés, je suis partisan de regrouper les retours. C’est à ce moment là ou vous pourrez affecter à vos ressources les problèmes rencontrés. C’est souvent plus efficace que faire des retours point par point. Idéalement, sur des sites fonctionnels, vous établissez des procédures de tests par rubrique ou fonctionnalité.

Exemple : un site e-commerce

Procédure de test du module d’achat

1. Etape 1 : Aller sur la home www.maboutique.com
2. Etape 2 : Sélectionner la dernière fiche produit ajoutée au catalogue
3. Etape 3 : Ajouter cet article dans votre panier en cliquant sur le bouton « Ajouter a mon panier »
4. Etc.

Le très gros avantage de ces scénarios de tests est que vous organisez pour vous mais aussi votre client la recette du site. L’un des inconvénients qui pourrait vous venir à l’esprit est que si je cadre le parcours de tests, je réduis les risques de bugs qu’un internaute lambda pourrait rencontrer avec un parcours atypique.

L’idée est d’avoir vos parcours établis en phase de conception qui fonctionnent. Une fois ceux-ci validés, une recette globale avec des scénarios non définis pourra être envisagée. Les bugs constatés seront alors remontés. Ce qu’il faut, c’est fonctionner par étape (dans les tests mais après dans le débug) pour être efficace et ne pas laisser de coquilles.

En tant que chef de projet, vous êtes le garant du bon déroulement fonctionnel et technique de votre site. Dans vos chiffrages, prévoyez 20 à 25% de temps en plus pour cette phase. Sur des sites évènementiels full flash, qui sortent en charrette, cette recette est malheureusement effectuée trop rapidement et on rencontre une fois la mise en ligne des bugs parfois majeurs qu’il vous faudra corriger rapidement. Je vous laisse imaginer le stress que génère ce genre de situation quand il s’agit de jeux concours à fort trafic…

Et vous, quels sont vos outils pour tester un site correctement ?