Mois : mars 2018

« Un vieillard qui meurt, c’est une bibliothèque qui brûle »

Pour ce deuxième article sur les métaphores au service du test, nous allons nous concentrer sur un aspect crucial de tout projet informatique : la gestion des connaissances. Comment faire pour partager les bonnes infos aux bons endroits, de manière à ce que les bonnes personnes puissent les trouver au bon moment ? Et pour commencer, comment donner aux collaborateurs l’envie de transmettre leur savoir d’une part, d’augmenter leurs compétences d’autre part ? Lorsque vous étudiez ces questions avec votre équipe, nous vous proposons de garder à l’esprit une métaphore, qui nous vient des confins du Pacifique Sud. Au passage, merci au Guichet du Savoir pour les recherches bibliographiques sur ce sujet !

Gestion des connaissances : et si on jouait les Néo-Zélandais ?

Problématique

Vous en êtes certain, il y a des trous dans la raquette. Les membres de votre équipe sont excellents dans leur spécialité, mais ne connaissent pas suffisamment le travail les uns des autres et sont incapables de se relayer. Cela peut être un handicap à plusieurs niveaux :

• fonctionnel, car l’absence d’un membre peut constituer un frein pour l’ensemble de l’équipe
  • Marjolaine est la seule à connaître la nouvelle procédure de mise en qualification, mais est clouée au lit par la dengue pour les deux semaines à venir. Les autres membres de l’équipe, frileux à l’idée de se lancer dans une procédure non documentée, se défendent en disant que ce n’est pas à eux de le faire.
• relationnel, car l’estime et l’empathie ne sont pas toujours au rendez-vous (surtout si les membres de l’équipe ne travaillent pas au même endroit)
  • Quand le projet prend du retard, Anselme le PO considère que les devs ont codé trop lentement et Polly la team leader considère que les specs trop brouillonnes les ont ralentis.
• individuel, car les membres de l’équipe pourraient s’épanouir davantage en acquérant de nouveaux savoir-faire
  • Boniface est testeur ; le projet dure depuis des mois et des mois et il se sent enfermé dans une routine, il a le sentiment de ne plus rien apprendre. Il songe parfois à changer de boîte.

Métaphore

Mike Talks est testeur en Nouvelle-Zélande. Cité dans More Agile Testing de Janet Gregory et Lisa Crispin (2014), il s’inspire au travail de l’histoire de son pays.

Dans la lignée des idéaux historiques néo-zélandais, j’encourage tout un chacun à sortir de sa zone de confort au sein de son équipe et s’essayer à de nouvelles choses. Dans un contexte de rareté des ressources et des compétences, ces modes de fonctionnements se sont révélées cruciaux pour les premiers pionniers de Nouvelle-Zélande. De manière générale, les spécialistes étaient amenés à diversifier leurs connaissances pour devenir des « spécialistes généralisants« . [Traduction Hightest]

A propos des pionniers de Nouvelle Zélande, Francine Tolron (source) rapporte effectivement les détails d’une vie quotidienne débrouillarde, émaillée de multiples activités :

Le pionnier […] dut trouver en lui-même ses ressources : construire […] un abri, une baraque de ponga, à partir des stipes de fougères, un toit en feuille de lin ; il lui fallut ramasser la nourriture de la forêt […], brûler les troncs pour fertiliser la terre entre les souches afin de planter du blé qu’il devait moudre sur place. Il fabriquait tout ce dont il avait besoin, depuis le beurre jusqu’aux chandelles et aux briques.

Visualisez-vous en train de fabriquer vos propres chandelles pendant que les briques que vous avez vous-mêmes façonnées sont en train de cuire dans votre four ; il n’y a rien que vous ne puissiez pas apprendre, ni vos collègues. Cela dit, on peut être aussi débrouillard que l’on veut, certains savoir-faire ne s’inventent pas, et les cycles projet ne permettent pas forcément de s’accorder de longues journées d’apprentissage autodidacte. La métaphore de Mike Talks permet donc de mettre l’accent sur les liens indispensable entre les membres de l’équipe. De même que les pionniers de Nouvelle-Zélande, il est nécessaire de développer des compétences secondaires, en s’appuyant sur les compétences les uns des autres. L’équipe projet est comme une île où il est nécessaire de valoriser au maximum chacune des ressources, car les risques de perdre une expertise sont décuplés.

Pour la petite histoire, Mike Talks a mis en action cette idée en travaillant de concert avec un business analyst. D’abord convaincu qu’il lui serait simple de rédiger des expressions de besoins, il s’est finalement rendu compte qu’il s’y prenait mal. D’une part, il n’expliquait pas suffisamment le cœur du problème, d’autre part il partait trop loin dans les détails, empiétant sur la marge de manœuvre des développeurs. Progressivement, monter en compétences dans ce domaine a enrichi ses propres pratiques et a par la suite amélioré la performance de ses échanges avec d’autres business analysts.

Mike Talks a également pu approfondir sa connaissance du métier en allant proactivement à la rencontre des utilisateurs du produit testé. Bâtir une relation de confiance, là où il aurait pu ne rien y avoir, lui a encore permis de gagner en pertinence lors de ses tests.

De l’équipe-île au testeur en forme de T

Cette démarche d’apprentissage a pour conséquence de modeler une expertise en forme de T, de nous transformer en « versatilistes » ou « T-shaped testers » (et non, on ne parle pas d’haltérophilie). Cette image a été développée en 1991 par David Guest dans l’ouvrage The Hunt Is On for the Renaissance Man of Computing, où est évoquée l’image de l’homme de Vitruve dessiné par Léonard de Vinci.

Ici, la barre verticale du T représente les connaissances en test, approfondies par l’expérience, et qui permet au testeur d’exercer au mieux son coeur de métier. C’est la taille du testeur ; plus il est grand, plus il voit loin ; il a en tête de nombreux paysages logiciels, il voit venir les problèmes à l’horizon et a le temps de s’y préparer.

La barre horizontale est quant à elle le symbole des domaines connexes maîtrisés en second plan. C’est l’envergure du testeur, ce qui lui permet de tendre la main et d’attraper, d’assimiler et de valoriser des informations issues d’autres domaines. Ce sont les connaissances métier engrangées au contact des clients, la culture technique acquise au contact des développeurs, les compétences managériales développées au fil des projets.

Et vous, quelle est votre T ? Quel est celui de vos collègues ? Que pouvez-vous vous apporter les uns les autres, de manière à ce que votre île soit la plus vivable possible ?

Conclusion

La métaphore de l’île nous amène à capitaliser les connaissances qui existent au sein d’une équipe, afin d’élargir le champ de compétences de chaque individu. De la même manière qu’une fonctionnalité peut être partiellement couverte par des tests portant sur une autre fonctionnalité, des activités peuvent être sommairement assurées par des personnes dont ce n’est pas le coeur de métier.

La démarche d’apprentissage peut s’accompagner d’une réflexion sur le « nous » de l’équipe. Pour cela, nous vous conseillons d’explorer les ateliers et supports développés par l’UdN (Université du Nous).

Nous vous proposerons prochainement une nouvelle métaphore issue de More Agile Testing, qui nous reliera cette fois au monde agricole… d’ici-là, n’hésitez pas à poster en commentaire les métaphores qui vous semblent précieuses pour illustrer la gestion des connaissances.

Priorisation : que faire quand ça semble trop tard ?

Pour ce troisième article sur les métaphores au service du test, nous allons nous pencher une fois de plus sur l’ennemi juré de la qualité : le temps, qui vient souvent avec ses cousins le rush, le stress et la précipitation. Et si une métaphore nous aidait à nous réconcilier avec ce facteur incontrôlable ?

Problématique

Le sprint est presque fini mais rien n’est vraiment prêt. Toute l’équipe est stressée et ne sait plus où donner de la tête. Freeze : c’est peut-être le moment de se calmer un peu et de faire le point sur ce qu’on peut rapidement finaliser. Vous avez besoin d’un déclencheur pour vous sortir la tête du guidon et aller à l’essentiel.

Métaphore

« Récolter les fruits d’un travail » est une métaphore assez commune. En cette fin de sprint ou d’itération, vous et votre équipe êtes en pleine cueillette. Mais vos paniers ne se remplissent pas très vite et vous vous inquiétez car le soleil est en train de se coucher. La lumière décline, les figues sont de moins en moins visibles dans les arbres et l’angoisse de ne rien cueillir habite chacun d’entre vous. Naturellement, à ce stade, ce sont les figues les plus basses que vous devez récolter, peu importe si elles sont petites. Le « low-hanging fruit« , c’est un bénéfice rapide que l’on peut faire en déployant un effort modéré.

Cette métaphore est souvent utilisée dans la littérature agile, et en particulier dans More Agile Testing. Dans l’objectif de livrer de la valeur à chaque sprint, il est parfois intéressant de se focaliser sur ce qui est rapidement faisable plutôt que sur ce qui serait idéal à long terme. On pourrait utiliser cette métaphore en réunion, par exemple pour organiser des postits énumérant des solutions à un problème. Attention tout de même à garder en tête la notion de valeur, afin de ne pas cueillir un fruit pourri…

Un exemple de schéma :

Si vous êtes pressé par le temps, relevez la tête et pensez fruit !

Priorisation bis : le puzzle logiciel au service de la sérénité

Mais fort heureusement, nous ne sommes pas toujours en guerre contre le temps. Côté test, une analyse d’un logiciel par les risques permet de limiter les situations de stress et de faire au mieux en temps limité. Et cela, c’est encore une métaphore qui va nous aider à le partager.

Problématique

En bon choriste de l’ISTQB, vous connaissez par coeur les paroles de « Les défauts sont regroupés » et de « Les tests exhaustifs sont impossibles« . Vos interlocuteurs n’ont peut-être pas envie de vous les entendre chanter encore une fois. Il vous faut rafraîchir cette même idée avec une métaphore.

Métaphore

Janet Gregory compare un logiciel à un puzzle dont on découvre l’image peu à peu, au fur et à mesure où l’on assemble ses pièces. Elle explique qu’il est possible d’obtenir des informations sur le puzzle sans l’assembler en entier, et tant mieux, car cela prendrait un temps fou. Pour tester dans les temps, il faut se concentrer sur les parties du puzzle qui nous intéressent le plus.

Imaginons que notre tableau représente une réplique, peinte par un contemporain, de la fresque de La Création d’Adam, peint par Michel Ange sur le plafond de la Chapelle Sixtine au début du XVIè siècle. Il est spécifié que la réplique doit être la plus fidèle possible à l’original, nous voulons donc tester si cela a été respecté, en maximisant nos chances de trouver d’éventuels défauts. Alors, voici ce que nous allons prendre en compte :

• La partie du tableau où les doigts d’Adam et de Dieu sont sur le point de se toucher est absolument critique. C’est la plus connue, la plus emblématique de l’oeuvre, celle qui justifie son titre ; c’est l’équivalent du cœur de métier. Il faut qu’elle soit testée.
• Les visages sont des parties d’un tableau qui peuvent être très intéressantes, mais le moindre détail peut ruiner une expression. On va donc assembler ces parties avec une priorité élevée.
• On sait que le ciel est quasiment un aplat, il contient peu de détails. Inutile d’assembler beaucoup de pièces pour pouvoir affirmer, avec un niveau de confiance élevé, s’il est fidèle au ciel original.
• Le paysage où se tient Adam n’est pas aussi uniforme. Il n’est pas utile d’assembler toutes ses pièces si jamais on manque de temps, mais il n’est pas à négliger pour autant.

Les trois puzzles ci-dessous correspondent à des couvertures de test différentes, mais en cas de manque de temps, on comprend que c’est la première qu’il faudra choisir.

Pour approfondir cette métaphore avec son inventrice, rendez-vous sur le blog de Janet Gregory !

Conclusion

Ici, la métaphore nous permet de dynamiser notre exigence de qualité plutôt que de laisser l’exigence de rapidité inhiber nos forces. Même en cas d’urgence, il est profitable de faire une courte pause pour orienter au mieux nos dernières heures disponibles.

Nous espérons que cette petite série d’articles vous aura plu. Nous développerons peut-être à l’avenir d’autres métaphores ; nous espérons avoir bien illustré le fait qu’il s’agit de puissants outils de pensée.

N’hésitez pas à poster vos propres métaphores dans les commentaires !

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

La métaphore en action

« Tu travailles dans le test ! Quels langages tu connais ? »

Dans les prochains articles, nous n’allons pas parler de Python, Java ou Ruby, mais d’un langage que l’on utilise tous les jours en tant que QA : le « langage naturel« . Par commodité, c’est comme ça que l’on nomme le langage que l’on parle aussi bien à la maison qu’au bureau. Mais il n’a rien de « naturel » ; nous allons au contraire nous pencher sur des manières de le modeler, de le ciseler, afin de le rendre plus efficace, plus à même de servir la qualité des projets. Nous allons pour cela nous appuyer sur le procédé de la métaphore.

Pourquoi cette figure de style en particulier ?

La rencontre de deux univers sémantiques

Le mois dernier, sur le blog de la Taverne du Testeur, Marc Hage Chahine filait une longue métaphore sur le métier du test en le mettant en parallèle avec une chasse aux champignons. L’article allie l’utile à l’agréable en poursuivant un but bien précis : donner une explication d’un processus complexe, de façon à ce qu’un enfant de 6 ans puisse la comprendre.

Le résultat est assez réussi. Pourquoi ? Parce qu’en sollicitant un univers sémantique familier, on peut faciliter la compréhension d’un autre univers plus difficile à imaginer. Autre avantage : l’interlocuteur peut poursuivre la métaphore et ainsi alimenter la discussion, beaucoup mieux que s’il n’avait pas ce point de repère. Il peut par exemple se replonger dans un embarras qu’il a déjà vécu (ramasser un caillou qu’il prenait de loin pour un champignon) pour imaginer certaines situations du métier (la frustration des QA qui tombent sur des faux positif).

Et les métaphores sont partout. D’ailleurs, elles constituent souvent le ressort comique des memes et des GIF. Un exemple ?

On dit souvent qu’une image vaut mille mots. Mais ce qui est vrai à l’écrit, avec les graphiques et les illustrations (et, donc, les GIF), l’est donc aussi à l’oral, avec les métaphores. La formulation d’une idée peut avoir un impact notable sur la façon dont le cerveau de l’interlocuteur est stimulé. Ces dernières années, des chercheurs se sont même employés à le confirmer expérimentalement.

Les effets d’une métaphore sur le cerveau

Le psychologue Rutvik Desai, dans un article paru en 2011, a par exemple observé que les verbes d’action, y compris ceux qui étaient présents dans des métaphores, faisaient réagir les zones moteur du cerveau (source [PDF]). Ce qui pourrait signifier que la phrase « Il va falloir qu’on se serre les coudes pour terminer cette campagne de test » est plus stimulante que « Il va falloir qu’on s’entraide […] ». A noter : plus une métaphore est commune, moins elle active les zones moteur du cerveau. Quand on dit qu’on saisit l’intérêt de quelque chose, l’image de la préhension est assez lointaine. C’est comme si le cerveau avait besoin d’un effet de surprise pour que la métaphore joue son rôle.

Des résultats similaires ont été obtenus par l’université d’Emory en 2012 avec des métaphores contenant des références au toucher (source). Là, par exemple, on pourrait remplacer « Votre implication m’a fait très plaisir » par « m’a fait chaud au coeur ».

On voit bien pourquoi les ouvrages de fiction nous donnent l’impression de nous évader ; l’imagination, entendue comme production d’images mentales, peut mettre en action les zones du cerveau impliquées dans les mêmes actions lorsqu’on les vit réellement. De la même manière, on peut aussi supposer que les métaphores, lorsqu’elles sont utilisées au travail (pour susciter l’attention, expliquer une idée, défendre un point de vue, motiver une équipe…) peuvent jouer un rôle intéressant.

C’est en tous cas ce que nous avons pensé en lisant l’excellent ouvrage More Agile Testing (2014) de Janet Gregory et Lisa Crispin. Le propos, truffé de métaphores intéressantes, en est d’autant plus limpide et stimulant. Nous avons donc décidé d’en sélectionner quelques-unes et de les développer dans une série d’articles.

Pour entrer dans le vif du sujet, voici la première métaphore de notre série, qui vous permettra peut-être de résoudre des situations de conflits d’intérêts.

Vélocité : le bus rapide VS le bus efficace

Problématique

Vous en avez assez de ressasser le sempiternel triangle Coût-Temps-Qualité. Dans certains contextes, vous avez besoin d’une autre image pour faire comprendre que la qualité prend du temps au début, mais qu’il serait contre-productif de la négliger.

Métaphore

Parole à David Evans, coach agile (traduit par nos soins) :

« Le management se montre parfois réticent lorsque je préconise d’écrire collaborativement les tests d’acceptation avant de se lancer dans l’implémentation de chaque story. On m’objecte généralement que cette tâche ralentirait la vélocité du développement. Je leur concède qu’en effet, en une certaine mesure, ça ralentit les choses. Cela dit, s’arrêter pour prendre des passagers ralentit aussi le trajet d’un bus. »

Il cite ensuite Kent Beck dans Test-Driven Development: By example (2002).

« Si écrire des tests d’acceptation avant de se lancer dans l’implémentation ralentit une chose, c’est bien la vitesse de création de code qui ne marchera pas. »

La métaphore du bus met en oeuvre un raisonnement absurde :

• Les transports publics sont trop lents
• S’arrêter pour prendre des passagers ralentit les transports publics
• Donc les transports publics devraient cesser de prendre des passagers.

Si l’on suit cette logique, les transports publics gagneront en rapidité mais le résultat final ne correspondra en rien à ce qui était attendu. Les usagers résilieront leur abonnement, congestionneront le centre ville avec leurs voitures personnelles et critiqueront les transports publics sur les réseaux sociaux.

Nous vous proposons de filer la métaphore d’une manière qui vous permettra maintenant de rejoindre votre interlocuteur. Il s’agit d’abonder dans son sens dans la première partie de l’argumentation, mais de proposer d’autres solutions pour accélérer le trajet du bus. La métaphore devient ici force de créativité. En se projetant dans la problématique du bus, on quitte le quotidien du projet et on suscite de nouvelles idées.

Un exemple :

• Les transports publics sont trop lents
• Un ensemble de trajets mal optimisés ralentit les transports publics
• Donc il faut s’atteler à revoir tout ou partie de ces trajets. Autrement dit : existe-t-il des étapes de notre workflow qui ralentissent le projet sans contrepartie ?

Ou encore :

• Les transports publics sont trop lents
• Le trafic des autres modes de transports ralentit les transports publics
• Donc il faut s’atteler construire des voies dédiées aux transports publics. Autrement dit : existe-t-il des facteurs extérieurs qui ralentissent le projet et que nous pourrions limiter ?

La métaphore nous a servi ici à combattre une idée allant à l’encontre de la qualité du projet, de rejoindre son interlocuteur et d’entamer avec lui une discussions sur l’amélioration des processus.

Conclusion

Les métaphores peuvent donc être utilisées pour mieux nous faire comprendre, en particulier lorsque le sujet est complexe. Mieux encore, en nous faisant voir les choses sous un autre angle, elles peuvent initier une réflexion et susciter de nouvelles idées.

Merci au Guichet du Savoir pour les recherches bibliographiques sur la confirmation expérimentale de la puissance de la métaphore ainsi qu’à Audrey Loiseau qui nous a transmis le GIF. Et merci à vous, qui posterez vos propres métaphores dans les commentaires !

Nous publierons prochainement une autre métaphore issue de More Agile Testing.