Rationalisations
Il n’y a pas assez de testeurs·es dans les entreprises qui développent du logiciel. Et lorsqu’il s’en trouve, le processus de l’entreprise rend leur travail inefficace. C’est une évidence qui saute aux yeux. Mais lorsqu’on évoque le problème, on entend ces rationalisations :
C’est très complexe une application. 🤷♂️
On ne peut pas tout tester. 😅
Ce ne serait pas rentable de tester plus. 💸
“C’est très complexe”
Il est rare qu’une activité très complexe se généralise et s’étende à grande échelle : commercialement, ça ne tiendrait pas la route. Par ex. il y a plus de 5000 éditeurs logiciels en france. Editeur ou autre, chacun de nous a rencontré dans sa carrière des systèmes modérément compliqués, dont le code était défectueux, pas testé, et pas maintenable. Produit par des entreprises qui vont très bien commercialement, merci pour elles.
“On ne peut pas tout tester”
Mais apparemment on peut tout coder. C’est un problème. Vous ne devriez pas coder puis livrer quelque chose que vous ne savez pas tester. C’est comme si vous décidiez de lancer un produit sans vous soucier de son impact sur ceux qui vont l’utiliser. Vous allez me dire : si ça se trouve, ça marche, et sinon on pourra toujours corriger notre produit.👌
“Ce ne serait pas rentable”
Voilà l’argument le plus répandu. La qualité coûte cher. Donc c’est aux clients et aux utilisateurs de la payer de leur temps.
Si j’avais la fantaisie de me lancer dans la fabrication de chaises, je ne resterais pas longtemps sur le marché : mes chaises ne seraient pas belles, pas finies, pas stables, pas solides. Ce serait la faillite assurée. Si je veux un jour fabriquer et vendre de belles chaises, et concurrencer par exemple une grande entreprise scandinave, il faut que je me lève tôt, que je trouve un maître, et que j’apprenne ce métier pendant un certain temps.
Ce n’est pas le raisonnement que tient une entreprise qui se lance dans le logiciel. Pour elle, il suffit de :
- trouver une idée
- trouver des fonds
- trouver des gens qui savent coder
- se lever tôt (cette partie là, oui c’est pareil).
(à suivre)
PS: Voici ce que dit Boris Beizer (que je considère comme un maître en matière de tests) à propos du code non testé:
L’excuse que j’ai entendue le plus fréquemment pour mettre du code non testé en production est qu’il ne reste plus assez de temps ou plus assez d’argent pour tester. Par quelle magie le code non testé elimine t’il donc ses propres bugs ? S’il n’y avait pas assez de temps et d’argent pour tester le code, alors il n’y avait pas assez de temps et d’argent pour créer ce code en premier lieu. Car ce que vous appelez du code, avant qu’il ne soit proprement testé, n’est pas du code, mais une simple promesse de code. Non pas un programme, mais une parodie perverse de programme. Si vous mettez un tel truc dans votre système, ses bugs vont se voir, et parce qu’il n’y a pas eu de tests unitaires rigoureux, vous aurez du mal à trouver précisément ce qui a causé le bug.
