Le crowdtesting met-il en danger les testeurs professionnels ?

Rappel : qu’est-ce que le crowdtesting ?

Crowdfunding, crowdlending, crowdsourcing et crowdstorming, de Wikipedia à Wawa.nc… Le pouvoir de la foule n’en est pas à sa première implémentation. Sur la planète Test, le crowdtesting existe maintenant depuis plus d’une décennie, le pionnier uTest (désormais nommé Applause) ayant vu le jour en 2007. De quoi s’agit-il exactement ?

La définition d’un ancien de Google

James Whittaker, dans How Google Tests Software, dont nous parlions précédemment, donne une définition très accessible de cette tendance de fond :

« Le crowdsourcing […] représente une solution au fait que le nombre des testeurs soit limité, de même que leurs ressources matérielles à leur disposition. Les utilisateurs sont quant à eux très nombreux et possèdent tous les environnements qu’on pourrait avoir envie de tester. Et si une sous-population de ces utilisateurs était d’accord pour nous aider ?

Ainsi la foule entre-t-elle en scène. C’est une cohorte d’utilisateurs clés, férus de tests, et qui souhaitent donner un coup de main en échange d’une rémunération raisonnable. Ils n’ont besoin que d’un environnement de pré-production pour exécuter l’application à tester, et d’un mécanisme pour fournir leurs retours et leurs rapports d’anomalies. […]

La foule représente non seulement un grand nombre de machines et de configurations, mais aussi un volume important de perspectives différentes. Au lieu d’avoir un testeur qui essaie de deviner comment mille utilisateurs vont se comporter, on a mille utilisateurs qui se comportent comme des testeurs. Quoi de mieux, quand on souhaite connaître le comportement qu’auront les utilisateurs finaux, que de compiler directement les retours d’utilisateurs réels ? On a besoin de changer d’échelle et de multiplier les variations, et ça, la foule le permet. » (p. 107, traduction Hightest)

L’atout du regard humain

La possibilité d’avoir des retours sur une grande variété d’environnements est le premier atout auquel on pense généralement quand on parle de crowdtesting. Toutefois, ce n’est pas le seul de ce modèle. Pour donner d’autres perspectives d’application du crowdtesting, prenons un autre exemple de Google.

Pour certains services tels que Google Chrome, un système de tests automatisés effectue des comparaisons d’écrans entre la nouvelle et l’ancienne version. Les faux positifs sont évités au maximum, par exemple en ignorant les changements graphiques induits par les publicités incrustées sur les pages web.

Ensuite, les erreurs automatiquement remontées par ce système sont envoyées à des crowdtesters afin qu’ils fassent le tri entre faux positifs et bugs réels.

Là, c’est l’œil humain et son intelligence qui sont sollicités, plus que la diversité des configurations.

Une double promesse

En bref, le crowdtesting promet donc :

  • Pour les éditeurs, un soutien lors des tests pouvant être rapidement sollicité
  • Pour les crowdtesters, un revenu complémentaire

On est sur un modèle de mise en relation gagnant-gagnant. Cela n’est pas sans rappeler bon nombre de services qui ont fleuri cette dernière décennie : Uber, Airbnb, Deliveroo, Blablacar et autres services entre particuliers.

Ici, le besoin des entreprises de faire face à l’explosion des usages numériques répond à l’aspiration d’un nombre important de personnes de s’assurer des fins de mois plus confortables.

Mais comment s’intègre le crowdtesting au sein d’une démarche qualité logicielle ? Le crowdtesting va-t-il à l’encontre des professionnels du test, de même qu’Uber va à l’encontre du secteur des taxis ?

Le positionnement du crowdtesting dans une stratégie de test

Les crowdtesters affectés à une portion du métier du test

Aujourd’hui, les activités des crowdtesters se cantonnent surtout à l’exécution de test et à la rédaction de rapports de bugs. En ce sens, le crowdtesting ne menace pas le cœur de métier du testeur. Le test correspond à une famille d’activités très large :

Les activités des crowdtesters (en jaune) sont en petit nombre par rapport à l’ensemble des autres activités.

Une activité nécessaire de coordination

Afin d’orchestrer ces activités, il faut souvent faire appel à des testeurs qualifiés. Ceux-ci conçoivent les cas de test à soumettre aux crowdtesters et valident leurs rapports d’anomalies.

Cela nécessite un recul important sur la solution. Les tests effectués par les crowdtesters représenteront la plupart du temps un sous-ensemble des tests existants : lesquels choisir ? Pourquoi ?

Le testeur en charge de coordonner des activités de crowdtesting doit traiter ces questions avec attention. En fait, on retrouve pratiquement le même type de réflexion que lorsqu’on se lance dans une stratégie d’automatisation des tests.

Une activité complémentaire en bout de chaîne

En pratique, comme le montrent les témoignages d’entreprises (par exemple celui de B/Acceptance), le crowdtesting ne se substitue pas aux tests existants, si ce n’est aux tests, très coûteux et souvent mis au second plan, de portabilité. Schématiquement, on peut voir émerger la répartition suivante :

  • Un faible nombre de testeurs professionnels réalisent un grand nombre de tests sur un nombre limité d’environnements et de configurations. Ces testeurs automatisent une partie de ces tests.
  • Un grand nombre de crowdtesters réalisent un petit nombre de tests sur un grand nombre d’environnements.

Le crowdtesting met-il en danger l’image du test ?

La plupart des plateformes rémunèrent les testeurs au bug. Dans cette mesure, le modèle actuel du crowdtesting peut donner une vision erronée du métier. En effet, la valeur des tests ne se limite pas au nombre de bugs trouvés !

D’ailleurs, ce qui fait la beauté du test, c’est qu’on est toujours gagnant :

  • soit on gagne une occasion d’améliorer le produit
  • soit on gagne en confiance dans le produit.

Quel sens y a-t-il donc à ne rémunérer un testeur que quelques euros, pour récompenser un bug validé ? Il a peut-être passé deux journées entières à s’efforcer de trouver des anomalies sur un logiciel finalement très robuste. Cette pratique répandue dans le domaine du crowdtesting inhibe certainement des vocations au lieu d’en susciter. Stéphane Colson, dans son article sur le blog Lyon Testing, soulève bon nombre d’autres problèmes : communication insuffisante, informations lacunaires, processus inadaptés. Bref, des conditions de travail qui semblent mettre l’humain au second plan, ce qui rejoint la pensée de M. Six Silberman dans « Ethics and Tactics of Professional Crowdwork » (2010) : « solliciter des crowdworkers rémunérés n’est pas la même chose que de faire un appel d’API, mais bien souvent ils sont traités comme si c’était le cas ».

Plutôt que les professionnels du test, le crowdtesting met donc plutôt en danger l’image du métier du test auprès du grand public.

Vers un crowdtesting éclairé ?

A l’image du métier du test en général, le crowdtesting est un secteur en pleine expansion. Il tend cependant à former une classe de testeurs de seconde zone. Ces nouveaux entrants ne mettent donc pas directement en danger les professionnels du test. En fait, ce serait peut-être même l’inverse… Un aspirant testeur qui souhaiterait se lancer dans le crowdtesting à des fins autres que pédagogiques risquerait de voir sa motivation s’effriter. Dommage dans un contexte où le métier du test manque de profils !

Mal rémunérés et peu guidés dans leur pratique, les crowdtesters sont en quelque sorte traités comme des mercenaires du test. Il y a fort à parier qu’un accompagnement pourrait décupler et valoriser leur potentiel.

EDIT du 14/02/2022 : l’offre de crowdtesting a évolué depuis la publication initiale de cet article. Nous sommes notamment heureux d’avoir mis en place une plateforme en accord avec nos valeurs. Il s’agit de Testeum. Si cela vous intéresse, voici le lien pour vous lancer !

Test Automation University en 12 questions – réponses

1) Qu’est-ce que Test Automation University ?

Test Automation University est un service en ligne gratuit de formation à l’automatisation des tests. Il est rapidement devenu un grand classique dans le domaine de l’automatisation des tests.

2) Comment se déroulent les formations ?

Les cours se présentent comme des séries de vidéos et de textes, qui donnent lieu à des QCM réguliers. Des références complémentaires sont citées au sein des cours de façon à donner des pistes d’approfondissement.

Attention, vous ne pourrez plus accéder au contenu des questions une fois que vous aurez obtenu les résultats des QCM !

3) Les formations Test Automation sont-elles certifiantes ?

Un certificat nominatif est généré à la fin de chaque formation. La notation est généreuse, donc ne surestimez pas la valeur de tels certificats ! Toutefois, ils seront certainement utiles pour mettre en valeur la curiosité d’un candidat : si vous êtes en démarche de reconversion (de développeur à QA par exemple), c’est une piste intéressante qui donnera du corps à votre CV. N’oubliez pas également de jeter aussi un œil à notre article « Comment devenir testeur logiciel » !

4) Combien de temps durent les formations ?

C’est très variable, mais sachez que certains cours peuvent être suivis en entier en moins d’une heure. Par exemple, « AI for Element Selection: Erasing the Pain of Fragile Test Scripts » se compose de 3 vidéos pour un total d’environ 30 minutes.

5) Qui sont les formateurs ?

Là, c’est une merveilleuse surprise. La plateforme est un projet porté par la société Applitools, on pourrait donc s’attendre à du contenu austère et dogmatique issu d’un quelconque éditeur en mal de visibilité. Ce n’est pas du tout le cas. Les formateurs sont tous des experts reconnus dans le monde du test, et sont indépendants les uns des autres. Comme indiqué dans le « cours » de présentation de la plateforme, l’esprit du site est de mettre en valeur une grande diversité de façons de voir l’automatisation des tests. Et ça fonctionne !

De notre côté, nous avons reconnu avec plaisir quelques-uns d’entre eux, dont Jason Arbon, un des co-auteurs de How Google Tests Software (dont nous parlions dans notre article sur les plans de test), et Dave Haeffner, auteur du blog Elemental Selenium, dont nous recommandons la newsletter.

6) Que faut-il attendre du Slack associé ?

Fin juin 2019, ce Slack comptait non moins de 1591 inscrits, pour un total de 6470 messages répartis sur 25 chaînes.

Certaines chaînes ont des thématiques générales, d’autres portent sur des cours de la plateforme. Les formateurs répondent directement aux questions des apprenants.

Quelques questions générales de testing donnent lieu à des discussions entre testeurs (sur des choix d’outils notamment). Certains partagent des ressources en rapport avec le contenu des cours (ce qui nous a permis notamment de découvrir ce joli petit exercice d’entraînement aux sélecteurs CSS, CSS Diner). Cette plateforme deviendra certainement plus active au fil du temps ; en tout état de cause, il y règne déjà une ambiance conviviale et sympathique.

Un canal de ce Slack se consacre uniquement aux petites anomalies présentes sur la plateforme !

7) Les formations sont-elles accessibles aux débutants ?

Sur la page d’accueil, on peut classer les cours de Test Automation University par niveau de difficulté ou par thématique. Les cours débutants sont accessibles aux « grands débutants », surtout si l’on tient compte de la communauté Slack qu’on peut solliciter en cas de problème.

Par exemple, le cours « Web Element Locator Strategies » (un sujet sur lequel nous vous avons mis à l’épreuve !) revient aux fondamentaux : structure des pages web, rôle du HTML, du CSS et du JavaScript, différence entre éléments et sélecteurs… Ce qui en fait un contenu accessible à tous.

8) La plateforme met-elle en œuvre de la gamification ?

A un niveau basique, oui, la plateforme propose une petite surcouche de gamification qui plaira à certains. Au fur et à mesure qu’il gagne des crédits en répondant correctement aux questionnaires, l’utilisateur progresse de niveau en niveau (de « licorne » à « kraken »). En revanche, ces niveaux ne donnent lieu à aucun privilège (fonctionnalités supplémentaires par exemple).

Sur la page de l’utilisateur se trouvent ses badges (un badge par cours, plus à l’heure actuelle un badge spécial) ainsi qu’un camembert représentant l’avancée globale de l’utilisateur sur la plateforme.

EDIT du 14/02/2022 : si vous vous intéressez au sujet de la gamification, vous aurez peut-être plaisir à découvrir notre série d’articles sur le sujet ! Voir le premier de cette série : « Pourquoi gamifier le métier du test logiciel ? »

9) Les vidéos ont-elles une transcription ?

Oui, et elles sont vraiment bien. Elles ne contiennent pas seulement le script que l’on peut entendre dans la vidéo, mais aussi le code qui s’affiche à l’écran (au format texte avec une bonne mise en forme). On peut donc noter un effort d’accessibilité.

10) Test Automation University est-il disponible en français ?

Tout le contenu du site est pour le moment en anglais.

11) Est-ce gratuit ?

Oui, et sans publicité envahissante. A l’heure actuelle il n’y a qu’un lien sponsorisé en bas de la page d’accueil. Les vidéos hébergées sur Youtube vous occasionneront peut-être quelques pubs par-ci par-là, mais cela n’est pas du ressort de la plateforme.

12) Les contenus sont-ils récents ?

À l’heure où nous écrivons cet article, oui ! Le service a vu le jour le 1er premier janvier 2019, avec un premier cours : « Setting the Foundation for Successful Test Automation ».

La plateforme est en effervescence, de nouveaux cours apparaissent quasiment chaque semaine.

Nous avons beaucoup aimé découvrir ce site et lui souhaitons de rencontrer tout le succès qu’il mérite.

Faut-il sauver le plan de test ?

Chez Hightest, on sait tous ce qu’est un plan de test, comme on sait tous ce qu’est un wombat ; certains en ont déjà vu en vrai, d’autres non, et ça ne nous empêche pas de faire du test. Ça vous choque ?

Le plan de test est peut-être le livrable le plus ingrat de notre métier. Comme l’écrivent des testeurs de Google dans « How Google Tests Software ? », les managers traînent avec eux des plans de test comme un enfant garde toujours son doudou avec lui. Ces documents les rassurent, mais ils ne leur accordent pas d’attention particulière, et se plaignent seulement quand ils ne sont pas là.

C’est exagéré ? Il doit quand même y avoir un fond de vérité…

Le plan de test est-il un ennemi de la qualité ?

En contexte agile notamment, mais aussi plus généralement, on comprend les risques que présenterait le fait de toujours produire un volumineux plan de test.

Un tel document peut représenter un risque projet, en ralentissant les équipes de test qui devront s’attacher à longuement rédiger ce référentiel. Et pour quel gain, si personne ne le lit ?

Il pourrait aussi présenter un risque produit, en verrouillant en quelque sorte les testeurs à un engagement à tester d’une certaine façon, au lieu de constamment faire l’effort de s’adapter au produit. En pratique d’ailleurs, la rédaction d’un plan de test en bonne et due forme n’est pas systématique.

Il n’est donc pas si étonnant que de nombreux testeurs n’aient jamais écrit ou même lu un plan de test au sens traditionnel. Faut-il en conclure que ce livrable mérite d’être rangé au grenier ?

Mais au fait, qu’est-ce qu’un plan de test ?

Voici la définition d’un plan de test d’après le « Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels » (août 2012), citant IEEE 829 :

Document décrivant l’étendue, l’approche, les ressources et le planning des activités de test prévues. Il identifie entre autres les éléments et caractéristiques à tester, l’affectation des tâches, le degré d’indépendance des testeurs, l’environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser ainsi que tout risque nécessitant la planification de contingence. Il constitue la documentation du processus de planification de test.

Un template de plan de test correspondant à cette approche pourrait donc suivre la trame suivante :

  • Introduction
  • Présentation de l’équipe de test et de ses liens avec les autres parties prenantes
  • Présentation de l’applicatif à tester
  • Présentation des bases de test et de leur traçabilité avec les tests
  • Liste des fonctionnalités à tester
  • Liste des fonctionnalités à ne pas tester
  • Techniques de conception des tests
  • Techniques d’évaluation des tests
  • Critères de testabilité
  • Conditions de refus de la version
  • Liste des livrables de test
  • Liste des tâches de test en regard avec les personnes impliquées
  • Risques projet et risques produit
  • Planning
  • Environnements requis
  • Besoins spécifiques en outils
  • Besoins spécifiques en formations
  • Besoin spécifiques en prestations

En somme, l’ensemble des informations « méta » qui touchent à la phase de test à venir. Chacune est digne d’intérêt, mais on voit qu’il y en a beaucoup.

Revoir la définition du plan de test ?

On attend peut-être trop de choses différentes d’un seul et même document. Cette liste comprend des éléments qui aident à la coordination inter-équipes, d’autres qui ne concernent que les testeurs. Il y a des parties qui concernent le projet, d’autres qui sont tournées vers le produit.

Pour « sauver le plan de test », il faudrait peut-être trier ces divers éléments afin d’isoler ce qui sera utile au niveau contractuel et ce qui servira de ligne de conduite pour les testeurs. C’est dans cette direction notamment qu’est parti Google.

Un plan de test au service des testeurs

Comment s’en sort Google

« How Google Tests Software ? » Le titre de ce livre est intimidant. A première vue, il laisse penser que Google travaille avec des méthodologies si sophistiquées qu’elles seront totalement inaccessibles aux « plus petits ». Surprise : leur façon de concevoir les plans de test est applicable à la plus petite équipe projet, et elle ne requiert même pas une heure. Ici, le plan de test est un document qui aide les testeurs à concevoir leurs cas de test, une trame opérationnelle à laquelle ils pourront se référer dans le temps, quitte à la faire évoluer. Avec la méthode ACC développée par Google, on va créer non pas un document de type cale-porte, mais une cartographie légère, exploitable et droit-au-but sur laquelle les testeurs pourront se baser pour écrire leurs tests.

La méthode ACC de Google : un plan de test pour ceux qui n’en ont pas le temps

La méthode ACC se base sur trois concepts : les Attributs, les Composants et les Capabilités. Ces trois concepts vont permettre de dresser un schéma de ce qu’on va avoir besoin de tester.

James Whittaker rapporte que l’exercice ne durerait pas plus de 30 minutes. Alors, on se lance ?

Les attributs : des mots pour dire « comment » c’est

La première étape du plan de test ACC est de lister les attributs de l’application.

Qu’entend-on par attribut ? Tout simplement les adjectifs dont on souhaiterait qualifier l’application en production. Des exemples ?

  • Accessible
  • Adaptatif
  • Durable
  • Facile
  • Graphique
  • Interactif
  • Interopérable
  • Navigable
  • Pédagogique
  • Pertinent
  • Rapide
  • Sécurisant
  • Social

Afin de garantir un maximum d’adhésion de la part des parties prenantes (et certainement d’éviter des débats sans fin), l’ouvrage suggère de tirer cette liste d’attributs de documents existants, par exemple des supports issus du marketing.

Les composants : des mots pour dire « ce que » c’est

Deuxième étape du plan de test ACC : lister les composants de l’application.

Peut-être plus simples à trouver, les composants sont les noms des fonctionnalités. Cette liste est généralement facile à trouver : on peut la tirer de cahier des charges, story-mappings, user stories, spécifications

Ceci dit, il est intéressant de revoir cette liste. Plus généralement, ce qui va avoir du sens ici, c’est de créer une liste des entités pouvant donner lieu à des tests spécifiques.

Par exemple, si votre liste de fonctionnalités comprend « Page des nouveautés » et « Page de recherche enregistrée », et que les deux donnent lieu à des notifications, il vous faudra peut-être ajouter l’élément « Notifications » à votre liste de composants, même si cela ne figure pas dans la liste des fonctionnalités.

Les capabilités : au final, ce qu’on peut faire avec l’application

Dernière étape : lister les capabilités de l’application.

Les capabilités représentent les activités effectuées via ou par l’application ; elles sont exprimées par des verbes d’action.

La particularité de ces capabilités, c’est qu’elles se trouvent à la croisée des attributs et des composants. Par exemple, on peut imaginer que sur un client de messagerie, la capabilité « Recevoir les mails commerciaux dans un dossier dédié » correspond au composant « Liste des courriels » et à l’attribut « Bien organisé ».

Ce qui nous permet de ranger ces trois notions dans un tableau à double entrée !

Nous allons tout de suite rendre les choses plus concrètes en présentant un plan de test ACC.

Un exemple de plan de test ACC

Pour cet exemple, nous allons prendre comme exemple l’application FromageZone. FromageZone est une boutique en ligne qui permet d’acheter du fromage en s’aidant des avis d’autres utilisateurs.

Voici le support commercial de FromageZone :

Nous retenons ici 3 attributs : « Intelligent », « Simple » et « Social ». Nous allons aussi prendre la liberté d’extrapoler le terme « commander » en ajoutant l’attribut « Sécurisé », car il est impossible d’imaginer un e-commerce sans notion de sécurité des transactions.

En outre, FromageZone est une application de e-commerce dont les fonctionnalités sont les suivantes :

  • Achat
  • Gestion du compte utilisateur
  • Liste des fromages
  • Détails d’un fromage

En combinant les attributs et les composants, on peut ensuite formaliser les capabilités, ce qui nous donne notre plan de test ACC :

  Intelligent Sécurisé Simple Social
Achat   Payer en ligne en toute sécurité Passer commande en suivant un parcours simple  
Gestion du compte utilisateur   Gérer de manière sécurisée ses préférences de paiement Modifier simplement ses informations utilisateur  
Liste des fromages Visionner en premier les fromages les plus pertinents par rapport à mon profil   Naviguer dans la recherche de fromages en étant efficacement guidé Partager les résultats d’une recherche de fromage
Détails d’un fromage Visionner mon pourcentage de chances d’aimer ce fromage

Visionner les commentaires les plus pertinents sur le fromage

  Visionner simplement toutes les informations du fromage Donner son avis sur le fromage

Chacune des cases non vides devra donner lieu à des tests.

Comment utiliser le plan de test ACC ?

Visualiser les risques

Outre le guidage de la rédaction des tests, l’ouvrage mentionne aussi la possibilité de se servir du plan de test ACC pour visualiser les risques. Chaque case sera verte, jaune ou rouge, en fonction de la moyenne des indices de risque de l’ensemble de ses capabilités. Plus simple que ça, c’est impossible !

Guider les tests exploratoires

De par sa forme tabulaire, le plan de test ACC se prête également bien à l’exercice des tests exploratoires. Lors d’une session, le testeur aura loisir de se concentrer sur une « tranche » horizontale ou verticale de ce tableau.

Limites du plan de test ACC

Certes, l’exercice du plan de test ACC pourra parfois sembler artificiel : par exemple, une capabilité pourra correspondre à deux attributs différents. Il y a également des capabilités dont on saura qu’elles existent, mais qu’on ne pourra pas lier aux attributs cités.

Il est aussi compliqué de savoir comment introduire les tests non-fonctionnels à cette approche sans faire exploser le nombre de colonnes. Ci-dessus nous prévoyions des tests de sécurité (voire également des tests d’utilisabilité), mais quid des tests de performance, de charge, d’accessibilité ?

Le plan de test ACC reste un exercice intéressant à faire, qui permet d’avoir une autre approche sur le produit. Une manière aussi de tester de nouveau une application comme si c’était la première fois.

Conclusion

Une façon de sauver le plan de test serait de convertir ce document protéiforme en un document de travail centré sur une et une seule problématique opérationnelle. Le plan de test ACC de Google est une possibilité parmi d’autres d’aller dans ce sens. Quand le plan de test traditionnel propose de répondre à la très large question « Comment vont se passer les tests ? », cette variante se concentre sur « Que faudra-t-il tester ? ».

Et vous, quelle place donnez-vous au plan de test dans vos projets ?

Le Véritable Plan de Test

Le Bingo des Recettes à la Noix

Dernièrement, nous avons organisé dans nos locaux un petit déjeuner consacré au test logiciel et aux façons d’améliorer les phases de recette. « Phases de recette » ? Eh oui, si cette expression peut sembler désuète pour un testeur habitué à travailler en mode agile, elle représente encore une réalité pour une grande partie des projets informatiques calédoniens.

En guise d’ice-breaker, nous avons proposé un jeu de notre cru : le Bingo des Recettes à la Noix.

Chaque participant se voit confronté à 24 situations ; si cela lui rappelle des souvenirs, à lui d’ajouter une gommette dans la zone correspondante.

L’objectif était de prendre la mesure des pires embrouilles (pour ne pas dire emm…) qui peuvent briser le moral des testeurs en période de recette.

Nous n’avons pas été déçus, le Bingo (rebaptisté presque aussitôt « Mur des Lamentations »…) a suscité de nombreuses discussions. Sans surprise, nous nous sommes aperçus qu’il y aurait fallu bien plus qu’un mur pour lister l’ensemble des situations malheureuses dans lesquelles on peut se retrouver en période de recette !

Voici les résultats de ce jeu, sachant qu’il y avait 15 participants.

Le grand gagnant : le manque de communication formelle

« On me parle d’une décision prise à l’oral et dont il ne reste aucune trace. »

C’est dans cette situation que le plus de participants (10) se sont reconnus.

Quand nous avons créé le jeu, nous pensions par exemple, dans des projets agiles, à des ajustements d’User Stories qui sont décidées à l’oral entre le PO et le développeur concerné, sans que la US ne soit jamais mise à jour. Nous avons déjà vu des conflits germer à cause de cela !

Voir l’article d’Atlas Management sur le sujet, « Respectons le sens des valeurs agiles ».

Qui a peur de la mise en prod ?

« J’ai peur qu’il faille mettre en prod avant la fin des tests, ou qu’il faille décaler la mise en prod. »

Ex-aequo avec la situation suivante, cette situation s’est avérée familière pour 9 participants.

On retrouve là l’emblème récurrent de la qualité comme goulot d’étranglement, des campagnes de test que l’on exécute à la fin du projet « s’il y a le temps », et autres images d’Epinal qui collent encore à la peau de notre beau métier. Et que l’on s’efforce de contredire au quotidien…

Sur ce sujet, plusieurs axes peuvent être creusés : la classique question de la couverture des tests, mais aussi la notion de « Shift-Left », que nous aborderons dans un prochain article.

Le cauchemar du testeur

« Un bug est découvert en production, je m’arrache les cheveux. »

8 personnes se sont reconnues dans cette situation. Ce qui rend les choses encore plus frustrantes, c’est quand le bug ne se manifeste qu’en production, à cause d’environnements de pré-production non iso-prods

Des tests dysfonctionnels ?

« Les tests non-fonctionnels (performances, charge, sécurité) sont laissés de côté. »

Ce constat a été fait par 8 personnes.

C’est un mal fréquent. Comme le souligne Gojko Adzic dans un témoignage recueilli par Janet Gregory et Lisa Crispin dans More Agile Testing (édition Addison-Wesley, p. 109), la notion d’exigence non-fonctionnelle a tendance à intimider les responsables du produit. Il caricature l’attitude que l’on peut avoir, consciemment ou non, face à cette idée : « Cela va donner lieu à une discussion compliquée, laissons tomber. »

Ces tests sont pourtant accessibles à la compréhension de tous, au moins dans les grandes lignes. Voulez-vous rafraîchir votre mémoire avec notre article dédié aux tests de performance, de charge, et consorts ?

Routine contre passion

« La recette approche et je sais que la phase de tests de régression va m’ennuyer. »

8 personnes se sont reconnues. Les tests de régression, lorsqu’ils sont manuels, demandent souvent une patience pénélopique.

Pénélope et les prétendants, tableau du peintre préraphaélite John William Waterhouse, 1912

Contre l’ennui, qui non seulement est désagréable mais peut également amener à des attitudes dangereuses (négligence, biais de confirmation), nous avons un remède. Le mot d’ordre : toujours s’autoriser à aller au-delà du scénario de test écrit, garder son cerveau allumé (suivre un cas de test ne veut pas dire s’auto-automatiser !) et comme le dit Alan Richardson dans Dear Evil Tester, s’efforcer de toujours tester le produit comme si c’était la première fois.

Autre point important : c’est souvent au moment de l’exécution des tests qu’on peut se rendre compte de lacunes au niveau des cas de test écrits. Vous connaissez la règle du boy-scout ? Elle s’applique dans le domaine du développement, mais peut aussi être adoptée par le testeur. Ne perdez jamais une occasion d’améliorer le patrimoine de test.

Le bug pas bien méchant

« Je tombe sur un bug qui n’a jamais été remonté car « il n’est pas bien méchant ». »

Sacrilège ! Une belle collection de bugs se compose de toutes sortes de défauts ; des grands teigneux, des gros mous, des petits qui grattent, des furtifs, des mignons, des poilus, des grégaires…

Collection d'insectes de Debivort, partagée sur Wikipedia

Contrairement à ce qu’on est habitués à penser, les bugs ont de la valeur.

Un rapport de bug :

  • fait gagner du temps aux autres testeurs
  • quand il est bien fait, il en fait aussi gagner aux développeurs
  • permet parfois d’imaginer de nouvelles fonctionnalités
  • permet parfois d’envisager des refontes de l’implémentation.

Alors pas d’excuse, rapportez ce tout petit bug minuscule que vous serez (ou pas !) la seule personne à avoir jamais vu !

Et les autres…

Voici les autres situations proposée dans notre Bingo, de la plus à la moins fréquente.

  • « Je découvre que l’environnement de pré-prod n’est pas identique à celui de la prod. »
  • « Je découvre un bug que personne n’a vu et qui est en prod depuis des mois. » A ce sujet, vous aimerez peut-être lire cet article
  • « Un dev me rétorque que « ce n’était pas dans les specs ». »
  • « Un dev me rétorque que ça marche sur sa machine. »
  • « Je mets à jour le patrimoine de test : ça me prend 150 ans. »
  • « J’ai l’impression que les tests ne couvrent pas tout mais je ne vois pas comment vérifier. »
  • « Je ne sais pas ce que contient exactement la dernière version. »
  • « Un bug corrigé réapparaît dans une version ultérieure. »
  • « Personne ne peut me dire si ce comportement relève du bug ou non. »
  • « L’application fonctionne sur Window 7 avec IE11. Pour le reste, on se fie à notre karma. » Selon un sondage récent auquel une centaine de testeurs ont répondu, il est apparu que 79 % des répondants ne faisaient pas de tests de portabilité !
  • « Quelqu’un dit « Il faudrait automatiser cela » mais personne n’en aura le temps. »
  • « Je me retrouve dans un dialogue de sourds où chacun parle un jargon différent. »
  • « J’ai l’impression d’avoir déjà vu ce bug mais je ne sais plus par quel canal il a été remonté. »
  • « Je rejoue un test car je ne suis pas sûr.e qu’il ait été joué. »
  • « J’ai trouvé le bug de l’année mais je n’arrive à le reproduire que quand je suis tout.e seul.e. »
  • « J’ai créé 387 bugs mais aucun ne semble devoir être traité dans la décennie qui vient. »
  • « Une recette c’est comme un accouchement, à chaque fois c’est différent. » Cette phrase nous vient d’une testeuse que nous avons rencontrée lors d’une mission, une phrase accrocheuse qui nous a bien fait rire !
  • « Je ne trouve pas de bug dans cette version. Je trouve ça louche, très louche. »

Un de nos participants a souligné un biais dans notre Bingo : nous n’avons pas mentionné l’absence totale de tests… Cela nous a fait froid dans le dos ; qui sait le nombre de gommettes qu’aurait reçu cette situation ?

Et vous, qu’auriez-vous ajouté à ce Bingo ?

Merci à tous les participants de notre petit déjeuner, et à bientôt pour un autre événement de ce type !

Retrouvez nos autres jeux dans leurs articles dédiés :

Syllabus ISTQB Fondation 2011-2018 – qu’est-ce qui a changé ?

Vous êtes un vieux de la vieille, vous avez passé le niveau Foundation il y a belle lurette (et peut-être d’autres certifications entre-temps, si oui bravo). Vous n’avez pas le temps ni l’envie de vous replonger dans la Bible du testeur, et pourtant vous vous demandez ce qui a pu changer entre 2011 et 2018. Ca tombe bien, cet article est fait pour ça !

Comment connaître précisément les évolutions du syllabus ?

EDIT d’octobre 2020 : auparavant existant une liste des évolutions entre les deux versions, qui indiquait les changements de manière systématique. Ce document nous a bien aidés pendant la rédaction de cet article, malheureusement il n’est plus disponible.

Au passage, voici le lien vers la version de 2011 du syllabus, et la version de 2018.

Y a-t-il plus de contenu dans la nouvelle version du syllabus ?

Oui, un peu plus, on passe de 82 à 96 pages.

Y a-t-il de nouveaux chapitres ?

Le document listant les évolutions du syllabus indique la création de 6 nouveaux sous-chapitres, mais pour certains il s’agit de thématiques déjà traitées dans la version précédentes, qui ont simplement été structurées différemment.

Les sous-chapitres totalement nouveaux sont les suivants :

  • 1.4.1 : « Le processus de test dans le contexte », p. 18
  • 3.2.4 : « Application des techniques de revue », p. 54
  • 4.4.3 : « Tests basés sur des checklists », p. 65

Qu’est-ce qui a disparu ?

Le code d’éthique, qui était en 1.6.

La nouvelle version du syllabus est-elle plus agile ?

Globalement oui. Des notions propres à l’agilité, et qui étaient absentes dans la version de 2011, sont maintenant évoquées au fil du syllabus. Cela permet de se raccrocher plus facilement à des situations connues et au vocabulaire désormais couramment employé dans les organisations.

Les méthodes et techniques de test agile font cependant l’objet d’une certification à part, l’extension Testeur Agile, qui a aussi son syllabus, daté de 2014.

Exemples de termes apparus entre 2011 et 2018 :

  • User Story (26 fois). La User Story est citée comme une base de test (ce sur quoi on se base pour définir les scénarios de test), mais aussi comme un document que le testeur peut aider à raffiner pour éviter les bugs liés aux ambiguïtés.
  • Epic (4 fois). Idem que pour User Story.
  • Product Owner (9 fois). Ce rôle ainsi que les responsabilités qui lui sont associées sont évoquées dans certains exemples qui permettent encore une fois de faire appel à des situations connues, qui parleront à un maximum de testeurs.

De nouveaux types de tests sont-ils évoqués ?

Oui, notamment les tests d’accessibilité, qui sont mentionnés brièvement à 3 reprises.

Les tests non-fonctionnels sont plus souvent mentionnés (37 fois contre 18 dans la version d’avant).

Quid de l’aspect psychologique des tests ?

Ces dernières années, des articles très intéressants sur les biais cognitifs du testeur sont apparus dans la communauté scientifique (par exemple « Cognitive Biases in Software Quality and Testing » de Iflaah Salman) ainsi que sur le web (voir la série d’articles dédiée sur LyonTesting). Il est satisfaisant de voir que cette notion de biais, absente dans la version de 2011, est aussi régulièrement évoquée dans la version de 2018 (11 fois).

En tant que testeur, il est important de savoir remarquer ses propres automatismes mentaux pour prendre du recul sur sa pratique et améliorer ses tests. Ces passages sur les biais cognitifs sont appréciés donnent de la profondeur au syllabus.

De plus, cette notion permet d’apporter certaines nuances au contenu du syllabus. On ne sous-entend plus que le testeur a une vision plus objective du produit, mais qu’il a des biais différents de ceux qui en sont les auteurs. Cette reformulation est tout à fait constructive.

Cartographie des biais cognitifs

Y a-t-il un 8ème principe du test logiciel ?

Eh… non ! On reste sur le nombre magique de 7.

Quelques changements cependant : le principe 3, « Tester tôt » devient « Tester tôt économise du temps et de l’argent ». Ce même principe évoque maintenant la notion de « shift left », absente dans la version précédente.

Le principe 6 (« Les tests dépendent du contexte ») n’indique plus seulement le contexte produit, mais aussi le contexte projet : « le test dans un projet agile est effectué différemment du test dans un projet à cycle de vie séquentiel ». Cela fait écho au nouveau sous-chapitre 1.4.1, « Le processus de test dans le contexte ».

Pour réviser les 7 principes du test logiciel, on vous suggère de regarder nos broderies faites main sur ce sujet !

Le style du syllabus est-il moins austère ?

Oui, de manière générale le syllabus nous a semblé plus digeste. Les phrases sont moins alambiquées, plus naturelles qu’auparavant.

Les exemples sont plus nombreux (on passe de 53 à 96 « par exemple » !) et mieux expliqués.

La mise en page est également plus claire, avec notamment davantage de listes à puces.

Autres remarques stylistique

Certains anglicismes ont été supprimés (« bug » est devenu « bogue »).

Le métier de testeur n’a pas été féminisé, il n’est nulle part question de « testeuse ».

Faut-il relire le syllabus ?

Oui, allez-y ! Bonne lecture à vous !

Pssst : la photo utilisée pour l’image de couverture de cet article est de Gilles San Martin, un professionnel du portrait de bugs. De nombreuses ressources sont disponibles sur son profil Flickr.

Utilisateur par droit, testeur par devoir ?

Êtes-vous déjà rentré chez vous en fin de journée, pour découvrir dans le miroir que vous aviez de la salade dans les dents ? « Tous ces gens qui l’ont vu et qui ne m’ont rien dit ! » En tant que testeur, c’est ce genre de malaise que l’on ressent lorsqu’on trouve un bug et que l’on se rend compte qu’il est déjà en production depuis plusieurs mois. Mais à quel point devons-nous attendre des utilisateurs qu’ils remontent des anomalies ? Et si l’on renverse les points de vue, dans quelle mesure peut-on considérer que rapporter un bug est un devoir ?

Premier constat : rapporter des bugs n’amuse personne

(… sauf les testeurs ?)

En tant qu’utilisateur, nous poursuivons un but qui nous est propre. Quand nous rencontrons un bug non bloquant, le plus simple est de le contourner. Lorsqu’au contraire on se retrouve bloqué, avant de prendre la décision de demander de l’aide, on réévalue notre but initial. Est-ce que ça peut attendre ? Je réessaierai plus tard. Est-ce vraiment indispensable ? Je laisse tomber complètement, ou bien je bascule sur un service concurrent.

Résultat : les entreprises reçoivent essentiellement des feedbacks d’utilisateurs irrémédiablement bloqués dans leur navigation. Encore faut-il ensuite faire le tri entre les demandes d’assistance (mécompréhension de l’application) et les « vrais » bugs.

En général, il y a donc une perte d’informations dommageable pour l’organisation concernée.

Une question de confiance ?

Au fond, chaque utilisateur pourrait faire le calcul et envisager les gains, pour lui-même et pour les autres utilisateurs à venir, d’une remontée d’anomalie. Pourquoi ne le fait-il pas ?

Outre les problématiques habituelles de manque de temps, peut-être est-ce parce que le chemin paraît incertain, que l’interlocuteur souhaité semble injoignable. Un formulaire de contact trop généraliste ou difficile d’accès suffit certainement à décourager un bon nombre d’utilisateurs.

A titre d’exemple, Facebook semble dissimuler à dessein son formulaire de remontée d’anomalies, et tout dans le parcours utilisateur invite plutôt à se rétracter.

Premièrement, il faut cliquer sur le bouton « point d’interrogation ». Pour quelle raison ? Vouloir communiquer un problème et se poser une question, ce n’est pas la même chose.

Deuxièmement, il faut cliquer sur l’option « Signaler un problème », précédée d’une icône en forme de point d’exclamation (ah, là c’est plus cohérent !)

Troisièmement, quatre options, assez hétéroclites, se présentent dans une modale. Il faut cliquer sur « Quelque chose ne fonctionne pas ».

Un formulaire de rapport de bug s’ouvre enfin, qui permet à l’utilisateur de saisir son problème.

Pour finir, un message de remerciement un peu mielleux affiche (ironie du sort !) une liste d’anomalies connues, qu’il eût été bien avisé de positionner avant l’accès au formulaire.

Cette sinueuse suite d’étapes n’incite pas à la remontée d’anomalies, et pourtant Facebook fait partie des sites les plus fréquentés au monde.

Pour favoriser ces usages, il faudrait adapter le design des applications pour éviter des efforts inutiles à l’utilisateur (ainsi que le travail de dédoublonnage des anomalies en aval), et lui assurer, si la remontée d’anomalie est bel et bien nécessaire :

  • que son retour sera traité en un laps de temps donné
  • qu’il sera informé du traitement de « son » anomalie le cas échéant.

Eventuellement, une compensation (réelle ou symbolique) pourrait lui être attribuée le cas échéant.

En rendant à la fois familier et attractif le processus de remontée d’anomalies, il serait alors possible d’engager véritablement les utilisateurs dans la qualité des services numériques.

La démarche n’en est qu’à ses débuts, même si l’on peut observer ici et là quelques petites trouvailles d’UX (comme l’onglet ci-dessous, discret mais toujours présent sur l’interface web d’AdopteUnMec.com).

Cependant, au moins deux domaines contredisent ce premier constat : la sécurité informatique et le monde du jeu vidéo.

Sécurité informatique : une symbiose plus ou moins organisée

Les échanges entre utilisateurs et entreprises peuvent être assez intenses concernant l’aspect de la sécurité logicielle. Il s’agit alors essentiellement d’utilisateurs experts en la matière qui recherchent activement des failles de sécurité. Leurs motivations peuvent être de toutes natures. Elles sont tantôt sociétales, visant à protéger la communauté des utilisateurs (dans ce cas, on est clairement dans une optique de devoir citoyen). Elles peuvent également être vénales dans une certaine mesure, si l’on tient compte des politiques de « bugs bounties » mis en place par les grands noms du web ou des opportunités de recrutement occasionnées. Le processus de feedback est parfois structuré de manière à inclure le hacker white-hat dans la chaîne de production logicielle.

Dernièrement, ce fonctionnement a reçu de la part de l’Union Européenne une véritable reconnaissance dans la mesure où cette institution a lancé en 2019 un bug bounty sur quinze des logiciels libres très utilisés (dont VLC, Drupal, Notepad++ et FileZilla).

Les médias évoquent l’initiative avec enthousiasme, scandant avec gourmandise les montants des rémunérations hypothétiques. Rappelons tout de même que cette « chasse au trésor » ne profitera qu’à ceux qui trouveront des anomalies (pour la première fois), et non à ceux qui confirmeront, par l’échec de leurs tentatives d’intrusion, la robustesse des applicatifs. Pourtant, l’une et l’autre de ces issues ont de l’importance. Il y a un décalage paradoxal entre l’urgence des enjeux de sécurité informatique et les moyens déployés, qui reproduisent sans complexe le mécanisme de la machine à sous, où seul l’alignement des trois paires de cerises profitera au joueur assidu.

Early-access : un pacte sous le sceau de la qualité

Tu paies tout ou partie du prix du produit, et tu obtiens en accès anticipé une version inachevée de celui-ci. Dans le monde du biscuit, on aurait droit à des paquets d’Oreo à 50 XPF, pour découvrir peut-être que certains ne contiennent pas de crème vanillée (ou sont même carrément immangeables, carbonisés). Quelques mois plus tard, on recevrait éventuellement un deuxième paquet gratuit, rempli de biscuits parfaits. Ce contrat vous conviendrait-il ?

Les offres d’accès anticipé (ou early-access) sont très variées et comportent toutes un risque : le jeu pourrait très bien s’avérer rempli de bugs et ne jamais être finalisé. Certains jeux passent par des rebondissements des plus burlesques. D’autres sortent au bout de plusieurs années, comme DayZ qui est resté en version alpha de décembre 2013 à décembre 2018. Nombreux sont ceux qui se découragent de voir sortir un jour Star Citizen, en alpha depuis juin 2014.

Le early-access, en résumé, c’est un pacte entre un joueur enthousiasmé par un produit, et une équipe de développement ayant besoin d’alimenter leur trésorerie avant la release finale.

Les retours sur la qualité (et surtout sur les bugs ou glitches) du jeu sont très bienvenus. Voir par exemple les consignes de rapport d’anomalie prodiguées par l’équipe de Sad Square, éditeur du jeu Visage dont le jeu est sorti en accès anticipé en octobre dernier. Le joueur est invité d’abord à vérifier si « son » bug a déjà été rapporté, à trouver un moyen de le reproduire, puis à rédiger le rapport en tant que tel en suivant une trame prédéfinie, comprenant les informations de jeu, les étapes de reproduction, etc. Pour être rigoureux, il n’est pas excessif de penser que le processus entier dure entre 15 minutes voire 30 minutes au minimum.

Sans cette sollicitation de rapports de bugs, on pourrait comparer le modèle du early-access à la vente de billets pour les pool parties du Kuendu Beach, qui sont à 1500 XPF en pré-vente et 2500 XPF sur place. Le produit est le même, mais ceux qui prennent le risque de payer à l’avance (sans savoir par exemple s’il pleuvra des cordes le jour même) sont récompensés par un prix plus avantageux.

Mais force est de constater que le rôle du joueur va plus loin que ça. On peut considérer que les bénéficiaires de l’accès anticipé sont amenés à réaliser un travail de testeur, un travail rémunéré par avance, au forfait, grâce au tarif préférentiel. La frontière entre producteur et consommateur se brouille. La responsabilité de la qualité semble de déplacer du côté de l’utilisateur, et le travail du testeur se cantonner à un forfait bloqué, au-delà duquel il faudra œuvrer bénévolement, pour l’amour de l’art.

Si cette problématique vous intéresse, nous vous conseillons cet article de fond consacré au modèle économique de l’accès anticipé.

Une question de responsabilités ?

Faire participer les utilisateurs à la remontée des anomalies et plus globalement à la démarche qualité d’un produit pose donc un certain nombre de problèmes, et en premier lieu celui de la responsabilité.

Marie-Anne Dujarier, dans son essai Le Travail du consommateur, De Mac Do à eBay : comment nous coproduisons ce que nous achetons, met au jour la manière dont un certain nombre de tâches ont été déléguées aux consommateurs, que ce soit dans le monde physique (peser ses fruits et légumes au supermarché) ou numérique (faire la promotion d’une marque sur les réseaux sociaux). Ce phénomène est une véritable tendance de fond qui s’invite subrepticement dans nos vies. Il structure parfois des processus auxquels on ne peut pas échapper, comme si nous étions une partie d’une chaîne de production minutieusement conçus ; impossible par exemple d’attendre à une table au Mac Donald que l’on prenne notre commande, comme de quitter ladite en laissant les reliefs du repas aux soins d’un inexistant employé de salle. Lorsqu’un client entre dans un fast-food, il accepte tacitement le rôle que l’enseigne lui confère. D’ailleurs, s’il s’assied à une table souillée de soda et de frites, ce n’est pas à la chaîne qu’il s’en prendra dans ses vitupérations, mais bien à l’incivilité de ses semblables.

De la même manière, un produit buggé sera-t-il à terme la faute des utilisateurs réputés négligents, dont on aurait attendu qu’ils préviennent dès que possible les équipes techniques ?

Il faudrait trouver un équilibre entre optimisation de la qualité à l’aide des utilisateurs d’une part et responsabilisation des éditeurs d’autre part. Exercice difficile qui, nous l’espérons, s’illustrera dans les années à venir par des dispositifs innovants.

Pour finir sur une note pragmatique, en tant qu’utilisateur, nous vous proposons de retenir ces derniers points :

  • Si vous avez payé pour accéder au produit, vous n’êtes pas tenu de fournir un travail bénévole à son éditeur.
  • Si vous n’avez pas payé pour accéder à ce produit mais que son modèle économique repose sur l’exploitation de vos données, vous n’êtes pas non plus tenu de fournir un travail bénévole à son éditeur.
  • Toute contribution bénévole à l’amélioration de ce produit est un acte surérogatoire qui vous honore, et non un devoir qui vous incombe.
  • Tentez d’obtenir une compensation proportionnelle en tant qu’échange de bons procédés (bon d’achat, réduction, entrée gratuite…)

En parallèle, à nous d’inventer les meilleures façons d’écouter nos utilisateurs, mais aussi et surtout de compenser leurs efforts.

Le crowdtesting comme filet de sécurité

Le crowdtesting, ou test participatif, représente un moyen d’anticiper les problématiques rencontrées en production par les utilisateurs réels. En général, les campagnes de test participatif ont lieu en amont d’une mise en production. On peut voir cette pratique comme un filet de sécurité, en complément des canaux à mettre en place pour permettre à l’ensemble des utilisateurs de remonter les anomalies trouvées.

Le crowdtesting prévoit une rémunération pour les testeurs ; la relation gagnant-gagnant est garantie dès le début. Sur notre plateforme Testeum, la rémunération est identique que l’on trouve des anomalies ou non, ce qui garantit le paiement des testeurs. Si vous souhaitez vous inscrire, c’est par ici !

Les xPath et les tableaux : 8 exercices pour se perfectionner

Il est vrai, rien ne surpasse les id dans les techniques d’identification des objets dans un DOM. C’est le plus simple et aussi le plus rapide à trouver par Selenium. Mais parfois (souvent) on ne peut pas faire autrement que d’écrire des xPath tellement complexes qu’ils frisent le « write-only ». Ces moments de solitude arrivent souvent lorsqu’on interagit avec des tableaux. On met 10 minutes à trouver la bonne formule et deux semaines après on ne s’en souvient plus. Nous voulons que ce temps soit révolu !

Voici donc 8 défis pour vous entraîner à écrire des xPath pour attraper des éléments dans des tableaux. Pour vérifier vos réponses nous vous conseillons l’outil CSS and XPath checker.

Les réponses se trouvent en bas de l’article.

xPath vs tableau HTML

Dans cet exercice, nous nous baserons sur ce tableau fruité. Vous pourrez valider vous-mêmes les formules sur la présente page.

Fruit Description Prix au kilo (XPF)
Pomme-liane Un feu d’artifice de saveurs acidulées 700
Banane poingo Le compromis entre la patate et la banane 500
Pomme-cannelle De loin, ressemble à un artichaut 630
Letchi Ce n’est plus la saison 700
Noix de coco Son germe est délicieux 350
Chouchoute Oups, ce n’est pas un fruit 300

Sous chaque question se trouve une copie d’écran du tableau avec le résultat attendu en surbrillance.

Exercices de xPath pour identifier des éléments dans le tableau

1) Ecrire un xPath pour récupérer la deuxième cellule qui contient « Pomme ».

2) Ecrire un xPath pour récupérer la première case des lignes dont la colonne 3 contient la chaîne 700.

3) Ecrire un xPath pour récupérer la deuxième case après les cellules contenant « Pomme-cannelle ».

4) Ecrire un xPath pour récupérer les cases qui contiennent des prix entre 300 (inclus) et 630 (exclu).

5) En hommage à Georges Perec, écrire un xPath pour récupérer les cases qui ne contiennent pas de « e » minuscule (cases de l’entête du tableau comprises).

6) Ecrire un xPath pour récupérer les lignes qui contiennent une case dont le texte commence par « Oups ».

7) Ecrire un xPath pour récupérer les cellules du tableau (hors entête) qui contiennent la chaîne « de », qu’elle soit en minuscules ou en majuscules.

8) Allez, un bien compliqué pour finir. Ecrire un xPath pour récupérer les noms des fruits dont la description contient le texte « est » et dont le prix est entre 300 (inclus) et 630 (exclu).

Alors, combien d’exercices avez-vous réussi à faire ? 😀

Rappel de bonnes pratiques

Attention, même s’il est préférable d’avoir des sélecteurs simples à comprendre, ne faites pas reposer la lisibilité de votre projet d’automatisation sur la lisibilité de vos sélecteurs. Envisagez l’adoption de l’objet Selecteur tel que nous détaillions dans notre article sur la lisibilité des logs Selenium :

public class Selecteur {
   public String nom;
   public By chemin;

   public Selecteur(String nom, By chemin){
      this.nom = nom;
      this.chemin = chemin;
   }

   public String getNom(){
      return nom;
   }

   public By getChemin(){
      return chemin;
   }
}

Avec comme exemple d’application :

protected void clickElementTableau(int ligne, int colonne) {
    Selecteur cellule = new Selecteur("la cellule située sur la ligne " + ligne + " et la colonne " + colonne + " du tableau", By.xpath("//tr[" + ligne + "]/td[" + colonne + "]"));
    logger.info("Clic sur " + cellule.getNom());
    driver.findElement(cellule.getChemin()).click();
}

En sortie, vous aurez des logs en langage naturel, par exemple : « Clic sur la cellule située sur la ligne 3 et la colonne 4 du tableau ».

Rappels sur les xPath

  • les xPath sont en base 1, c’est-à-dire que le premier élément d’une série a comme index 1, contrairement, par exemple, aux tableaux et aux listes Java dont le premier élément a pour index 0.
  • les xPath sont sensibles à la casse quand on fait une recherche sur du texte ou un attribut

Solutions

Il existe souvent plusieurs solutions possibles, celles ci-dessous ne sont que des possibilités.

1. Un xPath pour récupérer la deuxième cellule qui contient « Pomme » :

(//td[contains(., 'Pomme')])[2]

2. Un xPath pour récupérer la première case des lignes dont la colonne 3 contient la chaîne 700 :

//td[3][contains(., '700')]//../td[1]

3. Un xPath pour récupérer la deuxième case après la cellule qui contient « Pomme-cannelle » :

//td[contains(., 'Pomme-cannelle')]/following-sibling::td[2]

4. Un xPath pour récupérer les cases qui contiennent des prix entre 300 (inclus) et 630 (exclu) :

//td[. >= 300 and 630 > .]

5. Un xPath pour récupérer les cases qui ne contiennent pas de « e » minuscule (cases de l’entête du tableau comprises) :

//td[not(contains(., 'e'))] | //th[not(contains(., 'e'))]

6. Un xPath pour récupérer les lignes qui contiennent une case dont le texte commence par « Oups » :

//td[starts-with(., 'Oups')]/parent::tr

7. Un xPath pour récupérer les cellules du tableau (hors entête) qui contiennent la chaîne « de », qu’elle soit en minuscules ou en majuscules :

//td[contains(translate(., 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz'), 'de')]

Conseil : si possible encapsuler cette transformation de casse dans une fonction.

8. Un xPath pour récupérer les noms des fruits dont la description contient le texte « est » et dont le prix est entre 300 (inclus) et 630 (exclu).

//td[. >= 300 and 630 > .]/preceding-sibling::td[contains(., 'est')]/preceding-sibling::td

Même exercice pour les sélecteurs CSS

Mise à jour du 24 juin 2019 : nous avons découvert, grâce à une personne sur le Slack de la Test Automation University, un exercice en ligne pour s’entraîner à écrire des sélecteurs CSS. Un petit jeu interactif réjouissant et très bien fait : découvrez CSS Diner !

Tests autos d’applis lourdes : le défi du gratuit

Attention, cet article date d’il y a plusieurs années et ne correspond peut-être plus à l’état de l’art. Pour découvrir nos derniers articles, nous vous invitons à consulter la page d’accueil de notre blog !

________________

Vous venez du monde de Selenium, vous aimez ce framework gratuit, sa souplesse, la beauté du pattern page-object et son DSL aux petits oignons. Magnifique, mais aujourd’hui vous devez automatiser les tests d’une application lourde.

Il y a quelques années encore, choisir un outil d’automatisation gratuit et open-source pour ce genre de tests était un sérieux défi et présentait de nombreux risques : frameworks peu maintenus, résultats instables… Une solution propriétaire telle qu’UFT pouvait alors s’imposer comme un choix par défaut.

Est-ce différent aujourd’hui ? Nous pensons que certaines solutions sont désormais assez mûres pour être choisies au sein de projets de test ambitieux.

Pywinauto : go !

Ce nom incongru est la contraction de Python, Windows et Automation. Ce framework de test a vu le jour en 2006 (!), et donne lieu à des releases régulières depuis 2015. La version 1.0 n’est pas encore sortie (modestie de la part de Vasily Ryabov, développeur de Pywinauto ?) mais à l’utilisation, l’outil est parfaitement stable.

Avantages de Pywinauto

Utilisable dans tout IDE Python, la solution permet à l’utilisateur d’architecturer les projets de tests comme bon lui semble. Nous avons opté pour le pattern page-object, un grand classique qui permet de maintenir facilement les tests.

Principes

Identification des objets pour Pywinauto

L’identification des objets d’application Windows peut se faire grâce à des outils comme Inspect.exe, fourni avec le SDK Windows. UI Spy peut aussi être envisagé, mais il n’est plus maintenu par Microsoft. Cependant, à l’usage, nous l’avons trouvé plus rapide.

Grâce à ces utilitaires, il est possible de connaître les paramètres des objets, et donc de les identifier pour interagir avec eux (voir la liste des paramètres gérés par Pywinauto).

Interaction avec les objets avec Pywinauto

Dans l’exemple ci-dessous, nous déclarons ainsi une page ainsi que quelques objets, en utilisant au besoin plusieurs paramètres.

class AccueilPage:

    def __init__(self, test):
        self.ECRAN_ACCUEIL = test.app.window(title='Ma super appli - Accueil')
        self.INPUT_NOM = self.ECRAN_ACCUEIL.child_window(control_type="Edit", auto_id='23', found_index=0)
        self.INPUT_PRENOM = self.ECRAN_ACCUEIL.child_window(control_type="Edit", auto_id='24', found_index=0)

Dans l’architecture que nous avons mise en place, un test doit être invoqué au moment de l’appel du constructeur de la page. Ce test est initialisé au début de chaque scénario et correspond à la classe suivante :

class Test:
    app = Application(backend='uia')

    def __init__(self):
        parser = argparse.ArgumentParser()
        parser.add_argument("--log", help="enable logging", type=str, required=False)
        args = parser.parse_args()

        actionlogger.enable()
        logger = logging.getLogger('pywinauto')
        if args.log:
            logger.handlers[0] = logging.FileHandler(args.log)

        self.app = Application(backend='uia').start(r'C:cheminversmasuperappli.EXE')

Selon la façon dont l’application a été développée, certains objets ont un titre qui est affiché dans l’arborescence, ici d’UI Spy :

Dans cet exemple, on peut interagir avec le bouton « Appliquer » en utilisant le mot-clé title :

test.app.window(title='Appliquer')

Points d’attention

Certains objets complexes, par exemple des cellules de tableaux spécifiques, n’apparaissent pas toujours dans l’arborescence. Ce n’est pas nécessairement un problème provenant de Pywinauto, mais il faut garder en tête des solutions de contournement, par exemple la reconnaissance d’image que l’on trouve entre autres avec Sikulix.

Verdict

De notre côté, c’est un go ! Pywinauto a toute sa place au sein d’un POC, et a en outre l’avantage d’avoir un support efficace. Vasily Ryabov est très réactif sur Github aussi bien que sur StackOverflow, ce qui permet d’aller au-delà des blocages éventuels. EDIT du 19/20/2020 : et c’est toujours vrai en 2020 !

Winium : no go !

Framework basé sur Selenium et adapté aux applications Windows, la promesse de Winium est (était) séduisante… Malheureusement, il n’est plus maintenu et certains bugs empêchent de s’en servir efficacement. Nous vous expliquons cependant ce qui nous a plu et déplu dans cet outil, qui reste une excellente initiative.

Avantages de Winium

Pour un habitué de Selenium, la transition se fait en douceur ; les mêmes méthodes peuvent être utilisées dans la plupart des cas.

Vous ne rêvez pas ! On dirait bien un test Selenium…

Problèmes rencontrés

Identification des éléments

Afin d’interagir avec les objets de l’application à tester, plusieurs méthodes sont possibles (mais moins que pour Pywinauto). De la plus à la moins robuste, on peut procéder :

  • Par Id
  • Par Name
  • Par ClassName
  • Par Xpath

Les trois premiers paramètres, que l’on peut trouver avec les outils mentionnés précédemment, sont les plus pratiques à utiliser. Malheureusement, ils ne sont pas toujours renseignés. Il faut  alors avoir recours à la recherche par xPath, ce qui peut être plus difficile dans ce contexte que dans celui d’un DOM HTML.

Quelle que soit la méthode utilisée, les éléments semblent être trouvés d’autant plus lentement que l’interface compte un grand nombre d’objets.

Comme solution de contournement pour accélérer le test, nous avons utilisé Sikulix, avec toutes les questions que cela soulève côté maintenance.

Bug de focus

Nous avons relevé un bug assez ennuyeux : il arrive que l’application cible ne reçoive pas le focus pendant les tests. Pour peu que la fenêtre de l’IDE soit affichée, on se retrouve à taper l’identifiant en lieu et place du script de test.

A part fermer les fenêtres inutiles et réduire la fenêtre de l’IDE après le lancement de la campagne, nous n’avons pas trouvé de solution à ce problème.

Des nouvelles du créateur de Winium

Les logiciels ne poussent pas dans les arbres, en l’occurrence Winium est la création de Nick Abalov, actuellement développeur chez Badoo. Sur Twitter, il a gentiment répondu à notre question « Winium est-il mort ? » :

For Windows Desktop automation you might want to look into https://t.co/2agvjg2Kdj

— Nick Abalov (@NickAb) 20 décembre 2018

<script>

A suivre alors, WinAppDriver présentant cependant la contrainte de nécessiter un environnement Windows 10.

Verdict

Pour nous, c’est donc un no-go. Il est possible de mettre en place de petits projets d’automatisation en utilisant Winium, mais entamer un projet ambitieux avec cet outil serait imprudent.

Et vous, quels frameworks gratuits d’automatisation d’applications lourdes utilisez-vous ?

Un jeu pour sensibiliser aux tests unitaires

Dans l’article précédent, nous parlions d’un de nos jeux permettant de clôturer un projet en faisant le point dans la bonne humeur. Aujourd’hui ça continue, car c’est important de jouer avec la qualité !

Les tests unitaires : une expérience à vivre

Dans certaines organisations, il existe une dette technique importante concernant les tests unitaires. Mettre en œuvre une reprise de cette dette demande du temps et du budget, et il est important que les décisionnaires comprennent précisément l’intérêt d’un tel chantier. Le problème : les tests unitaires sont généralement dans la partie invisible de l’iceberg.

Un acteur du projet se tient en haut de l'iceberg logiciel. Il ne voit que la partie visible du projet : un logiciel qui marche à peu près.

Le jeu présenté ici va permettre de répondre à cette problématique. Il va être question de développer une application sans tests unitaires, puis avec ; une application constituée non pas de classes, de méthodes, d’API et de bases de données, mais de cartes à jouer !

Le jeu : « Avec ou sans tests unitaires ? »

Combien peuvent jouer ?

Vous pouvez jouer à ce jeu de 2 à N personnes, la seule limite étant l’espace et le nombre de jeux de cartes dont vous disposerez !

Une personne doit endosser le rôle de sentinelle de la qualité (super classe, non ?). A vue de nez, ce sera vous !

Matériel

  • 2 jeux de cartes par équipe (idéalement, une équipe ne dépassera pas les 4 personnes). Il est possible de ne jouer qu’avec une équipe.
  • De quoi montrer les règles de gestion (projecteur, fiches imprimées…)
  • Un chronomètre

Déroulement du jeu

Le jeu se joue en 2 sessions de 10 tours, qui simulent 10 sprints.

Au début de chaque session, l’application est composée de 4 cartes tirées au hasard dans le jeu (on part rarement de rien…) Il n’est pas important de conserver ces 4 cartes au cours de la partie, cela constitue simplement un point de départ.

La sentinelle lance un chronomètre, ce qui va constituer un levier de pression en cas de bavardage entre les participants ! En effet, la deadline est dans 10 minutes, mais comme ça arrive parfois, la mise en prod risque d’être décalée…

A chacun des 10 tours, une règle est lue par la sentinelle. La règle du tour est lue par la sentinelle uniquement pendant le tour N. Elle peut être répétée à volonté au cours du tour, mais en aucun cas après. La sentinelle peut être assez tranchante sur ce point :

« La règle du tour d’avant ? Vous devriez vous en souvenir ! ».

On passe au tour suivant dès que les « devs » considèrent que c’est terminé.

Bien sûr, toutes les règles doivent être respectées à l’issue des 10 tours.

Une autre phrase peut être retenue, par exemple si les personnes se posent des questions sur la meilleure implémentation à fournir :

« Je me fiche des détails techniques, je veux juste que l’application corresponde à toutes mes règles métier. »

Il n’y a pas de temps limite, mais la sentinelle est invitée à presser et stresser les devs. La durée visée est de 10 minutes par session.

Tous les membres de l’équipe ont le même rôle. C’est à l’équipe de valider à l’issue des 10 sprints que l’application fonctionne comme demandé.

Première session

Les règles de la première session sont les suivantes :

  1. La plus petite carte de carreau a sa jumelle dans tous les autres signes.
  2. Toutes les cartes de trèfle sont présentes en double.
  3. Le code contient deux piques de plus que de trèfle.
  4. Le code ne doit pas contenir de 2, 4, 6 et 10.
  5. Les dames et les as sont respectivement présents en nombre impair.
  6. Il n’y a pas de carte de carreau inférieure au valet.
  7. Toutes les cartes de trèfle ont au moins une jumelle dans les piques, mais l’inverse n’est pas forcément vrai.
  8. Toutes les cartes de pique ont au moins une jumelle dans les cœurs, mais l’inverse n’est pas forcément vrai.
  9. Le nombre de cartes de carreau correspond au plus petit nombre que l’on peut trouver sur une carte de cœur.
  10. Il y a 2 fois plus de cartes de cœur que de cartes de pique.

A la fin de la session, la sentinelle montre l’ensemble des 10 règles qui ont été lues à tour de rôle, et les équipes comptent le nombre de règles qu’elles ont et n’ont pas respectées.

Après cela, la sentinelle peut éventuellement interroger les équipes. Quelques idées de questions :

  • Quels ont été vos ressentis pendant cette session ?
  • Avez-vous été plus rapides au début ou à la fin des 10 sprints ?
  • La qualité était-elle meilleure au début ou à la fin des 10 sprints ?
  • Comment a évolué l’ambiance de l’équipe au cours des 10 sprints ?
  • Que faudrait-il améliorer ?
  • Que pourrait-on changer ?

NB : si des personnes vous rétorquent que des règles se contredisent, vous pourrez leur présenter a posteriori une solution possible :

Coeur Pique Trèfle Carreau
1

K

Q

Q

V

V

9

9

1

K

K

Q

1

1

1

Deuxième session

La deuxième session se déroule comme la première, à la différence que cette fois, la sentinelle met à disposition des équipes chaque RG énoncée. Ainsi, au tour 4, les personnes auront accès aux RG 1, 2, 3 et 4.

Les règles de la deuxième session sont les suivantes :

  1. Toutes les cartes de cœur sont présentes en double.
  2. Le nombre de cartes de trèfle correspond au plus petit nombre que l’on peut trouver sur une carte de pique.
  3. La plus petite carte de trèfle a sa jumelle dans tous les autres signes.
  4. Il y a 2 fois plus de cartes de pique que de cartes de carreau.
  5. Il n’y a pas de carte de trèfle inférieure au valet.
  6. Les dames et les as sont présents en nombre impair.
  7. Le code contient deux carreaux de plus que de cœur.
  8. Le code ne doit pas contenir de 2, 4, 6 et 10.
  9. Toutes les cartes de cœur ont au moins une jumelle dans les carreaux, mais l’inverse n’est pas forcément vrai.
  10. Toutes les cartes de carreau ont au moins une jumelle dans les piques, mais l’inverse n’est pas forcément vrai.

Les règles des deux sessions sont les mêmes, seuls les signes changent et l’ordre d’énonciation des règles ! Une solution possible pour la deuxième session est donc :

Pique Carreau Coeur Trèfle
1

K

Q

Q

V

V

9

9

1

K

K

Q

1

1

1

Prévoyez un temps d’échange après la deuxième session. Les mêmes questions qu’après la première session pourront être posées. Vous verrez les parallèles s’établir entre les vérifications humaines et les tests unitaires (beaucoup plus rapides soit dit en passant !)

La conclusion naturelle de ce jeu sera : les TU permettent de vérifier à tout moment la présence de régression, et même de les anticiper.

Un bon préambule avant d’organiser en pratique la résolution de la dette technique.

L'acteur projet plonge au fond de l'eau pour apercevoir tous les aspects cachés d'un projet réussi : spécifications bien écrites, gestion des tests, tests unitaires...

Bon jeu et bons échanges autour des tests unitaires !

Vous aimerez peut-être…

Nos autres jeux :

Réunion de clôture : un jeu pour finir en beauté !

En fin de projet, il est temps de faire le point sur les éventuelles insatisfactions, frustrations et tensions accumulées chemin faisant, et de réfléchir ensemble à des moyens d’y remédier à l’avenir.

En partenariat avec Atlas Management, à l’occasion d’une réunion de clôture, nous avons conçu un jeu inédit que nous vous présentons ici.

Libre à vous de l’adapter et de le faire vôtre !

Principe du jeu

Le jeu se joue sur un plateau dont le motif ressemble à celui du Trivial Pursuit : des cases disposées sur le périmètre d’un cercle et sur des rayons de celui-ci, avec la case départ au centre du cercle.

Chaque case correspond à une activité ou à un bonus. Chaque case est présente plusieurs fois sur le plateau. Dans notre cas, nous avons choisi d’illustrer chaque case par une icône présente dans l’applicatif recetté.

Le jeu est semi-coopératif : en 1 heure, il faut que l’équipe réalise toutes les activités (nous en avions 11), mais chaque joueur peut choisir de perdre un peu du temps de l’équipe en se rendant sur des cases de bonus individuel !

Chacun leur tour, les joueurs font avancer leur pion avec le dé. Lorsque le joueur dont c’est le tour tombe sur une case d’activité, il lit à voix haute la carte associée. Toute l’équipe participe à l’activité. Lorsque le joueur tombe sur une case bonus, il récupère son bonus et on passe au joueur suivant.

Si une case a déjà été visitée, le joueur qui arrive dessus peut rejouer.

Matériel nécessaire

  • 1 équipe motivée !
  • 1 plateau de jeu comme décrit ci-dessus
  • Les cartes associées à chaque case (cela sera détaillé ci-dessous)
  • 1 pion par joueur
  • 1 dé
  • 1 stylo par joueur
  • 1 bloc de postits par joueur
  • 1 mur avec une zone par activité (nous avons simplement collé au mur des répliques de chaque case)
  • Des petits cadeaux pour les cases bonus ! Pour cette fois, nous avons prévu des bonbons fabriqués en Nouvelle-Calédonie ainsi que des goodies Hightest et Atlas Management (clés USB et stylos-lasers) (conseil : choisissez les bonbons, ils sont plus sucrés !)

Les cartes du jeu

Voici des exemples d’activités que nous avons proposées. Les possibilités sont infinies, laissez parler votre imagination !

A titre indicatif, dans notre version, les participants étaient essentiellement des personnes ayant recetté le produit. Les questions à poser dépendent beaucoup des personnes qui seront présentes au jeu.

Cartes d’activités

La loterie de la qualité

Votre organisation gagne une somme ahurissante à la loterie. Vous avez la possibilité de demander plusieurs centaines de millions pour améliorer le produit (ses fonctionnalités, son interface, son infrastructure technique…) selon vos préférences. Que choisissez-vous de demander ?

Note : pour cette activité comme pour les suivantes, chaque joueur est invité à écrire sa réponse sur un postit et à aller le coller sur le mur, dans la zone dédiée à l’activité, en lisant sa réponse. Plusieurs postits par personne sont acceptés. Les échanges sont également les bienvenus, dont les points importants seront notés par le maître du jeu. Attention toutefois à respecter le timing !

La transfusion de cerveaux

Regardez vos collègues et souvenez-vous de toutes les informations contenues dans leurs cerveaux et qui vous ont ou vous auraient été bien utiles au cours des derniers mois. Si vous pouviez recevoir, par transfusion directe, des informations de première main pour les prochaines recettes, que choisiriez-vous ?

Le génie des ressources humaines

En vous promenant sur la place des Cocotiers, vous trouvez une petite lampe coincée entre un pavé et un bout de noix de coco. Vous essuyez la lampe et un génie en sort. « Merci de m’avoir convoqué », dit-il, « je suis le génie des ressources humaines. Je peux te fournir n’importe qui pour n’importe quelle tâche pour t’aider à recetter la prochaine version du produit. Quel est ton rêve le plus fou ? »

Le génie logiciel (le fameux !)

Ce matin, en allumant votre ordinateur, en lieu et place de votre écran d’accueil, vous voyez un gros visage hilare. « Je suis le génie logiciel », dit-il, « les lampes magiques c’est has-been, moi je vis dans les ordinateurs. Tu as été particulièrement habile lors de la dernière recette et je t’en remercie, j’ai passé le week-end dans le code source et je me suis bien amusé. Pour te remercier, je vais t’accorder un super pouvoir que tu pourras utiliser lors de la prochaine recette. Que choisis-tu ? »

Note : ces activités contenant des génies nous ont été inspirées par un format de rétrospective dédié.

L’Oscar de la Meilleure Recette

Vous recevez l’Oscar de la Meilleure Recette. Alors que vous allez chercher ce trophée, on vous fait comprendre que vous devez faire un discours. Vous vous exécutez, une larme d’émotion au coin de l’oeil. Qui remerciez-vous ?

La machine à remonter le temps

Ce matin en entrant dans votre bureau, vous voyez qu’une étrange machine trône au milieu. Une notice indique que c’est une machine à remonter le temps. Vous avez la possibilité d’annuler ou de modifier certaines choses que vous avez faites pendant la recette. Que choisissez-vous de faire ?

Un colis pour eux

Un conteneur de colis part en direction de la ville de l’équipe de développement. L’un de ces colis lui est destiné et contient un petit cadeau de votre part pour marquer la fin de ce marathon et repartir sur de bonnes bases en anticipation de la prochaine livraison. Que contient ce colis ?

Un colis pour vous

L’équipe de développement vous a envoyé un colis. Vous êtes en route pour vous acquitter des droits de douane. A votre avis, que contient le colis ?

Faites-vous plaisir !

Vous recevez un chèque en blanc pour vous offrir un petit quelque chose qui améliorerait grandement votre quotidien lors de la prochaine recette. Que choisissez-vous d’acheter ?

Une carte postale éclair

C’est le moment d’envoyer une carte postale à un membre du projet ou à une équipe ayant participé au projet. Faites vite car la poste ferme dans 2 minutes !

Cartes bonus

  • Votre collègue préféré a oublié la clé de son armoire a bonbons sur votre bureau. Profitez-en !
  • Êtes-vous bien réveillés ? A 3, montrez du doigt la personne impliquée sur le projet depuis le plus longtemps. 1-2-3… Les personnes ayant la bonne réponse gagnent un paquet de bonbons.
  • L’équipe qui tombe sur cette case doit retrouver l’auteur de la citation suivante : « Insérez ici un bon mot d’un de vos collègues qui vous a marqué au sujet du projet ! ». Le premier qui trouve la bonne réponse gagne un paquet de bonbons.
  • Vos collègues apprécient votre disponibilité. Pour vous remercier, ils vous offrent cette magnifique clé USB Atlas Management !
  • Vos collègues se délectent de vos documentations. Pour vous remercier, ils vous offrent cette magnifique clé USB Hightest.
  • Aujourd’hui c’est Noël, vos collègues vous ont offert un magnifique stylo Hightest !
  • Aujourd’hui c’est votre anniversaire, vos collègues vous ont offert un magnifique stylo Atlas !

Bonne réunion de clôture, et n’hésitez pas à suggérer d’autres cartes d’activité ou de bonus dans les commentaires !

Merci à ceux qui ont participé à notre jeu, c’était un plaisir !

Pour aller plus loin

Le site Retromat est une mine d’or en matière de rétrospectives (et est donc tout indiqué pour les projets en Scrum, mais pas seulement). En page d’accueil, vous trouverez notamment un assortiment aléatoire d’activités, applicable immédiatement pour les plus courageux !

Vous aimerez peut-être…

Nos autres jeux :

Mais aussi :

5 graphiques Jira pour mieux communiquer sur les anomalies

Testeur en contexte Agile