Tester un logiciel, le cas (d’école) de la ZEP-12

Ca y est, la zep-12 est en test (clementine/orange pour ceux qui connaissent pas)!

Les premiers enseignements de ce projet aussi monstrueux qu’intéressant tombent déjà.
Comme la qualité logicielle m’intéresse depuis un bout de temps et que je vais entrer dans l’équipe de qualification de VadeRetro Technology, je m’intéresse beaucoup à ce qui est en train d’arrivée à notre bébé.

Petit tour d’horizon de ce que je retiens de tout ça.

Les vendeurs de framework de TU ne disent pas n’importe quoi

Ne vous a-t-on jamais dit qu’écrire un test unitaire ça faisait gagner du temps?
Et un grincheux de vous répondre que la réalité c’est pas ça. Après tout, ça coûte cher d’écrire un test. En plus ça prend du temps.

Tout au plus, on acceptera de dire que quand on travaille en équipe, c’est vachement utile les tests unitaires automatisés.
La ZEP-12 est un projet d’équipe (2 personnes au départ, 6 au pic d’activité) alors on a fait des tests unitaires, systématiquement.

Plus précisément on a fait des tests unitaires sur nos fonctions utilitaires et des tests d’intégration sur nos vues django. Mais comme on fait un site web, c’est franchement plus logique de faire comme ça. Je sais, ça casse le discours des puristes, mais au moins dans le cas de la ZEP-12, cela permet d’être très expressif dans les tests et donc d’être très efficace.

Soyons clair, le temps que nous ont fait gagner les tests unitaires est sans commune mesure avec le temps de développement du projet. Car en plus de détecter les bugs rapidement avant de pusher notre travail sur le dépôt, cela permet d’avoir confiance en ce qui a été codé jusque là. Ainsi, tout bug détecté est forcément dans le nouveau code. Et d’aussi loin que je me souvienne, cette assertion s’est toujours vérifiée.

Du coup, la zep-12 est le module le mieux couvert par les tests de zeste de savoir. Le résultat? Lorsque la pull request a été lancée, le premier commentaire lancé sur IRC a été “il est vachement stable votre truc”. Dans le jargon, on appelle ça une réussite.

Qualifier au fur et à mesure est le futur de l’Homme

Et dans ce rôle Vayel a été la pièce maîtresse de la ZEP-12. En testant à la main tous les scénario possibles et en mettant en note très précise tous les bugs rencontrés, nous avons pu corriger tous les éléments rapidement, proprement et sereinement.

Je pense qu’ici nous avons manqué de deux choses :

  • une automatisation de certains scénario pour éviter de redemander à chaque petite modification de tout rejouer;
  • un moyen simple de suivre l’évolution d’une correction de bug.

Pour le deuxième point, c’est celui qui m’a le plus frustré (logique hein, le principe étant “celui qui dev ne peut pas valider un test, donc la répétition des scénario, ce n’est pas moi qui l’ai subite). En effet au fur et à mesure que des bugs plus ou moins bloquant dans les nouvelles fonctionnalité (déplacement) ou dans la compatibilité (migration), il arrive souvent qu’à partir de 20-30 messages de tests, d’hypothèses et d’échecs on n’arrive plus à voir ce qui a été fait, ce qui est vraiment un bug, ce qui ne l’est pas, ce qui est souhaitable…

Au boulot, je découvre TestLink, un poil trop complexe à mon goût , mais qui en ce sens nous aurait permis de vraiment nous y retrouver dans les étapes de la correction. Mes condisciples de l’ISEN, m’ont aussi présenté l’outil ProjeQtOr qui a l’air pas mal, à explorer donc.

Fuck lo(r)em

Soyons clairs. Plus jamais je n’utiliserai de lorem pour faire un test, même bidon d’un logiciel. Je veux bien comprendre que ça semble cool d’utiliser ces textes latin à gogo ou de les remplacer par des mots de flemmard tels que coucou, ping/pong ou mieux frezdf.

Mais en fait c’est la merde car :

CES MOTS NE SERONT JAMAIS UTILISÉS DANS VOTRE APPLICATION.

Corollaire, il est plus que probable (probabilité de l’ordre de 99%) que ces mots ne mette en exergue aucun des vrais problèmes auxquels feront face vos utilisateurs.

Pire, ils risquent même de vous montrer des problèmes qui n’arriveront jamais en prod.

Et la ZEP-12 a eu son lot de trucs qui marchent super bien avec les lorems. Et puis un jour on passe au monde des adultes et on essaie de migrer un tuto sur java ee où il y a des bouts de texte qui sont des chemins windows. Paf, impossible de génerer un PDF car on a mal réglé le truc.
Et puis on doit migrer un vieux tuto sur Android qui a une particularité assez étrange. Paf bug non reproductible et on se tappe quelques heures de dev en plus.
Et puis surtout les lorem c’est tout beau alors quand on utilise des algo de slugification et que la nouvelle version du logiciel change d’algo, avec les lorems on ne se rend pas compte que certains caractères anciennement supprimés sont maintenant changés en “-“.

Bref, je ne comprends pas pourquoi les gens s’entête à faire un processus de gestion de projet qui commence par “identifier le besoin, le transformer en exigence puis en réalisation technique” mais lorsqu’il s’agit des données on tape directement sur de la réa technique et quand les besoins nous rappellent à la réalité on se dit “merde, j’ai fait une bourde dans mon code”.

Ceci est une évolution

Cette phrase est sûrement celle qui m’a fait le plus de mal en tant que développeur. Mais bon sang, qu’est-ce qu’elle fait du bien quand on livre le projet avec seulement un mois de retard sur les prévisions, avec une stabilité impécable et qu’en plus on a une idée de comment gérer cette évolution plus tard.

Car oui, le projet ZEP-12 était ambitieux et finalement notre pire ennemi, c’était de vouloir en faire plus, toujours plus.
Oui mais, même sans publication partielle, sans changement d’interface dans la rédaction, sans API REST, sans ce petit truc ci et ce petit machin là, la ZEP-12 fait environ 850 commits soit 20% du nombre de commits du projet actuel. Aurait-il était réaliste d’implémenter ces “petits plus”? Aurait-il était possible de le faire avec le même niveau de qualité? Dans le même intervalle de temps?

Conclusion

Mener un projet au bout, c’est bien. Faire un projet de qualité c’est tellement plus valorisant !

Leave a Reply

Your email address will not be published. Required fields are marked *