Recetter un site internet

Qu’est ce qu’une recette ?

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 ?