Auteur/autrice : admin@hightest

On dit que les cordonniers sont les plus mal chaussés. Qu’en est-il des testeurs ; sont-ils les plus mal testés ?

De la qualité des tests découle en partie la qualité des applications. Une application de qualité est souvent une application qui a été bien testée. Les tests permettent d’avoir une idée de la qualité des applications, mais qu’est-ce qui permet d’avoir une idée de la qualité des tests ? En quelque sorte, comment tester les tests ?

On peut comprendre cette question dans deux sens différents. D’une part, comment rendre compte de la qualité des tests à un interlocuteur extérieur à l’équipe de test (le présent article) ? D’autre part, comment s’assurer en tant que testeur que nos tests apportent la meilleure valeur ajoutée possible (l’article suivant !) ? Un troisième article traitera de l’épineux et passionnant sujet des KPI (Key Performance Indicators).

Une ligne directrice anime le contenu de ces articles : la prudence. Nous allons voir que le contrôle des tests est une activité hautement piégeuse.

Articles de la série :

1. Organiser le contrôle des tests logiciels
2. Auto-évaluer la qualité de ses tests
3. L’épineuse question des KPI

Quand le contrôle devient contre-productif

Cette question de la qualité des tests, nous l’avons devinée derrière certaines pratiques en vigueur dans les organisations où nous sommes intervenus, parfois sous forme d’un reporting très rigoureux permettant le contrôle de l’exécution des tests. Nous allons voir que toutes les façons de « tester les tests » ne sont pas bonnes.

« Je veux voir tout ce que vous avez testé. »

Par exemple, dans une certaine organisation, des personnes en phase de recette donnaient des preuves très précises de leurs tests en réalisant des copies d’écran à chaque étape. En l’absence d’outillage, cela donnait lieu à d’interminables fichiers Word. Ces personnes produisaient donc une preuve tangible de la bonne exécution des tests… Mais cela occasionnait aussi une perte de temps abominable, pour avoir finalement un livrable très difficilement interprétable.

Ailleurs, d’autres prenaient l’initiative de créer un rapport de bug à chaque fois qu’ils reproduisent une anomalie. Une manière de matérialiser l’activité de test, alors qu’en réalité cette pratique se soldait par un long et fastidieux travail de dédoublonnage.

Ces formes de contrôle n’apportent pas vraiment de valeur, et permettent simplement de vérifier qu’à un moment donné, quelqu’un a suivi les instructions de scénarios de test quelconques.

Quel besoin derrière le contrôle ?

Ces pratiques peuvent en dire long sur la perception des tests, et témoigner peut-être de la vision courante selon laquelle les tests sont une activité improductive. On se retrouve alors face au souci de laisser une trace fidèle, relatant l’ensemble du parcours de test, pour justifier de cette activité auprès de la hiérarchie par exemple.

Cela peut aussi dénoter un manque de confiance dans l’équipe chargée des tests. Mais dans ce cas, à quoi ce manque est-il dû ? Le nombre de bugs trouvés est-il inférieur à ce à quoi on s’attendait ? Des bugs non détectés sont-ils passés en production ? Le contenu des activités de l’équipe de test semble-t-il opaque aux autres services ?

Bref, il est important de disséquer les intentions cachées derrière la demande de preuve de tests. La réponse à apporter sera sans doute alors différente d’un compte-rendu complet des activités de test.

La nécessaire liberté du testeur

Enfonçons le clou encore plus loin. Les outils de gestion des tests proposent des fonctions de reporting très précieuses pour donner des indications sur la qualité des applications testées. Mais il ne faut pas confondre reporting et justification.

Certes, si l’équipe de test exécute seulement 30 % des tests de la campagne prévue, elle devra être en mesure d’expliquer pourquoi. Et les raisons peuvent être excellentes : sélection des tests joués en fonction de l’étude des impacts de l’évolution, optimisation du temps pour livrer dans les meilleurs délais, couverture complémentaire par des tests exploratoires…

Le reporting est un outil qui permet d’appuyer le discours de l’équipe de test. En outre, en aucun cas la nécessité de reporting ne doit empêcher l’équipe de test de procéder à des tests inédits, qui ne seront pas forcément formellement tracés. Tel cas de test écrit peut donner au testeur l’idée de dévier un peu et d’explorer un scénario de test différent, augmentant ainsi la couverture sans pour autant laisser de trace. Cette pratique de « hors-piste » permet d’ailleurs de mettre à l’épreuve les tests écrits. Un nouveau bug détecté ? On écrit un scénario pour compléter le patrimoine existant.

La liberté de tester est essentielle, et il serait contre-productif d’exiger un rapport exhaustif de tous les tests joués lors d’une campagne.

Répondre aux besoins plutôt qu’aux lubies

Une démarche d’élucidation du besoin, par exemple avec la technique des 5 pourquoi, est à mettre en œuvre pour comprendre la nécessité du reporting demandé. De quoi renforcer les liens avec les autres interlocuteurs, tout en se donnant l’occasion d’améliorer ses façons de faire.

Exemple d’échange fictif avec un Project Manager aussi zélé que nerveux :

QA : Pourquoi veux-tu un compte-rendu de tous les tests écrits et exécutés cette semaine ?

PM : Pour voir s’ils couvrent bien ce que j’imagine pour la User Story en cours de développement.

QA : Pourquoi as-tu des doutes là-dessus ?

PM : Parce que je ne sais absolument pas ce qu’il se passe en environnement de test, par exemple comment on crée et utilise les jeux de données.

QA : Pourquoi n’as-tu pas cette vision ?

PM : Je n’ai pas accès à cet environnement.

QA : Pourquoi ?

PM : J’ai fait une demande, mais les développeurs préfèrent ne pas m’y donner accès.

QA : Pourquoi ?

PM : Je pense qu’ils ont peur que je m’affole si je vois des bugs… Cet environnement par nature un peu instable. Du coup, je passe par vous. J’imagine que vous tracez tout ce que vous testez. C’est pour ça que je vous demande ces livrables plutôt que d’insister encore auprès des développeurs.

Dans cet exemple un peu caricatural, on voit que la vraie bonne réponse n’est pas de donner le compte-rendu exhaustif qu’il demande, mais :

• D’approfondir l’inquiétude quant à la User Story évoquée. On dirait en effet que des éléments ne sont pas clairs pour tout le monde
• D’engager un dialogue ouvert entre les développeurs et le Project Manager. Dans quel objectif et sous quelles conditions ce dernier pourrait-il avoir accès à l’environnement de test ?
• De clarifier auprès du Project Manager la façon dont sont organisés les tests. Il faut qu’il comprenne pourquoi (le cas échéant) tout n’est pas systématiquement tracé.
• D’envisager un échange avec le Project Manager au sujet des jeux de données. Il a vraisemblablement des éléments qui pourraient permettre de rendre les tests plus pertinents.

Prévenir plutôt que guérir

Tout ce que nous venons de décrire correspond tout de même à un scénario à éviter au maximum. L’idéal est bien sûr de pouvoir anticiper en y réfléchissant dès le départ. On établit alors au plus tôt à les façons d’évaluer les tests, et de communiquer sur leur qualité. Comme l’écrivent Janet Gregory et Lisa Crispin : « When our work is transparent for the organization, the need for control is reduced ». (More Agile Testing, notre livre de chevet, qui n’a pas pris une ride depuis 2014).

Dès que possible, il sera intéressant d’analyser les éléments attendus pour que chacun puisse avancer sereinement :

• Fréquence, teneur et présentation des rapports de tests
  • Si votre interlocuteur n’a pas d’idée précise en tête, présenter un rapport existant. Faudrait-il imaginer quelque chose de plus fourni, plus clair, plus visuel, moins technique… ?
• KPI (Key Performance Indicators) de l’équipe de test (comme promis, nous y reviendrons prochainement, car ça n’a rien de trivial)
• Accès en lecture aux cas de test et/ou aux campagnes de test
• Implication d’autres équipes dans les activités de test
• Traçabilité plus forte entre les exigences, les cas de test et les anomalies
• Ateliers et réunions

Les possibilités sont infinies et gagnent à être co-construites.

A chaque fois, comprendre l’objectif du livrable demandé, pour être sûr de ne pas faire fausse route (lubie versus besoin !) et pour savoir exactement quoi communiquer.

Et vous, en tant que testeur ou à l’inverse en tant qu’interlocuteur de testeurs, comment organisez-vous la communication sur la qualité des tests logiciels ?

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 !

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

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.

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…

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 :

• Réunion de clôture, un jeu pour finir en beauté (inspiré, de très loin, du Trivial Pursuit)
• Un jeu pour sensibiliser aux tests unitaires (un casse-tête qui vous empêchera de dormir)

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.

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.

De retour chez vous en fin de journée, avez-vous déjà découvert 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 QA, 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 espérer que les internautes lambda 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 QA ?)

En tant qu’internaute, 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 dans un cul de sac, 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 tout de suite ? Je laisse tomber complètement, ou bien je bascule sur un service concurrent.

Résultat : les entreprises reçoivent essentiellement des feedbacks de personnes irrémédiablement bloquées 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 grosse perte d’informations. C’est bien sûr dommageable pour l’organisation concernée.

Une question de confiance ?

Au fond, tout le monde pourrait faire le calcul et envisager les gains, pour soi et pour les autres, d’une remontée d’anomalie. Pourquoi n’est-ce pas le cas ?

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

A titre d’exemple, Facebook semble dissimuler à dessein son formulaire de remontée d’anomalies, et tout dans le parcours qui suit invite plutôt à changer d’avis.

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 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 (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’on l’informera du traitement de « son » anomalie le cas échéant.

Éventuellement, 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 sa clientèle 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 le public et entreprises peuvent être assez intenses concernant l’aspect de la sécurité logicielle. Il s’agit alors essentiellement de personnes expertes 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é (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 » mises 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 les hackers 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 la plateforme Testeum par exemple, la rémunération est identique que l’on trouve des anomalies ou non, ce qui garantit le paiement des testeurs.

Pour continuer d’explorer ce sujet, nous vous suggérons également de consulter l’article « Why I don’t report bugs« , de Cassandra H. L.

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.

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.

Bon jeu et bons échanges autour des tests unitaires !

Vous aimerez peut-être…

Nos autres jeux :

• Le Bingo des Recettes à la Noix
• Notre jeu pour pimenter les réunions de clôture, inspiré (de très loin) du Trivial Pursuit
• Notre série sur la gamification des tests logiciels