Si comme moi vous avez l’occasion de tester très souvent un site web ou une appli, vous serez d’avis qu’un certain nombre de bugs vous échappent avant la mise en ligne de votre service. A force d’erreurs j’ai retenu quelques leçons surement évidentes, mais que je souhaite partager avec vous.
1) Ne jamais être le testeur de ce que l’on code
Si vous codez vous serez tenté de dire que vous êtes le meilleur testeur de ce que vous avez codé, puisqu’on connait par cœur ce que l’on a fait.
En fait c’est tout l’inverse : avec son code on a tendance à être « trop gentil » et à tester toujours les mêmes cas. Inconsciemment on a pas envie de se trouver des bugs. Alors qu’à son collègue, beaucoup plus 
Bref faites toujours tester votre code par quelqu’un d’autre.
2) Tester avec de VRAIES données…
Au début pour tester je mettais des données genre lorem ipsum ou vraiment n’importe quoi . Et finalement tout semblait marcher bizarrement .
Mais avec l’expérience j’ai compris que rentrer des vraies données ( vraie adresse, vrai nom ) c’était beaucoup mieux : ainsi les erreurs m’étaient beaucoup facilement visibles ( ah non mon prénom c’est pas Lebel, ça c’est mon nom. Oups j’habite pas ici en fait… ) .
Oui cela prend plus de temps mais c’est indispensable pour découvrir de nouveaux bugs.
3) Et n’oubliez pas de mettre des accents….
Alors ça c’est la base . Le nombre de services ( surtout américains car ils s’en foutent ) qui gèrent mal les accents est incroyable ( pour les geeks si je vous dis encodage vous avez déjà deviné ! ) . Donc allez-y avec vos é, à ,…. Caractères encore plus bizarres appréciés.
4) Repartez du début aussi souvent que possible
Quand on lance un service on procède souvent par itération : des petits bouts de code, des tests, des debugs, du code, etc…
Bref à la éniemme itération on teste souvent avec un compte créée il y a fort longtemps , qui a pu être patché ou ne sais-je encore…
Si vous ne testez pas dans les mêmes conditions qu’un NOUVEL utilisateur et bien cela est une source énorme d’erreurs car vous ne serez jamais sûr d’être dans les mêmes conditions.
Bref à chaque phase de test pensez a recréer un compte, vous trouverez plein d’erreurs… Et au moins vous serez sûr que l’inscription marche bien !! ( ce qui est très important vous en conviendrez )
5) Testez dans le « pire » cas
En théorie il faut testée pour un mobile sur tous les devises possibles, et sur les sites web sur tous les navigateurs possibles.
Si par manque de temps et de moyen ce n’est pas possible, essayez d’avoir une config aussi « minimale » que possible .
Pour le site web en général le point faible c’est IE ( surtout si vous voulez être compatible IE7 ) par exemple.
Si vous faites des tests pour une app iPhone, essayez de garder une version d’OS minimale. Par exemple si votre target est iOS 4.0 minimal essayez d’avoir un device en 4.0 .
Je me souviens avoir trouvé ainsi un bug critique de cette manière car une fonction utilisée était compatible 4.1 et plus uniquement.
Ces petits conseils sont surement évidents pour beaucoup. Et évidemment en théorie il faut un plan de test détaillé et sans faille. Mais même avec un plan de test , ces conseils restent valables, car aucun plan ne peut couvrir la combinatoire énorme que représente un service avec des interactions utilisateurs.
