Catégorie : Méthodologie

Au cours de la présente série, nous nous attachons à étudier ce qui motive les individus à exercer le métier du test, en nous servant du framework Octalysis inventé par Yu-Kai Chou, grande référence dans le monde de la gamification.

La semaine dernière, nous évoquions 2 leviers motivationnels à l’œuvre dans le métier du test comme dans tous les autres domaines de la vie : le sens épique, et la peur de la perte. Comme deux pôles d’un même aimant, l’un nous attire vers un but ultime (une qualité logicielle irréprochable), et l’autre nous éloigne de ce qu’on redoute (une avalanche de bugs en production).

Aujourd’hui, nous abordons 2 autres leviers motivationnels parfois liés : le développement et l’accomplissement (levier 2 de l’Octaclysis de Yu-Kai Chou) et le renforcement de la créativité et le feedback (levier 3).

Ces deux leviers sont situés dans la partie haute de l’Octalysis, qui mettent la personne dans un position de maîtrise. Les mécanismes de gamification associés sont dit « White Hat » pour cette raison. Pour rappel, voici une représentation de ce framework désormais bien connu dans le monde de la gamification :

Note préalable : pour bien comprendre cet article, nous vous conseillons de lire d’abord les 2 premiers articles de cette série !

1. Pourquoi gamifier le test logiciel ? Cet article évoque les enjeux de la gamifications pour aller au-delà des clichés. L’Octalysis de Yu-Kai Chou est brièvement présentée.
2. Chevaliers de la qualité ou esclaves des anomalies ?
3. Tester pour le plaisir ou pour la gloire ?
4. Le test, ma team et mes bugs
5. Traqueurs de bugs ou explorateurs de la qualité ?

J’ai trouvé un bug, je gagne un point ?

Le 2^ème levier motivationnel présenté par l’Octalysis est le développement et l’accomplissement. On pourrait dire que c’est la partie visible de l’iceberg de la gamification. Ce levier est actionné par les fameux PBL (Points, Barres de progression et Leaderboards, ou classement des joueurs).

Ces ressorts sont intégrés à pas mal d’expériences numériques, avec plus ou moins de succès. Vous avez certainement le souvenir d’un site qui vous a décerné un badge suite à une action qui vous semblait totalement triviale ; un encouragement vide de sens, qui a peut-être même contribué à vous désengager de l’expérience.

Quoi qu’il en soit, et même si les mécanismes de gamification sont parfois maladroitement implémentés, le besoin de développement et d’accomplissement sont bien réels. Cela nous motive à nous améliorer, franchir des étapes, concrétiser des réussites.

Dans le monde du test, ce levier motivationnel peut nous pousser à :

• Obtenir une certification, ISTQB ou autre
• Ouvrir le plus de tickets d’anomalie possible (cela n’est pas forcément une bonne chose d’ailleurs, cf. les métriques de la mort…)
• Trouver le courage d’exécuter encore 10 tests avant de rentrer chez soi complètement HS
• Mériter un compliment de la part d’un membre de l’équipe que l’on estime particulièrement
• Trouver le plus vite possible un bug bloquant pour débloquer du temps additionnel pour réaliser les tests (une suggestion d’un participant de la Paris Test Conf, merci à lui !)

Certaines interfaces déclenchent ce levier, en nous montrant par exemple des graphiques de « reste à faire » qui nous poussent à abattre un maximum de travail… pour la satisfaction de faire bouger ces graphiques.

Ce levier est identifié par Yu-Kai Chou comme un levier de motivation extrinsèque : on effectue des actions non parce qu’elles sont plaisantes, mais dans le but d’obtenir des gains extérieurs à ces actions elles-mêmes.

Par exemple, ce levier est actionné quand on se plonge dans la fastidieuse lecture d’un support de formation, parce que l’on s’imagine avec bonheur en train de brandir fièrement notre certification. La motivation ici est bien extrinsèque, comme pour tous les leviers situés sur le côté gauche de l’Octalysis.

Les mécanismes de gamification sont nombreux pour actionner ce levier, et comme on parle de motivations extrinsèques, ils présentent l’avantage de pouvoir s’appliquer dans le cadre de situations dont le potentiel de « fun » n’est pas forcément le plus élevé.

Un des participants de la Paris Test Conf rapportait qu’il organisait des bugs bounties dans son équipe, et que le bug le plus rigolo était récompensé par des sucreries. Une super idée si le contexte, votre équipe, l’ambiance générale et les objectifs de l’équipe le permettent !

En effet, chaque chose en son temps : quelle émotions souhaitez-vous faire ressentir, à qui, et à quel moment ? Quel est le but de votre démarche de gamification ? C’est bien cette question qui doit vous obséder en premier lieu.

Ce magique état de flow

De l’autre côté de l’axe vertical de l’Octalysis se trouve le 3^ème levier : le renforcement de la créativité et le feedback. Le nom de ce levier n’est pas forcément le plus simple à comprendre au premier abord ! Il désigne tout simplement le plaisir de faire ce que l’on fait, un plaisir intrinsèque donc. Ces moments où on se sent à la fois très concentrés sur notre tâche et heureux de l’effectuer. On en retire un feedback immédiat ou peu différé ; on voit par soi-même le résultat de notre action menée en toute liberté.

Dans le monde du test, on peut penser à des moments comme :

• Quand on réalise des tests exploratoires et que l’on saute d’une hypothèse à l’autre, que l’on prend plaisir à décortiquer l’application
• Quand on se plonge dans les spécifications à l’affût de la moindre ambiguïté, et que notre concentration est toute à l’imagination de la solution demandée
• Quand on automatise les tests en profitant de l’aisance apportée par des heures et des heures de pratique. Ca ne vous rappelle rien ?

Il est plus difficile d’activer ce levier, car il faut pour cela faire en sorte que l’activité proposée soit en tant que telle captivante et permette de solliciter la créativité de la personne. L’autonomie, le sentiment de liberté, semblent en tous cas être des pré-requis : comment développer sa créativité quand quelqu’un nous observe en permanence ou nous donne à tout moment la marche à suivre ?

Yu-Kai Chou met l’accent sur ce levier en indiquant que, puisqu’il est positionné à la fois dans la zone « White Hat » (en haut de l’Octalysis) et dans la zone de motivation intrinsèque, il constitue l’angle d’or de l’octogone.

Associer les leviers

Il est intéressant de constater que les leviers 2 et 3 peuvent se faire écho. Pendant les moments où la créativité est renforcée, le feedback que l’on peut observer peut s’accompagner de métriques qui nous font pencher un peu vers le levier 2. De même, on peut imaginer qu’à la fin d’une session de test exploratoire, on peut ressentir une sensation d’accomplissement.

Dans le prochain article, nous évoquerons les leviers 4 et 5, positionnés sur l’axe horizontal, en équilibre entre Black Hat et White Hat. A bientôt !

Au cours de la présente série, nous nous attachons à étudier ce qui motive les individus à exercer le métier du test, en nous servant du framework Octalysis inventé par Yu-Kai Chou, grande référence dans le monde de la gamification.

1. Pourquoi gamifier le métier du test logiciel ?
2. Chevaliers de la qualité ou esclaves des anomalies ?
3. Tester pour le plaisir ou pour la gloire ?
4. Le test, ma team et mes bugs
5. Traqueurs de bugs ou explorateurs de la qualité ?

Comme indiqué dans l’article précédent de cette série, la raison pour laquelle nous réalisons toute action de notre vie quotidienne est toujours liée à un ou plusieurs leviers motivationnels. Yu-Kai Chou, expert en gamification, a classé les 8 leviers fondamentaux de tout être humain au sein d’un framework nommé Octalysis. En voici une représentation :

Avant d’entamer une démarche de gamification, et pour éviter de tomber dans les travers courants de cette pratique, il est important d’avoir en tête ces 8 leviers, qui vont permettre de choisir les meilleurs mécanismes en fonction de l’effet recherché.

Les leviers positionnés vers le haut de l’octogone sont des leviers qui mettent la personne (ou le joueur, l’utilisateur…) dans une position de maîtrise ; elle peut librement s’adonner à l’expérience et en retirer des bienfaits qui reflèteront son talent. Les leviers positionnés vers le bas sont au contraire ceux qui mettent la personne dans une position de passivité, voire de soumission. Ces leviers prennent racine dans sa vulnérabilité.

Le présent article présente deux leviers motivationnels opposés sur le frameworks Octalysis de Yu-Kai Chou : le sens épique ou vocation (levier 1, tout en haut), et la peur de la perte et l’évitement (levier 8, tout en bas).

Le test logiciel, une vocation ?

Le 1^er levier motivationnel identifié par Yu-Kai Chou est le sens épique ou la vocation.

Il s’agit de l’envie de contribuer à quelque chose qui dépasse notre propre personne. Cela peut être l’envie de protéger notre environnement, d’aider son prochain, d’assurer le bien-être de sa famille, de promouvoir l’équipe de cricket de son quartier, bref, de servir une cause, quelle qu’elle soit.

Dans les jeux vidéo, ce levier est souvent activé dès le début de l’aventure. Par exemple, quand on incarne Mario, on apprend rapidement que l’on va devoir sauver la princesse Peach. Un récit épique vient mettre en tension le joueur, lui donner envie de poursuivre un objectif, éveiller sa vocation.

Peut-on travailler dans le test par vocation ? C’est une question intéressante, soulevée il y a quelques temps dans un article sur le blog LyonTesting. Même si, quand nous étions enfants, nous ne rêvions pas de travailler dans le test, il y a quelques aspirations épiques qui peuvent nous animer désormais au quotidien :

• Contribuer à la qualité d’un applicatif que l’on considère vertueux
• Contribuer à la santé d’une entreprise dont l’impact nous semble positif
• Contribuer au succès d’une équipe dont on apprécie les membres
• Contribuer au rayonnement, à l’enrichissement et à la renommée du métier du test

En fonction des environnements de travail, du contexte général et de la personnalité du testeur, ces aspirations vont prendre une place plus ou moins importante. Si on le jugeait insuffisamment activé, la gamification pourrait permettre de solliciter davantage ce levier.

Ce 1^er levier motivationnel est par excellence un levier qui met en valeur la personne, qui la rend véritablement actrice de son succès ; en anglais, cette position est désignée sous le terme à peu près intraduisible d’« empowered ».

Ces motivations positives peuvent nous donner l’impression d’accomplir des réalisations grandioses dans un esprit chevaleresque qui nous met en valeur. Mais le levier opposé n’est jamais bien loin…

La peur au ventre du testeur

Le 8^ème levier de l’Octalysis est celui de la peur de la perte et de l’évitement.

Quand on tient d’une main un plateau rempli de verres en cristal, c’est ce levier qui nous pousse à la précaution. Il nous aide aussi à y aller mollo sur les chips à l’apéritif (ne pas perdre l’appétit, ne pas perdre la ligne), ou encore à respecter les limites de vitesse (ne pas perdre les points de son permis).

Dans une très grande partie des jeux, les biens que l’on possède en début de partie ou que l’on accumule au fil du temps peuvent nous glisser des mains à tout moment, que ce soit suite à un mauvais calcul, un coup de malchance, ou la fourberie de ses adversaires. Si ce n’est pas le cas, du moins a-t-on envie de gagner la partie, et œuvre-t-on du mieux qu’on peut pour ne pas obtenir la dernière place.

Ce levier, cette peur de perdre, est peut-être la seconde nature des testeurs. Récapitulons : au quotidien, en tant que testeurs, que risque-t-on de perdre ? Ou formulé de manière plus positive : que cherche-t-on à protéger ?

• Un certain niveau de qualité. Des tests insuffisants peuvent laisser passer des bugs sur les nouvelles fonctionnalités ainsi que des régressions. Quel déshonneur pour l’équipe et en particulier (culturellement, c’est encore assez ancré) pour les personnes ayant testé l’applicatif…
• La confiance de ses collègues. Personne n’est parfait et l’erreur est humaine, certes, mais la petite voix dans l’esprit d’un testeur peut parfois lui souffler qu’il se doit d’être irréprochable pour que sa parole continue d’être écoutée.
• Un temps précieux. Trouver un bug bloquant dans les dernières heures allouées à une recette peut signifier que l’on a mal priorisé et organisé ses tests ; c’est bien sûr moins pire que de laisser un bug aller en production, mais cela reste frustrant et cela signifie une perte de temps pour l’ensemble de l’équipe.

Liens entre leviers motivationnels

Il est intéressant d’observer les liens qu’il existe entre les motivations positives présentées plus haut, et les motivations négatives liées au levier n° 8. Il existe également des liens entre ces motivations et le levier n°5 : influence sociale et connexion. Nous visons des objectifs non seulement pour nous-mêmes, mais bien souvent aussi pour en faire profiter d’autres personnes. Inversement, un échec vient aussi avec un certain regard que les autres pourraient nous porter.

Le levier n° 8 s’oppose aussi bien souvent au levier n° 4, celui de la propriété et de la possession : les biens que l’on amasse on a plaisir à les posséder et les utiliser, et on fait tout pour ne pas les perdre. Si on prend la peine de remonter 10 anomalies, on peut à la fois se sentir fier de ces 10 rapports de bugs, et on ressentira une grande frustration si l’outil de ticketing plante et que ce travail est effacé.

Et la gamification dans tout ça ?

A la suite de Yu-Kai Chou, nous choisissons ici de parler des leviers motivationnels en premier. Ces leviers sont à activer ou non en fonction de l’effet rechercher. Quel but est recherché par la démarche de gamification de l’activité de test ?

S’il s’agit de (re)donner du sens au travail des testeurs, le levier 1 pourrait être activé avantageusement. Pourquoi teste-t-on, quelle est notre raison d’être ? Chacun sait-il pourquoi son travail est essentiel ?

S’il s’agit d’accroître leur vigilance, le levier 8 pourrait offrir des perspectives intéressantes. Comment symboliser le coût de la non-qualité ? Comment augmenter le sentiment de responsabilité et donner envie de protéger la qualité ?

Dans les prochains articles seront présentés les 6 autres leviers motivationnels, qui vous permettront d’avoir une vue d’ensemble sur ce qui peut motiver les testeurs à se surpasser.

A très vite pour le prochain article, qui parlera accomplissement, développement et créativité !

En 2020, nous avons proposé une intervention à la Paris Test Conf sur un sujet qui nous tient à cœur depuis des années : la gamification. Vous l’avez d’ailleurs peut-être remarqué au fil des articles de ce blog : nous avons lancé un bingo permettant d’échanger sur les échecs fréquents lors des recettes, un jeu de plateau permettant de terminer un projet en beauté, ou encore un jeu de cartes permettant de sensibiliser aux tests unitaires.

Nous appréhendons la gamification comme l’art d’implémenter notamment dans notre activité professionnelle des ressorts motivationnels tels que l’on peut en trouver dans les jeux.

Si vous voulez vous replonger dans l’ambiance de la conférence, vous trouverez le replay en fin d’article. Ce sera d’ailleurs l’occasion de découvrir bien d’autres talks, animés par des personnes aussi talentueuses que passionnées ! Si vous préférez lire, vous trouverez au sein de cette série d’articles tous les points les plus importants de la présentation.

1. Pourquoi gamifier le métier du test logiciel ?
2. Chevaliers de la qualité ou esclaves des anomalies ?
3. Tester pour le plaisir ou pour la gloire ?
4. Le test, ma team et mes bugs
5. Traqueurs de bugs ou explorateurs de la qualité ?

Merci à toute l’équipe d’organisation de la Paris Test Conf, en particulier à Diana Marimoutou pour ses bons conseils et son suivi assidu, ainsi qu’au public qui a bravé le sommeil pour s’adonner à la passion du test !

Gamification : au-delà des clichés

Le Robert définit la gamification (ou en bon français, ludification) comme suit : « Application de mécanismes ludiques à ce qui ne relève pas du jeu. » Une définition qui peut donner lieu à des interprétations hâtives : pour une gamification réussie, suffit-il d’ajouter des badges et des points à tour de bras ? Suffit-il d’ « appliquer », comme on applique une couche de peinture, un semblant ludique à une activité rébarbative « qui ne relève pas du jeu » ? Non.

Tout au long de cette intervention, nous nous avons plutôt pris appui sur l’approche définie par Yu-Kai Chou, référence du domaine, et à l’origine d’un schéma bien pratique pour concevoir et analyser des expériences gamifiées.

La gamification n’est pas ce que vous pensez !

Pour Yu-Kai Chou, la gamification ne devrait pas forcément porter ce nom ; il lui préfère l’expression de « human-focused design ». La raison pour laquelle on parle de jeu, c’est qu’un jeu doit obligatoirement être suffisamment motivant en tant que tel pour qu’une personne ait envie d’y consacrer du temps. Dès qu’on ne s’amuse plus, on s’arrête de jouer, car il n’y a aucun besoin de jouer à un jeu. La gamification consisterait donc à rendre une expérience aussi amusante et engageante qu’un jeu, le jeu étant donc une simple analogie.

Cette expression de « human-focused design » s’oppose au « function-focused design », qui se concentre avant tout sur les résultats opérationnels. Cependant, Yu-Kai Chou ne perd pas de vue ces résultats. Vous pourrez par exemple découvrir sur son site une liste de 90 exemples de gamification ayant démontré leur ROI.

Alors, comment enrichir la pratique du test et la rendre plus engageante, plus orientée vers les motivations humaines ?

Test et gamification

Un constat pour commencer : aux yeux des outsiders, le test logiciel est une activité qui souffre d’une assez piètre réputation. Des exemples ?

• « Ce doit être ennuyeux, répétitif, rébarbatif ! »
• « Concevoir et développer une application, ce doit être beaucoup plus motivant… car le test n’est pas une activité créative. »
• « Le métier du test, c’est pour les personnes qui n’ont pas réussi à devenir dev. »

En toute honnêteté… il serait faux d’ailleurs de récuser en bloc la première affirmation, car il peut arriver de se lasser d’exécuter de longues et monotones campagnes de test. Alan Richardson a même écrit un poème sur le sujet afin d’inciter à toujours tester comme si c’était la première fois. Ce n’est pas une mince affaire !

Le test logiciel est donc une activité qui gagnerait à être (ré)enchantée. Que ce soit pour attirer de nouveaux talents dans cette profession, pour engager nos équipes autour de la qualité, ou tout simplement pour rester, soi-même, dans un état d’esprit positif.

Des leviers motivationnels universels

Yu-Kai Chou considère que tout ce que nous faisons, nous le réalisons parce qu’un ou plusieurs de nos 8 leviers motivationnels sont enclenchés. Ces leviers étant les suivants :

1. Sens épique et vocation
2. Développement et accomplissement
3. Renforcement de la créativité et feedback
4. Propriété et possession
5. Influence sociale et connexion
6. Rareté et impatience
7. Imprévisibilité et curiosité
8. Peur de la perte et évitement

Nos deux hypothèses :

• Tous ces leviers sont actionnés par le métier du test.
• Prendre conscience de ces leviers peut nous aider à nous développer professionnellement et à améliorer nos pratiques.

Ces 8 leviers seront donc présentés, deux par deux, dans les 4 prochains articles à venir, avec à chaque fois des exemples concernant le métier du test logiciel.

Bonne lecture ! Et si vous souhaitez plutôt visionner le replay de la conférence, le voici :

« Maintenant, on va automatiser les tests. »

La première fois que vous avez entendu cette phrase, vous avez certainement pensé que ce serait une bonne idée et que cela permettrait de consolider durablement la qualité des applicatifs concernés. Dans la plupart des cas, vous aviez raison. Mais à ce moment-là, pensiez-vous déjà à toutes les émotions que vous ressentiriez au cours de ce périple ?

Réjouissantes, mordantes, bouillonnantes, subtiles ou dévastatrices, on en voit de toutes les couleurs. En l’espace d’un quart d’heure, on peut passer de l’impression d’être une andouille à celle d’être un génie. Et vice-versa. Ce n’est pas de tout repos, surtout au début !

Un petit point sur la gamme d’émotions associée à l’automatisation des tests, car contrairement à nos bien aimés tests auto, on n’est pas des robots !

Cet article aborde 4 types d’émotions :

• Celles qu’on ressent immanquablement au début, quand on découvre l’automatisation
• Celles qui nous accompagnent dans la routine
• Celles que l’on ressent dans les moments où on dresse des bilans
• Les sonnettes d’alarme qui accompagnent les crises !

Frémissements des débuts

Emerveillement

C’est une des premières émotions qu’on peut ressentir quand on démarre en automatisation des tests. C’est un peu la même qu’on a eue, des années et des années plus tôt, quand on a joué pour la première fois avec une voiture télécommandée.

Pas la peine de s’en cacher, c’est merveilleux de voir un navigateur s’ouvrir tout seul et exécuter sagement tout ce qu’on lui a demandé de faire !

Fierté

Jusqu’alors, ça vous ennuyait qu’on vous qualifie de « testeur manuel » ? Il y a de quoi ; les activités de test nécessitent certes des mains (quoi que…) mais c’est un poil réducteur de réduire un testeur à ce qui lui permet de cliquer sur sa souris. On devrait peut-être parler davantage de « test cérébral »…

Mais bref, dans certains contextes, acquérir la casquette de l’automatisation peut sembler prestigieux.

On ne va pas bouder son plaisir, il y a de quoi ressentir de la fierté, tant qu’on se prémunit contre les maladies des tests automatisés ! Et tant qu’on se souvient que l’automatisation n’est pas une fin en soi, ni une raison de snober les collègues qui préfèrent développer d’autres compétences de test.

Confusion

« Pourquoi ça ne marche pas ? »

« Et surtout, pourquoi là ça remarche ? »

Bienvenue dans le monde occulte de l’automatisation des tests. Pour le meilleur et pour le pire, ça vous arrivera régulièrement et vous n’y comprendrez rien.

Si votre confusion a raison de votre bonne humeur et menace de vous poursuivre en-dehors du travail, prenez le temps de vous attarder dans la section « Pulsations des méandres ».

Illumination

C’est vrai, on aurait pu dire « Inspiration ». Mais il y a des moments où, sans crier gare, la solution que l’on cherchait s’impose enfin à nous. Elle nous délivre en une seconde d’un problème d’automatisation qu’on se traînait depuis des jours. Et dans ces moments-là, c’est toute notre âme qui se sent illuminée.

C’est beau, non ?

Bourdonnements de la routine

Flow

Vous êtes tellement à votre ouvrage que tout ce qui vous entoure disparaît. C’est un état exceptionnellement agréable, qui vous semble constitué de 90 % de concentration profonde et de 10 % d’euphorie. Profitez-en, vous êtes au max de votre productivité !

Attention toutefois, ce qui peut vous manquer dans ces moments où vous faites corps avec votre tâche, c’est votre esprit critique vis-à-vis de cette tâche. Avez-vous vraiment besoin d’automatiser tous ces comportements dans les moindres détails ?

Amusement

Nouvelle fonctionnalité, nouveau challenge ! Parfois, il vous suffit de jeter un œil aux spécifications pour que vous sachiez tout de suite : « Là, on va bien se marrer ! »

Et le mieux, c’est que vous pensez cela sans la moindre ironie.

Appréhension

Au moment d’appuyer sur le bouton de lancement, vous craignez que vos tests se cassent la figure, que les faux positifs se multiplient et que votre beau projet d’automatisation soit discrédité. Respirez un coup, rien n’est fait, et quand bien même, il faut voir au-delà du faux-positif… On y reviendra dans un prochain article !

Ennui

Le mythe : les tests automatisés vont abolir l’ennui du quotidien des testeurs, en leur épargnant de longs et fastidieux tests de non-régression.

Le scoop : automatiser les tests peut également être ennuyeux !

Au quotidien, il est aussi pertinent qu’épanouissant de jongler entre différentes activités de test : revue des spécifications, conception des scénarios de test, gestion des bugs, organisation d’ateliers, sessions de test exploratoire, veille technologique… Pour une bonne santé mentale, testez équilibré !

Gratitude

Il arrive que vous ayez besoin de tel ou tel bout de code qui fasse telle ou telle chose. Et là, vous vous rendez compte qu’il existe déjà, vous l’avez développé il y a quelques mois et vous l’aviez complètement oublié.

Frustration

Plus vite, plus vite !!! Qu’il est frustrant de voir un test automatisé exécuter certaines tâches plus lentement qu’un humain.

Double peine : non seulement vous vous faites du mal à attendre qu’il se déroule, mais vous perdez aussi de votre précieux temps ! Certaines fois, il n’y a rien à faire pour que ça aille plus vite, alors profitons simplement de pouvoir tester d’autres choses en parallèle.

Jubilation

L’automatisation des tests permet de trouver des bugs marrants, que ce soit lors de l’exécution de ces tests ou lors de leur conception. Ne boudez pas ce plaisir, au contraire c’est important que tout le monde sache que l’automatisation permet aussi cela. Vous pouvez trouver un moyen de conserver la liste des bugs que vous avez trouvés grâce à l’automatisation des tests, par exemple une métadonnée associée aux tickets d’anomalies. Cette liste pourra être dégainée en temps voulu.

Enthousiasme

Quoi de plus enthousiasmant que d’apprendre de nouvelles techniques et de les appliquer avec succès ? Cela fait aussi partie du quotidien quand on automatise des tests. Les technologies étant en constante évolution, vous aurez toujours de nouveaux chemins à explorer.

Soulagement

Ces derniers temps, les tests autos vous ont malmenés. Vous avez dû gérer une liste longue comme le bras de scripts KO, qui n’était pas due à des bugs réels mais à une inadéquation entre les automates et le système à tester. Un orage de faux positifs, ça ne fait jamais plaisir, même quand « c’est normal » (changement dans l’interface, modification des règles de gestion…). Alors c’est un profond soulagement que vous ressentez le jour où vous relancez vos tests, et que tous se déroulent correctement.

Vibrations des bilans

Tristesse

Vous avez passé un temps fou à automatiser cette suite de tests, vous y avez mis tout votre cœur et ça marchait du tonnerre.

Mais la sentence est tombée : la fonctionnalité testée va disparaître. Vos merveilleux automates ne pourront plus « tourner ». Respirez par le ventre et soyez philosophe, ça fait partie des déconvenues possibles !

En revanche, par pitié, ne commentez pas vos vieux bouts de code désormais inutiles. Supprimez-les, ça fait partie du deuil ça conservera propre votre projet d’automatisation.

D’ailleurs, ils seront toujours quelque part… non non, pas dans votre coeur, mais dans votre logiciel de gestion de versions !

Satisfaction

Mmmmmh, qu’il est doux de profiter du ronronnement bien huilé des tests auto. Vous voyez la liste des cas de test qui s’exécute et vous pensez « C’est moi qui ai fait ça. » Profitez de ces instants, vous savez qu’il y en aura d’autres moins agréables !

Sérénité

C’est une émotion à la fois discrète et très précieuse. Si, en lançant vos tests automatisés, vous ressentez de la sérénité, c’est que vous avez pris confiance en vos scripts, et que vous savez qu’ils vont vous apporter ce que vous attendez d’eux. Félicitations.

Sentiment de maîtrise

Ça y est, vous connaissez la chanson, vous l’avez jouée tant et tant de fois. Vous pourriez développer vos tests sans regarder l’écran (non, quand même pas). Vous savez assez précisément combien de temps vous prendra une tâche avant de la commencer. Vous vous sentez à l’aise, vous avez une bonne productivité, profitez-en !

Cependant, pas question de laisser ce sentiment vous empêcher d’explorer de nouvelles pratiques où vous serez moins à votre aise.

Joie

En prenant un peu de recul, vous constatez que l’automatisation a bel et bien accéléré la cadence de vos tests, que vous êtes maintenant en mesure de tester plus en profondeur, plus intelligemment, et de fournir toujours plus de retours intéressants sur la qualité. Mission accomplie.

Mettez tout en œuvre pour que cette joie n’ait pas de fin !

Pulsations des méandres

Désespoir

Quand ça marche pas, ça marche pas.

En vous lançant dans l’automatisation des tests, vous traverserez certainement de grands moments de solitude. Il faut s’y préparer ! Voici quelques situations que vous rencontrerez certainement :

• Vous voulez interagir avec un certain élément d’une page web, mais vous ne trouvez aucun moyen de le faire !
• Un script de test fonctionnel fonctionne une fois sur deux. Ou sur trois.
• Les outils et/ou les dépendances que vous utilisez ne s’entendent pas, à cause d’un problème de compatibilité, ou autre couac que vous ne pensez pas être en mesure de résoudre.
• Ça marche dans le tuto, ça devrait marcher chez vous aussi !!!

Parfois (et de plus en plus souvent avec le temps), vous arriverez à vous en dépatouiller. Mais d’autres fois, ce ne sera pas le cas. Des remèdes ?

• L’entraide. Si dans votre organisation vous êtes en solo sur les tests automatisés, vous pourrez tout de même compter sur la communauté des testeurs (comment, vous n’êtes pas encore membre du groupe LinkedIn Le métier du test ?) et sur des sites tels que StackOverflow. N’hésitez pas à créer un compte et à poser vos questions, un jour ce sera à votre tour de « sauver la vie » de quelqu’un !
• La communication. Si ça ne marche pas, parlez-en, même si personne n’est en mesure de vous aider. Si une tâche d’automatisation vous demande trop de temps en recherche, c’est peut-être qu’il vaut mieux ne pas l’automatiser tout de suite, que quelqu’un d’autre s’en charge. Ça ne sert à rien de se flageller dans son coin, vous allez juste vous faire du mal.

Honte

Wow, autant de tests en échec ? Le rouge vous monte aux joues. Des faux positifs, ça doit être une montagne de faux positifs…

Vraiment, vous avez honte avant de savoir ce qui s’est vraiment passé ? Si ça se trouve, il s’agit d’une vraie anomalie ! Au fond c’est pour détecter des anomalies que vous avez automatisé ces tests, vous vous souvenez ?

Sentiment d’absurdité

Votre mission est d’automatiser des tests pour gagner du temps, pour faire plus de test cérébral. Mais depuis quelques temps, votre métier consiste davantage à maintenir de vieilles breloques supposément automatisées, qu’à fournir des informations à forte valeur ajouté sur la qualité de ce que vous testez. Ça ne tourne pas rond, tout ça…

Réagissez, ce sentiment d’absurdité vous informe que quelque chose doit changer !

Sentiment d’injustice

Vous venez d’atteindre le niveau le plus décadent de l’anthropomorphisme. Au fond de vous, vous savez bien que les tests auto n’ont pas de conscience, et qu’ils ne se mettent pas en échec pour vous faire souffrir.

Comme vu précédemment, pas la peine de vous laisser sombrer dans de telles considérations, prenez une pause, visiblement vous en avez besoin.

Conclusion

Le but de cet article est double :

• Que nous prenions conscience de la place que les émotions occupent dans nos activités d’automatisation des tests, et
• Que nous voyions mieux la valeur qu’elles peuvent nous apporter. En prenant un peu de recul, nous pouvons voir ces émotions comme des indicateurs. Si vous souhaitez donner le meilleur à un projet, vous gagnez à cultiver les émotions qui vous font réussir. Vous gagnez aussi à écouter certaines émotions qui vous font souffrir, si elles vous donnent des informations sur ce qui devrait être changé. Quant aux autres… même si c’est plus facile à dire qu’à faire… nous espérons que vous apprendrez à lâcher prise et les laisser partir.

Bon courage à toute la communauté des QA qui automatisent sans relâche et vivent ce faisant autant d’émotions diverses ! Il y a bien des cœurs qui battent derrière ces austères scripts.

Ce qu’apporte le crowdtesting ? En tout premier lieu, un entraînement d’élocution, car c’est un des mots les plus rugueux que vous aurez à prononcer dans votre vie (mais pour votre bonheur, vous trouverez dans cet article des propositions alternatives plus francofluides).

Aujourd’hui, pour répondre à cette question, nous nous plaçons du côté des éditeurs. Cela regroupe à la fois, certes, les sociétés éditant des logiciels, mais aussi les organisations ayant fait développer un site ou une appli, en interne ou par un prestataire.

Vous avez déjà testé votre produit en interne et tous vos cas passants… passent. Et là, vous envoyez ces mêmes scénarios à une plateforme de crowdtesting (comme Testeum !), et vous découvrez que la validescouade ouvre des bugs sur ce qui fonctionnait à merveille. Quelle est cette sorcellerie ? Pourquoi les crowdtesteurs découvrent-ils des bugs que vous n’aviez pas vus ?

Les crowdtesteurs vous fournissent des paires d’yeux neufs

A force de voir votre produit à longueur de journée et à longueur d’année, votre regard s’est émoussé. Un élément du site vous semblait ambigu, étrange ou disgrâcieux au premier regard, puis vous avez pris l’habitude de le voir. Vous avez perdu la volonté de demander un changement. Le phénomène qui est à l’œuvre ici est le biais de simple exposition : il suffit de se trouver en présence d’une chose pendant assez longtemps pour que cette chose nous semble appréciable.

Les crowdtesteurs sont libres de ce biais, ils n’ont jamais vu votre produit et ne se gêneront pas pour vous dire tout ce qui les tracasse. Leur avis pourrait même avoir plus d’impact. Nul n’est prophète en son pays, et bien souvent, ça vaut aussi pour les remarques d’UX…

Les crowdtesteurs ont la motivation que vous n’avez plus

Même si des tests automatisés ont été rédigés pour votre applicatif, il y a certainement des tests de régression que vous continuez de jouer à la main, version après version, sprint après sprint si vous travaillez en Scrum. Et ces scénarios-là, vous en avez assez de les ruminer encore et encore.

Les crowdtesteurs ont la fougue de la découverte, la même que vous aviez la première fois que vous avez posé les yeux sur le produit. Le scénario qui désormais vous semble insipide et sans surprise, ils le joueront avec une attention que vous ne pouvez plus fournir aussi spontanément.

Les crowdtesteurs vous prêtent leur matériel (mais il s’appelle revient)

C’est une des promesses majeures du crowdtesting : déclencher des tests tout-terrain. On pourrait parler d’immensitest, ou de diversitest. Vous pourriez tomber sur :

• Andrea, 18 ans, alternant, qui testera sur son vieux PC et une version obsolète de Chrome avec la connexion ADSL de sa résidence étudiante en Angleterre.
• Betty, 68 ans, retraitée, qui testera sur sa tablette Samsung de seconde main dans le TGV avec la 3G.
• Chafia, 34 ans, graphiste, qui testera sur son iPhone flambant neuf avec la Wifi d’un café en Australie.

Vous allez découvrir avec surprise que votre menu sandwich se comporte bizarrement sur certains devices, ou que votre panier se charge décidément trop lentement. Et tant d’autres choses encore…

Les crowdtesteurs ont chacun leur corps

Ça vous semble incongru de le rappeler ? Quand on imagine des tests IHM, on pense énormément au « I », mais pas assez au « H ». Or, dans notre exemple précédent :

• Andrea est daltonien, et les graphiques bariolés que vous affichez si fièrement sur votre site vont souverainement l’agacer. Ne vous inquiétez pas, il vous expliquera tout dans son rapport de bug.
• Betty aime bien en rire en disant qu’elle a « des gros doigts ». Pourtant, elle ne manquera pas de vous expliquer quels sont les éléments qu’elle a du mal à cliquer sur votre interface.
• Chafia est entourée par les clients du café qui parlent et chahutent sans discontinuer. Elle vous signifiera que vos contenus vidéos sont impossibles à consulter dans ces moments-là… à moins que vous n’y ajoutiez des sous-titres.

Votre utilisateur idéal est une personne à l’aise avec l’informatique, valide, 100 % en forme, qui a du super matos, une super connexion, un navigateur à jour, du temps devant lui, un environnement calme et un tempérament patient et bon public. Vous ne risquez pas de le rencontrer de sitôt. En attendant, faites plutôt appel à des « gens de la vraie vie », qui massifouineront votre produit avec les moyens du bord.

Les crowdtesteurs sont aussi fous que vous

Plus on est de fous… plus il y a de folies. Dans votre équipe, certaines personnes remarquent immédiatement quels éléments d’une page web ne sont pas bien alignés. D’autres ne jurent que par l’orthographe et traqueront la moindre espace insécable. C’est grâce à cette diversité de lubies que votre qualité se consolide au fil du temps.

Les crowdtesteurs ont aussi leurs propres lubies. Un background SEO, et vous voilà avec des suggestions d’amélioration de vos titres. Un penchant pour l’édition, et vous récoltez des remarques sur les polices et les espacements de lignes.

Le crowdtesting, c’est comme une boîte de chocolats, il y a des saveurs de bugs à découvrir que vous n’auriez jamais imaginées.

Récapitulons : les crowdtesteurs vous offrent des paires d’yeux neufs, la motivation du commencement, des environnements et des profils utilisateurs inédits, et enfin des angles d’attaque que vous n’auriez pas anticipés. Voilà les principales raisons pour lesquelles les bugs issus du crowdtesting sont différents de ceux que vous trouvez déjà avec brio en interne. Si vous en avez constaté d’autres, dites-nous lesquelles en commentaire !

A l’heure où cet article est publié, une partie importante de la population mondiale vit confinée. Le coronavirus est de toutes les conversations, il modèle notre quotidien et habite nos pensées à tout moment. Difficile de relire les 7 principes généraux du test logiciel sans que le parallèle avec la situation actuelle ne saute aux yeux…

Cet article est aussi l’occasion pour toute l’équipe Hightest de vous souhaiter bon courage en cette étrange période, où que vous soyez.

Les tests montrent la présence de défauts

Sur un million de dépistages, 1 dépistage positif suffit à signifier que le virus est encore là. Cependant, si tous les dépistages sont négatifs, cela ne signifie pas que le coronavirus a disparu de la population globale.

Les tests exhaustifs sont impossibles

On ne peut pas dépister simultanément 7 milliards d’êtres humains et analyser toutes les surfaces potentiellement infectées du monde entier. Par ailleurs, d’autres tests seraient envisageables : vérifier la présence du virus dans l’air, vérifier tous les animaux pouvant en être la source, tester la transmission sur les pingouins…

Tester tôt

Dépistage rapide ➔ prise en charge rapide ➔ contagion mieux maîtrisée. Ce principe a été mis en application avec succès à Singapour. Les Etats-Unis au contraire ont montré le contre-exemple.

Regroupement des défauts

Certaines zones géographiques sont beaucoup plus touchées que d’autres, comme l’indique cette carte.

Paradoxe du pesticide

Sur une population d’un million de personnes, si on dépiste à chaque fois les 100 000 mêmes personnes, on risque fort de passer à côté de malades.

Les tests dépendent du contexte

A l’heure actuelle, il ne serait pas pertinent de faire dépister les astronautes de retour de l’ISS.

L’illusion de l’absence d’erreur

Jeudi 19 mars en Nouvelle-Calédonie, nous étions rassurés : nous pensions qu’il n’y avait aucun cas parce aucun n’avait encore été détecté ; en réalité, il y en avait déjà 2.

Nous souhaitons encore bon courage à toutes les personnes qui nous lisent ainsi qu’à leur entourage personnel et à leurs collègues. Prudence avant tout.

Crédit image : benjamint444

Dans l’article précédent, nous proposions quelques ressources pour (mieux) appréhender le Behavior Driven Development. Mais quid de l’implémentation de cette méthodologie dans le cadre de projets dont le code historique (ou legacy) représente une part très importante ? Florent Vaution, Software QA Manager chez Ouest-France, a tenté l’expérience et présente ici son témoignage.

Origines de la démarche

Quel contexte de départ ?

A mon arrivée chez Ouest-France il y près de 3 ans, un parcours d’intégration est organisé et me permet de rencontrer différents acteurs qui gravitent autour du SI : métiers du commerce/marketing, métiers du numérique, journalistes, membres de la DSI. A cette occasion, je fais rapidement deux constats :

• Le premier est qu’il y avait un manque de confiance des équipes métiers vis à vis de la production de la DSI. C’est pourquoi les équipes métiers vérifiaient systématiquement tous les cas d’usages, nominaux ou non, sur les produits livrés. Et, bien souvent, dès qu’un problème survient, les équipes de la DSI étaient pointées du doigt.
• Le second est que les membres de la DSI se désengagent petit à petit de la qualité de leur production. Ils souffrent de cette défiance et du manque de sens par rapport à ce qu’on leur demande de produire.

Beaucoup plus proche de mon métier, je note aussi un manque cruel de formalisation des tests ainsi qu’une documentation pas forcément à jour, ou quand elle l’est, l’effort important de mise à jour en cas d’évolution.

Qui a eu cette idée folle ?

L’idée de rapprocher ces acteurs via une approche BDD émerge assez rapidement. Avec pour objectifs de casser cette défiance, de faire comprendre aux métiers les contraintes et problématiques de la DSI, de redonner du sens aux équipes techniques vis à vis de ce qu’elles produisent pour qu’elles s’investissent et s’approprient leur production. Et ceci pour tous les services de la DSI, des sites web à la distribution du journal dans les boîtes aux lettres des abonnés, de la gestion du compte client à l’impression quotidienne du journal papier.

Un challenge quotidien !

Dans les coulisses de Ouest-France

OK, pour le BDD on comprend bien. Mais il est où le legacy là-dedans ?

Faisons un focus sur cette performance quotidienne qui est d’imprimer tous les jours à près de 600 000 exemplaires du journal papier divisés en 52 éditions (une édition correspond à une zone géographique précise, la zone de Rennes représente 5 éditions par exemple : centre, est, nord, ouest, sud, et chaque édition comporte des pages locales différentes) et répartis sur 3 imprimeries différentes. Ce miracle est possible principalement grâce à un gros legacy. La majorité des applications sont âgées de 15 – 20 ans, et il y a, heureusement, très très très peu de turn-over. Ce qui signifie qu’une partie des personnes qui ont créé ces applications sont toujours présentes et donc qu’elles sont très bien maîtrisées et peu soumises aux défauts.

Les rotatives de Ouest-France, à Rennes le 24 novembre 2014 afp.com/DAMIEN MEYER

L’équipe technique de la DSI est en charge de maintenir et faire évoluer les solutions de mise en page et d’impression du journal papier.

Au niveau organisation, l’équipe technique de la DSI est constituée de PPO, de 5 développeurs, d’un scrum master et d’un testeur. Une petite équipe pour gérer un petite trentaine d’applications différentes. Le legacy est géré grâce à la méthodologie Kanban. Les applications plus récentes et encore en cours de développement sont gérées par la méthodologie Scrum.

Mon rôle dans cette organisation est d’aider à établir la stratégie de test sur les différentes applications développées, de partager les bonnes pratiques venant d’autres équipes et d’accompagner les membres de l’équipe dans ce changement pour qu’il se passe de la meilleure façon possible. A noter que la démarche est aussi déployée dans plusieurs autres équipes.

Côté documentation des différents applicatifs, elle est maintenue sous Word depuis leur création. Côté tests, uniquement des campagnes de non régression étaient présentes dans Testlink mais sans réelle traçabilité avec les “exigences”.

Un journal, trois domaines fonctionnels

Les solutions développées sont utilisées au sein de trois domaines fonctionnels :

• celui des journalistes, qui créent la maquette éditoriale du journal qui partira à l’impression le soir même
• celui des coordinateurs, qui s’assurent que les 52 éditions différentes sont complètes avec leurs publicités respectives, leurs avis d’obsèques, leurs annonces légales…
• celui de l’impression en elle-même. On entre dans le domaine industriel (rotatives)

La qualité : un enjeu crucial

Mais pas facile de faire évoluer un processus industriel qui doit fonctionner tous les jours et qui est soumis aux aléas de l’actualité ! En effet, une information de très grande importance et qui arrive tardivement après le bouclage, peut nécessiter une reprise de la maquette complète du journal (modification, ajouts ou suppression de pages). Les applications mises à disposition doivent donc être prêtes à aborder ces dernières nouvelles.

Le moindre défaut sur cette chaîne peut prendre des proportions considérables : maquette éditoriale à revoir donc décalage de l’impression et distribution plus tendue, remplacement de publicités donc perte de CA et de confiance des annonceurs déjà peu nombreux, non impression de tout ou partie des éditions donc perte de CA. A titre d’exemple, ne rien imprimer représente une perte quotidienne de 600K€ environ.

Passer au BDD : notre plan d’action

C’est dans ce contexte très établi que je mets les pieds dans le plat. Heureusement, mon discours a un écho favorable auprès de plusieurs personnes, notamment auprès du DSI,  et nous mettons en place un plan d’action en 3 étapes.

© investissements.org

Première étape : expliquer la démarche

Pourquoi changer ? Cette question, je l’ai entendue souvent. Et il m’arrive encore de l’entendre. La réponse n’est pas évidente quand on est sur un système qui fonctionne, qui permet de produire correctement le journal tous les jours. Néanmoins, nous arrivons aux limites d’un système. Les applications sont basées sur des technologies anciennes, une partie des personnes qui y ont contribué est passée à autre chose (mobilité interne, retraite). Se pose donc la question de la mise à jour et de l’évolution de ces applications.

C’est une réelle opportunité pour démarrer la démarche BDD !

J’ai donc commencé par mettre au point une formation pour expliquer ce qu’est le BDD et ce que j’en attends : de la collaboration entre équipes métiers et équipes techniques !

La formation mêle les concepts théoriques et des ateliers pratiques de réflexion collective pour répondre à un besoin. Le besoin est fictif et volontairement hors de leur champ de compétences mais on peut aussi prendre des cas très concrets.

Bien sûr, l’aspect formalisation qui accompagne cette démarche est abordé et quelques règles sont données pour bien commencer.

L’écho de cette formation a été plutôt bon, et quelques jours plus tard l’équipe a décidé de se lancer dans la démarche. Les membres de l’équipe ont donc bien saisi l’opportunité qui s’offraient à eux.

Nous avons alors défini un plan d’accompagnement pour supporter la démarche et rendre l’expérience la plus bénéfique possible.

Deuxième étape : profiter d’un contexte d’évolution sur un produit exemple

Un POC interne

Nous avons défini ensemble le contexte le plus favorable pour se lancer. Et nous avons profité de l’évolution mineure d’une application existante. L’idée était double :

• traiter l’évolution avec cette nouvelle méthode
• valider la démarche avec l’équipe sur un cas concret de leur périmètre

Nous avons fait le choix de mettre le testeur de l’équipe au centre de la mise en place de cette démarche. Nous avons estimé qu’il était le mieux placé pour à la fois formaliser les discussions autour de l’évolution et exprimer des contraintes de test.

Faux départ et rollback

Le plan ne s’est malheureusement pas déroulé sans accroc. L’écueil que nous avons rencontré est que ce testeur n’avait finalement pas totalement saisi les objectifs et qu’il a aussi repris la totalité des fonctionnalités de l’application mais d’une mauvaise façon. Le testeur a utilisé une méthode très directive avec une action par step. Ce qui inclut des steps techniques non compréhensibles par l’ensemble des membres de l’équipe. On est alors en contradiction avec les principes premiers de la démarche BDD.

Ce qui fait que nous nous sommes donc retrouvés avec un patrimoine de plusieurs centaines de scénarios inutilisables. Grosse frustration du testeur et de moi-même, et léger moment de doute. Mais on se remotive collectivement car on se dit que c’est tout de même la bonne démarche !

© reussitepersonnelle.com

Donc on efface tout et on recommence. J’ai fait des ateliers plus précis avec lui et le Scrum Master pour s’assurer que nous étions tous sur la même longueur d’ondes. Ces ateliers étaient basés sur des cas très concrets et mettaient en avant l’aspect collaboratif. Pourquoi ces 2 personnes uniquement ? Parce que le testeur se faisait le représentant de l’équipe technique et le Scrum Master le représentant de l’équipe métier. Je dis bien le Scrum Master car :

• c’est lui qui a le plus de connaissances métier dans l’équipe et donc qui peut rapidement dire si un scénario est compréhensible ou non
• c’est lui qu’il faut surtout convaincre
• il n’y a pas de PO mais plusieurs PPO qui ont été épargnés lors de cette première phase pour qu’ils continuent à avancer sur les sujets opérationnels

Et aussi tout simplement parce que ces deux personnes sont les plus à même à faire passer des messages au quotidien à l’ensemble de l’équipe.

Donc nous sommes repartis pour un tour. Au-delà de l’aspect perte de temps engendrée par cet écueil, cela a permis de montrer que cette démarche BDD n’est pas si évidente que cela à formaliser afin que tout le monde ait le niveau d’information suffisant et la même compréhension d’une fonctionnalité.

Quand la BDD-mayonnaise prend…

Une autre question s’est aussi levée au début de la démarche : doit-on aussi mettre à jour la documentation existante (Word) ? Nous avons collectivement fait le choix de ne pas le faire. Cela démontre l’adhésion à la démarche initiée et la volonté de la faire aboutir.

Une fois le bon niveau de formalisation atteint, il a fallu reprendre l’existant depuis la documentation existante afin d’obtenir une documentation centralisée et facilement évolutive.

La suite a été la prise en main de la démarche par l’ensemble de l’équipe. Nous avons poursuivi la démarche en ajustant les pratiques avec l’ensemble des membres de l’équipe pour atteindre la bonne façon de faire. Quand je dis la bonne façon de faire, cela signifie que c’est la façon qui convient à tous les membres de l’équipe.

Et ça fonctionne bien ! Les membres de de l’équipe ont bien sûr eu une période de prise en main nécessaire. D’où l’intérêt d’avoir deux personnes à leurs côtés pour échanger, corriger, améliorer leurs pratiques, de manière collaborative. Néanmoins, l’équipe s’est révélée opérationnelle dans l’application de la démarche BDD.

Troisième étape : déployer la démarche sur les autres produits

Mise à profit du retour d’expérience

Une fois cette étape franchie sur une application, il faut réfléchir au déploiement de la démarche sur les quelque trente autres.

Nous avons appliqué la même tactique qu’avec la première : toujours profiter des  opportunités engendrées par les évolutions, les refontes de produit, les nouveaux développements. C’est donc au gré des événements que le déploiement s’est déroulé et continue à se dérouler car toutes les applications n’ont pas subi d’évolutions et donc ne sont pas inscrites dans la démarche BDD. A ce jour, 16 applications voient leur développement guidé par cette démarche collaborative. Les autres suivront tôt ou tard. Les équipes sont prêtes.

Nouvelle péripétie !

Mais comme rien n’est parfait dans ce bas monde, nous avons dû faire face à un imprévu en cours de route : le départ du testeur qui avait entamé la démarche et qui en était le référent dans l’équipe. Nous avons donc entamé des recherches pour le remplacer et pour poursuivre l’effort au sein de l’équipe. C’était un coup dur car la dynamique était bonne et cet évènement risquait de balayer tous les efforts accomplis.

De plus, trouver la bonne personne pour animer la démarche au quotidien n’a pas été une chose facile.Il faut mêler de bonnes compétences en test (c’est quand même le métier premier) et des soft skills pour embarquer rapidement dans la démarche et l’animer au quotidien. Une combinaison pas si courante que ça autour de nous.

En effet, ce n’est pas parce que les autres membres de l’équipe sont autonomes qu’il n’y a plus rien à faire. C’est peut-être même à ce moment que l’effort doit être plus important pour toujours chercher de l’amélioration, ne pas s’endormir sur des certitudes. Et donc, il faut un animateur de la démarche, un référent, qui peut pousser les autres membres de l’équipe à s’améliorer, à penser à tous les impacts d’une évolution, qui peut s’assurer que tout se déroule correctement, qu’il n’y a pas de raccourci de fait, qui peut répondre à des questions sur la méthode, l’outillage …

L’heure du bilan : qu’a apporté le BDD ?

© resonances-vs.ch/

Vous me direz, c’est bien beau tout ça, mais est-ce que c’est efficace ?

Très bonne question. Je rappelle les objectifs initiaux :

• casser la défiance des équipes métiers vis-à-vis des équipes de la DSI,
• faire comprendre aux équipes métiers les contraintes et problématiques de la DSI,
• redonner du sens aux équipes techniques vis à vis de ce qu’elles produisent pour qu’elles s’investissent et s’approprient leur production

J’ajoute à ces objectifs des choses plus terre à terre tel que l’amélioration globale de la qualité des produits développés, la réduction du temps de conception d’une nouvelle fonctionnalité, la réduction du temps de maintenance de la documentation.

Amélioration des relations inter-équipes

Concernant la défiance, nous n’y sommes pas encore tout à fait. Il existe encore de grosses phases de recette métier après plusieurs itérations de développement et malgré tous les tests effectués par l’équipe technique. Dans notre cas, il y a aussi une dimension organisationnelle : l’équipe n’a pas accès à un journaliste pour lui servir de Product Owner. Si nous nous cantonnons au PPO (Proxy Product Owner), alors il y a du mieux car il a gagné la compréhension des contraintes techniques à travers les échanges systématiques avec l’équipe technique.

Reprise de sens du travail de développement

Pour ce qui est de redonner du sens aux équipes techniques, c’est difficile de se prononcer, notamment sur la partie legacy qui n’évolue pas ou peu. Si on regarde les applications plus récentes et celles qui ont bénéficié des plus grosses évolutions, alors on peut dire que l’implication est supérieure. C’est encore plus flagrant sur les nouveaux développements lancés après la mise en place de la démarche BDD et qui bénéficient depuis le début de ses bienfaits.

Performance de l’équipe

Si on regarde les objectifs plus terre à terre, l’amélioration de la qualité est difficile à mesurer (d’ailleurs comment mesure-t-on la qualité ? Hightest et Brice Roselier proposent quelques pistes dans cet article). Ce que je peux dire c’est qu’il n’y a pas eu de dégradation car le journal est imprimé tous les jours. Il y a bien sûr des incidents de temps à autre mais rien qui n’empêche la sortie sur les rotatives.

A propos de la réduction du temps de conception d’une nouvelle fonctionnalité, j’ai du mal à quantifier s’il y a eu un progrès. Ceci est dû au fait que la méthode BDD demande un effort plus important que ce qu’ils pratiquaient auparavant. Elle apporte aussi une réalisation meilleure du premier coup. Mais comme les mises en production sont au mieux trimestrielles, l’équipe technique a le temps de faire les choses…

Le paramètre sur lequel on voit la plus grande amélioration est la maintenance de la documentation. Fini la spec qui mêle le besoin et la solution. Nous avons d’un côté la documentation des fonctionnalités exprimées du point de vue des utilisateurs, et de l’autre la documentation technique de la solution. Ainsi si l’implémentation de la solution change, la documentation fonctionnelle n’a pas à être touchée. Et dès le moindre changement fonctionnel, la documentation est mise à jour automatiquement. Ce qui permet aux membres de l’équipe de toujours avoir une référence documentaire à jour.

Conclusion

La mise en place d’une démarche BDD dans un contexte où le legacy est très majoritaire n’est pas une pratique évidente à mettre en oeuvre. Il faut une équipe volontaire, qui croit en la démarche et qui souhaite s’y investir. Car c’est un investissement. Et pas sur du court terme mais plutôt sur du moyen-long terme, le temps de reprendre petit à petit un existant qui peut être conséquent.

Des questions restent toujours ouvertes (traçabilité des changements, granularité des scénarios, …) et les axes d’amélioration sont encore nombreux. Ce qui est sain et encourageant car c’est un signe que les personnes qui intègrent la démarche sont pleinement investis !

Sachez profiter des événements qui seront un terreau bénéfique à la mise en place de la méthode.

Préparez le terrain avec des formations, des ateliers pour accompagner les équipes dans ce changement.

Chaque équipe est différente, adaptez-vous !

Identifiez les relais dans les équipes qui porteront au quotidien la démarche.

 

Merci à Florent Vaution de Ouest-France pour ce témoignage inspirant, et bon courage aux QA qui se lancent ou se démènent déjà pour mettre en place une démarche de BDD dans leur organisation !

Crédit image couverture : © Ouest-France

Le Behavior Driven Development : vous connaissez « de nom, de loin, vite fait », ça a l’air bien mais il vous manque des précisions. Cet article est votre chance d’y remédier !

Si le BDD fait déjà partie de votre quotidien, vous trouverez peut-être aussi des points de clarification, ou des éléments historiques qui donneront de la profondeur à votre pratique.

D’excellents articles ont été écrits sur le sujet et pour la plupart des questions il vous sera proposé d’en consulter ailleurs sur le web. Cet article est donc une table d’orientation, plutôt qu’un article de fond sur le sujet.

Bonne lecture !

Qu’est-ce que le BDD ?

Si vous découvrez tout juste le BDD et souhaitez avoir les notions de base bien en tête, nous vous conseillons avant tout de faire un tour sur cet article, qui pose bien le décor. Vous verrez que, même s’il date de 2012, il n’a pas pris une ride !

Qui doit piloter la démarche BDD ?

Bonne question ; le BDD est-il du ressort des développeurs ou du métier ? Dans la vidéo « Comment échouer un projet en BDD », Vincent Pretre (CucumberStudio, anciennement HipTest) explique comment son entreprise a échoué dans chacune de ces deux approches.

Spoiler : malgré ces deux échecs, l’histoire se termine (très) bien.

Quels sont les différences entre BDD, TDD et ATDD ?

Cette question est un véritable marronnier de la blogosphère du test…

Entre BDD et ATDD

Sur la différence entre BDD et ATDD, nous vous invitons à consulter cet excellent article de Marc Hage Chahine sur La Taverne du Testeur. Vous verrez qu’elle est relativement ténue et qu’elle invite au débat.

De manière générale, vous trouverez pas mal d’articles qui se démènent à trouver la différence entre ces deux approches.

Dans leur ouvrage More Agile Testing, Janet Gregory et Lisa Crispin détaillent les deux, tout en indiquant que, de même qu’avec la méthode SBE (Specification By Example), “il s’agit avant tout de commencer par des exemples et des conversations” (p. 148).

Entre BDD et TDD

La différence entre BDD et TDD est bien plus nette. Le TDD est avant tout une méthode qui concerne les devs, et le test ici est avant tout un test unitaire. Une équipe de développement pourrait très bien se mettre au TDD d’un jour à l’autre, sans que l’équipe de test ne s’en rende compte (ou alors indirectement, en constatant une raréfaction des régressions !).

Le TDD se matérialise par une routine en trois phases :

·        La rédaction d’un test unitaire de sorte à ce qu’il soit en échec (il vérifie quelque chose qui n’a pas encore été implémenté)

·        La rédaction du code afin que le test unitaire soit au vert

·        Le remaniement (ou refacto) du code afin de consolider, entre autres, sa maintenabilité. Et on revient si besoin à l’étape 1 pour préparer une nouvelle vérification !

Rien à voir, donc, avec le BDD et l’ATDD qui mobilisent aussi bien les devs que les QA et le PO. Pour autant, BDD et TDD sont bel et bien liés, car l’inventeur du BDD pratiquait le TDD au quotidien, et a voulu aller plus loin. Pour bien assimiler l’essence du BDD, il est donc intéressant d’avoir en tête le contexte dans lequel cette méthodologie a été fondée.

Ce qui nous amène à la question suivante…

Quelles sont les origines du BDD ?

Les bases du BDD ont été posées en 2003 par Dan North, celui qui sera amené à inventer le framework JBehave. A l’époque, la notion de TDD existait déjà depuis 4 ans. Elle portait ses fruits mais des problèmes subsistaient, notamment au niveau de la communication des attendus fonctionnels.

L’histoire de la naissance du BDD est contée dans cet article de Dan North (si vous préférez la version française, c’est ici).

Un résumé de l’histoire du BDD

Un premier déclic a eu lieu lorsque Dan North a commencé à utiliser Agiledox, un utilitaire développé par un de ses collègues, qui consistait à transformer des noms de méthodes en langage naturel. Un moyen bien pratique de générer des documents utiles à toute l’équipe.

Puis, de fil en aiguille, il a commencé à modifier les titres de ses tests unitaires en y introduisant le mot « should ». Il a remarqué que cette notion éveillait bien plus de remarques pertinentes (“Ca doit faire ça ? Mais pourquoi ?”) que l’austère notion de test.

Il a ainsi remarqué que la notion de “test” pouvait être trompeuse et ambiguë, alors que la notion de comportement parlait bien plus à l’ensemble de l’équipe. En parlant davantage de comportements que de tests, pas à pas, les blocages qui résistaient au TDD se sont levés. La méthode s’est étendue hors de la sphère du développement pour conquérir aussi l’analyse métier.

Le BDD était né !

Il y a donc un lien fort entre TDD et BDD. Et comme le dit si bien l’article du blog d’Arolla, « De manière un peu caricaturale, le BDD va guider le développement d’une fonctionnalité, tandis que le TDD guidera son implémentation. »

Ce que cette histoire nous apprend

L’histoire du BDD telle que racontée par Dan North est intéressante à plusieurs niveaux.

Premièrement, parce qu’elle retrace précisément toutes les étapes qui ont mené progressivement à l’émergence du BDD. C’est rare d’avoir une genèse qui aille autant dans le détail.

Deuxièmement, parce qu’elle est racontée avec beaucoup d’humilité et qu’on comprend que le BDD a été inventé grâce à une combinaison de contextes, d’outils et de personnes, et non pas du fait d’un éclair de génie de Dan North tout seul dans son bain.

Troisièmement, parce qu’elle illustre la difficile quête de la simplicité. Il est bien facile en 2020 de lire cette histoire en se disant « Finalement, ce n’était que du bon sens ». Le chemin devait être fait une première fois à petits pas avant de former l’autoroute dont on profite aujourd’hui.

Qu’est-ce que le langage BDD ?

Attention, le BDD n’est pas un langage, c’est une méthodologie !

Et la structure « Given / When / Then » (GWT) est simplement un canevas pour formaliser un comportement voulu, pas un langage en tant que tel. Bref, pour parler de manière exacte, il vaut mieux éviter de parler de langage BDD.

La structure GWT semble être ce qu’on retient le plus facilement du BDD, et elle est parfois utilisée comme raccourci pour présenter le BDD à une personne néophyte. Et donc, par abus de langage, on peut donc parfois entendre « un test en langage BDD ».

L’habit BDD fait-il le moine ?

Comme l’explique très bien Vincent Pretre dans la vidéo évoquée précédemment « Comment échouer un projet en BDD », ce n’est pas parce qu’on utilise le formalisme GWT qu’on fait du BDD, et inversement certaines équipes travaillant en BDD n’utilisent pas ce formalisme. Il fait un parallèle très parlant avec l’utilisation des post-its, qui n’est en aucun cas un gage d’agilité, même si cet artefact est largement représenté dans les images d’Épinal de l’agilité.

Quels sont les types d’outils de BDD ?

Les outils de BDD constituent un « passe-plat » efficace entre script et langage naturel. Mais… dans quel sens ? Dans un billet de blog de la décennie précédente (mais qui n’a pas non plus pris une ride), Jonas Bandi différencie deux types d’outils de BDD :

·        Ceux dont l’output est en langage naturel (là, l’équipe de développement est un peu le centre de gravité de la démarche BDD)

·        Ceux dont l’input est en langage naturel (là, toutes les personnes liées au projet peuvent être impliquées de la même façon)

La façon dont on souhaite travailler va donc avoir un impact majeur sur l’outil ou la chaîne d’outils choisie.

Le framework JBehave, initié par Dan North, permet d’utiliser les termes Given, When et Then en tant qu’annotations Java. Ce sont les rapports de test qui sont en langage naturel. Cet outil appartient donc à la 1^ère catégorie. Le principe est similaire dans le framework Spock (oui, comme le Spock de Star Trek !)

Gherkin, intégré au framework Cucumber, est une syntaxe utilisant la structure GWT, avec une panoplie d’autres mots-clés. Les comportements sont exprimés en langage naturel, avec des fonctionnalités comme des tableaux de jeux de données. On est là dans la 2^ème catégorie.

Cette typologie montre bien à quel point le formalisme GWT ne suffit pas à déployer une démarche BDD. Si on vise une collaboration inter-équipes (la philosophie même du BDD), on va avoir tendance à préférer un outil de la deuxième catégorie.

On pourrait même en arriver à penser que certains outils dits de BDD pourraient présenter un risque de nous éloigner des principes du BDD. A méditer…

Et en français, ça donne quoi ?

Libre à vous de développer l’usage de l’expression « Programmation pilotée par le comportement », même si elle n’est pas très usitée !

Pour info, le syllabus ISTQB niveau Fondation – Agile Tester s’éloigne un petit peu de la traduction littérale et parle de « Programmation pilotée par les tests de comportement ».

Est-ce possible de mettre en place le BDD sur un projet existant ?

La question se pose effectivement, mais sachez que la transition vers le BDD n’est pas évidente non plus sur un nouveau projet. Des aspects relevant de la culture d’entreprise et des interactions personnelles sont en jeu, ce n’est pas seulement une histoire d’outils ou de process.

Pour ce qui est des projets existants, cela ne coule a fortiori pas de source, mais ce n’est pas impossible. Dans le prochain article, notre invité Florent Vaution vous parlera de son expérience chez Ouest-France, où il a mis en place une méthodologie BDD dans un contexte legacy. Préparez-vous, ça va être passionnant !

 

Les longs récits de conférence n’intéressent personne, nous ne vous dirons donc pas à quel point TestBash Australia 2019 a été stimulant, merveilleux et inspirant ! En revanche, nous voudrions partager avec vous un atelier proposé à cette occasion par Mark Winteringham (merci à lui !), et que vous pourriez avoir envie de réaliser avec votre équipe.

L’idée de cet atelier est de mettre en lumière les différentes représentations que l’on a des tests automatisés. C’est un travail collectif qui permet de se rendre compte des images, attentes, déceptions et points de blocages liés à l’automatisation des tests. Bref, de mettre en lumière des pensées qui bien souvent nous habitent sans que nous en ayons conscience ! Selon nous, il s’agit d’une démarche très intéressante, et nous comptons déjà cet atelier parmi les outils phares de l’automatisation des tests.

La théorie des médias et sa tétrade

La théorie des médias de Marshall McLuhan est à la base de cet atelier. Disons d’abord quelques mots là-dessus pour ne pas se perdre dans les concepts !

Qu’est-ce qu’un média ?

Ce terme peut être compris de trois manières différentes :

• Les médias comme moyens de diffusion d’information
• Les médias comme techniques et matériaux qu’utilise l’artiste pour créer
• Les médias comme l’ensemble des techniques et objets qui modifient notre façon d’interagir avec le monde, en étant une sorte de prolongement de nous-mêmes. Ça englobe énormément de choses ! Les cuillères, les jeux de société, les alphabets. Et tout ce qu’englobent les deux précédents points. En fait, il ne nous semble pas maladroit de dire que « média » peut être compris comme « outil » au sens large.

C’est la troisième acception du terme qui est à l’œuvre dans l’atelier de Mark Winteringham.

Les quatre axes de lecture d’un medium

Dans Laws of Media: The new Science (publié en 1988), Marshall McLuhan considère que les médias (ou outils) comportent tous 4 problématiques.

En effet, chaque média :

• Propose une extension, une amélioration.
  • Par exemple, un blog améliore notre capacité à partager nos idées, nous donne de nouvelles occasions d’échanger avec des personnes intéressantes, nous permet de figer et de pérenniser une réflexion à un instant donné.
  • Autre exemple, un vélo électrique permet de faire des trajets plus longs et moins pénibles (Nouméa est une ville vallonnée !)
• Rend quelque chose obsolète.
  • Dans certains cas, les blogs rendent obsolètes les longs circuits de relecture et de validation qui peuvent exister dans le monde de l’imprimé, car si une coquille est constatée dans un article, elle peut être corrigée immédiatement.
  • Le vélo électrique rendra sans doute jaloux votre vélo musculaire.
• Ramène à nous un média plus ancien, éveille des représentations.
  • La blogosphère pourrait rappeler par exemple la circulation des idées dans les salons du XVIIIème siècle.
  • La facilité de déplacement procurée par le vélo électrique pourrait vous rappeler votre expérience à scooter, par exemple.
• Produit l’effet inverse à celui escompté lorsqu’il est poussé à l’extrême.
  • Si tout le monde passe son temps à produire de nouveaux articles de blog, plus personne n’a le temps de lire ou de s’intéresser à ce qu’écrivent les autres ; la notion de réseau disparaît.
  • Si vous n’utilisez plus que votre vélo électrique, vous perdrez une partie des bénéfices que vous aviez obtenus dans le passé en passant de la voiture au vélo musculaire.

Ces quatre problématiques sont schématisées par une tétrade.

Les automates de test : un média comme les autres ?

L’objet de l’atelier de Mark Winteringham est de questionner les automates de test en tant que média.

Déroulement de l’atelier

Pendant quelques minutes, par petits groupes de réflexion, on écrit sur des post-its des aspects de l’automatisation des tests répondant aux questions suivantes :

• Que nous apporte l’automatisation des tests ?
• Qu’est-ce que l’automatisation des tests rend obsolète ?
• Que nous évoquent les tests automatisés ?
• Lorsqu’elle est poussée à l’extrême, en quoi l’automatisation des tests produit-elle l’effet inverse à celui escompté ?

A l’issue de ces quelques minutes d’échange en petit groupe, chaque partie de la tétrade est traitée collectivement. Chaque groupe explique aux autres les points qu’il a relevés, et le débat se poursuit collectivement.

Les tests automatisés au prisme de la tétrade

Apports de l’automatisation des tests

Quand on se pose la question dans l’absolu, en-dehors de tout contexte, il est difficile d’innover sur le premier point. Celui-ci donne d’ailleurs déjà lieu sur le web à une infinité d’argumentaires plus ou moins teintés de velléités commerciales.

En revanche, au sein d’un contexte dédié, cela a beaucoup de sens de s’interroger sur ce qu’apportent au quotidien les tests automatisés. Posez-vous donc bien la question : dans notre organisation, qu’apporte l’automatisation des tests ?

L’obsolescence induite par les tests automatisés

Le deuxième point, la question de l’obsolescence, questionne sur la vision « avant / après » ; quelles pratiques, artefacts et pensées ont disparu depuis la mise en place de l’automatisation des tests ? On s’interroge sur ce que l’automatisation vient remplacer.

L’imagerie de l’automatisation des tests

Le troisième point se démarque des autres car il est question avant tout de représentations. Il est intéressant de se demander quelles images font surgir les tests automatisés. Voyez-vous l’automatisation des tests comme une armée de robots rebelles dont vous êtes responsable ? Ou bien comme un tableau de bord comme ceux qu’on voit dans les vaisseaux spatiaux de films de science-fiction ? Il est possible aussi que l’automatisation des tests change la vision que vous avez de vous-mêmes. Prenez le temps de vous interroger sur toutes ces représentations que vous pouvez avoir.

Le côté obscur des tests automatisés

Sans surprise, c’est le dernier point qui a suscité le plus de réflexions intéressantes. Il permet d’identifier ou d’anticiper les pièges qui jalonnent les projets d’automatisation des tests. L’exercice de pensée consistant à pousser au maximum les caractéristiques du médium jusqu’à ce que ses avantages deviennent des inconvénients est particulièrement stimulant. Cela nous a rappelé entre autres la logopathie, l’automatite et la scalophobie (vous vous souvenez peut-être de ces maladies imaginaires de l’automatisation des tests…)

A vous de jouer !

Par choix, nous n’en disons pas plus sur les éléments qui sont ressortis de cet atelier à Sydney ; maintenant c’est à vous de jouer et nous ne voudrions pas influencer vos découvertes !

Encore une fois, merci à Mark Winteringham pour cet atelier très intéressant et pour nous avoir fait découvrir ce concept sociologique. Merci aussi à toute l’équipe de TestBash Australia 2019 d’avoir réuni à Sydney d’illustres spécialistes en qualité logicielle (Angie Jones et Nicola Sedgwick notamment) et mis à disposition des contenus d’une excellente qualité.

Bonus : l’équipe de test comme média

La théorie des médias de McLuhan est un outil particulièrement fécond pour questionner les outils et leurs pratiques. Nous avons trouvé sur le web un article qui questionne la notion d’équipe de test à la lumière de cette théorie. Une lecture très intéressante (en anglais) que nous vous conseillons.

Bonus 2 : Marc Winteringham est l’auteur d’un site web (anglophone) riche en ressources sur le test logiciel et que nous vous invitons à consulter.

Crédits images : Merosonox (pour le schéma de la tétrade)

How Google Tests Software (de James Whittaker, Jason Arbon et Jeff Carollo, 2012) est à nos yeux un ouvrage de référence. Il ne s’agit certes pas d’un référentiel de pratiques de test à appliquer à la lettre, mais nous avons été agréablement surpris de voir qu’il regorge d’idées intéressantes pouvant être adaptées à des entreprises de toutes les tailles. Ce qui nous a d’ailleurs inspiré un article sur les plans de test.

Ce livre peut être appréhendé comme une photographie des processus de test de Google à un instant T. Un instant déjà lointain, et pourtant bon nombre d’idées vous sembleront venues du futur ! Il est également truffé de bons mots, dont certains que nous avons choisi de partager avec vous dans cet article. A méditer sans modération !

A noter : les traductions sont de notre cru.

Sur la qualité

« La qualité doit être intégrée au logiciel, et non pas boulonnée par-dessus. Dans cette mesure, elle est du ressort du développeur. Point. » p. 229

« Quand le test devient un service qui permet aux développeurs de ne pas penser à la qualité, alors ils ne pensent plus à la qualité. » p. 230

Ces punchlines résument bien la vision du testeur portée par cet ouvrage : celle d’un facilitateur de la qualité, qui partage intelligemment le fardeau de cette responsabilité. Une vision agile par excellence.

Sur l’état d’esprit du testeur

« Les testeurs mettent en avant leur rôle, et non pas le produit sur lequel ils travaillent. Et dès lors qu’on détourne son attention du produit, celui-ci en pâtit. Après tout, le but ultime du développement logiciel est de construire un produit, pas de le développer, de le tester ou de le documenter. […] Les utilisateurs tombent amoureux de produits, pas des processus qui ont permis de le construire. » p. 230

Dans cette logique, les auteurs considèrent que pour se présenter professionnellement, « Je travaille sur Chrome » est une affirmation plus saine que « Je suis testeur ».

Sur les livrables de test

« Les développeurs ont un avantage clé sur les testeurs en ce que tout le monde s’intéresse aux artefacts qu’ils produisent. » p. 79

Elle pourrait être lue comme un constat grinçant, mais cette phrase est simplement un rappel de bon sens. Elle implique entre autres qu’en tant que communicant, le testeur doit se tenir à une exigence de concision. Les livrables de test doivent être avant tout opérationnels et les plus digestes possible. Cela rejoint la punchline précédente, on doit avant tout travailler au service du produit, la « beauté » de nos tests n’a pas d’importance.

Dans le même esprit, on retrouve :

« Un plan de test qui n’aboutit pas directement à des cas de test est une perte de temps. » p. 82

Sur les rapports d’anomalies

« Les bugs sont comme des gamins couvés par leurs parents. […] De même qu’un papa ou une maman sort son thermomètre, le testeur prépare ses outils. Un parent veut faciliter le diagnostic de la maladie de son enfant. Une mère veut faire comprendre au docteur à quel point son petit est mal en point. Un testeur veut faire connaître la criticité du bug, et plus encore, le rendre facile à corriger. » p. 126

Voilà une tendre comparaison à opposer aux esprits chagrins qui considèrent que le test est une activité destructrice… Elle est issue d’un encart très intéressant nommé « It’s a Bug’s Life ». Encore une puissante métaphore (voir notre série sur ce sujet) qui pourrait aider à faire changer la perception que beaucoup de gens ont des testeurs !

Sur les tests manuels

« ‘Pourrai-je bientôt me passer du test manuel ?’ Notre réponse est un non catégorique. [La mise en place de l’automatisation des tests] permet simplement aux testeurs de faire enfin le travail pour lequel ils ont été recrutés : des tests exploratoires bien pensés, de l’analyse des risques, et une réflexion orientée utilisateur. » p. 152

S’il fallait mettre un dernier clou au cercueil de cette idée reçue (« Les robots vont tester à la place des testeurs, youpi ! »), voilà une punchline qui pourrait vous inspirer. On la doit à Tejas Shah, alors à la tête d’un projet d’automatisation des tests pour Chrome.

Sur les risques

« Assurément, ne pas livrer un logiciel n’est pas une option, bien qu’elle représente un risque d’échec inexistant. Une entreprise tire profit de risques correctement estimés. » p. 97

Bref, nous ne pouvons que vous conseiller la lecture de cet excellent ouvrage, et nous espérons que ces quelques amuse-bouche vous auront donné envie de le lire. Qui sait, peut-être voudrez-vous l’offrir à un de vos collègues pour Noël ?