Un-jour-je-serai-le-meilleur-testeur

Comment devenir testeur logiciel ?

Note : cet article a été mis à jour en décembre 2021

Le monde du test fait face à un paradoxe.

D’une part, peu de formations initiales proposent de se lancer dans la profession, et le métier, quoique de plus en plus recherché en entreprise, peine à sortir de l’ombre. A l’heure actuelle, il est relativement difficile d’attraper un testeur logiciel dans son Pokédex.

D’autre part, un nombre croissant de personnes se tournent vers les métiers du test en ayant une vision très floue des activités auxquelles elles devront prendre part, ou qui ont des attendus parfois complètement erronés. Un exemple vécu ? « Je souhaite quitter mon poste de développeur pour un emploi de testeur car c’est moins difficile et il y a moins de responsabilités ! »

Plus fréquemment, nous recevons des candidatures de la part de profils divers, plus ou moins intrigués par le métier, mais sans notions de test logiciel.

Pour essayer de faire coïncider un peu mieux offre et demande, voici donc quelques pistes à l’usage de l’aspirant testeur.

Avertissement : dans cet article, nous employons le terme « testeur » au sens générique du terme ; cela englobe beaucoup de dénominations particulières que l’on peut retrouver par ailleurs (QA, ingénieur test applicatif, technicien qualité logicielle, test manager, etc).

Sommaire

  • Quels prérequis pour devenir testeur ?
  • Quelles sont les tâches du testeur ?
    • L’exécution des tests manuels à partir d’un référentiel de tests
    • La conception des tests
    • La gestion des anomalies
    • Les tests exploratoires
    • L’automatisation des tests
    • En bref : un métier polyvalent
  • Les outils du testeur
    • Les outils de gestion des tests
    • Les outils d’automatisation des tests
    • Les outils transverses
    • Et surtout…
  • Les formations
    • Les formations universitaires
    • Les formations éligibles au CPF
    • La POE
    • L’auto-formation
  • Premier entretien !
  • Pourquoi le métier de testeur est-il si peu connu ?
    • Une famille de métiers, une multitude de dénominations
    • Une communication insuffisante auprès du grand public
    • Comment faire connaître le métier du test ?

Quels prérequis pour devenir testeur ?

Le métier du test est un métier complexe et passionnant, et peu de prérequis sont strictement exigés. Outre un goût pour l’informatique et le travail d’équipe, il est toutefois souhaitable d’avoir quelques-unes des qualités ci-dessous :

  • Rigueur
  • Curiosité
  • Adaptabilité
  • Aisance relationnelle
    • Diplomatie
    • Humilité
    • Assertivité…
  • Goût pour l’apprentissage continu
  • Aisance rédactionnelle

Le contexte est important et les compétences et qualités requises dépendront d’un environnement à l’autre !

Pour vous épanouir dans cette carrière, il est avant tout important… d’en avoir envie ! A noter tout de même que beaucoup de testeurs le sont devenus « par hasard » et ne le regrettent pas. Ce choix de carrière est tout à fait pertinent dans une démarche de reconversion. Un passé dans la biologie, la comptabilité, l’enseignement, la traduction… ne peut être qu’un atout dans ce métier. Premièrement, parce que votre expertise peut vous être directement utile (connaissance fonctionnelle de l’applicatif à tester). Deuxièmement, parce qu’en tant qu’« outsider », vous porterez un regard neuf sur les process, les produits et tout ce qui gravite autour. Et cette prise de recul est bénéfique à toute entreprise !

Quelles sont les tâches du testeur ?

Mais tout d’abord, à quoi faut-il s’attendre quand on candidate à un poste de testeur ? Cette section s’adresse à tous les curieux de test logiciel qui sont attirés par cette activité et souhaitent savoir, concrètement, ce à quoi s’adonne un testeur.

Il faut garder à l’esprit le fait que l’activité de test varie d’une entreprise à l’autre, en fonction du type de projet, du mode de développement, du domaine métier et d’autres facteurs encore.

Voici tout de même une liste de quelques tâches qui brossent, dans les grandes lignes, un schéma grossier du quotidien d’un grand nombre de testeurs.

L’exécution des tests manuels à partir d’un référentiel de tests

L’exécution des tests est la partie la plus visible de l’iceberg du test. Selon les cas, elle représente 0 à 99% du temps de travail. Vous avez bien lu : 0%. C’est la première idée reçue à combattre sur le métier : on ne passe pas notre temps à cliquer machinalement sur des boutons en suivant minutieusement d’austères modes opératoires.

Quoi qu’il en soit ; quand cela se présente, le testeur se trouve devant une fiche de test (ou, bien plus souvent, devant un outil de gestion des tests) qui détaille un scénario de test à exécuter. Un scénario de test décrit d’une part les actions à réaliser, d’autre part les vérifications à effectuer.

Un exemple de cas de test : « Se rendre sur la page d’accueil et cliquer sur le bouton « En savoir plus ». Une popup doit s’ouvrir, dont le contenu doit être défilable verticalement mais pas horizontalement. »

Le testeur lit la fiche de test et exécute le scénario indiqué. Si le logiciel fait ce qui est demandé, le testeur le signale et passe au test suivant. Sinon, il rédige un rapport d’anomalie en respectant le format en vigueur dans son organisation.

Le risque de s’ennuyer existe, car les tests sont souvent répétitifs. Mais il faudra plus que de la patience pour être un bon testeur : il faudra faire en sorte de toujours tester comme si c’était la première fois !

Si vous débutez, il est possible qu’on vous demande de suivre à la lettre les scénarios de tests du référentiel. Cependant, si le contexte vous le permet, n’hésitez pas à sortir des scénarios indiqués pour faire des tests en complément. Au fur et à mesure, vous allez « flairer » les bugs de mieux en mieux ! L’exécution des cas de tests est une activité qui peut être fastidieuse, mais qui sera d’autant plus efficace que vous vous autoriserez à être créatif.

La conception des tests

La conception des tests est l’activité qui permet de construire le référentiel de tests, qui est utilisé pendant l’exécution des tests.

A partir d’un cahier des charges ou de tout autre document décrivant comment un logiciel devra fonctionner, on imagine des scénarios à exécuter. La rédaction de cas de test est bien souvent outillée, de manière à améliorer la productivité de cette activité.

Le testeur, quand il conçoit les tests, doit garder à l’esprit le fait que le temps alloué à l’exécution des tests est limité. Il doit donc cibler l’effort de test sur les fonctionnalités qui demandent le plus de test. Cela nécessite d’avoir une vue d’ensemble sur le logiciel à tester, et de définir, seul ou le plus souvent en équipe, une véritable stratégie de test.

La gestion des anomalies

Ce n’est pas tout de créer des rapports d’anomalies ; il faut aussi faire en sorte que les bugs soient corrigés. Le testeur ne corrige pas lui-même les bugs ; il doit donc les prioriser, les rendre faciles à reproduire, bref orchestrer au mieux le travail de correction. Ce travail se fait souvent en bonne intelligence avec d’autres acteurs du projet.

La gestion des anomalies est un travail effectué tout au long d’un projet ; la criticité, la priorité et les étapes de reproduction d’un bug peuvent évoluer au fil du temps. Il est important d’avoir toujours des informations fiables sur la qualité du logiciel.

Le testeur doit donner une visibilité des anomalies ouvertes. Il crée notamment des rapports indiquant les informations importantes sur le nombre et la nature des anomalies ouvertes. Ces rapports sont très importants, car ils permettent de prendre des décisions impactant la vie du projet (changement de priorités, décalage de la mise en production du logiciel).

Les tests exploratoires

On parlait précédemment de l’exécution des tests à partir d’un référentiel. Sachez qu’un référentiel formel de tests n’est pas toujours utilisé, et que la conception des tests a parfois lieu… en même temps que l’exécution ! On parle alors de test exploratoire, qui représente un sous-ensemble important de méthodes de test. Ces pratiques permettent de sonder les produits en profondeur en se basant sur des hypothèses et problématiques spécifiques (exemple : « nos utilisateurs se plaignent du moteur de recherche ; passons 40 minutes à explorer à fond cette fonctionnalité »).

L’automatisation des tests

Ah, là on s’attaque à un gros morceau !

Jouer les tests à la main encore et encore, ça a un coût et ça prend du temps. En tant que testeur, il vous sera peut-être (probablement !) demandé d’automatiser une partie de vos tests.

Concrètement, vous allez écrire des scripts qui, une fois lancés, vont simuler le scénario utilisateur au sein du logiciel à tester. Un petit exemple en vidéo ?

Cela demande encore une fois de mettre en place une stratégie : on ne peut pas tout automatiser. Pour cette activité, on vous demandera certainement des compétences techniques (souvent, des connaissances en développement orienté objet). Vous devrez aussi faire preuve d’esprit critique afin de mettre au mieux à profit ce temps d’automatisation.

Conseil : pour avoir bien en tête les tenants et les aboutissants de l’automatisation des tests, n’hésitez pas à parcourir cette ressource, qui a vocation à fournir un tour d’horizon assez complet sur le sujet.

En bref : un métier polyvalent

Bien d’autres activités encore pourraient être évoquées. Le métier de testeur est un métier largement polyvalent. Vous aurez parfois l’opportunité d’inventer, de modeler votre poste selon les besoins en qualité que vous identifierez. L’esprit d’initiative sera valorisé, et il vous faudra développer vous-mêmes des stratégies, des tactiques et des astuces pour vous adapter à un grand nombre de situations ! Cela sera d’autant plus vrai dans les équipes agiles.

Ci-dessous, à titre d’exemple, voici la répartition du temps d’un testeur sur une de nos dernières missions. Ce n’est pas un exemple à suivre absolument, simplement une illustration parmi d’autres de ce qu’il est possible de vivre dans le monde du test.

repartition-activité-du-testeur-logiciel

Pour finir, rien de tel que d’échanger avec d’autres testeurs pour se rendre compte des multiples facettes du métier ! Et pour ce faire, nous conseillons de rejoindre le groupe LinkedIn « Le métier du test ».

Les outils du testeur

C’est une question récurrente, surtout de la part des étudiants. Pour maîtriser le métier du test, il est important d’en maîtriser les outils principaux. Toutefois, nul besoin de suivre tous les cours en ligne de tous les outils de test les plus utilisés ! Maîtriser un outil de chaque type vous donnera suffisamment d’aisance pour pouvoir évoluer et en maîtriser d’autres par la suite.

Les outils de gestion des tests

Peut-on organiser une campagne de test sur un fichier Excel ? Ce n’est sans doute pas impossible, mais nous conseillons d’utiliser plutôt un outil optimisé pour cet usage. Les outils de gestion des tests permettent de concevoir les tests, de les rédiger, de les maintenir, d’organiser les campagnes de test (qui fait quoi ?), de suivre les résultats de celles-ci et, souvent, de générer des rapports.

Chez Hightest, nous sommes fans de Squash TM, un outil français (cocorico !), open source et simple d’utilisation. Si vous découvrez l’outil, nous vous conseillons de vous penchez sur ces quelques bonnes pratiques.

Les outils d’automatisation des tests

Difficile de citer ne serait-ce que tous les différents types de tests qui peuvent être automatisés ! Toutefois, lorsqu’on parle de « tests automatisés », il est souvent question de tests fonctionnels dynamiques automatisés ; c’est-à-dire d’automates qui vont parcourir l’applicatif comme s’ils étaient des utilisateurs, réaliser des parcours clients, vérifier ce qui est affichés sur l’écran à l’issue d’une transaction, etc.

Il existe cependant beaucoup d’autres outils de tests automatiques : des scans de vulnérabilité, des outils de scripting de tests de performance, de charge, de stress, des outils permettant d’identifier les problèmes d’accessibilité, des plateformes permettant de mesurer la qualité d’un code source

Chez Hightest, nous utilisons toutes sortes d’outils de tests automatisés ; cela dépend notamment du contexte, du besoin et des acteurs impliqués dans la démarche d’automatisation des tests.

Bien que tous les testeurs ne soient pas des automaticiens, nous ne pouvons que vous encourager à découvrir cette importante facette du métier.

Les outils transverses

Beaucoup d’outils qui ne sont pas spécifiquement des outils de test pourront vous être utiles. Pensez à toutes les tâches transverses que vous devrez effectuer :

  • reporting
  • brainstorming
  • rédaction, synthèses
  • communication interne, voire externe
  • gestion du temps, gestion de la productivité
  • prise de notes

Nous vous invitons à rester en veille sur les outils transverses (notamment les plugins de navigateur si vous testez des sites web) qui pourraient vous aider dans vos multiples tâches de testeur.

Et surtout…

Un seul outil vous manque, et tous les autres ne servent à rien. Il s’agit d’un freeware que tout le monde a sur soi ! C’est notre capacité d’attention et de réflexion. Si vous abordez chaque projet de test avec un regard neuf, que vous posez toutes les questions qui vous viennent, et que vous gardez toujours à l’esprit les enjeux réels de votre activité de test, vous aurez avec vous le meilleur outil de la place.

Les formations

Les-formations-pour-devenir-testeur

Si les activités que nous avons citées vous ont fait envie, voici quelques pistes pour vous préparer avant de candidater à un poste de testeur junior.

Les formations universitaires

Il est important de noter qu’à l’heure actuelle, sur le territoire français, l’offre de formation universitaire en test logicielle est peu fournie.

Licence professionnelle Test et Qualité Logicielle (LP-TQL)

Proposée par l’IUT de Laval, cette formation est accessible à niveau bac +2 (filières informatiques ou scientifiques), en formation initiale, continue ou VAE. Elle existe depuis 2009 et accueille 28 étudiants par an. Classiquement, à l’issue de cette formation, les personnes l’ayant suivie rejoignent le monde du travail sans besoin de passer par la case master.

16 semaines de stages sont obligatoires (+ 150 heures de projet tuteuré), à moins que vous ne choisissiez d’augmenter ce nombre en optant pour l’alternance.

Quelques outils étudiés : Selenium, Jenkins, MaTeLo, TestLink, JavaUnit, PHPUnit, Squash, Android Studio. La formation comprend un passage de la certification ISTQB de niveau Fondation.

Voir la présentation de ce cursus.

Merci à Lahcen Ouhbassi, responsable de cette formation, d’avoir répondu à nos questions.

Master Ingénierie du Test et de la Validation Logiciels et Systèmes (ITVL)

Le master ITVL, proposé par Polytech Angers (anciennement ISTIA) en collaboration avec l’Université de Franche-Comté, offre un cursus de deux ans comprenant un stage de 6 mois, 50 heures de projet et le passage de plusieurs certifications reconnues (dont ISTQB et IREB).

Ce master est ouvert uniquement en formation continue. Il se déroule 75% à distance et 25% en présentiel, à Angers. Les promotions oscillent pour l’instant entre 8 et 10 personnes par promotion, mais la formation pourrait à l’avenir accueillir davantage de personnes (pour un total de 16 à 18 étudiants). La formation en est à sa troisième promotion en 2019, et à ce jour le taux d’obtention du diplôme est de 100 %. A l’issue de cette formation, la très grande majorité des personnes ont obtenu des évolutions importantes de poste, soit dans la même entreprise, soit dans une autre entreprise. Deux personnes ayant suivi la formation se sont mises à leur compte.

Pour ce qui est du processus d’entrée, les responsables de la formation organisent un entretien individuel pour comprendre les motivations du projet professionnel du candidat ainsi que ses compétences, son expérience métier et son niveau d’études – en relation ou non avec le métier. L’éventuelle prise en charge financière par l’entreprise est également évoquée, de même que l’organisation de cette formation et le travail à fournir pendant les 2 années. Suite à cet entretien, les responsables de la formation expriment leur avis sur cette candidature et la personne postule ou non à la formation.

Merci à Alexis Todoskoff, responsable de cette formation, de nous avoir communiqué ces éléments.

Ecole Française du Test Logiciel et de la Cybersécurité (EFTL-CYBER)

Cette école se situe à Rennes et propose 3 formations autour de la qualité logicielle :

Autres formations

Le site de l’association QTL-Sup mentionne quelques autres formations ; voir cette liste.

Les formations éligibles au CPF

Si vous êtes en poste, il vous est peut-être possible d’utiliser votre CPF pour bénéficier d’une formation au test logiciel. Si celle-ci prépare à passer la certification ISTQB de niveau Fondation, cela pourra donner un vrai plus à votre CV. En tant qu’aspirant testeur, vous devez savoir que les certifications ISTQB, s’ils ne sont pas obligatoires pour trouver un emploi, sont tout de même une excellente manière de montrer patte blanche dans le monde du test ! Si vous souhaitez vous faire une idée du type de questions du test ISTQB de niveau Fondation, vous pouvez faire dès à présent notre test en ligne.

Comme elles sont assez nombreuses et que leur liste est amenée à fluctuer, nous ne listerons pas ici l’ensemble des établissements proposant ces formations.

La POE

La POE (Préparation Opérationnelle à l’Emploi, aussi appelée POEIC pour « individuelle et collective ») est un dispositif permettant d’acquérir une formation professionnalisante avec un emploi à la clé. Elle est particulièrement intéressante pour les entreprises recherchant des profils rares, et les testeurs qualifiés sont en effet très recherchés.

Acial notamment propose des parcours de POE qui permettent d’acquérir les fondamentaux du test logiciel en 10 semaines, pour devenir ensuite consultant dans ce domaine. Deux parcours sont disponibles : un parcours axé sur l’automatisation et un autre parcours plus généraliste.

L’auto-formation

Des MOOCs en français sur le test logiciel ? Il y en a quelques-uns sur la plateform OpenClassroms, notamment :

Deux autres cours sur le sujet devraient être disponibles à l’été 2019 : « Testez en continu avec Jenkins » et « Testez vos fonctionnalités avec Selenium et Python ».

Des MOOCs en anglais abondent également sur plusieurs plateformes.

Pensez aussi à Test Automation University, une plateforme qui contient notamment des cours débutants en automatisation. Si vous partez de zéro, ce site vous aidera à acquérir de précieuses notions ! Pour en savoir plus, jetez un oeil à l’article que nous avons écrit sur cette plateforme.

A noter qu’il est possible, pour les très débrouillards, de passer la certification ISTQB en candidat libre pour 250 euros (prix pour un passage en France métropolitaine). Voir la liste des prochaines sessions. Il est également possible de passer l’entretien en distanciel.

Un autre axe, non certifiant, mais qui permet de faire un premier pas dans le métier, est le crowdtesting. Même si cela ne vous occupera pas forcément à plein temps, l’expérience acquise peut être très riche et valorisante. Vous serez en contact avec un nombre important d’applications dans des domaines différents, ce qui représente autant d’opportunités de monter en compétences. Nous avons créé une plateforme de crowdtesting nommée Testeum, qui vous permettra, si cela vous intéresse, de découvrir cette activité.

Premier entretien !

Votre formation va bientôt s’achever et votre premier entretien d’embauche pour devenir testeur se profile ? Nous vous recommandons de jeter un œil à l’article que nous avons dédié à ce grand moment ! On croise les doigts pour vous 🍀

Pourquoi le métier de testeur est-il si peu connu ?

Nous espérons que cet article a pu permettre à certains d’avoir une idée plus précise sur le métier. Avant de se quitter, nous proposons de se pencher sur le problème de fond qui a mené à cet article : la méconnaissance importante dont souffre le métier de testeur.

Une famille de métiers, une multitude de dénominations

Le métier de testeur ne cesse de se développer et de se spécialiser, ce qui conduit à une diversification des dénominations. Rares sont les offres d’emploi qui se contentent du mot « testeur », comme l’explique cet article de la Taverne du Testeur.

Cependant, selon nous, ce phénomène n’explique qu’une petite partie du problème.

Une communication insuffisante auprès du grand public

En effet, un nombre important de sources d’informations grand public donne une vision parcellaire voire erronée du métier de testeur.

A titre d’exemple, la nomenclature 2018 du Cigref (EDIT : celle de 2021 aussi !) réserve le métier de testeur aux « Bac + 2 (BTS ou DUT) » ou aux « ingénieurs débutants », avec comme possibilités d’évolution une bifurcation vers les « fonctions études » ou la maîtrise d’ouvrage. L’automatisation des tests n’est pas mentionnée, ni les multiples spécialisations possibles dans le domaine de la qualité (test management, test de performance, test de sécurité, UX, SDET…). Vu comme ça, le métier peut donc ressembler à une « seconde chance » pour ingénieurs médiocres, en attente de trouver mieux. Quel dommage de réduire le métier à cela !

Le site « Etudiant » du Parisien relève-t-il le niveau ? Un petit peu, même si dès la première phrase, on grince un peu des dents : « Le testeur repère et relève les anomalies et bugs présents dans un logiciel ou une application avant sa publication. » La partie la plus intéressante n’apparaît qu’en troisième dans la liste des activités qui incombent au testeur : « Établir une tactique opérationnelle, créer des outils de test et d’analyse des résultats trouvés, dans le but de rédiger des bilans précis des logiciels étudiés. »

En 2019, le site de l’Apec ne mentionnait tout simplement pas le métier de testeur dans sa liste des fiches métier de l’informatique, même si on le retrouvait en filigrane sur les pages « Consultant maîtrise d’ouvrage », « Responsable de la maîtrise d’ouvrage bancaire / MOA » et « Ingénieur qualité/méthodes (informatique) ».

En 2021, ça y est, on trouve une fiche dédiée ! Celle-ci ne mentionne pas encore l’automatisation à proprement parler, mais rend tout de même justice à la polyvalence du métier, alors merci à l’Apec.

Comment faire connaître le métier du test ?

Nous espérons sincèrement que le métier deviendra plus connu grâce aux efforts de la communauté du test francophone. Les différents groupes, meetups, événements et blogs existants pourront sans doute faire rayonner le métier à leur échelle.

L’apparition de personnages de testeurs dans la culture populaire pourrait également mettre notre métier sous le feu des projecteurs (comme c’est largement le cas pour les métiers de développeur et d’administrateur système !) Un grand nombre de métiers sont entourés d’un imaginaire épique et enthousiasmant ; et si c’était notre tour ?

[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)

Tests de portabilité de navigateurs : le défi du gratuit avec BrowserStack

Dans notre dernier article, nous abordions l’un des aspects non-fonctionnels de la qualité les plus critiques en ce contexte d’explosion du choix des devices : la portabilité. Saviez-vous que des sociétés aussi inattendues que Land Rover (oui, le constructeur de 4×4 !) proposaient des smartphones ? Il est désormais virtuellement impossible de tester toutes les configurations existantes.

Ce phénomène est désigné sous le terme de fragmentation. Mais il ne concerne pas seulement les devices ; il touche aussi les systèmes d’exploitation (OS), la diversité des navigateurs web, ainsi que les différentes moutures et version de chacun des éléments cités.

Techniques de test de portabilité

Dans ce contexte, les équipes de test ne baissent pas les bras, car il existe de nombreuses solutions pour répondre à cette problématique.

La plus classique : posséder sur site des moyens de tester telle ou telle configuration. Ça peut être un tiroir rempli de téléphones de test (qui à la longue pourrait plutôt tenir lieu de musée du rétrophoning). Certaines entreprises conservent également des machines avec des OS anciens, comme Windows 7 ou Vista, avec de vieilles versions d’Internet Explorer.

Si l’on veut s’affranchir de ces contraintes et augmenter le nombre de configurations testables, il existe des fermes de devices qui permettent de tester sur des environnements réels tout en n’ayant pas à les acquérir chez soi. pCloudy fait partie de ces services, de même que BrowserStack dont nous allons parler ensuite.

Des émulateurs permettent, quoi qu’il en soit, d’avoir un premier niveau d’information. Si on arrive à reproduire un bug vu en production sur un émulateur, il n’y a pas forcément besoin de pousser le test plus loin pour pouvoir commencer à corriger le bug.

Enfin, pour les besoins croisés de tests de portabilité et d’utilisabilité, le crowdtesting est une stratégie tout indiquée.

Situation

Vous avez besoin de reproduire rapidement un bug sur un navigateur particulier ?

Vous souhaitez avoir un aperçu rapide d’un site web sur un grand panel de navigateurs ?

Dans ces situations, ce qui suit vous intéressera !

Tester rapidement et gratuitement un navigateur

BrowserStack est, si on traduit mot à mot, un « tas de navigateurs », mais cette simple traduction est trompeuse, car il est aussi possible d’interagir directement avec des téléphones réels. Tout comme pCloudy, BrowserStack propose une formule gratuite et des formules payantes. Ce qu’il est intéressant de noter, c’est que si la version gratuite de pCloudy propose un choix de devices restreint, celle de BrowserStack suit une stratégie différente : c’est le temps de chaque session qui est limité !

Si votre scénario prend une minute ou moins, rendez-vous sur BrowserStack et vous serez en mesure de profiter du service d’un grand nombre de navigateurs.

Rendez-vous sur la page d’accueil de BrowserStack, cliquez sur « Free trial », et choisissez votre environnement !

Une image contenant texteDescription générée automatiquement

Une minute, c’est peut-être un peu court pour tester chacune des fonctionnalités offertes, en revanche elles sont bien là, même en version gratuite :

Une image contenant texteDescription générée automatiquement

Par exemple, le rapport de défaut sur Slack permet d’envoyer en un clic les informations essentielles :

Une image contenant texteDescription générée automatiquement

Et voilà, vous êtes maintenant en mesure d’exécuter rapidement et simplement des tests sur un grand nombre de navigateurs, et ce gratuitement.

Et si vous souhaitez un jour passer en version payante, les prix sont tout à fait raisonnables pour le service rendu. Il existe en outre un tarif réduit pour les freelances et, cerise sur le gâteau, une gratuité les projets open source !

Quoi qu’il en soit, bons tests à vous !

pCloudy en 9 questions-réponses

Qu’est-ce que pCloudy ?

pCloudy est une plateforme qui donne accès des machines (physiques ou virtuelles) situées en Inde ou aux Etats-Unis, et avec lesquelles il est possible d’interagir. Un grand nombre de smartphones et de tablettes sont proposées, de multiples constructeurs différents et avec une large gamme de versions d’Android et d’iOS. Des navigateurs sont également disponibles.

Ce type de service est parfois désigné sous l’expression de ferme de devices.

A quoi sert ça sert ?

La plateforme pCloudy permet de récolter de précieuses informations sur la portabilité des applicatifs. Parfois négligés, les tests de portabilité sont pourtant essentiels ; ils permettent de comprendre comment les utilisateurs finaux verront l’interface. Pourront-ils interagir correctement avec cette interface, quel que soit leur navigateur, leur système d’exploitation et la version de ce dernier ? Les éléments d’affichage seront-ils harmonieusement répartis, quelle que soit la taille de leur écran ? Est-on vraiment responsive ? Au même titre que les autres tests non-fonctionnels, cet aspect passe malheureusement souvent au second plan, faute de temps, de moyens et souvent, de sensibilisation.

On a déjà des téléphones de test, est-ce utile de tester aussi sur pCloudy ?

Ha, les fameux téléphones de test… Les développeurs et les testeurs se chamaillent pour les avoir, on ne sait jamais qui a emprunté le Google Pixel 2, on cherche partout ce fichu câble (« non pas celui-là, l’USB C tu sais ») et on doit gentiment attendre son tour pendant que Boniface monopolise l’unique iPhone de l’équipe (« Attends encore deux minutes s’il te plaît. Enfin, deux autres minutes… »).

Autre problème : la couverture. Vous avez 10 téléphones de test ? Bravo, c’est davantage que beaucoup d’équipes projet. Mais combien de téléphones différents ont vos utilisateurs ? C’est un autre ordre de grandeur. Effectuer des sanity checks sur un grand nombre de machines vous donnera une confiance bien plus solide dans la qualité de votre applicatif.

Enfin, dernier problème : la reproductibilité. Un utilisateur de prod se plaint de ne pas pouvoir réaliser telle ou telle action, vous avez besoin de reproduire « son » bug pour comprendre de quoi il en retourne. Sur un de nos derniers projets, il y avait un bug majeur que l’on pouvait reproduire sur OnePlus 7, mais pas sur OnePlus 6, avec la même version d’Android ! Il est donc bien pratique d’avoir un pool important de machines pour maximiser ses chances de reproduire des bugs marginaux.

En conclusion : qui peut le plus peut le moins ; pas besoin de jeter au compost vos téléphones de test, en revanche pCloudy pourrait vous apporter un coup de boost considérable.

Comment ça marche ?

Voici un petit aperçu de l’usage le plus basique que l’on peut avoir de pCloudy : le test « manuel » d’applications mobiles.

Premièrement, dans l’onglet « My app / data », téléverser un fichier APK ou IPA.

Puis, dans l’onglet « Devices », choisir un téléphone ou une tablette.

Après quelque secondes, on se retrouve face à l’écran du téléphone et on peut librement interagir avec.

Libre à nous alors d’installer une application, de changer les paramètres du téléphone, de retourner l’écran… et de réaliser tous les tests souhaités !

Combien de machines sont mises à disposition ?

Sur la liste des devices, en février 2021, s’affichaient 267 devices physiques. Selon nos calculs, cela représente bien 40 kilos de smartphones et tablettes ; qui dit mieux ?

Est-il possible d’utiliser pCloudy dans une démarche d’automatisation des tests mobiles ?

Oui. pCloudy s’interface avec plusieurs solution d’automatisation des tests mobiles : Appium, Espresso, Opkey, Calabash et XCTest.

Combien ça coûte ?

Une quinzaine de devices peuvent être librement utilisés sans abonnement payant. Pour pouvoir accéder à l’ensemble des devices proposés, un abonnement doit être acheté, au mois ou à l’année (voir le détail des prix).

Le support est-il réactif ?

Oui : un chat est proposé au sein du site et le support pCloudy répond dans la minute. C’est en tous cas ce que nous avons pu constater dans notre timezone particulière ; une confirmation métropolitaine serait la bienvenue !

Une astuce à donner ?

Oui ! Lorsque vous tentez d’installer une application iOs (donc contenue dans un fichier IPA), il peut arriver que vous tombiez sur l’erreur « A valid provisionning profile for this executable was not found. » A ce moment-là, pour régler le problème, se rendre dans l’onglet « My app / data » et cliquer sur l’option « Re-sign » associée au fichier IPA.

La documentation pCloudy donne davantage d’informations sur ce comportement.

Si vous souhaitez découvrir un autre service de tests de portabilité, vous pouvez aussi vous pencher sur BrowserStack.

Et vous, utilisez-vous une ferme de devices ? Qu’est-ce que cela vous apporte ? La section des commentaires est à vous. A bientôt !

La certification A4Q Selenium Tester Foundation en 12 questions-réponses

Pourquoi passer la certification A4Q Selenium ?

Les certifications sont un sujet clivant. Certaines personnes en raffolent, d’autres considèrent cela d’un œil méfiant, tandis que rôdent les spectres du bachotage et du bourrage de CV. De notre côté, nous voyons cela comme une bonne manière de confirmer des acquis. Nous avons tendance à passer une certification après plusieurs années de pratique, plutôt que de démarrer from scratch par une formation intense et de passer l’examen dans la foulée, avant que les connaissances ne soient bien ancrées dans notre esprit. C’est dans cette optique que nous avons envisagé de passer la certification A4Q Selenium Tester Foundation.

Comme le contenu du syllabus est intéressant, le lire ne peut être que profitable et vous aidera à prendre du recul ; à vous de juger ensuite si passer la certification peut apporter à votre carrière.

A qui s’adresse cette certification ?

Le syllabus ne précise pas le public visé. Nous considérons que la certification serait profitable aussi bien aux QA en charge de l’automatisation des tests, qu’aux test managers ayant besoin d’avoir une vue d’ensemble sur les bonnes pratiques d’automatisation des tests.

Que contient le syllabus A4Q ?

Autant l’annoncer d’emblée : le contenu du syllabus est excellent. En plus des éléments techniques auxquels on s’attend, il contient également de très bonnes connaissances de fond (philosophie de l’automatisation des tests, facteurs de réussite, sensibilisation aux biais qui entourent cette discipline). De précieux conseils pour partir sur de bonnes bases !

Le syllabus A4Q apprend-il à mettre en place un projet Selenium ?

Oui et non, mais pour préciser les choses simplement, le syllabus n’est pas un tutoriel ! Si vous souhaitez apprendre Selenium, mieux vaut vous tourner vers des sites tels que Test Automation University. Le syllabus vous permettra d’ancrer tout ce que vous aurez appris, et vous apprendra peut-être aussi de nouvelles fonctions que vous ne connaissiez pas.

Quel « parfum » de Selenium est enseigné ?

Selenium dispose de connecteurs avec une dizaine de langages ; dans ce syllabus, c’est Python qui est utilisé.

Si vous avez l’habitude d’un autre langage, pas de panique, la transition est plutôt douce.

En vrai… la certification Selenium est-elle difficile à obtenir ?

Maîtriser le syllabus doit être votre priorité ; avoir de l’expérience sur l’implémentation de tests Selenium vous aidera aussi évidemment.

40 questions sont posées lors de l’examen, qui dure une heure, ce qui laisse quand même du temps pour réfléchir (c’est deux fois moins de questions que pour la certification PSPO et PSM par exemple !)

Le seuil de réussite est de 65 %, comme pour ISTQB Fondation. Toujours à titre de comparaison, PSPO et PSM exigent 85 % de réussite.

Peut-on passer la certification A4Q à distance ?

Oui. Préparez-vous à une surveillance assez stricte pendant l’examen : quelqu’un devra garder un œil sur vous via la webcam de votre ordinateur et via la caméra de votre appareil photo ; il vous faudra aussi montrer la pièce où vous passerez l’examen sous toutes les coutures (c’est le moment de mettre un peu d’ordre dans votre maison…) Attention aussi, un débit internet minimum est requis, il faudra vous assurer de disposer d’une excellente connexion pour éviter les pépins.

Peut-on passer la certification A4Q en candidat libre, sans formation préalable ?

Le syllabus est trompeur sur cette question :

« Les examens ne peuvent être passés qu’après avoir suivi la formation A4Q Testeur Selenium au niveau fondation, puisque l’évaluation par l’instructeur de la compétence du candidat dans les exercices fait partie de l’obtention de la certification. »

Malgré cette mention, il est tout à fait possible de passer la certification en candidat libre, sans avoir passé de formation au préalable.

Peut-on passer la certification A4Q Selenium en français ?

Bonne nouvelle pour les personnes qui redoutent les examens en anglais : il est possible de passer la certification A4Q en français.

Prenez tout de même quelque chose en compte : si vous choisissez de passer l’examen en anglais et que ce n’est pas votre langue maternelle, vous pourrez disposer de 15 minutes supplémentaires.

Cette certification est-elle valide à vie ?

Nous n’avons en tous cas pas trouvé de mention contraire.

Où peut-on s’entraîner en passant un test blanc A4Q Selenium ?

Un quiz en ligne A4Q Selenium est présent depuis peu sur notre site. Voici le lien vers le test blanc. Bon courage !

Quelques punchlines pour donner envie ?

Avec plaisir car on aime les punchlines ! En voici quelques unes :

L’importance d’une stratégie d’automatisation

« Une organisation n’a jamais construit par hasard un projet d’automatisation réussi. » Syllabus, partie 1.1

« Tous les tests manuels ne devraient pas être automatisés. Parce qu’un script automatisé nécessite plus d’analyse, plus de conception, plus d’ingénierie et plus de maintenance qu’un script manuel, nous devons calculer le coût de sa création. » Syllabus, partie 1.2

Chaque projet d’automatisation est différent

« Tous les avantages ne peuvent pas être obtenus dans tous les projets, et tous les inconvénients ne se produisent pas dans tous les projets. » Syllabus, partie 1.1

Cela rejoint le 6ème des 7 principes généraux du test logiciel : les tests dépendent du contexte.

L’origine de la plupart des bugs

« Les êtres humains trouvent la plupart des bogues ; l’automatisation ne peut trouver que ce qu’elle est programmée pour trouver et est limitée par le paradoxe des pesticides. » Syllabus, partie 1.1

N’est-ce pas libérateur à lire ? Comme vous le voyez, le syllabus s’attache rigoureusement à détruire les fausses attentes attachées à l’automatisation des tests.

L’arbre qui cache la forêt

« Les organisations sont souvent tellement préoccupées par les tests via l’interface graphique qu’elles oublient que la pyramide des tests suggère que davantage de tests unitaires/composants soient effectués. » Syllabus, partie 1.4

Si vous souhaitez expliquer l’importance de ces tests aux décideurs de votre organisation, ce jeu de sensibilisation aux tests unitaires pourrait vous être utile !

L’importance des logs et des acteurs qui en ont besoin

« Il est primordial qu’un automaticien de tests soit attentif à la précision des logs. Une bonne gestion des logs peut faire la différence entre un projet d’automatisation qui échoue et un projet qui réussit à apporter de la valeur lorsqu’elle est réalisée. » Syllabus, partie 3.1

Nous approuvons fortement cette remarque et vous proposons d’aller plus loin avec cet article, qui propose un moyen d’écrire des logs en langage naturel. Le syllabus met aussi l’accent sur les personnes qui vont avoir besoin de logs et de rapports de qualité :

« Il est important que les automaticiens de test déterminent qui veut ou a besoin de rapports d’exécution des tests, et quelles informations les intéressent. » Syllabus, partie 3.1

Nous espérons que ces éléments vous auront été utiles et que vous vous faites désormais une idée plus précise de la certification A4Q. Bonne révisions si vous envisagez de la passer, et bonne lecture du syllabus dans tous les cas !

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 !

  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é ?

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 !

  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 !

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.

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

  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’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 :