Je teste donc je suis

Cette semaine, nous lançons officiellement la beta publique de notre produit phare, OverBlog. Cela fait près d'un an que les premières reflexions ont commencé, que le développement a commencé. Nous avons changé d'organisation de travail (passage à scrum), nous avons accentué le TDD (test driven development), nous avons changé de technologie (Symfony)

Nous avons mis en place de nombreux contrôles afin de mieux tester et s'assurer que tout se passe bien. Pourtant, malgré tout cela, le stress me gagne depuis quelques jours : je serais en première ligne après le lancement. Je gérerais les retours internes de dernière minute, le support des utilisateurs... je centraliserais tout, pour donner ensuite les priorités à mes collègues développeurs.

Pour ajouter au stress :

• Certains collègues sont absents (pour assister à des conférences)
• Le lancement se fait à New-York, pendant le BlogWorld. (Donc, avec du décalage horaire)
• Il faut continuer de gérer la version actuelle : cela complique un peu la tâche, surtout lorsque l'utilisateur vous parle sans vous préciser quelle plateforme il utilise...

Ce que je retiens de ma nuit ?

• Faire une modification en urgence à 17h était une mauvaise idée. Suite à un problème, elle a provoqué un effet de bord désastreux durant une demie-heure.
• L'équipe est restée mobilisée une grande partie de la nuit pour s'assurer que tout se passait bien.
• Suivre l'avancement du trafic sur cette version était une émotion forte : cela fait 5 ans que je travaille dans les bureaux d'OverBlog, mais c'est la première fois que j'attends devant un graphique pour voir s'il va monter.
• Un souci sur un détail technique particulier : une seule personne était capable de le résoudre, et il nous a fallu une heure pour le contacter, et 2 heures pour que le problème soit totalement corrigé.
• La nuit a été courte pour certains d'entre nous. Mais ce matin, l'envie de finir au plus tôt les correctifs nécessaires pour que ce soit parfait est toujours là.

Mais ce que je retiens avant tout : les premiers utilisateurs sont ravis, et accrochent bien à cette nouvelle version.

Notre travail des derniers mois, particulièrement stressant durant les dernières semaines à peaufiner les détails, à régler les derniers problèmes, est vu à sa juste valeur (par des blogueurs célèbres, des développeurs...)

Lors de SudWeb en mai, j'ai discuté avec le créateur de CasperJS pour lui expliquer pourquoi je préférais Watir à son outil.

Petit tour rapide des défauts de CasperJS

• Limitation des sélecteurs : Avec watir, je peux sélectionner un élement à peu près comme je veux. Avec CasperJs, le choix est plus limité (mais il peut être étendu en javascript.
• Navigateur : CasperJS utilise un navigateur headless basé sur webdriver. Watir permet de prendre le contrôle de la plupart des navigateurs (via selenium)
• Langage : je n'aurais pas dit ça il y a 2 ans, mais je préfère le ruby au javascript.
• Capture d'écran : ~~Il est difficile de faire une capture d'écran anvec un navigateur headless.~~ Apparement, c'est possible aussi en CasperJs.

Mais je suis partial : je connais et j'utilise Watir depuis 2 ans, et j'au découvert CasperJs depuis une semaine.

Point sur CasperJS

Je ne nie pas son intérêt. Mettre en place des tests fonctionnels sous Watir / cucumber (et hudson pour gérer tout cela) prend du temps, et cela me fait penser à sortir l'infanterie pour écraser un moustique.

Si on a besoin de créer des tests rapides, et que "webdriver" nous suffit, et si on en plus on est à l'aise avec le javascript : je vous le conseille.

Notre point de désaccord n'était pas sur les outils, leurs limitations, etc.. mais sur les tests eux-mêmes.

Doit-on utiliser les textes de l'interface pour tester ?

Lorsqu'on met en place des tests, on utilise au maximum les informations de l'interface : class, name, id, parfois même url (src ou href).

Certains utilisent même les xpath, mais je le déconseille : je trouve que cela alourdit la maintenance du projet à long terme.

Mais cela n'exclut pas d'utiliser aussi le texte. Mais dire "Cliquer sur le bouton 'Ajouter au panier'" a un défaut : si le texte change, il faut mettre à jour les tests.

Donc, utiliser les textes peut être intéressant, mais il ne faut pas en abuser, et les "limiter".

Doit-on tester les textes de l'interface ?

Tester tous les textes reviendrait à devoir modifier les tests à chaque mise à jour de textes. Ce serait coûteux en temps, et dà difficile à maintenir. (Dans la plupart des projets web, le nombre de texte augmente dans le temps)

Par contre, certains textes doivent être tester dans l'interface :

• Tous les messages d'erreur
• Tous les message de validation
• Les liens principaux de navigation
• Les boutons d'action

Quoi d'autre ?

Cela nous donne une liste "réduite" de textes qui peuvent être utilisés durant les tests. Si un texte change pour une raison inconnue, certains tests passeront dans le rouge, et il n'y aura qu'à les mettre à jour le texte dans les tests pour corriger.

Il n'est pas utile de tester les textes : les utiliser durant les tests revient au même. (l'optimisation est importante, j'y reviendrais)

Je travaille sur un projet disponible dans 5 langues. J'ai donc rassembler tous les textes dans un lot de fichier (un par langue)

Last but not least : en tant que responsable qualité, je suis garant que les textes soient conformes. Si nos traducteurs modifient le texte anglais du bouton "Save" en "See", je dois agir en conséquence pour obtenir une correction au plus tôt.

Witch Doctors should no longer receive an error if they kill a Shadow Clone with a Damage-Over-Time (DoT) skill after it's launched a Firebomb but before it's reached its target
Blizzard

Parfois, on trouve un bug de façon complètement aléatoire, on n'arrive pas à le reproduire, etc. Mais Blizzard m'épate dans leur premier patch de Diablo 3. Pour résumer pour les non anglophones / non joueurs :

Si un personnage de la classe féticheur tue son ombre (en affrontant Diablo), en utilisant un sort de "dommages périodiques" (ex : du poison) et que la mort se produit après lui avoir jeté une bombe incendiaire mais avant qu'elle le touche, on a une erreur.

Je n'ose imaginer le temps et les tests pour le reproduire.

Pour donner une idée : j'ai un personnage de cette classe, j'ai affronté plusieurs fois Diablo, et mon ombre. Et je n'ai jamais rencontré ce cas de figure.

Les tests d'un jeu vidéo n'ont sans doute pas grand chose à voir avec les tests d'une application web, en particulier quand il faut tester également la charge très importante d'un titre de Blizzard. Qui pour ne rien simplifier, est très variable dans le temps.

Je sais que l'équipe de Blizzard se penche actuellement sur une erreur 37 lors de la connexion, et je leur souhaite bien du courage. Les propos sur les forums de battle.net, facebook, sont très amères (et je peux le concevoir en partie : il est impossible de jouer en Europe pendant qu'il est possible de jouer en Asie ou en Amérique)

SudWeb, conférence sur le faire-savoir dans le domaine du web au sens large, se tenait vendredi et samedi dernier.

Depuis, les tweets et les articles sur le sujet racontant ce grand moment se suivent, et se ressemblent tous, tellement tout le monde a trouvé l'événement bien organisé et intéressant. Voici ma vision des choses :)

Jeudi : accueil des orateurs

Les orateurs, dont je faisais partie, se sont retrouvés tous ensemble pour se rencontrer en avant-première, discuter entre nous, faire connaissance, et parler de nos attentes et de nos présentations.

Ma présentation était un élaboratoire, et j'ai pu ainsi avoir une vision de ce que je voulais/devais présenter le samedi.

En passant, j'ai retrouvé un ancien camarade de promo que je n'avais pas vu depuis 10 ans : beaucoup d'histoires à se raconter. Et les toulousains que je rencontre régulièrement aux apéroweb étaient là aussi, fidèles au postes. (Et une bonne partie dans le staff de SudWeb)

Vendredi : conférences

Les conférences s'enchainent, certaines me semblent plus passionnantes que d'autres, mais cela ne me choque pas : il en faut pour tous les goûts.

Des moments forts m'ont marqués :

• L'utilisation de canard en plastique durant le développement.
• L'amour pour IE de Bruce Lawson (travaillant chez Opéra). Et je suis d'accord avec lui : IE6 a forgé le monde du web actuel.
• Les conférences courtes menées tambour battant par des orateurs comptant les mots et le temps.
• Une discussion entendue entre deux personnes en début d'après-midi. Reprise dans une conférence moins d'une heure après, sans qu'il l'ait entendue.

Et autour de cela, une organisation aux petits oignons, que ce soit l'accueil, les repas, les casques pour les traductions...

Le soir avait lieu le repas communautaire : un grand moment pour rencontrer, échanger, discuter de tout et de rien. J'ai entendu parler de serveurs, de qualité, de web, de php, de télé 3D...

Certains ont commencé à planifier leur journée du samedi ce soir là, pour être sur de ne rien rater.

Samedi : ateliers

Le ateliers/conférences du samedi étaient au top également. Du haut niveau, et mon principale regret et de ne pas pouvoir les suivre tous en même temps. Il fallait choisir, mais il était possible de changer d'atelier en plein milieu.

Mon programme à moi :

• Ajoutez du sens à vos page web avec les microdonnées par Corinne Schillinger
• Le Web au doigt et à l’œil avec CasperJS par Nicolas Perriault (le créateur de CasperJs)
• CSS : hier, aujourd’hui et demain par Bert Bros (Co créateur du CSS)
• Comment tester la qualité d’un projet en constante évolution, que j'ai animé.

Chaque atelier était différent : certains étaient menés comme une présentation pour commencer, d'autres était 100% mise en pratique.

L'important était les échanges sur le sujet, et j'ai l'impression d'avoir réussi pour mon atelier. Une dizaine de personnes sont passées m'écouter, avoir des informations. Pouvoir montrer ce qu'on a mis en place dans ma boîte était une bonne base de départ :)

Mes regrets

En 2011, j'avais longtemps hésité pour SudWeb à Nîmes. Cette année, je n'ai pas hésité, et j'ai bien fait d'y aller. J'ai du chercher longtemps ce qui m'avait gêné durant ces journées bien chargées.

• La chaleur à Toulouse. (Et ca continue après SudWeb)
• La planification des ateliers : j'ai changé 2 fois d'horaires et de salle. Un peu plus de stabilité n'aurait pas fait de mal
• Mon stress avant de présenter un atelier à des gens que je ne connaissais pas.
• Je n'ai pas pu parler autant que j'aurais voulu à toutes les personnes que j'aurais voulu : trop de monde, pas assez de temps
• Durant 2 jours : tout le monde ne parle que qualité, perfection, nouvelle technologie, bonnes pratiques... Le retour à la réalité est "douloureux". (Et encore, j'ai de la chance, les bonnes pratiques et les tests sont déjà en place chez nous)

Notre équipe va utiliser certaines connaissances "découvertes" durant ces 2 jours bientôt, sur notre projet. Je regrette presque que cela soit déjà fini, et qu'il faudra attendre un an avant le prochain.

Pour garder l'esprit "SudWeb" jusqu'à l'an prochain, je vais sûrement retourner à des apéro web toulousains dans les prochains mois ;)

Testing is like a box of chocolates. You never know what you’re gonna get.
Peter Shih

Je suis tout à fait d'accord avec lui. Quand on met en place des tests automatiques ou qu'on teste manuellement une nouvelle fonctionnalité, on ne sait jamais ce qu'il va se passer.

On peut tout avoir :

• Tout fonctionne, et tout s'affiche parfaitement
• Une partie ne fonctionne pas, bloquant une partie des tests.
• L'affichage est décalé (avec parfois des problèmes en cascade)

Du coup, rien ne se ressemble : chaque nouveau test permet d'être surpris, et de devoir réflechir en profondeur pour assurer la stabilité du produit testé. (Qu'il soit logiciel ou matériel d'ailleurs)