3 questions essentielles pour bien démarrer en automatisation des tests

L’automatisation des tests est une piste que vous voulez investir. Vous souhaitez, par cette démarche, maîtriser les coûts associés à la qualité, bénéficier d’une meilleure couverture des tests, ou encore mettre en œuvre des recettes plus courtes et efficaces. Très bien, mais par où commencer ? Qui affecter à ce chantier ? Quels tests faut-il automatiser ? Quels KPI suivre ? Quel outil choisir ?

Une fois qu’on a répondu « oui » à la question « faut-il automatiser les tests ? » c’est effectivement une autre ribambelle de questions qui se présentent, comme si on avait ouvert une boîte de Pandore. Pire encore : en répondant mal à ces problématiques, l’automatisation des tests pourrait se solder par un échec.

Dans l’article précédent, nous donnions 10 bonnes raisons d’automatiser les tests. Aujourd’hui, nous vous offrons des clés pour mettre en œuvre concrètement un tel chantier. Accrochez-vous, car les pièges sont nombreux, mais le jeu en vaut la chandelle !

1) Quels challenges et difficultés pose l’automatisation des tests ?

Des challenges autant techniques qu’organisationnels, et la bonne nouvelle c’est qu’il est possible d’en anticiper certains avec un minimum d’effort.

Il est important, avant de se lancer, d’avoir en tête les principales difficultés associées à l’automatisation des tests. Commençons donc par cela, en nous basant sur l’édition 2020-2021 du World Quality Report.

Selon cette source, la problématique la plus fréquente (52 %) est le manque de personnel suffisamment qualifié pour mener à bien l’automatisation des tests. C’est la question du « QUI ».

La deuxième difficulté la plus fréquente (42 %), est liée aux lacunes au niveau des environnements de test et des jeux de données. Un exemple à la fois simple et très fréquent ? L’environnement dédié aux tests automatisés est parfois aussi utilisé par des testeurs humains, qui modifient ou suppriment des ressources dont les tests automatisés ont besoin. Ces actions peuvent provoquer des faux positifs et donner du fil à retordre au moment où on analyse les résultats des tests automatisés. Cette difficulté pointe du doigt une réalité : l’automatisation des tests est un enjeu d’équipe ; si des environnements spécifiques et des données séparées sont requises, il est important d’impliquer l’ensemble des parties prenantes concernées (administrateurs systèmes, métiers…) Automatiser « dans son coin » n’est pas envisageable.

Problème suivant ? 41 % des entreprises rencontrent des difficultés à définir une bonne stratégie d’automatisation. C’est la question du « QUOI ».

D’autres challenges sont également évoqués ; le classique « on n’a pas assez de temps ! » est invoqué par 37 % des entreprises (cela prend en effet du temps de s’arrêter au bord de la route pour remplacer ses roues carrées par des rondes !), juste avant « on n’a pas les bons outils » (32 %).

Au sein de cet article, nous aborderons spécifiquement les questions du QUI et du QUOI, qui constituent la base d’une bonne stratégie d’automatisation des tests.

2) Qui est responsable de l’automatisation des tests ?

Bien plus de personnes qu’on pourrait l’imaginer de prime abord !

Nous disions plus haut que 52 % des entreprises déclarent manquer de personnel qualifié pour l’automatisation des tests. Les « testeurs automaticiens » sont en effet comme des trèfles à quatre feuilles : ils existent (contrairement aux moutons à 5 pattes…), mais il y en a peu. Restent donc, classiquement, 3 possibilités.

  • Faire monter en compétences les testeurs en automatisation des tests
    • CONTRE :
      Le développement n’est pas la tasse de thé de tous les testeurs ; une telle montée en compétences nécessite des efforts importants et une bonne dose de motivation
    • POUR :
      L’automatisation des tests produit des informations dont les testeurs seront en général les premiers bénéficiaires, et ce sont les mieux placés pour savoir ce qui doit être automatisé
  • Déléguer l’automatisation aux développeurs
    • CONTRE :
      L’automatisation des tests est une activité de test, les développeurs peuvent avoir du mal à adopter l’état d’esprit critique qui rend les tests efficaces
    • POUR :
      L’automatisation des tests est une activité de développement, les développeurs sont naturellement en mesure de s’y adonner
  • Externaliser la mise en place de l’automatisation des tests
    • CONTRE :
      Cette démarche peut être moins féconde si vous la décorrélez totalement des autres activités de test ; même « externes », les automaticiens auront besoin de s’immerger dans la vie du projet
    • POUR :
      Les prestataires aguerris connaissent les principaux écueils et les évitent plus facilement ; leur œil extérieur leur permet de questionner la démarche et de proposer une solution sur mesure.

Mais il ne suffit pas de répondre à cette question pour se tirer d’affaire ; c’est un arbre qui cache une forêt. Un autre tiroir de questions doit être ouvert !

En effet, l’automatisation des tests recouvre une multitudes d’activités, et l’implémentation des tests automatisés n’est qu’une d’entre elles.

Nous préconisons de réaliser une matrice des responsabilités (ou matrice RACI) afin d’établir, en amont du projet, qui interviendra sur quoi, et de répondre aux questions suivantes :

  • Qui choisira les tests qu’il faudra automatiser ?
  • Qui implémentera les tests automatisés ?
  • Qui lancera les tests automatisés ?
  • Qui analysera les résultats et rapportera les anomalies ?
  • Qui consommera les reportings des tests automatisés ?
  • Qui maintiendra les tests automatisés ?
  • Qui assurera la disponibilité des environnements dédiés aux tests automatisés ?
  • Qui produira les jeux de données nécessaires ?
  • (Et enfin, la question qui tue !) Qui sera responsable de la réussite de la démarche d’automatisation des tests ?

Il est important de répondre à ces questions, car elles permettent également de se rendre compte qu’il y a souvent plus de personnes qu’on l’imagine qui sont impliquées dans la démarche.

3) Quels tests faut-il automatiser ?

Pour trouver la meilleure liste de tests à automatiser, il faudra encore une fois se poser les bonnes questions.

Cette partie est dédiée aux 41 % qui peinent à établir une stratégie d’automatisation efficace !

Comme de bons tests prennent leur source dans de bonnes questions, voici celles que nous préconisons pour aider à définir le périmètre des tests automatisés :

Quels tests sont les plus critiques ?

Cette question est la plus évidente. Les tests révélateurs de la santé de l’application sont souvent les premiers que l’on souhaite automatiser. On les appelle les « smoke tests », par analogie à des tests que l’on ferait sur une machine industrielle par exemple : si vous appuyez sur le bouton de marche et que de la fumée sort de la machine, vous aurez détecté un bug bloquant en quelques secondes.

Quels sont les modules ou fonctionnalités qui, historiquement, sont les plus buggées ?

Cette question vaut surtout quand le projet d’automatisation est initié tardivement. Les « nids à bugs » ont besoin d’être sécurisés.

Quand le projet d’automatisation est lancé en même temps que le projet de développement (une bonne pratique permettant de maximiser le ROI des tests automatisés), vous pouvez vous baser sur votre expérience de projets similaires, puis étudier a fil de l’eau les modules où les bugs se concentrent.

Quels sont les tests les plus répétitititititi…tifs ?

Vous avez peut-être en tête ce formulaire qui compte 36 champs, ces champs pouvant être remplis de diverses manières, et chacune de ces manières devant être testée. L’œil est vigilant au premier remplissage, il persiste au deuxième, tient encore bon au troisième, puis il se perd, on ne sait plus ce qu’on a déjà rempli, on se trompe, on s’ennuie, et on a vraiment envie de passer à autre chose. Dommage, c’est à ce moment-là qu’on aurait pu détecter un joli bug.

Ces problèmes sont étrangers aux scripts de tests automatisés, c’est pourquoi les tests très répétitifs sont souvent de bons candidats à l’automatisation.

Quels sont les tests les plus rejouables ?

Certains tests ne peuvent être joués qu’une fois par an, qu’une fois par trimestre, ou encore une fois par jour. Il y a le fameux « batch de 4 heures du matin », la « moulinette du dimanche soir » et le « programme du 31 décembre ». Est-il vraiment intéressant d’automatiser les tests associés ? Pas sûr. Autant que possible, il est intéressant d’automatiser les tests facilement rejouables.

Quels sont les tests les plus difficiles à comprendre ?

Dans l’article précédent, nous parlions du fait que les tests automatisés constituent une documentation vivante du fonctionnement de l’applicatif. C’est un avantage quand ce fonctionnement est complexe. Un test difficile à comprendre sera peut-être mal effectué par un humain néophyte ; en l’automatisant, on se prémunit contre ce risque, et on donne en même temps plus de visibilité sur le fonctionnement précis du système à tester. Coup double !

Quels sont les tests qui seraient les plus faciles à implémenter ?

Il est souvent mal vu de commencer par le plus facile, de « choisir la facilité ». Ce n’est effectivement pas le premier critère à prendre en compte, mais la facilité d’implémentation est tout de même un élément important à avoir en tête. On veut des quick wins, pas des challenges insurmontables qui pourraient décourager l’équipe !

Synthèse des 6 questions

Comment utiliser efficacement ces 6 questions ? Afin de définir le périmètre à automatisés, il est nécessaire de :

  • Pondérer l’importance de chacune des questions
  • Répondre, pour chaque test ou suite de tests, à ces questions (sur une échelle de 1 à 5 par exemple)

En faisant une moyenne de ces scores, pondérée par l’importance des questions, on est alors en mesure de construire un périmètre à automatiser de manière solide et argumentée.

Chez Hightest, nous nous servons d’un modèle de tableur afin d’effectuer ce travail ; nous le partageons avec plaisir sur simple demande.

Tant d’autres questions…

Au sein de cet article, nous nous sommes concentrés sur QUI intervient dans la démarche d’automatisation des tests, et QUOI automatiser.

Nous pensons sincèrement que ces deux questions sont trop peu souvent posées, et que cela constitue une source importante d’échecs dans les projets d’automatisation des tests.

D’autres questions viendront ensuite, mais attention à ne pas mettre la charrue avant les bœufs ! En voici quelques-unes :

  • Quels KPI mettre en œuvre pour mesurer l’efficacité de la démarche d’automatisation des tests ?
  • Quelles mesures qualitatives surveiller en complément ?
  • Et le grand classique, la question qui a tendance à être posée en premier et à détrôner toutes les autres… Quel outil choisir ?

« Quel outil choisir »… Il faudrait un article dédié (voire, plutôt, une série d’articles) pour répondre à cette question ! En attendant, voici quelques articles de notre blog qui vous donneront des éléments.

Nous espérons que cet article vous aura apporté des éléments utiles à votre démarche. A bientôt pour de nouveaux articles sur ce sujet passionnant qu’est l’automatisation des tests !

10 bonnes raisons d’automatiser les tests

Nos organisations reposent d’ores et déjà presque toutes sur des systèmes d’informations ou d’autres outils numériques sans qui elles ne peuvent clairement plus fonctionner correctement.

Au-delà des enjeux professionnels, quand une population entière repose sur un logiciel, les enjeux deviennent parfois des enjeux de santé publique (santé, énergie, télécommunication, etc).

C’est de cette dépendance aux outils numériques et aux risques associés qu’est née la notion de qualité logicielle et la discipline du test logiciel.

Pourquoi automatiser ses tests ?

Recettes à rallonge, coûts non maîtrisés, testeurs épuisés, résultats de test insatisfaisants, difficiles à interpréter, incomplets… Sortir une application ou un logiciel est trop souvent douloureux au sein des organisations.

L’automatisation des tests a le vent en poupe et fait fantasmer un avenir où les bugs seront gommés, sans aucun effort. Au-delà de l’utopie, de nombreuses raisons peuvent effectivement interroger sur la pertinence de cette démarche dans un contexte d’amélioration de sa qualité logicielle.

Vous êtes impactés au quotidien par la non-qualité et cherchez désespérément une solution pour limiter ses effets sur votre équipe et votre portefeuille ? Cet article liste 10 bonnes raisons d’engager une démarche d’automatisation des tests.

Les 10 raisons d’automatiser ses tests

L’automatisation des tests est une pratique susceptible de décupler l’efficacité des tests, de multiples façons différentes. Si l’on reprend le document de référence de la certification d’automatisation des tests A4Q Selenium Tester Foundation, ainsi que l’édition 2020-2021 du World Quality Report, les avantages de l’automatisation des tests sont les suivants :

#1 – Réduction du temps nécessaire à l’exécution des tests

C’est le plus évident, et le plus impactant pour les structures où les compétences et la charge coûtent cher, avec des délais pas forcément en adéquation avec les ressources ! Certaines vérifications longues et répétitives qui seraient effectuées en quelques heures par un humain, peuvent l’être en quelques secondes par un robot.

Le World Quality Report, qui se base sur 1750 témoignages d’entreprises du monde entier, tous secteurs confondus, a démontré que 65 % des entreprises constataient un réel gain de temps grâce à l’automatisation des tests.

#2 – Réduction des erreurs humaines

Lors de la répétition des tests de régression notamment (vous savez, ceux qu’il faut jouer et rejouer à chaque fois pour s’assurer que les nouveaux développements n’ont pas cassé les anciens !), des erreurs peuvent être commises par des testeurs lassés ou distraits. On ne peut d’ailleurs pas leur jeter la pierre, des biais cognitifs puissants sont à l’œuvre, qui rendent très difficile de se concentrer sur des tâches répétitives ! Par chance, les scripts de tests automatisés répètent inlassablement et minutieusement les mêmes actions, avec un meilleur résultat : 57 % des organisations constatent une meilleure détection des défauts grâce à l’automatisation des tests (World Quality Report 2020-2021).

#3 – Réduction des coûts alloués aux tests

La réduction des coûts : cette raison fait partie des motivations récurrentes pour se lancer dans l’automatisation des tests ; selon le World Quality Report, ce bénéfice est constaté par 62 % des organisations.

Attention, cela ne signifie pas que le test dit « manuel » soit rendu caduc par l’automatisation des tests ; simplement, l’automatisation va aider à se concentrer sur les tests des nouvelles fonctionnalités, tester de manière plus ciblée et plus créative.

#4 – Augmentation de la confiance envers le produit

Une version testée automatiquement permet d’augmenter la confiance que nous portons au produit. Ce niveau de confiance évoluera au fil du temps : les premiers tests automatisés permettront en quelques minutes de confirmer qu’une version est testable ; un arsenal plus complet pourrait aller jusqu’à justifier un déploiement continu.

#5 – Exécution de tests impossibles à jouer manuellement

C’est le cas, par excellence, des tests de charge ou de performance. L’automatisation rend presque infinie les possibilités de scenarios de test, sans à avoir à se soucier de la charge humaine.

#6 – Gain de valeur pour les testeurs humain

Eh oui, l’époque où les machines domineront le monde est encore loin. Néanmoins, libérés d’une partie des tests de régressions, les testeurs peuvent exécuter des tests manuels plus intéressants et plus complexes. Ils peuvent par exemple s’adonner à des sessions de test exploratoire, qui permettent de quadriller l’application à tester de manière ciblée et intelligente.

#6 – Exécution des tests plus tôt

Grâce à l’automatisation, les tests peuvent être exécutés plus tôt dans le processus. C’est typiquement le cas quand les tests sont joués dans la chaîne d’intégration continue ; si on le souhaite, dès que de nouveaux « bouts de code » sont déployés, immédiatement des tests sont déclenchés. Cela répond à un des 7 principes généraux du test logiciel : « Tester tôt » !

#7 – Tester en-dehors des heures de travail !

Il est satisfaisant de commencer sa journée sachant que des tests ont « tourné » pendant la nuit et qu’il n’y a plus qu’à analyser leurs résultats. En outre, il peut être commode de libérer un environnement en journée, pour n’y effectuer de tests que lorsque personne ne travaille dessus.

#8 – Augmentation de la fréquence d’exécution des tests

Le temps imposé aux tests peut contraindre à laisser certains cas de côté quand les délais sont courts ; les tests automatisés permettent d’éviter ou raréfier ces raccourcis. Ils permettent même d’augmenter le périmètre de ce qui est testé (c’est ce qu’on appelle la couverture des tests).

Selon le World Quality Report, 58 % des organisations interrogées constatent que l’automatisation des tests leur a permis d’augmenter la couverture de leurs tests.

#9 – Transparence accrue des activités de test

Les tests automatisés produisent des rapports de test générés à la volée, qui sont souvent partagés automatiquement aux parties prenantes concernées. Le niveau d’information est alors le même pour tout le monde et cela contribue à créer un climat de confiance au sein de l’équipe. Ce gain est constaté par 69 % des organisations interrogées pour le World Quality Report.

#10 – Création d’une documentation vivante

Les tests automatisés ne se contentent pas de constituer un inestimable filet de sécurité ; ils représentent aussi, à un instant T, une documentation fine de la façon dont une application est censée fonctionner. Convenablement mis à jour et versionnés, les tests automatisés gardent ainsi la trace des différentes façons de fonctionner du système concerné. Un bénéfice inattendu, qui peut s’avérer bien utile !

L’automatisation des tests, une pratique désormais standard

La discipline a déjà derrière elle des dizaines d’années, puisqu’il existait déjà des outils d’automatisation des tests à la fin des années 1990. Astra Quicktest, l’ancêtre d’UFT, un des logiciel d’automatisation des tests les plus connus, a été créé en 1998.

A ce jour, selon le State of Testing de 2020, 89 % des entreprises ayant une démarche qualité logicielle pratiquent l’automatisation des tests.

Bien que les formations initiales en automatisation des tests soient rares, il existe des certifications qui permettent de standardiser les pratiques. La certification A4Q Selenium Tester Foundation, créée en 2018, en est un bon exemple, de même que les certifications ISTQB Analyste technique de test et Automatisation des tests.

L’automatisation des tests est donc aujourd’hui une pratique fortement implantée dans le paysage de l’IT, et on comprend pourquoi.

Comment initier l’automatisation des tests dans ma structure  ?

Si vous souhaitez vous lancer, de nombreuses ressources sont disponibles pour vous aider. Nous recommandons la lecture du syllabus A4Q Selenium évoqué plus haut, car ce document fournit une première vue d’ensemble des problématiques propres à l’automatisation des tests.

Prochainement sur notre blog, nous partagerons des bonnes pratiques pour mettre en œuvre l’automatisation des tests au sein de votre structure.

Et surtout n’oubliez pas, la question n’est pas de savoir si l’automatisation fournit réellement des avantages, mais plutôt de savoir quels sont les objectifs que vous souhaitez atteindre au sein de votre projet en utilisant l’automatisation des tests. Tous les bénéfices ne s’appliquent pas, ou du moins pas immédiatement, à tous les projet. C’est en les ciblant spécifiquement que vous multiplierez vos chances de les atteindre !

A bientôt !

Crédit image : Miguel Á. Padriñán

7 principes généraux : oui, mais…

Dans le métier du test, les 7 principes généraux du test logiciel sont un peu comme les 7 nains de Blanche Neige ; sympathiques, familiers, on s’amuse parfois à tous les citer.

Toutefois, ces principes peuvent donner lieu à des extrapolations parfois dangereuses ; cet article vise à mettre en garde contre celles-ci.

Les tests montrent la présence de défauts… mais ils ne sont pas les seuls !

Les tests montrent la présence de défaut dans l’applicatif, et il est impossible de prouver l’absence de défaut. Très bien, vous connaissez maintenant ce refrain par cœur ! C’est d’ailleurs un refrain consolant, un peu comme « personne n’est pas parfait » ou « l’erreur est humaine ».

Et maintenant, si on changeait de perspective ?

Les défaillances d’un applicatif en production montrent la présence de défauts… dans les tests. Dans cette optique, il est logiquement impossible de prouver que des tests sont dénués de défauts, et sont parfaitement adaptés à une application.

Il est donc dommage de penser « Une défaillance a eu lieu en production, mais ce n’est pas notre faute, car les tests montrent la présence de défaut, pas leur absence. »

Il est plus utile de se dire « Une défaillance a eu lieu en production, les défaillances montrent la présence de défauts dans les tests ; corrigeons maintenant notre façon de tester. »

Comme le dit la locution, l’erreur est humaine, mais persévérer dans l’erreur est diabolique !

Les tests exhaustifs sont impossibles… oui, mais ne partons pas défaitistes

Ce deuxième principe, au même titre que le premier, peut être utilisé comme un bouclier pour contrer les attaques de décideurs ou de clients mécontents.

Les tests exhaustifs sont impossibles, certes. Le périmètre des tests est limité, car le temps alloué à la qualité est limité.

Mais ce temps est-il utilisé au mieux ?

Les tests exhaustifs sont impossibles, mais des tests pertinents sont possibles.

Tester tôt… oui, mais restons calmes

Il est important de tester tôt.

Il est important aussi de savoir quand il est trop tôt pour tester.

  • Un produit est en cours de réflexion. Des cas d’utilisation ont été écrits. Des réunions de brainstorming ont lieu régulièrement, les plans changent au fur et à mesure… Il n’est pas trop tôt pour se pencher sur une stratégie de test, voire sur un début de conception des tests, mais il est bien trop tôt pour rédiger les cas de test en détail.
  • Un MVP est en cours d’implémentation. Des interfaces sont disponibles. Cette première mouture donnera peut-être lieu à un projet à long terme, mais ce n’est pas sûr. Il n’est pas trop tôt pour réaliser des tests ad hoc, voire des tests exploratoires, mais il est beaucoup trop tôt pour se lancer dans l’automatisation des tests !

Le principe « Tester tôt » doit toujours être conditionné par l’exigence de « Tester utile ». Il est infiniment utile de décortiquer des spécifications avec un œil de QA avant l’écriture de la moindre ligne de code. Il est infiniment inutile d’écrire des tests qui ne seront peut-être jamais exécutés.

Les défauts se regroupent… oui, mais il convient de qualifier ces regroupements

Tu préfères rapporter 1 bug ou 10 bugs ?

Formulée comme ça, « la question elle est vite répondue ». Voici maintenant une variante :

Tu préfères rapporter 1 bug majeur qui importe vraiment aux parties prenantes, ou 10 bugs mineurs qui n’embêteront que toi et qui seront corrigés à la Saint-Glinglin ?

Quand on tombe sur un « nid à bugs », il est tentant d’y passer du temps et de remonter consciencieusement tout ce qu’on trouve anormal. Pour autant :

  • Tous les bugs ne se valent pas
  • Si certaines zones de l’application sont et restent buggées version après version, c’est peut-être qu’elles n’importent pas tant que ça

Autre point à noter : il arrive que l’on croie tomber sur un « tas de bugs », alors qu’il s’agit d’un même défaut qui provoque plusieurs défaillances.

Un champ entier d’orties est moins dangereux qu’un seul piège à loup.

Le paradoxe du pesticide existe… oui, mais cette image doit être bien analysée

Rappelons d’abord ce qu’est le paradoxe du pesticide, un principe qui n’est pas si simple à comprendre.

Qu’est-ce que cette histoire d’antimoustique ?

En France actuellement, l’été arrive, avec son lot agréable de soleil, sorbets et transats, et aussi son lot désagréable de moustiques.

Mettons qu’un laboratoire mette au point un antimoustique révolutionnaire, le Blanuin3000, qui dissuade 99,99 % des moustiques de piquer les humains qui s’en aspergent la peau. Cet antimoustique fait ses preuves, et pendant tout l’été les humains sont quasiment débarrassés des nuisances associées.

En parallèle, les 0,01% de moustiques résistants profitent d’un avantage certain : comme ils peuvent profiter des proies humaines, ils sont moins susceptibles de mourir de faim ou de manquer des éléments nutritifs qu’apporte le sang humain.

L’été suivant, une nouvelle génération de moustiques arrive. Certains ont légèrement muté, et ne sont plus indisposés par l’odeur du Blanuin3000. Quant aux descendants des 0,01%, ils sont un peu plus nombreux, grâce à l’avantage évoqué. Le Blanuin3000 n’est donc plus efficace qu’à 70 %. Scandale !

Le paradoxe est le suivant : on ne peut pas se contenter d’une solution, même si celle-ci est efficace à près de 100% à un instant T.

Le paradoxe du pesticide dans le monde du test

Mettons qu’un cas de test vérifie 100 configurations sur 1000 configurations possibles. Ces 100 configurations auront été sélectionnées pour être les plus représentatives possibles, par exemple en réduisant la combinatoire avec des techniques de type Pairwise.

A la première exécution des tests, 10 configurations sont en échec ; toutes donnent lieu à un correctif.

Après la découverte des bugs de la version 1 et leur correction, des tests unitaires ont pu être mis en place pour vérifier les cas ayant donné lieu à des défaillances ; il est donc extrêmement improbable de retrouver les mêmes défaillances sur les jeux de données. Il serait profitable de couvrir d’autres jeux de données, de même que le Blanuin3000 pourrait contenir de nouveaux principes actifs pour repousser encore plus de moustiques.

A la deuxième exécution, après correction, les 100 mêmes configurations sont vérifiées avec succès. Félicitations, enfin un « logiciel sans bug » ! Ou pas. La vraie question à se poser : parmi les 900 cas non testés, est-il possible que certains soient en mesure de trouver des régressions non identifiées par les tests existants ? Si oui, alors nous sommes face au paradoxe du pesticide.

Les araignées n’ont que faire de l’antimoustique

Bien que les bugs ne se multiplient pas à la manière des moustiques, ils se cachent parfois dans des jeux de données particuliers.

Mais quand un bug passe entre les mailles du filet, cela peut être à cause du paradoxe du pesticide… ou bien à cause d’une mauvaise conception des tests.

Le paradoxe du pesticide se comprend dans la durée ; de même, une régression est un écart qui se constate dans la durée, d’une situation A en succès à une situation B en échec.

  • Si une régression n’est pas détectée par des tests dont les jeux de données sont comparables, nous sommes en présence du paradoxe du pesticide. Il aurait été utile de modifier un peu les tests existants.
  • Si cette régression n’aurait pu être détectée que par un test spécifique, qui n’a jamais été imaginé, on est tout simplement face à un problème de conception des tests.
  • Si le bug n’est pas une régression, on ne peut pas parler de paradoxe du pesticide, tout simplement parce qu’il n’y a pas de notion de durée.

Bref : à chaque bug son pesticide. Modifier un test X ne sert à rien quand il faudrait écrire un nouveau test Y. Les deux prennent du temps : à quoi choisirez-vous de vous consacrer ?

Les tests dépendent du contexte… oui, mais « le contexte » n’est pas un mot magique

Avez-vous déjà participé à un projet adoptant des processus et méthodes brinquebalantes, utilisant des termes Scrum à tort et à travers, et dont les membres se félicitaient d’avoir mis l’agilité à leur sauce ? (Avant de se rendre compte quelque mois plus tard que cela ne tenait pas, et de conclure avec amertume que « finalement l’agilité ce n’est pas si efficace que ça »…) « Le contexte » est souvent pris comme excuse pour se laisser aller à des pratiques peu efficaces, mais qui offrent une satisfaction immédiate.

Quelques exemples :

  • « Nous avons adopté le cadre Scrum pour ce projet. Dans ce contexte, toute documentation doit être bannie. » Quelle mésinterprétation courante, et quelle aubaine pour les personnes qui détestent écrire de la documentation ! Rendez-vous quelques mois plus tard, quand de nouveaux devs arriveront et demanderont où sont le README et les règles de gestion détaillées.
  • «  Nous développons un produit interne, dans ce contexte nous n’avons pas besoin d’une interface responsive. » La bonne occasion d’économiser des bouts de chandelle et de râper un peu les coûts de développement. Rendez-vous à la mise en prod, quand les utilisateurs découvriront avec horreur qu’ils ne peuvent pas travailler en réduisant la taille du navigateur.
  • « C’est un petit projet, on n’est que 5 dans l’équipe Scrum. Dans ce contexte, on n’a pas forcément besoin de faire un daily tous les jours… »

En 1977, à Harvard, Ellen Langer a démontré le pouvoir du « parce que ». Un complice devait s’adresser à des personnes faisant la queue devant une photocopieuse en formulant une de ces deux phrases :

  1. « Excusez-moi, puis-je utiliser la photocopieuse ? »
  2. « Excusez-moi. Puis-je utiliser la photocopieuse parce que j’ai des photocopies à faire ? »

La première phrase a obtenu 60 % de succès, contre 93 % pour la suivante. Bien que totalement redondante, l’excuse « parce que j’ai des photocopies à faire » est quasiment aussi efficace que « parce que je suis pressé » (94 % de réussite).

De même que « parce que », le « contexte » semble agir comme un mot magique permettant de faire tomber les objections alors même qu’il reste très vague. Restons à l’affût : apprêtons-nous toujours à demander des précisions sur ce contexte, et interrogeons-nous nous-mêmes sur sa véritable signification au moment où nous invoquons cette raison.

L’illusion d’absence d’erreur est un risque courant… oui, et la responsabilité est partagée

L’illusion d’absence d’erreur est celui des 7 principes qui est le moins contestable. Non seulement il permet à chaque membre de l’équipe de garder un œil critique sur l’applicatif en cours de développement, mais il permet aussi de guider les tests. L’illusion d’absence d’erreur met le focus sur les utilisateurs finaux et leurs besoins réels ; avoir à l’esprit ces personnes à tout moment nourrit la conception et la priorisation des tests.

Cette notion gagne à être connue ; elle n’est pas seulement un principe général du test logiciel, mais de manière plus large, un principe général du monde de l’IT.

Et vous, avez-vous déjà constaté des dérives possibles des 7 principes généraux des tests logiciels ? Si oui, indiquez-les en commentaire !

[Invité] Un jeu pour sensibiliser à l’importance de la stratégie de test

Aujourd’hui, le blog Hightest a l’honneur de donner la parole à Antoine Brebant, test leader chez Open, qui a mis au point un astucieux atelier gamifié permettant de sensibiliser aux problématiques de stratégie de test et de test basé sur les risques. Un grand merci à lui pour l’inventivité de cet atelier, que nous avons pu nous-mêmes expérimenter : la démonstration est brillante et extrêmement efficace. Bonne lecture !

Objectifs du jeu

Des articles de gamification ont déjà été publiés sur le blog Hightest, notamment la fiche explicative d’un jeu de carte. Ce jeu, je l’ai repris puis adapté sur Klaxoon, une suite d’outils collaboratifs numériques, et c’est ce qui m’a donné l’idée de concevoir d’autres jeux sur Klaxoon. Il est bien sûr possible de mettre en œuvre le jeu présenté aujourd’hui sur un autre support que Klaxoon, aussi bien au format numérique que physique.

Dans certaines organisations et équipes projet on agilise à tout va, en oubliant parfois que l’agilité demande de la méthode et qu’il ne faut pas négliger les fondamentaux du test. Parmi ces fondamentaux, il y a les stratégies de tests ! Une stratégie de test permet de guider l’effort de test tout au long du projet et apporte un cadre précieux. Il est important que les décideurs comprennent précisément l’intérêt d’un tel outil.

Le jeu présenté ici permet de sensibiliser à cette problématique. Il va être question de repérer non pas des anomalies, mais des bateaux ! Je me suis inspiré du blog de Nick Berry et j’ai conservé le modèle en deux parties utilisé dans le jeu de cartes d’Hightest 😉

Le jeu : « Le défi de l’Amiral »

Nombre de joueurs

Entre 2 à N. Idéalement limiter entre 4 et 10 personnes par instance Klaxoon. La limite réside dans le nombre d’animateurs/facilitateurs.

Matériel

En physique, un jeu de bataille navale par table, le facilitateur d’un côté, les joueurs de l’autre.

En distanciel, Klaxoon ou tout autre support vous permettant de reproduire le fonctionnement.

Naturellement, il faut de quoi expliquer/montrer les règles aux participants (présentation PowerPoint ou Meeting dans Klaxoon).

Voici à quoi ressemble votre terrain de jeu !

Déroulement du jeu

La partie se déroule presque comme une vraie partie, à ceci près que le facilitateur ne joue pas vraiment mais a plutôt un rôle de maître du jeu. Le but est très simple, il faut que les participants découvrent tous les bateaux cachés ; à la fin, on comptabilise le nombre de coups dans l’eau.

En moyenne, dans une partie « standard » (positionnement aléatoire et connaissances de base du jeu), il faut 77 coups, soit 60 ratés et 17 touchés, pour trouver tous les bateaux.

Dans Klaxoon, chaque case est une image verrouillée. Et derrière chaque case, il y a une icône elle aussi verrouillée. Les joueurs ont toutefois la possibilité de reculer la case mer pour faire apparaitre l’icône qui se cache derrière.

Tout est préparé à l’avance et tout est donc transparent : impossible pour le facilitateur de tricher ! 😉

Première session

Vous l’aurez peut-être déjà compris, la première session sert d’étalonnage et devrait permettre de confirmer la jauge des 60 coups ! 😉

Pour beaucoup de participants, les souvenirs de parties de bataille navale seront lointains ; il y a relativement peu de chances que cette première session donne des résultats fameux.

Entre les deux sessions

Avant la seconde session, il faut expliquer l’approche statistique de Nick Berry qui permet de descendre à une moyenne de 44 coups pour trouver tous les bateaux.

Nick Berry a en effet conçu un modèle qu’il nomme chasse (hunt) et ciblage (target).

La méthode la plus efficace conçue par Nick Berry utilise une fonction de densité de probabilité, qui prend en considération les différentes manières dont les cinq navires peuvent être déployés sur le plateau. L’algorithme de Nick Berry considère toutes les configurations possibles des cinq navires et calcule la probabilité, pour chaque case, d’être ou non occupée par un navire.

En début de partie, il y a de fortes chances de toucher un navire en ciblant le milieu.

Ensuite l’algorithme de Nick Berry calcule coup après coup l’évolution des statistiques.

Pour le jeu, j’ai simplifié le modèle en définissant un schéma de zones à risques inspiré de la méthode de Nick Berry et de ma propre expérience de ce jeu, dont je connais presque toutes les positions stratégiques. Mon record personnel à la version électronique : seulement 31 coups pour gagner.

La première phase de la méthode de Nick Berry est la « chasse », voici un exemple d’utilisation du modèle sans les bateaux :

Cela consiste à parcourir les zones en commençant par la zone en rouge puis allant progressivement vers le blanc jusqu’à trouver un navire.

C’est là que la seconde phase entre en jeu : celle de « ciblage ». En effet, le comportement va changer lorsque l’on va toucher : les cellules proches vont devenir plus intéressantes.

Enfin, voici un exemple de positionnement de navires et d’application de la méthode en simplifié :

Ici en utilisant la méthode de chasse et ciblage décrite précédemment, on trouve tous les navires en 41 coups malgré plusieurs coups dans l’eau !

Deuxième session

Une fois ces explications faites, la seconde partie se déroule comme la première mais avec un calque :

En physique, vous pouvez appliquer une feuille de papier calque avec le schéma ci-dessus et les trous prépositionnés.

Voici des exemples de positionnement de bateaux pour la seconde partie :

Normalement les joueurs devraient trouver vos bateaux plus rapidement… enfin, s’ils ne perdent pas de temps sur la première diagonale, qui a été évitée par fourberie xD !

Conclusion

J’ai emprunté cette image sur le blog ezyang, que j’ai traduite et très légèrement modifiée pour faire le parallèle entre :

  • l’océan et une application
  • les bateaux et les anomalies
  • les missiles et les tests
  • l’approche statistique et une stratégie de test 😉

Pour finir, il ne reste plus qu’à élargir le propos avec les différentes approches et stratégies de tests mentionnées dans le syllabus ISTQB de niveau fondation :

Connaître et combiner ces approches permet de concevoir des stratégies pertinentes rendant vos campagnes de test plus efficaces. De manière plus globale, être initié au contenu des syllabus ISTQB et en particulier du syllabus fondation permet aux membres d’une même équipe d’être plus efficace dans la recherche de la qualité !

Le mot de la fin, un grand merci à Zoé Thivet pour nos échanges, ses articles et ses interventions avec une approche innovante et inspirante.

Merci à mes collègues, Nelly, Emmanuelle, Tony et Alexandre qui ont bien voulu servir de cobayes pour ce jeu.

Merci enfin à Hightest de me permettre de publier ce billet sur leur blog.

Sources

https://datagenetics.com/blog/december32011/index.html

http://blog.ezyang.com/2011/12/bugs-and-battleships/

https://cliambrown.com/battleship/

L’auteur

Antoine BREBANT – Test Leader pour le groupe OPEN – 19 ans d’expérience dont 12 ans dans le test logiciel

  • Certifié ISTQB fondation et extension testeur agile
  • Certifié ISTQB niveaux avancés tests manager et automatisation des tests
  • Certifié IREB niveau fondation
  • Principaux Clients : SFR, Orange, Cedicam, BioMérieux
  • Lead Practice Testing OPEN région Est et Lyon
  • Animateur d’ateliers ludiques pour la Practice Testing
  • Formateur aux Fondamentaux du Tests (formation transposée dans Klaxoon)

Traqueurs de bugs ou explorateurs de la qualité ?

Au cours de la présente série, nous nous attelons à é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 les 2 leviers motivationnels positionnés pile sur l’axe horizontal de l’Octalysis : la possession (levier 4), liée à la motivation extrinsèque, et l’influence sociale (levier 5), tournée vers la motivation intrinsèque.

Dans ce dernier article de la série, nous étudierons aujourd’hui deux autres leviers opposés par rapport à l’axe vertical : la rareté et l’impatience (levier 6) et la curiosité et l’imprévisibilité (levier 7).

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

Pour rappel, voici une représentation de l’Octalysis :

Tout ce qui est rare… semble précieux

Le levier 6, celui de la rareté et de l’impatience, est celui qui nous pousse à profiter de tout ce qui est à la fois agréable et limité en quantité, en temps ou en disponibilité.

Certains jeux exploitent à fond ce levier ; Yu-Kai Chou prend pour exemple Candy Crush, qui « torture » le joueur en lui imposant de longs délais d’attente jusqu’à ce qu’il puisse lancer sa prochaine partie. Sans cette astucieuse limitation de temps de jeu, il est possible que le joueur finisse par se lasser des mécanismes passablement répétitifs de ce best-seller (« Candy Crush… ça me casse les bonbons ! »).

On comprend bien pourquoi ce levier est dans la partie basse de l’Octalysis, à savoir la partie « Black hat » qui met le joueur (ou l’utilisateur) dans une position de passivité. Ici, le joueur ne joue pas selon ses propres règles, et en particulier il ne peut pas agir en fonction de sa propre temporalité. Pour autant, tout ce qui est « Black hat » n’est pas à proscrire ; il est possible de se sentir tout à fait épanoui au sein d’une expérience qui comprend le juste dosage de ce levier.

Retrouve-t-on ce levier dans le métier du test ? Assurément.

  • Nous passons nos nerfs sur les applicatifs qui ne présentent pas de bug au premier abord (« Il doit y en avoir, c’est sûr ! ») ; nous jubilons lorsque nous trouvons enfin quelque chose qui ne fonctionne pas
  • Nous ressentons de l’impatience vis-à-vis de la livraison de nouvelles fonctionnalités intéressantes que nous avons hâte de tester ; nous ressentons de la joie et de l’excitation lorsqu’elles sont enfin disponibles
  • Quand nous sommes pris par des sujets urgents, nous nous languissons de nos projets de fond laissés en souffrance (veille, auto-formation, découverte de nouvelles techniques et outils, exploration d’autres domaines connexes…) ; c’est avec d’autant plus de plaisir que nous les retrouvons une fois la phase de rush passée
  • Nous attendons en trépignant la sortie de la dernière version de nos outils de test préférés et nous jetons dessus lorsqu’elle sort enfin.

Le levier 7 au cœur du métier du test ?

Le levier 7 est celui de la curiosité et de l’imprévisibilité. Il regroupe aussi bien les jeux de hasard que le plaisir de lire un roman, ou encore d’ouvrir ses cadeaux de Noël.

Le métier du test est un métier plein de surprises. Sur de nombreux postes, les journées se suivent et ne se ressemblent pas : entre revue des spécifications, conception et maintenance du patrimoine de test, découverte d’anomalies exotiques et défis d’automatisation, les rebondissements ne manquent pas !

La curiosité est un trait de caractère généralement valorisé par les équipes de test en tant que soft skill, au même titre que la rigueur et le souci du détail. La curiosité nous pousse à poser les questions qui, à la manière de chancelantes bougies, permettent d’éclairer les recoins les plus obscurs des besoins métiers et des détails de l’implémentation. Pour cette raison, ce levier semble inséparable du métier du test en général.

En plus d’être utile, la curiosité, associée à l’imprévisibilité, est source de motivation et de plaisir de travailler :

  • Nous apprenons avec plaisir les ressorts de métiers liés aux applicatifs que nous avons à tester
  • Nous prenons plaisir à acquérir des connaissances techniques et à étendre notre domaine de compétences
  • Nous nous réjouissons de comprendre les circonstances étonnantes permettant de reproduire un certain bug
  • Nous sommes curieux et enthousiastes de découvrir les fonctionnalités qui vont être demandées par la suite
  • Quand nous travaillons en tant que consultants, nous nous demandons avec excitation de quoi sera faite notre prochaine mission.

Conclusion de la série

Nous espérons que cette série vous aura permis de découvrir ou d’expliciter ce qui vous plaît dans le métier du test. Bien comprendre cela est un premier pas déterminant pour concevoir des mécanismes ludiques qui pousseront encore plus loin tous ces facteurs de motivation. Ce travail d’introspection gagne à être fait en équipe si vous prévoyez de mettre en œuvre une démarche de gamification au sein de votre organisation.

Nous vous souhaitons de bonnes réflexions autour du test, de la motivation et de la gamification ! N’hésitez pas à indiquer en commentaire les découvertes intéressantes que vous aurez pu faire sur le sujet !

Le test, ma team et mes bugs

Au cours de la présente série, nous nous attelons à é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.

Le mois dernier, nous évoquions 2 leviers motivationnels à l’œuvre dans le métier du test comme dans tous les autres domaines de la vie : le développement et l’accomplissement d’une part (lever 2), le renforcement de la créativité et le feedback d’autre part (levier 3). Ces deux leviers motivationnels sont tous les deux dits « White hat », car ils mettent la personne dans une position de maîtrise.

Etudions aujourd’hui 2 autre leviers motivationnels, cette fois-ci positionnés pile sur l’axe horizontal de l’Octalysis, c’est-à-dire qu’ils ne sont ni White Hat ni Black Hat par nature : la possession (levier 4) et l’influence sociale (levier 5).

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

Pour rappel, voici une représentation de l’Octalysis :

Le plaisir de construire un patrimoine

Le 4ème levier de l’Octalysis est celui de la possession. Dans la vie de tous les jours, il recouvre aussi bien la sensation de confort que l’on peut ressentir en contemplant une somme d’argent possédée, que la satisfaction de consulter un album photo et de prendre conscience des jalons de sa propre vie. Ainsi, au sens de Yu-Kai Chou, la possession regroupe à la fois des aspects matériels et des aspects symboliques.

En tant que testeur, que possédons-nous donc ? La question aurait peut-être semblé plus simple si on l’avait posée pour le Product Owner ou pour les développeurs ; pour le premier, un début de réponse est dans son intitulé ; pour les seconds, on aurait tendance à répondre « C’est leur code. »

Toutefois, les testeurs ne sont pas dépourvus de « possessions ».

  • Certains s’enorgueillissent du gros patrimoine de test qu’ils ont construit (avec toutes les dérives que cela peut impliquer)
  • D’autres contemplent avec fierté leur projet d’automatisation des tests
  • Les rapports d’anomalie sont également chéris par leurs rédacteurs, qui n’hésitent pas à les désigner en les appelant « mes bugs »
  • De même que les procédures et les processus de test, auquel on s’attache d’autant plus que nous avons contribué à les établir (une expression d’un biais cognitif que l’on appelle l’effet IKEA)

De manière générale, tous les artefacts que nous produisons sur notre lieu de travail sont susceptibles d’éveiller en nous cette petite flamme de la possession.

Cela peut être très gratifiant… tout comme cela peut nous emprisonner.

Untel automaticien pourrait se sentir enchaîné malgré lui au monstre qu’il a créé, et qu’il doit désormais maintenir péniblement, s’il n’a pas établi de suffisamment bonnes pratiques au moment de l’initialisation de ce projet et qu’il souffre d’une ou plusieurs maladies de l’automatisation des tests.

Un autre exemple : mettons qu’une équipe mette en œuvre un processus de validation, et que celui-ci, au bout de quelques mois, s’avère finalement limité. Il est possible que l’attachement à cette habitude empêche l’équipe de se remettre en question et d’imaginer un autre processus. On peut ainsi supposer que toute résistance au changement prend sa source, au moins en partie, dans ce levier 4.

C’est pour cette raison que la possession est un levier situé pile entre les sphères white hat et black hat ; le sentiment de maîtrise n’est pas toujours là, et s’il est là à un moment donné, rien ne garantit qu’il perdurera.

Le testeur, cet animal sociable

Le 5ème levier de l’Octalysis est celui de l’influence sociale ; il couvre tout le plaisir que l’on peut prendre en interagissant avec d’autres personnes, que ce soit pour sympathiser, pour apprendre d’elles, pour leur enseigner des choses, pour s’entraider… mais aussi pour entrer en compétition avec elles ou les faire enrager de jalousie ! Nous ne sommes jamais totalement dans une position de maîtrise dans ces interactions, c’est pourquoi ce levier se trouve sur l’axe horizontal de l’Octalysis. En effet, l’influence sociale peut aussi être subie, et nous motiver à entreprendre à reculons des actions que nous n’aurions pas envisagées sinon.

Le métier du test est bien souvent caractérisé par de nombreux échanges humains ; ainsi, il est possible que le métier du test soit apprécié au travers de cet aspect. Ce levier peut nous motiver au travers d’interactions libres et harmonieuses :

  • Nous prenons plaisir à aider les acteurs métier à obtenir le produit de leur rêve
  • Nous aimons échanger avec eux pour comprendre leur métier et élargir notre vision du monde
  • Nous apprécions la compagnie des développeurs avec qui nous engageons d’intéressantes conversations sur la concrétisation du produit
  • Nous aimons qu’ils nous apportent de nouvelles connaissances techniques
  • Inversement, nous aimons partager avec eux notre vision de la qualité
  • Nous aimons convaincre les décideurs de l’importance de tel ou tel aspect de la qualité
  • Nous aimons lire les retours d’utilisateurs satisfaits
  • Si nous avons l’occasion d’échanger avec eux de vive voix, nous aimons recueillir leurs idées, qui donnent vie à de nouvelles façons d’appréhender le produit
  • Nous aimons discuter entre pairs, au sein de notre équipe, à l’occasion de conférences ou au sein de groupes de discussion en ligne
  • Et tant d’autres interactions possibles !

A l’inverse, les situations suivantes sont susceptibles de nous « motiver » (du moins, nous pousser à agir) tout en annihilant en nous tout sentiment de contrôle :

  • Nous nous démenons car nous savons que les métiers n’auront aucune tolérance envers le moindre bug qu’ils pourraient découvrir après nous
  • Nous respectons à contrecœur un processus que nous trouvons inefficace car nous craignons froisser les acteurs historiques du projet
  • Nous prenons des précautions démesurées pour communiquer avec des développeurs que nous avons à la fois susceptibles et influents
  • Nous nous dépêchons de réaliser des tâches de support de peur de subir la colère des utilisateurs

On retrouve ainsi la même ambiguïté que dans le levier de possession.

Quelle synergie entre possession et influence sociale ?

Comme nous venons de le voir, les leviers 4 et 5 ont un fort potentiel motivationnel et peuvent induire aussi bien des sentiments positifs que négatifs. En cela, ils sont tout à fait similaires, c’est pour cette raison qu’ils sont tous deux situés sur l’axe médian horizontal.

En revanche, ils s’opposent radicalement d’un autre point de vue. Sur l’Octalysis, les leviers situés à gauche correspondent aux motivations extrinsèques, et ceux à droite aux motivations intrinsèques. Ainsi, le levier de possession suscite l’envie d’agir pour d’obtenir quelque chose à l’issue de cette action, alors que le levier d’influence sociale mobilise une motivation intrinsèque : les relations sociales sont appréciées pour ce qu’elles sont.

Ces deux types de motivation, intrinsèques et extrinsèque, ont des effets différents dans le temps. La motivation extrinsèque peut entraîner des actions rapides (on est tenté immédiatement par un gain et on recherche dans la foulée des moyens de l’acquérir), mais doit rester en proportion raisonnable, sous peine de perdre son efficacité. Par exemple, la valeur perçue d’un badge est susceptible de diminuer si l’on reçoit un badge pour toutes sortes d’actions triviales.

A contrario, la motivation intrinsèque n’est pas susceptible de s’user ou de perdre son sens ; elle correspond à des besoins que nous avons toujours en nous. Elle gagne toutefois à être valorisée et associée à une reconnaissance, qui peut se matérialiser par une possession. Ainsi, il serait tout à fait profitable d’associer les leviers 4 et 5.

Construire ensemble un patrimoine commun, régi par des règles décidées ensemble et soumis à des revues collaboratives régulières, pourrait apporter les avantages aussi bien du levier 4 et du levier 5. On peut retrouver cette philosophie notamment au sein de Promyze, qui tend à gamifier les activités associées à la qualité de code en y ajoutant des aspects sociaux (ateliers craft) et des aspects de possession (construction de référentiels de bonnes pratiques au moyen d’une collecte d’extraits de code de référence).

Dans le prochain article, nous évoquerons les leviers 6 et 7, positionnés tous deux en-dessous de l’axe horizontal. Nous basculerons donc résolument dans le côté Black Hat de la gamification. Préparez-vous !

Tester pour le plaisir ou pour la gloire ?

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 !

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 !

Chevaliers de la qualité ou esclaves des anomalies ?

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.

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 1er 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 1er 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é !

Pourquoi gamifier le métier du test logiciel ?

La semaine dernière, nous sommes intervenus à 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 conférenciers aussi talentueux que passionnés ! 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.

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’aux participants qui ont 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 » ? Il y a peu de chances.

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 créateur d’un schéma bien pratique pour concevoir et analyser des expériences gamifiées.

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’un joueur 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 est loin de perdre 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-humain ?

Test et gamification

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

  • « Ce doit être ennuyeux, répétitif et 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 test logiciel, c’est ce que les mauvais dev finissent par faire quand ils n’arrivent plus à trouver de poste, non ? »

Et il serait faux d’ailleurs de récuser en bloc la première affirmation, car il peut certes 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 les testeurs à toujours tester comme si c’était la première fois…

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 :

L’automatisation des tests en 22 émotions

« 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.