Des renforts de qualité pour vos équipes expertes
Nous recrutons et formons des ingénieurs logiciels pour équiper les départements tech des entreprises du numérique.
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 🥰
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 ?
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.
Le triangle coût-délais-qualité est un excellent outil qui permet d’appréhender la qualité logicielle visée :
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é.
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 :
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 ?
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.
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é.
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 :
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 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.
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.
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.
Vous avez dit tester ?
- Tester c'est douter mais douter c'est bien
- Du coup logiquement tu devrais douter de tes tests (voire même douter de tes doutes 🧐 ) 🤔
- C'est pour ça que de bon tests ne contiennent pas de logique
Coder c'est douter. Tester c'est vérifier si tes doutes sont fondés X)
Et parfois tester, ce n'est pas VRAIMENT tester (genre les TU... 🤫 )
Just because you've counted all the trees doesn't mean you've seen the forest
Le plus important c'est faire la différence entre le bon test et le mauvais test