Jekyll2023-10-17T15:54:55+00:00http://christophethibaut.com/feed.xmlToF’s blogI am an XP coach, consultant and developer with more than 30 years experience in software development, technical leadership, counselling and coaching. I help my customers to improve their practices and solving problems together.
Christophe Thibautcthibauttof@gmail.comNo Product2023-10-02T00:00:00+00:002023-10-02T00:00:00+00:00http://christophethibaut.com/2023/10/02/TS-10<p>Beaucoup de développeurs considèrent l’option “No Code” comme une mauvaise idée. Disons, une idée qui va faire long feu. Cela se comprend, si l’on considère que pour le développeur l’écriture du code constitue son activité essentielle.
<!--more--></p>
<p>Si Wikipedia donne une présentation claire et raisonnée de ce choix techonologique, il n’en va pas de même bien sûr, des éditeurs :</p>
<p>🚀 Créez une belle UI, générez du code propre, et déployez vers les app stores ou le web en un clic. Totalement extensible avec du code customisé. ‘Chose’ rend la contruction d’appli mobile facile pour les designers, les développeurs et les entrepreneurs.</p>
<p>🛸 Construire de la tech est lent et coûteux. ‘Truc’ est la plateforme no-code la plus puissante pour créer des produits digitaux. Construisez mieux et plus vite. La Liberté de Donner Naissance à Vos Idées. Pas de Limites. Pas de Code.</p>
<p>D’un côté, je comprends la réticence — pour ne pas dire la résistance — des développeurs, ayant cotoyé de nombreux projets legacy bâtis sur des “solutions” initialement garanties sans code, dans lesquelles on a dû, wait for it, ajouter du code.</p>
<p>Dans l’entreprise on gère assez mal la qualité logicielle des technos “code centric”. Sur une techno “code eccentric” à laquelle on a dû adjoindre du code après coup, c’est encore pire.</p>
<p>😞 Si vous n’aimez pas beaucoup le code legacy, vous allez carrément détester le code legacy sur une plateforme pas prévue pour le code. 😭</p>
<p>De l’autre côté, je me dis : pourquoi l’entreprise ne se lancerait elle pas dans le no code ? Après tout elle est déjà bien engagée et depuis longtemps dans le No Test.</p>
<p>🤹♀️No Test : Tester coûte cher, et c’est fastidieux, voire ennuyeux. Préservez la motivation et l’énergie de vos développeurs. Le code qui passe en prod marche instantanément. Et vous saurez le faire évoluer facilement. Inutile de chercher la petite bête. Libérez vous des esprits critiques.</p>
<p>Le No Test, cette profession de foi de ceux qui croient en leur chance et se remontent les manches même le dimanche, est probablement la technique de test la plus répandue dans toutes les entreprises aujourd’hui.</p>
<p>Répandue, oui, mais pas autant que le No Review.</p>
<p>🎭 No Review : Relire le code ensemble, c’est beaucoup de temps perdu à chicaner, et c’est prétexte à de nombreuses frictions. Adoucissez votre processus de développement ! Le code qui passe la porte pour aller en prod est parfait, lumineux. Ceux qui auront à le modifier plus tard (et qui sont encore à l’école primaire en ce moment) n’en reviendront pas.</p>
<p>Le No Review, comme pratique d’accélération des projets est très ancré dans l’entreprise, mais pas autant que le No Doc, qui lui est totalement généralisé.</p>
<p>🦄 No Doc : Pourquoi décrire quand on peut construire ? Grâce à No Doc, vos futurs développeurs accèdent en un coup d’œil sur la base de code à l’architecture de la solution, ils comprennent instantanément les enjeux métiers pour l’entreprise et savent exactement où coder leur modifications !</p>
<p><img src="/images/noproduct.jpg" alt="No Product" /></p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_qualitymanagement-activity-7115972842009026560-bqaB?utm_source=share&utm_medium=member_desktop">Publié sur Linked In le 02/10/2023</a></p>Christophe Thibautcthibauttof@gmail.comBeaucoup de développeurs considèrent l’option “No Code” comme une mauvaise idée. Disons, une idée qui va faire long feu. Cela se comprend, si l’on considère que pour le développeur l’écriture du code constitue son activité essentielle.Testeur et Programmeur2023-10-01T00:00:00+00:002023-10-01T00:00:00+00:00http://christophethibaut.com/2023/10/01/TS-9<p>La plupart des gens se font une idée très simplifiée ce que c’est que développer du logciel :</p>
<p>⌨️ développer du logiciel, c’est écrire du code ⌨️</p>
<p>Cet archétype, au sein même de l’industrie du développement et du conseil, omniprésent. Exemples :
<!--more--></p>
<p>🤖 on se demande si chatGPT (ou autre LLM) va remplacer les développeurs étant donnée la vitesse à laquelle ces outils peuvent produire du code relativement utile</p>
<p>📉 la performance des développeurs s’exprime en points de vélocité, une approximation de la quantité de code livrée en production, ou bien du temps passé à produire ce code</p>
<p>(pour vous en convaincre, proposez à une équipe d’ajouter à sa “definition of done” la documentation, la vérification ainsi que les tests : quelqu’un dans l’équipe vous opposera que cela risque de faire baisser la vélocité.)</p>
<p>🕳 en cas de retard, on préfère toujours livrer plus de code moins testé, moins vérifié et moins documenté, que livrer moins de code, mais du code testé, vérifié et documenté.</p>
<p>Sachant qu’il n’y a pas assez de testeurs·es dans les entreprises, et me demandant si on ne ferait pas bien d’écrire moins de code et plus de tests, en lisant l’introduction de Software Testing Techniques, j’ai eu envie de poser cette question :</p>
<p>À quel point faut-il distinguer testeur et programmeur ?</p>
<blockquote>
<p>📖 La plupart des techniques présentées dans ce livre peuvent être utilisées à tous les niveaux de tests — depuis l’unité jusqu’au système. Lorsque la technique est utilisée au niveau du système, le concepteur et le testeur sont probablement des individus distincts. En revanche lorsque cette même technique est utilisée au niveau des tests unitaires, le testeur et le programmeur sont une seule et même personne, qui agit un temps comme programmeur et un temps comme testeur.</p>
</blockquote>
<blockquote>
<p>📖Vous devez être un schizophrène constructif. Ayez clairement en tête la différence entre votre rôle de programmeur et votre rôle de testeur. Le testeur en vous doit être méfiant, intransigeant, hostile, et compulsivement obsédé par la destruction, la destruction ultime, du logiciel du programmeur. Le testeur en vous est votre Mr Hyde — votre Incroyable Hulk. Le programmeur en vous essaie de réaliser une tâche de la manière la plus simple et la plus propre possible, à temps, et dans les budgets. Quelque fois vous y arrivez grâce à une idée géniale à propos du problème, laquelle réduit la complexité et l’effort, tout en étant presque correcte. Et avec ce testeur/Hulk tapi dans un recoin de votre esprit, il devient très utile de développer une saine paranoïa concernant les bugs. Rappelez-vous, par conséquent, que lorsque je me réfère au “concepteur de tests” et au “programmeur” en tant qu’individus distincts, le degré de séparation entre eux dépend du niveau de test et du contexte dans lequel la technique est appliquée.</p>
</blockquote>
<p><img src="/images/software-testing-techniques-2nd-edition.png" alt="Software Testing Techniques" /></p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_testing-tdd-activity-7115698579792347141-P5Cj?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 05/10/2023</a></p>Christophe Thibautcthibauttof@gmail.comLa plupart des gens se font une idée très simplifiée ce que c’est que développer du logciel : ⌨️ développer du logiciel, c’est écrire du code ⌨️ Cet archétype, au sein même de l’industrie du développement et du conseil, omniprésent. Exemples :Rationalisations2023-09-30T00:00:00+00:002023-09-30T00:00:00+00:00http://christophethibaut.com/2023/09/30/TS-8<p>Travaillant dans le contexte de projets de développment depuis 35 ans, j’ai croisé plusieurs “générations” de développeurs et de managers. Leurs positions à propos des tests varie d’une génération à l’autre, avec quelques constantes :
<!--more--></p>
<p>🏝 le test est une activité mal connue, mal comprise, peu pratiquée, et très peu maîtrisée</p>
<p>🔧 on croit que l’essentiel de l’activité de test consiste à exécuter des tests</p>
<p>⛏ pour beaucoup, test = test manuel, un labeur réalisé par d’autres personnes moins qualifiées que les développeurs, qui eux, créent de la valeur</p>
<p>🤖 on place ainsi de l’espoir (et du budget) dans des outils permettant soi disant “d’automatiser les tests” mais qui n’automatisent que l’exécution des tests</p>
<p>🦾 cette confusion, pour des gens qui passent leur carrière à automatiser des traitements, fait sens</p>
<p>🦄 chaque génération arrive avec des raisons nouvelles de ne pas investir dans le test : progrès des langages, internet c’est différent, bientôt l’IA etc.</p>
<p>En lisant l’introduction de Software Testing Technique de Boris Beizer, publié il y a 40 ans, j’ai glané quelques idées intéressantes en regard de ces préjugés.</p>
<p>📖 Extrait 1 (sur le thème : à quoi servent les tests ?)</p>
<blockquote>
<p>Le test et la conception des tests, comme composante de l’assurance qualité, devraient également traiter de la prévention des bugs. Pour autant que le test et la conception des tests ne prémunissent pas contre les bugs, ils devraient découvrir les symptômes causés par les bugs. Enfin, les tests deraient fournir des diagnostics clairs permettant de corriger facilement les bugs. La prévention des bugs est le but primordial du test. Un bug empêché est plus désirable qu’un bug détecté et corrigé, parce qu’alors il n’y a pas de code a corriger, ni de test à rejouer pour confirmer que la correction était valide, personne n’est embarrassé, il n’y a pas de consommation de ressources, et les bugs empêchés ne peuvent pas impacter négativement le calendrier. Plus que l’acte de tester, l’acte de <em>concevoir</em> les tests est un des meilleurs moyens connus de prévenir les bugs. La réflexion et l’analyse qui entrent dans la création d’un test utile peuvent identifier et éliminer les bugs avant qu’ils soient codés. En fait, la conception des tests permet de découvrir et d’éliminer les bugs à toutes les phases de la création d’un logiciel, depuis la conception, en passant par la spécification, la conception détaillée, le code, et le reste. À ce stade une activité idéale de conception des tests serait tellement fructueuse qu’il ne serait même pas nécessaire de lancer les tests, parce que tous les bugs auraient été trouvés et résolus pendant la conception des tests.</p>
<p>Malheureusement, cet idéal ne peut être atteint. En dépit de nos efforts, parce que nous sommes humains, il y aura des bugs. Pour autant que le test échoue dans son but primaire de prévenir les bugs, il doit atteindre son but secondaire qui est d’identifier clairement qu’il y a un bug.</p>
</blockquote>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_travaillant-dans-le-contexte-de-projets-de-activity-7114975856036302849-DVQ0?utm_source=share&utm_medium=member_desktop">Publié sur Linked In le 30/09/2023</a></p>Christophe Thibautcthibauttof@gmail.comTravaillant dans le contexte de projets de développment depuis 35 ans, j’ai croisé plusieurs “générations” de développeurs et de managers. Leurs positions à propos des tests varie d’une génération à l’autre, avec quelques constantes :Jeu Quiz2023-09-29T00:00:00+00:002023-09-29T00:00:00+00:00http://christophethibaut.com/2023/09/29/TS-6<p>⚫️ Lorsque je passe mon smartphone sur la borne du portique pour présenter le QR code de mon ticket, le portique ne valide pas mon ticket. C’est parce que mon appareil est passé en mode “paiement”, et n’affiche plus le QR code.</p>
<p>Selon vous, qui serait le plus à même d’identifier ce problème ?
<!--more--></p>
<p>A - un utilisateur (et c’est tombé sur moi)<br />
B - un défenseur<br />
C - un explorateur<br />
D - un responsable de la SNCF ou de chez smartphone</p>
<p>🟣 À propos de l’application qui ne détectait pas correctement les portefeuilles ayant des comptes dont le solde dépasse le seuil de sécurité, ces informations :</p>
<ul>
<li>le code (Java) examine chaque compte en traversant un tableau au moyen d’une boucle for\</li>
<li>la boucle for est initialisée à 1\</li>
<li>le code a été testé à l’aide d’un jeu d’essai élaboré sur la base de données de DEV\</li>
<li>le jeu d’essai comprend 6 comptes dont 2 sont en dépassement de seuil, en position 1 et 4 dans le tableau\</li>
<li>le test passe</li>
</ul>
<p>Selon vous qui peut identifier ce problème le plus rapidement ?</p>
<p>A - le titulaire du portefeuille<br />
B - un défenseur<br />
C - un explorateur<br />
D - un sourcier pratiquant la radiesthésie</p>
<p>🟢 Une entreprise a développé un ERP pour ses propres besoins en partant d’une suite open source, en agile. Ses équipes veulent allonger la durée du sprint parce que la phase dite de “non-régression”, qui prend désormais plus de 4 jours, force à décaler les livraisons.</p>
<p>Selon vous quelle action serait la plus indiquée ?</p>
<p>A - recruter plus d’explorateurs<br />
B - recruter un(e) automaticien(e)<br />
C - demander aux défenseurs de passer explorateurs<br />
D - limiter le nombre de users stories en entrée du sprint</p>
<p>🔵 Une équipe de 15 personnes réalise un projet de développement depuis un an sans avoir écrit un seul test automatisé. Son client exige désormais que l’application dispose de tests automatisés.</p>
<p>Selon vous à qui devrait-on confier cette tâche ?</p>
<p>A - aux explorateurs<br />
B - aux défenseurs<br />
C - à une société extérieure qui pourra le faire pour moins cher<br />
D - à un outil à base de LLM pour encore moins cher</p>
<p>🔴 Le directeur financier de l’entreprise où vous travaillez vous demande : quel est le coût de ne pas faire de tests ?</p>
<p>Votre réponse :</p>
<p>A - Ça dépend de ce que vous entendez par “faire des tests”<br />
B - Si l’équipe connaît son métier et sait ce qu’elle fait, le coût est marginal<br />
C - Ça dépend de vos objectifs à moyen terme<br />
D - Je n’ai pas la réponse à cette question</p>
<p>🟠 Votre cousin nouvellement diplômé vient d’entrer chez un éditeur de logiciel dont le CTO déclare “Pas de tests automatisés chez nous: lorsque le soft évolue il faut aussi faire évoluer les tests, et c’est trop lourd”.</p>
<p>A - Votre cousin va faire un apprentissage intéressant<br />
B - Vous vous inquiétez pour l’avenir professionnel de votre cousin<br />
C - Cette entreprise vit sur une niche, votre cousin peut rester serein<br />
D - Votre cousin mérite mieux que ça</p>
<p><img src="/images/alarm-fault-reset.png" alt="Alarm Fault Reset" width="800pg" /></p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_testing-tdd-activity-7113391256260497408-hntZ?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 29/09/2023</a></p>Christophe Thibautcthibauttof@gmail.com⚫️ Lorsque je passe mon smartphone sur la borne du portique pour présenter le QR code de mon ticket, le portique ne valide pas mon ticket. C’est parce que mon appareil est passé en mode “paiement”, et n’affiche plus le QR code. Selon vous, qui serait le plus à même d’identifier ce problème ?Rationalisations2023-09-29T00:00:00+00:002023-09-29T00:00:00+00:00http://christophethibaut.com/2023/09/29/TS-7<p>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.
<!--more-->
C’est une évidence qui saute aux yeux. Mais lorsqu’on évoque le problème, on entend ces rationalisations :</p>
<p>C’est très complexe une application. 🤷♂️</p>
<p>On ne peut pas tout tester. 😅</p>
<p>Ce ne serait pas rentable de tester plus. 💸</p>
<p>“C’est très complexe”</p>
<p>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.</p>
<p>“On ne peut pas tout tester”</p>
<p>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.👌</p>
<p>“Ce ne serait pas rentable”</p>
<p>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.</p>
<p>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.</p>
<p>Ce n’est pas le raisonnement que tient une entreprise qui se lance dans le logiciel. Pour elle, il suffit de :</p>
<ul>
<li>trouver une idée</li>
<li>trouver des fonds</li>
<li>trouver des gens qui savent coder</li>
<li>se lever tôt (cette partie là, oui c’est pareil).</li>
</ul>
<p>(à suivre)</p>
<p>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é:</p>
<p>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.</p>
<p><img src="/images/software-testing-techniques.png" alt="Software Testing Techniques" /></p>
<p><a href="https://meet.google.com/ngi-aorj-tqv?hs=122&authuser=0">publié sur Linked In le 02/10/2023</a></p>Christophe Thibautcthibauttof@gmail.comIl 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.Défense vs Exploration (4)2023-09-28T00:00:00+00:002023-09-28T00:00:00+00:00http://christophethibaut.com/2023/09/28/TS-5<p>— Ah ! Cette fois-ci on a à la fois les concepteurs, et les chasseurs de bugs.<br />
— Oui. Appellons-les les “défenseurs” et les “explorateurs”.<br />
— À lire cette carte on dirait que dans leurs activités respectives ils sont parfaitement isolés les uns des autres.
<!--more-->
<img src="/images/defense-exploration-4.png" alt="défense vs exploration (4)" width="800px" />
— C’est l’impression que donne ce pentagone bleu, mais c’est le contraire qui est vrai : les explorateurs fournissent sans cesse aux défenseurs des informations cruciales à propos du système, et réciproquement.<br />
— Mais qui est responsable de sa qualité, au final ?<br />
— Les deux acteurs sont responsables, et contributeurs.<br />
— Il y a donc une phase de “build” et une phase de “test” ?<br />
— Il y a plutôt deux activités menées parallèlement et en complément l’une de l’autre : les défenseurs conçoivent, spécifient, implémentent et vérifient les comportements de l’application. Les explorateurs, eux, recherchent activement des problèmes possibles avec l’application, dont les défenseurs n’auraient pas encore conscience.<br />
— Je vois. Les défenseurs construisent des défenses. Les explorateurs vont au delà des défenses et cherchent les menaces qui ont échappé à la sagacité des défenseurs.<br />
— Voilà.<br />
— Pourquoi deux rôles ? Pourquoi les défenseurs ne deviendraient-ils pas des explorateurs à l’occasion ?<br />
— Individuellement, c’est parfaitement possible, il suffit que l’organisation l’encourage.<br />
— Je veux dire : la plupart des personnes que je connais et qui savent concevoir et coder un logiciel, seraient également capables, je pense, de tester ce logiciel de manière exploratoire.<br />
— Peut-être. Mais mets-toi un moment à la place de l’organisation, du management. Comment tu établis que des développeurs ont bien fait leur travail ?<br />
— S’ils ont livré dans les délais, un logiciel fiable, répondant au besoin, et du code facile à maintenir.<br />
— Et comment est-ce que tu établis que des testeurs ont bien fait leur travail ?<br />
— Je dirais : s’ils ont trouvé et signalé rapidement les problèmes les plus critiques ?<br />
— Voilà. Le management peut exercer une pression, ou une incitation, qui encouragerait à la fois la tenue des délais et la ténacité à rechercher les menaces à la valeur. Sur une équipe, c’est assez simple. Sur un individu, c’est problématique.<br />
— Donc, en résumé, qu’est-ce que tu préconises, comme stratégie de tests ?<br />
— En bref :</p>
<p>1️⃣ Si tu veux créer et faire grandir un logiciel, tu dois à la fois défendre et explorer. Il te faut de bons concepteurs et de bon testeurs.</p>
<p>2️⃣ Les personnes qui conçoivent et construisent le système sont les mieux à même de le défendre: en écrivant des tests.</p>
<p>3️⃣ Les explorateurs/testeurs ne peuvent travailler efficacement que si le système a des défenses.</p>
<p>— Deux rôles pour assurer la qualité ça complique quand même un peu les choses, tu ne crois pas ?<br />
— Ça les complique, mais pas autant que des nuées de bugs en production.</p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_ah-cette-fois-ci-on-a-%C3%A0-la-fois-les-concepteurs-activity-7113047094688395264-JqzX?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 28/09/2023</a></p>Christophe Thibautcthibauttof@gmail.com— Ah ! Cette fois-ci on a à la fois les concepteurs, et les chasseurs de bugs. — Oui. Appellons-les les “défenseurs” et les “explorateurs”. — À lire cette carte on dirait que dans leurs activités respectives ils sont parfaitement isolés les uns des autres.Défense vs Exploration (3)2023-09-27T00:00:00+00:002023-09-27T00:00:00+00:00http://christophethibaut.com/2023/09/27/TS-4<p>— Ok, nouvelle carte. Où sont passés les chasseurs ?<br />
— Ils ne font pas partie du dispositif. Pas de testeurs, pas de “QA”, ici.<br />
— Et ces acteurs, à l’intérieur du périmètre en bleu, qu’est-ce qu’ils font ?<br />
— De la conception.
<!--more-->
<img src="/images/defense-exploration-3.png" alt="défense vs exploration (3)" width="800px" />
— Je vois. D’où leur tableaux blancs. En tout cas, pas un seul “bug”, à l’intérieur de l’enceinte !<br />
— Exact. C’est de la bonne conception, tout est vérifié, relu, testé.<br />
— C’est propre !<br />
— Tu ne crois pas si bien dire, c’est comme ça qu’ils qualifient leur démarche. Quelle que soit la phase du projet, ils ont soin d’ajouter des vérifications automatisées là où ils développent, aménagent, et maintiennent.<br />
— Du coup, plus de problème.<br />
— Disons que toutes les inconnues connues sont “couvertes”.<br />
— Mais il reste les inconnues inconnues, c’est ça ?<br />
— Voilà.<br />
— Bah, tant qu’elles sont à l’extérieur du périmètre de conception, on s’en f…<br />
— Hmm. Ce n’est peut être pas clair, mais ce qu’indique la carte justement, c’est que l’usage du logiciel dépasse, et de loin, le périmètre de conception.<br />
— C’est à dire ?<br />
— Le pentagone bleu contient juste un modèle de ce qui va se produire avec l’application dans son éco-système, une vision simplifiée, si tu veux. À “l’extérieur” de cette conception, on va trouver des inconnues inconnues plus ou moins intéressantes, des “bugs” comme tu dis.<br />
— Hum. Un exemple serait le bienvenu, là maintenant.<br />
— Soit. L’application qui gére les vélos que j’utilise en ville me propose, contre remise, d’aller changer la batterie du vélo dans une des boutiques qui met à disposition des batteries de rechange. Elle m’indique où se trouve ce magasin et me demande si j’accepte d’aller faire l’échange. J’accepte.<br />
— Ok.<br />
— J’arrive à la porte du magasin. Normalement, je signale que je suis arrivé. L’application le valide (elle me localise) et doit maintenant me guider pour l’échange de batterie, une séquence bien précise.<br />
— Ok.<br />
— Tu devines le problème ?<br />
— Ton smartphone vient juste de mourir ?<br />
— Non.<br />
— Tu n’as pas de réseau là où se trouve le magasin ?<br />
— Bingo. Il faut que je marche un peu, 50 mètres, pour retrouver du réseau. Et là qu’est-ce qui se passe ?<br />
— Aucune idée.<br />
— L’application pense que je ne suis pas encore arrivé, et ne m’autorise pas à retirer la batterie.<br />
— Ah mince.<br />
— Oui, mince.<br />
— Non mais ce cas là ils ont dû le prévoir quand même !<br />
— Ce n’est pas la question. Ils l’ont peut être pressenti, et décidé qu’ils n’avaient pas de solution économiquement sensée à ce problème, ou simplement pas le temps.<br />
— Puisque ce n’est pas dans le périmètre… C’est ce que dit la carte.<br />
— Non, ce que dit la carte, c’est que la carte n’est pas le territoire, justement.<br />
— Concrètement ?<br />
— Elle dit: “Tu devrais explorer ce territoire, sinon tes utilisateurs vont rencontrer des triangles rouges que tu ne pourras pas localiser tant que tu reste dans les limites de tes modèles de conception.”<br />
— “Et ce sera ton problème”<br />
— Dans certain cas, oui, dans d’autres non.<br />
— Comment le savoir ?<br />
— En explorant !</p>
<p>(à suivre)</p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_testing-tdd-activity-7112661251985399808-VGuh?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 27/09/2023</a>
#testing #tdd</p>Christophe Thibautcthibauttof@gmail.com— Ok, nouvelle carte. Où sont passés les chasseurs ? — Ils ne font pas partie du dispositif. Pas de testeurs, pas de “QA”, ici. — Et ces acteurs, à l’intérieur du périmètre en bleu, qu’est-ce qu’ils font ? — De la conception.Défense vs Exploration (2)2023-09-26T00:00:00+00:002023-09-26T00:00:00+00:00http://christophethibaut.com/2023/09/26/TS-3<p>— Une nouvelle carte ! Avec cette fois des “acteurs” comme tu dis. Ils chassent les bugs ?<br />
— Disons qu’ils recherchent activement des problèmes possibles avec l’application.<br />
— À voir le nombre de triangles, ils ne vont pas rentrer bredouille…<br />
— Oui, c’est un bon terrain de jeu.
<!--more-->
<img src="/images/defense-exploration-2.png" alt="défense vs exploration (1)" width="800px" />
— On voit qu’ils sont surtout concentrés sur le périmètre initial de la conception.<br />
— Exact. Ils le parcourent en s’aidant de la doc fonctionnelle, qu’ils transforment en “plans de tests”. Ensuite ils exercent le code de l’application en suivant ce plan.<br />
— Ils explorent aussi la zone extérieure, on dirait ?<br />
— Dès qu’ils le peuvent, oui. Mais il ne le peuvent pas souvent: le périmètre “connu” de la conception présente déjà assez de problèmes pour remplir leurs journées.<br />
— Au moins ici le scénario dont tu parlais hier ne risque pas de se produire.<br />
— Tu veux parler du cas où la liste des comptes dont le solde dépasse un certain seuil n’est pas correcte ?<br />
— Oui. Ici, un testeur peut essayer la “feature” dans tous les sens possibles, et finir par trouver le bug !<br />
— En y passant le temps qu’il faut, bien sûr.<br />
— Bah ! C’est mieux que rien.<br />
— Supposons que l’application autorise une opération seulement si le portefeuille ne contient aucun compte en “dépassement”. Comment tu t’y prendrais pour vérifier cette partie de son comportement ?<br />
— Eh bien je testerais plusieurs cas :</p>
<p>∙ un portefeuille ne contenant aucun compte en dépassement, et l’opération est effectuée<br />
∙ un portefeuille contenant un seul compte en dépassement, et l’opération est refusée<br />
∙ un portefeuille contenant plusieurs comptes en dépassement, même résultat<br />
∙ un portefeuille vide…</p>
<p>— Pas sûr qu’avec cette liste de cas tu aurais détecté le défaut dont on parlait hier.<br />
— Je ne vois comment je l’aurais raté ! On a tous les cas de figure.<br />
— Je ne sais pas si tu as recensé tous les cas de figure, mais je sais une chose : effectuer tous ces tests prend un certain temps.<br />
— Hélas. Mais avec une IA…<br />
— En attendant qu’une IA soit capable de raisonner jusqu’au point où elle peut élaborer une suite de cas pertinente, les testeurs prennent leur courage à deux mains, leurs journées de 8 heures, leur maigre budget de test, et essaient tant bien que mal de “couvrir” le périmètre de l’application.<br />
— Je présume que pour cette application, tu militerais pour qu’on recrute plus de testeurs ?<br />
— Ce ne n’est pas dit que le remède “plus de testeurs” viendrait à bout de tous les problèmes. Mais ce serait déjà mieux que rien.<br />
— Évidemment, dans ce cas, le projet coûterait plus cher.<br />
— Oui. Je doute que le client de cette application accepterait de payer plus cher pour ce travail de vérification assez élémentaire…<br />
— Je suppose qu’il demanderait plutôt qu’on recrute de meilleurs développeurs !<br />
— “Des meilleurs développeurs” c’est aussi plus cher.<br />
— Il n’y a pas de solution, donc.<br />
— Tant qu’on passe plus de temps à corriger les problèmes qu’à essayer de prévenir leur apparition, non.</p>
<p>(à suivre)</p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_testing-tdd-activity-7112302315646115841-1_VO?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 26/09/2023</a>
#testing #tdd</p>Christophe Thibautcthibauttof@gmail.com— Une nouvelle carte ! Avec cette fois des “acteurs” comme tu dis. Ils chassent les bugs ? — Disons qu’ils recherchent activement des problèmes possibles avec l’application. — À voir le nombre de triangles, ils ne vont pas rentrer bredouille… — Oui, c’est un bon terrain de jeu.Défense vs Exploration (1)2023-09-25T00:00:00+00:002023-09-25T00:00:00+00:00http://christophethibaut.com/2023/09/25/TS-2<p>— Qu’est-ce que ça représente, cette carte ?<br />
— Ça ? Les vestiges d’une application…<br />
— Comprends pas.<br />
— La ligne pointillée bleue délimite l’ensemble des comportements que l’application devait présenter une fois installée en production. L’équipe qui a conçu cette application, et l’a construite, s’est dit : elle n’ira pas plus loin, mais à tout le moins, elle fera ça, c’est à dire ce qui se trouve à l’intérieur de la ligne bleue.<br />
— Et les triangles rouges ?<br />
— Ce sont tous les comportements incorrects rencontrés par ceux qui ont utilisé l’application.<br />
— Des bugs, donc.
<!--more-->
<img src="/images/defense-exploration-1.png" alt="défense vs exploration (1)" width="800px" />
— Disons des variations de comportement qui ne faisaient pas partie du plan.<br />
— C’est ce que je dis. Des bugs. Je ne vois pas la différence…<br />
— C’est parce le mot bug est si vague… on peut y mettre tout et n’importe quoi.<br />
— Par exemple, ce triangle rouge tout en haut vers la gauche, il représente quoi ?<br />
— La déclaration d’un utilisateur à l’équipe : “là le calcul est peut être conforme à la spéc, comme vous dites, mais en tout cas ce n’est pas comme ça que ça marche dans la vraie vie.”<br />
— Je vois. Ce n’était pas un défaut du programme.<br />
— C’était un problème de conception fonctionnelle, si tu veux.<br />
— Donc les triangles rouges représentent des défauts, non pas du programme, mais de la conception ? On n’a pas fait le bon produit ?<br />
— Pas forcément : tu vois qu’il y a aussi des triangles rouges à l’intérieur de l’enceinte tracée en bleu.<br />
— Qu’est-ce qu’ils représentent ceux-là ? Par exemple le triangle le plus haut dans le pentagone ?<br />
— Ça, c’est quand on a remarqué, en production, que l’application ne détectait pas correctement les portefeuilles ayant des comptes dont le solde a dépassé un certain seuil de sécurité.<br />
— Et ça, ça aurait dû être compris lors de la conception ? C’est pour cela que ce triangle est à l’intérieur de l’enceinte bleue ?<br />
— Exact. Le comportement “tu donneras la liste des comptes du portefeuille dont le solde dépasse tant” faisait partie des comportements possibles de l’application à la conception. Mais un utilisateur à réussi à montrer que dans certain cas, ce comportement n’était pas correctement implémenté.<br />
— Ça paraît fou. Vérifier les soldes des comptes d’un portefeuille, c’est quand même pas sorcier !<br />
— Je comprends ton étonnement. Ce que ne dit pas la carte, c’est qu’il n’y avait pas de test dans ce projet.<br />
— Quoi pas de test ?<br />
— Il y a eu tout au plus quelques essais à la hâte, juste avant de livrer.<br />
— Mais quand même ! Comment on peut se tromper sur un truc aussi simple ?<br />
— S’il n’y a pas de test, pas de vérification, pas de relecture, personne pour chercher ne serait-ce qu’un problème éventuel…<br />
— Mais ça ne peut pas marcher !<br />
— Et ça n’a pas marché. Est-ce que tu vois des acteurs sur cette carte ?<br />
— Non. On devrait en voir ?<br />
— Si le projet avait survécu, oui.</p>
<p>(à suivre)
#testing #softwaredevelopment #tdd</p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_testing-softwaredevelopment-tdd-activity-7111937947205029888-K59k?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 25/09/2023</a></p>Christophe Thibautcthibauttof@gmail.com— Qu’est-ce que ça représente, cette carte ? — Ça ? Les vestiges d’une application… — Comprends pas. — La ligne pointillée bleue délimite l’ensemble des comportements que l’application devait présenter une fois installée en production. L’équipe qui a conçu cette application, et l’a construite, s’est dit : elle n’ira pas plus loin, mais à tout le moins, elle fera ça, c’est à dire ce qui se trouve à l’intérieur de la ligne bleue. — Et les triangles rouges ? — Ce sont tous les comportements incorrects rencontrés par ceux qui ont utilisé l’application. — Des bugs, donc.Stratégies2023-08-23T00:00:00+00:002023-08-23T00:00:00+00:00http://christophethibaut.com/2023/08/23/TS-1<p>J’allais détailler pourquoi je jette aux gémonies la pyramide des tests, et la couverture des tests avec elle, mais inutile : le dernier billet de Laurent Bossavit met en lumière le problème bien mieux que je ne l’aurais fait. Lisez-le !</p>
<p>Vous l’avez lu ?
<!--more-->
Lorsque nous réduisons un potentiel problème de qualité à un rapport de quantité, nous raisonnons à l’emporte-pièce, et notre stratégie s’en ressent.</p>
<p>Traverseriez-vous une rivière profonde d’1 mètre en moyenne ?</p>
<p><em>“18 heures d’indisponibilité ! Et pourtant notre coverage est en amélioration constante, je ne comprend pas”.</em> Famous last words.</p>
<p>△</p>
<p>Je n’ai donc pas de conseil à donner en taille de couverture ou en forme de pyramide. Mais ça ne m’empêche pas de formuler certaines réflexions, et de les partager. 😅</p>
<p>Nous posons des tests sur un système et nous le testons (ce n’est pas la même chose) en vue de réduire autant que possible le potentiel de problèmes que ce système présentera eu égard à ses objectifs et au contexte dans lequel il devra fonctionner.</p>
<p>En écrivant des tests, nous cherchons à nous prémunir contre des inconnues connues : ce sont tous les problèmes que nous pouvons anticiper à la conception, les erreurs que nous savons que nous risquons de faire, la complexité que nous ne voulons pas laisser dans l’ombre. Nous voulons mitiger les effets connus de cette complexité.</p>
<p>▶️</p>
<p>— j’écris un test: testApres12StrikesScoreEgale300() et il va échouer parce que le programme ne tient pas encore compte de la règle du 10ème frame.</p>
<p>⏸</p>
<p>En testant, nous cherchons à nous prémunir contre des inconnues inconnues : ce sont toutes les surprises que nous réserve le produit, qui échappent à notre compréhension limitée de ce système à l’instant t. Nous allons à la rencontre de sa complexité (avant que celle-ci ne frappe nos utilisateurs).</p>
<p>▶️</p>
<p>— La QA a réussi à produire une facture avec un montant négatif! Ils sont trop forts !</p>
<p>⏸</p>
<p>Pour des raisons culturelles, sociologiques, historiques, mais aussi techniques, nous focalisons cette activité de “test” sur deux centres d’intérêt à peu près distincts :</p>
<ul>
<li>le comportement du système avec l’extérieur, i.e les interactions Humains/Machine 🖥🤔</li>
<li>le comportement “interne” du système, i.e les interactions Machine/Machine ⚙️🤖</li>
</ul>
<p>Ces deux partages :</p>
<ul>
<li>inconnues connues / inconnues inconnues</li>
<li>interactions H/M / interactions M/M</li>
</ul>
<p>divisent en 4 zones l’étendue du territoire dans lequel le mot “test” revêt du sens pour le développement de logiciel. Dans chacune des zones, les états de l’art, les procédés, les pratiques, les process sont différents, et à juste titre. Cf le diagramme en illustration. Cette carte heuristique, ce “mind-map”, permet de détecter rapidement des erreurs de stratégie. Je me suis permis de mentionner dans chaque zone ma stratégie préférée.</p>
<p><img src="/images/mindmap-test.png" alt="mind map tests" width="800px" /></p>
<p>Prochainement sur cette chaîne, un quizz pour valider ou infirmer ce modèle. Stay Tuned ! 📡</p>
<p><a href="https://www.linkedin.com/posts/christophe-thibaut-35b4657_jallais-d%C3%A9tailler-pourquoi-je-jette-aux-activity-7100042480359723008-qGFU?utm_source=share&utm_medium=member_desktop">publié sur Linked In le 23/08/2023</a></p>Christophe Thibautcthibauttof@gmail.comJ’allais détailler pourquoi je jette aux gémonies la pyramide des tests, et la couverture des tests avec elle, mais inutile : le dernier billet de Laurent Bossavit met en lumière le problème bien mieux que je ne l’aurais fait. Lisez-le ! Vous l’avez lu ?