Laissez-nous vous présenter notre 3ème épisode de podcast qui fait suite à vos nombreux et chaleureux retours sur ce format. Merci à tous et toutes 🥰
Tester son code, est-ce que c’est douter ?
Il parait qu’il ne faut jamais livrer en prod le vendredi. Pourtant, cela nous est tous et toutes déjà arrivé. Livrer en prod, c’est presque une phrase magique quand on le fait la première fois – puis ça devient vite une habitude, une partie d’un processus sur lequel on devient de moins en moins attentif.
Avant toute chose, on a demandé à notre team de Programistoj* leur avis sur la question. La réponse est avec appel (est-ce que ça se dit vraiment…) : le sujet fait parler !
Finalement, un logiciel de qualité, c’est un logiciel où toute la chaîne de valeur est restée attentive. Mais comment s’assurer que c’est bien le cas pour votre projet ?
La qualité logicielle : comment la définir ?
S’il est important de rester attentif, il l’est tout autant de définir le niveau d’attention attendu en fonction du projet. Celui-ci doit varier en fonction des contraintes !
C’est la responsabilité de l’Archi / Lead et du Chef de Projet de définir le plan d’assurance qualité en amont de sa production. Il est différent à chaque projet.
Triangle Coût Délais Qualité
Le triangle coût-délais-qualité est un excellent outil qui permet d’appréhender la qualité logicielle visée :
- C’est rapide et pas cher, la qualité laissera toujours à désirer
- C’est rapide et de grande qualité : ça coûte très cher
- C’est de bonne qualité, à bas coût : ça va nous prendre du temps
Finalement, le principal apprentissage que l’on retiendra du triangle c’est : la sous-qualité a un coût et la sur-qualité aussi. Un juste équilibre doit être trouvé.
Des outils pour tester son code à adapter selon votre méthodologie
Le triangle cout-délais-qualité n’est cependant le seul outil à utiliser pour assurer que votre plan de qualité soit efficace. Tout dépend également de la méthodologie qui sera employée sur la chaîne de valeur : Cycle en V, méthode agile ou Scrum, chaque plan doit s’adapter.
Outre la méthodologie, de nombreuses autres méthodes permettent de confirmer que le projet « fonctionne », ou plutôt correspond aux contraintes envisagées :
- Instauration de normes de qualité sur les différents déploiements
- Mise en place d’une politique de formation continue au sein de l’équipe
- Production d’audits sur la performance, la sécurité…
Est-ce qu’il vaut mieux avoir un projet très compliqué avec une batterie de tests très sophistiqués demandant un effort incroyable lorsqu’il faut débugger OU avoir un code très simple et facilement lisible permettant de corriger rapidement le problème avec des tests en moins ?
Tester son code : c’est obligatoire ?
C’est peut-être la question la plus importante soulevée par ce podcast. La réponse est non – et nous sommes formels ! Et de manière générale, rien n’est obligatoire dans notre métier – cependant tout est à faire si nécessaire.
Les développeurs sont familiers avec les fameux TU (pour Tests Unitaires), permettant de tester la qualité du code de manière programmatique.
Attention cependant si votre équipe s’en tient à ces tests ; vous risqueriez de louper un bug lié à l’expérience utilisateur que la programmatique n’a pas dans le viseur.
Utiliser les TU pour tous les projets et de la même manière est une sévère erreur. Cela mène généralement à un fonctionnement en anti-pattern ; voyez plutôt cet exemple du « Marteau doré :
Si je vous donne un marteau et un clou, vous allez voir que ça marche bien. Et demain je vais vous donner une vis et vous allez essayer de planter la vis avec votre marteau.
Tester son code tout en assurant son Time-To-Market
Chaque projet est définitivement unique. Maîtriser le choix de son approche pour tester son code et le contrôler est par conséquence un facteur critique pour assurer un Time-To-Market respecté et au niveau des attentes.
En tant que développeurs, vous allez contribuer à la stratégie de tests globale sur le projet : il faut faire ça de manière intelligente et en synchro avec le reste de votre équipe.
Notre expérience d’entreprise tech nous a mené à définir deux grandes approches pour les plans qualité.
Test Driven Development (bottom to top)
D’autres types de tests que les TU existent et sont tout aussi important à implémenter selon la nature de votre projet. Le TDD vient d’abord détailler le plus petit pour finir par le plus générique. Cette approche comprend :
- Les tests d’intégration qui servent à vérifier que l’ensemble des composants s’imbriquent selon l’expérience définie sur l’application
- Les tests de non régression qui servent à confirmer que les nouveautés ne rentrent pas en conflit avec l’actuel et l’historique de l’application
- Les tests IHM qui servent à valider la conformité de l’application par rapport à l’UX/UI et son accessibilité
- Les tests de performance pour appréhender l’absorption de volumétries de trafic importantes ou sur des pics identifiés
- Les tests de sécurité pour vérifier que l’application ne pourra que difficilement être hackée (c’est toujours possible…)
En marge des tests unitaires, l’application du TDD vous permettra d’assurer le respect des attentes côté métiers (UX, UI, SI, CdP, Marketing…).
Le Behavior Driven Development (top to bottom)
Le BDD pour Behavior Driven Development est une approche qui s’adapte assez bien aux projets agiles. En addition au TDD, cette approche assure que les contraintes soient issues directement des Users Stories.
- Rédaction des tests de comportement ; ou plutôt les spécifications qui vont décrire les règles de gestion et comportements attendus. On utilise un format Gherkin pour cela ; une syntaxe facile à lire et écrire à la fois côté métier et côté tech.
- Puis, une discussion est engagée entre les équipes métier et les équipes tech. C’est à ce moment qu’il faut se poser les bonnes questions et faire des choix.
- Les choix effectués, l’équipe tech va pouvoir s’attaquer à la production du pendant « exécutable » de ce qui a été décrit par le test Gherkin.
De nombreux frameworks existent pour chaque langage de programmation : C# (Specflow), PHP (Behat), Java (Jbehave), JavaScript (CucumberJs)… Votre test sera plus poussé qu’un simple TU.
⚠️ Les problèmes de performances, d’accessibilité et de nombreux tests décrits en TDD ne seront pas résolus par le BDD. Un savant mélange des deux peut être appliqué pour éviter un maximum les bugs – cependant vous livrerez toujours un bug en prod de temps en temps, ne culpabilisez pas.
Aller plus loin : fail fast, learn faster
Une pratique diffusée aux côtés du lean startup model qui a notamment fait ses preuves avec SpaceX et ses nombreux lancements échoués avant de s’imposer comme leader technologique à suivre.
Cette stratégie de test massive et à grande échelle, mais aussi très rapide, permet tout simplement d’apprendre plus vite par la pratique et donc de progresser plus rapidement.
On ne peut pas faire d’agile sans faire d’erreurs. Et ça marche aussi avec le code. S’ouvrir à d’autres typologies de tests est la partie la plus intéressante du métier.
Tester, c’est donc douter. Douter n’est pas obligatoire, c’est nécessaire. Et comme évoqué plus haut dans cet article, rien n’est obligatoire dans notre métier – cependant tout est à faire si nécessaire.
