La réalité d’un secteur où l’on n’apprend pas à développer des logiciels de haute qualité
(florianbellmann.com)- Dans beaucoup de projets, les mesures de QA sont repoussées puis concentrées dans un grand sprint QA juste avant la mise en production, et le même chaos se répète au cycle suivant
- Les formations en informatique consacrent du temps aux algorithmes, aux langages et à la gestion de projet, mais traitent souvent l’assurance qualité logicielle sans atteindre un niveau réellement opérationnel
- En entreprise, quand le budget manque, que le développement prend du retard ou que le périmètre s’élargit, c’est souvent la QA qui est réduite en premier, et des logiciels fragiles ne passent que par un minimum de tests non structurés avant d’être déployés
- Pour défendre la QA, il vaut mieux parler du coût de son absence — hausse des coûts de développement ou allongement de la phase de stabilisation avant release — plutôt que d’évoquer abstraitement un logiciel “plus stable”
- Au lieu de vouloir bâtir tout le dispositif qualité d’un coup, il est plus réaliste de protéger d’abord les fonctions critiques directement liées à la valeur client, puis d’écrire les tests au moment où les nouvelles fonctionnalités sont implémentées
La QA repoussée jusqu’à la veille de la release
- Dans de nombreux projets, le développement avance alors que des mesures essentielles d’assurance qualité sont absentes
- Même quand leur nécessité est connue, leur mise en œuvre se retrouve souvent reportée vers un grand sprint QA juste avant la release
- Cette approche augmente le stress et se contente de rendre le logiciel à peine fonctionnel
- Le même désordre se répète au cycle de release suivant, sans véritable amélioration structurelle
Le fossé qualité entre la formation et la pratique
- Les cursus d’informatique se concentrent surtout sur les algorithmes, le fonctionnement des ordinateurs, ainsi que l’histoire et les concepts des langages
- Il peut exister un semestre consacré aux méthodes de gestion de projet ou à Scrum, mais la QA est parfois totalement absente
- Comme plus de 90 % des diplômés travaillent ensuite dans un contexte d’entreprise, ils ont besoin de savoir livrer un logiciel sans bugs dans un délai donné
- Négliger la QA dans la formation ne correspond pas aux exigences du travail réel
Pourquoi la QA est la première à être sacrifiée en entreprise
- Quand un projet rencontre des problèmes de budget, les standards et mesures de QA sont souvent les premiers à être écartés
- La QA étant fréquemment placée en fin de projet, si le développement s’allonge ou que le périmètre augmente, le temps manque pour garantir la qualité
- Au final, on déploie des logiciels à l’architecture fragile après seulement un minimum de tests non structurés
- Certaines équipes disposent bien de standards QA, mais ils reposent souvent sur des membres seniors qui les imposent au reste de l’équipe
- Même avec des standards, si l’équipe écrit des tests uniquement pour satisfaire des indicateurs de gestion de projet, cela débouche rarement sur une assurance qualité suffisante
Le premier pas pour sortir des problèmes de qualité récurrents
- Signaler l’absence de mesures de QA demande de l’expérience et de la confiance en soi
- Le crunch avant release, les systèmes de production en panne et le monitoring manquant finissent par peser sur toute l’équipe
- Comme pour le refactoring, il est difficile de défendre auprès des managers des améliorations qui ne sont pas directement visibles, et la QA peut sembler encore plus intimidante quand on ne l’a jamais pratiquée correctement
- Il faut répéter les problèmes et rouvrir la discussion plusieurs fois pour créer un premier élan
Expliquer la QA avec le langage de l’argent
- Dire que “le logiciel sera plus stable” ou “plus facile à maintenir” reste trop abstrait pour des personnes qui ne travaillent pas dans la codebase
- Les développeurs doivent parler du coût de l’absence de QA
- Exemples de formulation :
- si on ne le fait pas maintenant, l’effort et le coût de développement augmenteront de 15 % dans 4 mois
- si on n’ajoute pas de tests unitaires à toutes les fonctionnalités, la phase de stabilisation avant release s’allongera à chaque fois
- plus on ajoute de nouvelles fonctionnalités, plus il faut tester manuellement les effets de bord, ce qui réduit les progrès à chaque release
- C’est un langage plus facile à faire passer auprès du business et du management
- Au final, les mesures de QA peuvent améliorer la vie des développeurs comme celle des managers
Commencer avec une capacité minimale viable
- Concevoir la QA comme un énorme investissement initial peut bloquer l’avancement du projet et rendre l’adhésion des parties prenantes difficile
- Un point de départ réaliste consiste à identifier les parties les plus importantes de l’application
- Il existe en général un use case, une fonctionnalité ou un comportement central dont dépend l’ensemble de l’application
- Il faut commencer par tester les fonctions critiques qui doivent absolument fonctionner pour créer de la valeur côté client
- La capacité minimale viable (MED) désigne la plus petite capacité permettant d’obtenir le résultat souhaité
- En QA, le MED peut être l’un des éléments suivants :
- un plan de tests manuels
- des tests automatisés dans le pipeline
- toute autre mesure garantissant le comportement critique
- Une fois les fonctions critiques sécurisées, on peut étendre progressivement la stabilité
- Pour chaque nouvelle fonctionnalité, il faut ajouter des tests unitaires et vérifier aussi les informations non maîtrisables, comme les API externes ou les entrées utilisateur
- La QA doit elle aussi être améliorée de façon itérative et progressive
Les questions QA à poser sur un nouveau projet
- Au démarrage d’un nouveau projet ou en rejoignant une équipe, il faut vérifier qu’il existe au moins une notion de QA, même minimale
- L’équipe devrait se poser les questions suivantes :
- que déploie-t-on ?
- qu’est-ce qui doit absolument fonctionner ?
- comment le garantit-on ?
- quelles mesures choisit-on délibérément de ne pas prendre, et pourquoi ?
- Documenter ces éléments et y ajouter un plan de tests constitue une bonne base pour faire avancer le logiciel
- L’approche retenue devrait être revue régulièrement, par exemple chaque trimestre
Écrire les tests en même temps que l’implémentation
- Même sans pratiquer le TDD, il est recommandé d’écrire les tests pendant que l’on développe le logiciel
- Le moment où une fonctionnalité est implémentée est le bon moment pour écrire les tests
- Écrire les tests en parallèle de l’implémentation oblige à donner au code une structure réellement testable
- Quand on ajoute des tests plus tard sur un logiciel existant, on découvre souvent que le code est trop interdépendant ou qu’il viole le principe de responsabilité unique
- Les tests servent à montrer que l’on a compris le comportement attendu et vérifié qu’il fonctionne comme prévu, tout en jouant aussi le rôle de documentation du code
Les bénéfices pour le projet et pour chacun
- Lancer des discussions sur la qualité et proposer des solutions possibles montre à l’entourage que l’on se soucie réellement du projet
- Les discussions sur la qualité peuvent élargir le champ d’influence d’un développeur
- Elles peuvent aussi améliorer la qualité de vie des développeurs comme des managers
- Un projet peut croître à un rythme sain lorsqu’il dispose de mesures de QA
- Tout le monde n’a pas besoin de devenir ambassadeur de la QA, mais on peut partir d’un petit MED et montrer de meilleures pratiques au sein de l’équipe
1 commentaires
Avis sur Hacker News
Ce genre de contenu est bien enseigné. Simplement, il se trouve plutôt dans des cours optionnels comme le génie logiciel, et non dans les matières centrales de computer science.
À CMU, il existe aussi des masters et doctorats en génie logiciel, qui couvrent ce dont parle l’article de blog, et davantage encore. Il y a bien une grande rupture entre CS et SE, mais on ne peut pas aller jusqu’à dire que « personne n’enseigne comment produire du logiciel de qualité ».
Ironiquement, quand j’étais étudiant, le cours de génie logiciel était celui que je détestais le plus. Le cours de design patterns qui imposait strictement UML paraissait daté, et le cours de QA où l’on apprenait le TDD et les outils de l’écosystème Java était ennuyeux. Quelques années plus tard, quand j’ai rejoint une équipe chargée de mettre en place les workflows et outils de test pour un logiciel à fortes exigences de sécurité, mes collègues ont été surpris que je sache déjà ce qu’il fallait faire.
Même quand c’est enseigné, c’est généralement dépassé ou très littéral, centré par exemple sur l’écriture d’applications web. S’il y avait eu un cours axé sur l’implémentation, le travail en équipe et la construction de systèmes complexes, j’aurais vraiment voulu le suivre.
Ce contenu ne devrait pas être relégué à des options ou à des masters : il faudrait des programmes de licence en génie logiciel, et 90 % des étudiants en CS devraient y basculer.
La base de code était un service simple proposant l’analyse de virus/malwares, conçu pour qu’il y ait toujours du travail à ajouter, y compris sur les scanners et les signatures. C’était une idée d’il y a plus de quinze ans, mais cela aurait pu devenir un excellent cours continu ; c’est dommage qu’il n’ait pas réussi à convaincre le département.
Ce n’était peut-être pas le cours qui a défini toutes mes années de licence, mais on n’en était pas loin ; le fait que la plupart des gens qui conçoivent des systèmes ignorent ce contenu me provoque à la fois de la colère et une terreur existentielle.
Il est plus facile de travailler avec des personnes ayant un diplôme de CS parce qu’il est moins souvent nécessaire de les convaincre de l’intérêt de bons algorithmes, ou du fait qu’il ne faut pas implémenter soi-même des parseurs ou de la cryptographie.
En revanche, côté génie logiciel, il n’existe pas vraiment de qualification permettant de croire que la naïveté sur la qualité, le travail en équipe et la collaboration avec d’autres équipes a été corrigée de la même manière. On voit apparaître des gens aguerris à écrire rapidement du code atroce et non vérifié, puis à partir avant que les problèmes n’explosent ; la direction aime ce genre de personnes et méprise celles qui restent derrière pour nettoyer les décombres.
Les protocoles textuels avec des séparateurs clairs sont généralement très faciles à parser, et selon le cas d’usage on peut n’en gérer qu’une partie. Bien sûr, il faut tenir compte des tests et des exigences fonctionnelles. Si l’on crée un langage, le conseil peut être différent.
Les débutants les écrivent eux-mêmes, les développeurs intermédiaires et les projets de taille moyenne utilisent des générateurs de parseurs, et les personnes qui maintiennent les parseurs les plus sophistiqués préfèrent elles aussi les écrire à la main. GCC utilisait autrefois un parseur bison, mais il est passé à un parseur descendant récursif écrit à la main pour obtenir de meilleurs messages d’erreur, et Clang utilise aussi la descente récursive.
La seule exception que je connaisse personnellement est jq, et c’est pour cette raison qu’il est difficile de produire des messages d’erreur de syntaxe utiles dans son implémentation.
Écrire un parseur peut être assez simple pour tenir dans un devoir, et le code d’un parseur écrit à la main finit par ressembler à une grammaire LL. Le parsing est la partie la plus facile de l’écriture d’un compilateur ou d’outils de langage ; donc si un parseur écrit à la main place la barre trop haut pour une équipe, c’est tout le projet qui peut devenir suspect. Je ne dis pas qu’il ne faut jamais utiliser de générateur de parseur, mais je préférerais travailler sur un projet doté d’un parseur écrit à la main et bien testé plutôt que sur un projet qui complique son build avec des outils supplémentaires ou utilise des outils anciens comme Bison ou ANTLR.
Cela dit, le niveau général semble plus élevé qu’il y a vingt ans. Par exemple, la gestion de sources, les tests unitaires et le CI/CD ne sont plus vraiment sujets à controverse.
Le postulat selon lequel « il faut livrer à temps un logiciel sans bug » est un très mauvais point de départ pour un article sur les logiciels de qualité
Si vous croyez pouvoir déployer du code sans bug, il est temps de changer de métier
Même avec des tests unitaires, des tests d’intégration et des tests d’acceptation utilisateur, une modification de code implique une nouvelle possibilité de bug. Quand un développeur dit « je ne déploie jamais de code avec des bugs », on a envie de creuser ce qu’il veut dire par là
Quand on dépasse « j’ai écrit la fonction », « j’ai testé la fonction », « j’ai même testé la fonction appelée au-delà du réseau », on comprend que, même en couvrant bien les cas limites et en faisant une QA rigoureuse, il restera toujours un comportement indéfini 0-day sur telle configuration, tel matériel, tel noyau. On se contente de dire que, puisque c’est passé par les tests, les yeux humains et les revues, on garantit qu’il n’y a presque pas de bugs ; au final, il ne reste plus qu’à croiser les doigts
Si un bug prend une semaine à corriger mais ne touche qu’un petit nombre d’utilisateurs dans des situations très rares, il peut être acceptable de ne pas le corriger
Il existe des cursus d’informatique, et des universités qui mettent l’accent sur les stages et la pratique. Mais dans beaucoup d’universités, les départements de CS viennent des mathématiques et restent centrés sur la théorie
À mon avis, ce n’est pas un problème, pas plus que la chimie n’est le génie chimique. L’université n’est pas une simple école professionnelle ; l’objectif de presque tous les diplômes est d’entraîner la pensée et de démontrer sa capacité à assimiler des sujets complexes
Une éducation universitaire pure qui ne se demande pas si elle est utile dans le monde réel nuit à l’éducation, mais une formation purement professionnelle qui enseigne seulement des méthodes sans compréhension n’est pas utile non plus. Cela dit, les vraies écoles professionnelles ne sont pas entièrement comme ça : même si elles passent parfois sur les parties difficiles, elles donnent souvent une compréhension approfondie des choses importantes
Cela reste néanmoins une bonne fenêtre sur le monde du logiciel professionnel
Ce genre de choses s’apprend dans de bonnes organisations de développement. Il y a 10 à 15 ans, c’était en gros FAANG ; aujourd’hui, TailScale en est un exemple
Il est possible de ne pas accumuler des microservices inutiles, des couches et des couches de Docker, des couches de sérialisation/désérialisation JSON, des tests unitaires uniquement pour la couverture tout en ignorant QuickCheck, Hypothesis et le fuzzing. Il est possible d’avoir des ensembles de changements empilés, des rotations d’astreinte pour l’équipe qui écrit le code, de minimiser les erreurs de liaison dynamique et de dépendances non imposées, de concevoir pour le runtime d’un langage managé, et même d’exiger comme « lisibilité » la syntaxe verbale lisible du langage. C’est ignoré à répétition, mais la manière de déployer du logiciel de qualité relève du savoir public
Il y a peut-être des idées sur le logiciel de qualité, mais ce commentaire est difficile à comprendre
J’aimerais aussi savoir quoi regarder, et s’il existe des livres ou des cours à recommander
Il est difficile d’atteindre des mesures suffisamment valides pour étayer des affirmations du type « si on ne le fait pas maintenant, l’effort et le coût de développement augmenteront de 15 % dans quatre mois »
Dans une startup, deux fondateurs m’ont déjà dit de « ne pas écrire de tests unitaires ». Je n’ai pas débattu ; j’ai compris que le vrai sens de leur phrase était que nous étions trop lents et qu’il fallait livrer le plus vite possible. Nous avons livré vite, maintenu la qualité, et écrit des tests unitaires. Ils n’avaient pas besoin de le savoir, ils avaient seulement besoin du résultat. Le cœur caché de ce genre de discussion, c’est que la plupart des organisations logicielles ne savent pas livrer à la fois vite et avec qualité. Il n’y a pas de formule magique : il faut un artisanat individuel, et c’est aussi un sport d’équipe. La situation varie selon les endroits ; des processus légers peuvent parfois aider, mais leur effet reste limité. Au final, il faut une bonne équipe avec de l’expérience, les bonnes valeurs, et la sagesse de se concentrer sur la livraison de valeur
L’idée que l’université enseigne comment produire du logiciel dans l’industrie est une affirmation assez audacieuse
Par ailleurs, cet article ressemble à un texte des années 90, quand on distribuait les logiciels sur CD ou disquettes. Aujourd’hui, les pipelines de déploiement continu rendent souvent la notion de « release » floue, et c’est considéré comme une bonne pratique. Dans ce contexte, l’idée qu’un département QA garantisse manuellement qu’une release est sans bug paraît très datée
Certaines personnes écrivent du code embarqué dans des appareils difficiles à mettre à niveau
Si vous avez besoin de l’approbation de quelqu’un, vous devez lui expliquer pourquoi c’est une bonne idée
Dire « c’est plus stable » ou « ce sera plus facile à maintenir » ne parle pas à quelqu’un qui ne travaille pas directement dans la base de code. Les développeurs doivent parler du coût de l’absence de QA, c’est-à-dire dans le langage de l’argent. Même si « mais c’est la bonne façon de faire ! » semble être un argument irréfutable, la personne qui approuve peut ne pas s’intéresser à cette justesse. Ce principe s’applique non seulement au fait de corriger correctement un logiciel, mais aussi à presque tout au travail
Si vous devez expliquer pourquoi la qualité est importante, c’est qu’ils sont au moins aussi ignorants que vous, peut-être davantage. Ce genre d’organisation doit accepter son destin. Dans une entreprise mature, en revanche, vous serez récompensé plus vite et davantage, et vous développerez aussi plus rapidement un sens de la manière dont une activité doit fonctionner. Bien sûr, vous devez prouver vous-même que le temps investi mène à de réelles améliorations, et que ce n’est pas une impulsion donquichottesque d’amateur
On peut grosso modo n’avoir que trois de ces quatre éléments : qualité, délais courts, faible complexité de communication et peu d’argent ; et ici, le temps est plutôt une variable dépendante
Les gens essaient d’appliquer des processus et des structures de type usine au logiciel, qui est à la fois un sport d’équipe et une discipline d’ingénierie. De même qu’on n’enseigne pas et qu’on ne construit pas une équipe de basket en découpant l’attaque en procédures et check-lists étape par étape, il faut minimiser la communication et faire en sorte que l’équipe se déplace comme un seul bloc. Il ne s’agit pas de construire un processus, mais de construire une équipe et des individus. Il faut planifier, mais comme le disait Moltke, aucun plan d’opérations ne survit avec certitude au premier contact avec l’ennemi. Or la mentalité business croit que, puisque le plan ne s’est pas déroulé comme prévu, il faut ajouter davantage de processus, ce qui permet au manager d’accuser des individus au prochain échec. Les processus ont leur place pour faire en sorte que les choses se passent dans un cadre légal et moral, et pour réduire les situations défavorables, comme le fait de miser par erreur l’intégralité des fonds d’un hedge fund pendant des tests. Mais dans la plupart des startups et des entreprises, ils sont utilisés d’une manière qui ne met pas l’équipe au centre
On ne crie pas sur un architecte traditionnel pour lui demander quand ce sera fini. En général, cela se termine quand le client est satisfait ou prend une décision. Beaucoup de développements ressemblent à cela
Je me demande s’il existe une activité humaine où l’on enseigne avec succès l’attribut qu’est la qualité
D’après mon expérience, la capacité à produire quelque chose de qualité ne s’acquiert que par la pratique, la pratique et encore la pratique
À l’inverse, le titre signifie simplement que la programmation n’est pas une pratique industrielle. Cela devrait être évident pour ceux qui y prêtent attention, mais certains refusent obstinément de le voir
Rien qu’avec l’écriture, beaucoup de gens apprennent à améliorer la qualité. On les guide sur ce qu’ils peuvent essayer d’écrire et, plus important encore, sur la manière de revenir sur la qualité de ce qu’ils viennent d’écrire et de l’améliorer
La pratique aide toujours, mais la qualité aussi s’apprend et se travaille chez beaucoup de gens
Quand on apprend à voler, on apprend les standards, mais avec le temps, on apprend à resserrer les tolérances. Par exemple, si le critère d’altitude dans un virage serré est de ±100 pieds, ce n’est que le minimum ; on vise 50 pieds, 20 pieds, voire une aiguille qui ne bouge pas. L’objectif est : « mieux, toujours mieux, que peut-on encore améliorer ? », et en vol, on ne réussit pas sur la base d’une moyenne globale : il faut satisfaire à tous les éléments. Culturellement, « satisfaisant » n’est pas la fin, mais le point de départ
J’ai l’impression que cette attitude crée un modèle bien plus collaboratif. Dans l’aviation, tout le monde souhaite sincèrement que chacun réussisse, et si quelqu’un échoue, on en porte soi-même une part de responsabilité. Il existait une culture où, en cas d’erreur, il fallait chercher comment réduire la probabilité d’erreurs futures ; dans les compagnies aériennes, l’assurance qualité des opérations de vol (FOQA) joue aussi un rôle important. Dans les petites organisations opérant dans des zones isolées, c’était plus informel, mais la plupart se rapprochaient d’une culture « sans faute », et la question centrale était : « comment rendre cela meilleur ? »
La qualité, la prise de décision et le fait de « faire ce qu’il faut » étaient au cœur de la culture aéronautique. Chez un opérateur réputé, juger que la météo est trop mauvaise pour opérer en sécurité conduit immédiatement à l’arrêt des opérations ; on ne décolle pas coûte que coûte pour terminer le travail. L’industrie tech que j’ai rejointe récemment me semble être l’inverse. Le concept même de produit minimum viable illustre le problème. Il ne devrait pas s’agir de « fonctionnalités minimales », mais du « produit de qualité minimale acceptable comme point de départ ». Il ne faut pas viser le minimum ; le minimum n’est qu’un point de départ
Si l’on ne s’entraîne qu’à produire des déchets, on devient simplement doué pour produire des déchets. Il existe réellement des gens qui ne se soucient pas de la qualité ; dans ce cas, tous les présupposés s’effondrent