Catégorie : Méthodologie

Nous avons le plaisir de vous dire que cet article a été écrit à quatre mains, avec Brice Roselier. Expérimenté en test, il a mis en place des KPI afin de suivre la progression de la qualité des activités de test dans son contexte.

Comment communiquer sur la qualité des tests ? Quels indicateurs de performance produire ? Comment suivre l’évolution de ces indicateurs ? Nous abordons ces questions pour faire suite aux deux derniers articles, portant respectivement sur l’organisation du contrôle des tests et sur l’auto-évaluation de la qualité des tests.

Voilà en tous cas une épineuse question, et le sujet devient d’autant plus glissant lorsqu’il est motivé par des problématiques d’intéressement. Il a donné lieu à un passionnant débat il y a quelques mois sur LinkedIn, dans le groupe « Le métier du test » (si vous n’y êtes pas encore, c’est vraiment le moment de le rejoindre, ça représente plus de 3900 testeurs passionnés !).

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

Les métriques de la mort

Avant toute chose, et avant que vous ne fermiez cet onglet parce que votre collègue vous appelle sur un sujet plus urgent, voici une liste de KPI à ne jamais, jamais, jamais envisager. S’il vous plaît. Please. Por favor.

Le nombre de bugs créés

Vous voulez vraiment vous retrouver avec un gros paquet de bugs doublonneux ? Ou vous retrouver dans une situation horriblement paradoxale, où les testeurs auraient envie que l’application soit de mauvaise qualité…

Le nombre de cas de test écrits

Un référentiel de tests c’est comme une maison : tu peux y ajouter des objets, mais tu dois aussi te débarrasser de ceux qui t’encombrent et ne te servent à rien, lutter contre la poussière et ranger le mieux que tu peux.

Le nombre de scripts de tests automatisés

Bonjour la maintenance si vous optez pour ce KPI. C’est comme si un développeur était rémunéré à la ligne de code…

La durée des tests

« Nous visons à réaliser des campagnes de test qui durent moins de 8 heures. »

Quelle belle résolution, et quelle tentation de créer un KPI associé vu qu’il y a 3 semaines on a même tout bouclé en 7 heures. Hélas, encore une fois on se retrouve dans un champ de peaux de bananes. Les activités de test sont largement impactées par la qualité constatée de l’application à tester.

Comme le souligne Gerald M. Weinberg dans Perfect Software, and other illusions about testing (2008), si les testeurs trouvent un grand nombre de bugs et passent du temps à les analyser, l’avancement de leur campagne sera nécessairement ralenti. Pour autant, sans analyse, la plupart des rapports de bugs ne sont que de médiocres ânonnements.

Toutes les métriques citées sont intéressantes lorsqu’elles sont contextualisées, mais ne devraient pas être utilisées comme KPI au risque de se retrouver à faire de la « gonflette ». Comme le dit un de nos amis développeurs de Nouvelle-Calédonie, « No disco muscle boy, we want strength! »

Quelques prudentes suggestions

De manière générale, les KPI sont à définir en bonne intelligence avec les autres membres de l’équipe. Il faut en premier lieu garder en tête la grande différence qui existe entre une simple métrique et un véritable KPI, qui peut être une métrique à laquelle on attribue une valeur de performance, ou un ensemble de métriques consolidées.

Et de même qu’on distingue la notion de « Créer un produit bien fait » et de « Créer le bon produit », on peut distinguer d’une part la notion « Faire bien les tests » et « Faire les bons tests ».

Quelques pistes peuvent être réfléchies ensemble :

• Les bugs non trouvés dans l’environnement de test, et qui sont remontés par des utilisateurs en production
  • Ça fait mal. Il faudrait aussi pouvoir s’assurer que le bug pouvait effectivement être trouvé en environnement de test. Ce n’est malheureusement pas toujours le cas… Ce KPI pourrait être remonté sous forme de ratio ou de valeur absolue, et être qualifié par exemple par le niveau de criticité du bug.
  • Avec ce KPI, on vérifie qu’on « fait les bons tests ».
• La qualité des rapports d’anomalie
  • Toute la difficulté sera d’établir des critères objectifs et de trouver le meilleur moyen de mettre en place cette évaluation. Sera-t-elle attribuée par un représentant de l’équipe de développement ? Par un collège de développeurs ? Par le team leader des testeurs ?
  • Avec ce KPI, on vérifie qu’on « fait bien les tests ».
• Le ratio de tests de régression d’importance haute automatisés versus non automatisés
  • Il est un peu moins facile de « tricher » avec ce chiffre, mais encore une fois attention à la gonflette…
  • Avec ce KPI, on vérifie également qu’on « fait bien les tests ».

Ce ne sont là que quelques exemples assez génériques, la définition des KPI devant prendre en compte les caractéristiques du produit, du projet et de l’équipe. Un grand sage disait : « Les tests dépendent du contexte »…

Suivre ses KPI à la trace

Une fois en place, les KPI doivent être suivis et exploités, c’est d’ailleurs tout leur intérêt. Pour des raisons de simplicité, cherchez à automatiser la relevée de vos KPI, de façon à les mettre à jour simplement et rapidement. En effet, pour suivre vos KPI, ceux-ci devront être régulièrement mis à jour. Le faire manuellement est à la fois un risque d’erreur, chronophage et surtout peu réjouissant !

Une fois que les KPI donnent une valeur, idéalement de façon automatique, vous devez vous en servir pour progresser. Posez-vous la question sur la façon dont vous exploitez les données brutes (les indicateurs), c’est-à-dire les unités de mesure et leur contexte. Par exemple, si votre KPI se base sur une charge en jours-hommes, est-ce que cette valeur représente le sprint en cours, la release, toute la période depuis le début du projet, ou bien le mois en cours, depuis le début de l’année ou même une période glissante (les 12 derniers mois) ? Il y a plusieurs moyens de faire parler vos indicateurs qui sont la matière première de vos KPI.

Ensuite, fixez-vous des objectifs, SMART de préférence, de façon à voir vos KPI embellir avec l’âge. Un objectif SMART est, comme l’indique cet acronyme, Spécifique, Mesurable, Acceptable (à la fois Ambitieux et Atteignable), Réaliste et Temporellement défini.

Je doute que le simple affichage de vos KPI ne vous satisfasse. Ces valeurs, vous voulez les voir évoluer car elles traduiront un progrès (ou pas) de votre processus de test et/ou de votre équipe. Pour cela, fixez-vous une valeur légèrement meilleure, et tentez de l’atteindre dans un délai relativement court. Cela vous donnera une idée de ce à quoi vous pouvez prétendre. Enfin, si vous souhaitez améliorer votre KPI sur la durée, planifiez un plan de progrès sur une période (par exemple augmenter la valeur de votre KPI de 10% en un an) avec des jalons intermédiaires qui vous mèneront à votre objectif.

Quelques exemples d’indicateurs et KPI

Dans un premier temps, listez les indicateurs que vous souhaitez suivre et réfléchissez à la manière dont vous allez les alimenter. A partir de là, alimentez vos indicateurs et KPI progressivement. Le piège étant, comme dit plus haut, qu’un indicateur puisse s’exprimer de plusieurs façons.

Tout le monde le sait, à court terme, le test est une charge qui augmente le budget d’un projet. Vous devez donc chercher à améliorer le ratio entre la qualité apportée par les tests et l’énergie à fournir pour atteindre ce résultat. Un peu à l’image d’un compte-tours, plus la vitesse est élevée et moins le moteur tourne rapidement, plus il est efficace.

A ce stade, c’est bien l’efficacité des tests que l’on souhaite mesurer et non la qualité intrinsèque de l’objet de test. Le tout étant de faire vivre les indicateurs et KPI dans le temps et chercher à améliorer le processus de test.

A titre d’exemple, voici ci-dessous la liste de quelques indicateurs que Brice suit chez lui.

Indicateurs liés aux anomalies

KPI associés : 

~ Anomalies détectées et confirmées / Anomalies non détectées

~ Anomalies corrigées / Anomalies non résolues

• Anomalie non détectée (faux négatif) : un classique de chez classique. Ce sont les anomalies qui passent entre les mailles du filet. L’utilisateur remonte une ano que le test n’a pas vu. On le mesure sous forme de coefficient qui représente la somme du nombre d’anomalies pondéré par leur criticité (on peut imaginer un barème 1, 3 et 20 pour mineur, majeur, bloquant). Pour aller plus loin vous pouvez même chercher à mesurer la quantité d’utilisateurs concernés par ces faux négatifs.
• Anomalies détectées et confirmées : on considère que l’anomalie n’est pas un faux positif et qu’elle n’est pas en doublon. Ici on ne se focalise pas sur la criticité, on compte simplement le nombre d’anomalies détectées via un test auto ou manuel.

Exemple de représentation des anomalies détectées :

Ici 2072 anomalies ont été détectées dont 64 critiques, 662 majeures et 1346 mineures.

Représentation de graphique représentant la provenance des anomalies détectées :

Exemple de graphique représentant la répartition des anomalies détectées par module :

• Anomalies non résolues : ça arrive, ce sont les anomalies peu impactantes que l’on accepte d’avoir en production, car elles sont coûteuses à corriger, liées à un contexte très particulier pour les reproduire et qu’il n’y a pas assez de temps pour les traiter avant la sortie de la version. Cet indicateur permet d’estimer l’effort de correction à court terme et la confiance à la clôture des tests. Comme les faux négatifs, on l’exprime sous forme de coefficient en pondérant la criticité des anomalies. Cet indicateur donne en premier lieu une information sur la qualité du livrable, mais dans un second temps on peut avoir ici un axe d’amélioration du processus de test : les anomalies sont peut-être découvertes trop tard. Cela donne aussi une estimation pour la campagne suivante car les anomalies non résolues donneront lieu à des tests de confirmation.

Exemple de représentation des anomalies non résolues :

Dans cet exemple, depuis la première version de l’application, 650 anomalies n’ont pas été résolues, dont 16 critiques, 213 majeures et 421 mineures. En affectant un barème de 20 points pour une anomalie critique, 3 points pour une majeure et 1 point pour une mineure cela donne un coefficient global de 1380.

Exemple de graphique représentant la répartition des coefficients des anomalies non résolues :

• Anomalies corrigées : nombre d’anomalies pondérées par leur criticité ayant été corrigées (sous forme de coefficient). Ici on cherche à mesurer l’amélioration de la qualité apportée grâce aux tests.
• Faux positifs et doublons : avec cet indicateur, on va chercher à mesurer l’effort de test sans valeur ajoutée. C’est-à-dire ce qui génère du temps passé pour rien. On peut le mesurer sous forme d’entier positif et le mesurer en pourcentage par rapport au nombre d’anomalies détectées. 10 faux positifs sur 20 anomalies c’est beaucoup, pour 1000 anomalies c’est mieux !

Représentation de graphique représentant la provenance des faux positifs :

Indicateurs liés à la complétude des tests

KPI associé :

~ Couverture du code

• Couverture du code : quantité du code exécuté au moins une fois pendant les tests. On cherche à mesurer la profondeur (in)suffisante des tests. On la mesure en pourcentage sur les fichiers, les lignes et les conditions couvertes. Cette couverture peut être calculée avec un outil d’analyse statique tel que SonarQube pour les tests unitaires, mais pas seulement. Chez Brice le code métier est en C, à la compilation peuvent être ajoutées des options pour générer des traces à l’exécution. En manipulant ces traces on peut donc calculer la couverture même sur du test système réalisé en boîte noire.
• Couverture des exigences : mesure la profondeur (in)suffisante des tests et la confiance à la clôture des tests. Cela permet également de prioriser les tests. On l’exprime sous forme de pourcentage, qui correspond au nombre de tests en succès divisé par le nombre de tests rattachés à l’exigence.

Indicateurs liés à la capacité d’exécution des tests

Pas de KPI ici, ce sont des indicateurs fortement influencés par les développeurs et le contexte (si tous les testeurs sont malades, pas de test)

• Quantité d’exécution cumulée : répartie sur chacun des niveaux de tests. On compte le cumul du nombre de fois qu’un test a été exécuté dans sa vie. Cela permet de mesurer la vélocité : le nombre moyen de tests qu’il est possible d’exécuter sur une campagne donnée.
• Nombre de retests : moyenne des aller-retour entre les équipes de test et les développeurs. C’est en quelque sorte le nombre de fois qu’un développeur s’y est repris pour résoudre une anomalie. Derrière, ça veut dire que le testeur va consommer du temps pour retester, requalifier l’anomalie en expliquant pourquoi l’anomalie n’est toujours pas résolue, joindre des impressions d’écran, des logs etc. et quand même retester plus tard. Il faut aussi comprendre pourquoi une anomalie a été difficile à résoudre. La description de l’anomalie n’était peut-être pas claire ou insuffisante (on a trouvé le défaut dans un contexte mais il se retrouve aussi dans d’autres).
• Quantité de régressions : on montre ici le niveau de maturité des tests de bas niveau et la suffisance en termes d’effort de test avant les niveaux supérieurs, mais ce qui nous importe le plus c’est de mesurer l’effort de test sur des articles qui ont été validés avant. On montre l’impact des modifications sur l’activité de test (test, analyse, retest, gestion de l’anomalie…).

Indicateurs liés au patrimoine de tests

Pas de KPI, ce sont des indicateurs sur les tests, pas de quoi soulever la coupe !

• Taux d’automatisation des tests : répartition du nombre de tests automatisés dans le patrimoine. Tout comme le patrimoine, Brice cherche à suivre l’avancement de l’automatisation, ce qui donne une information sur la capacité à tester. Il représente toutefois une charge de maintenance à ne pas oublier (comme un test manuel) ; la qualité de la conception des tests automatisés impactera fortement cet effort de maintenance.
• Tests sans anomalie : sur une campagne ou même sur un laps de temps, combien de tests n’ont trouvé aucune anomalie ? Ils peuvent questionner sur leur capacité à trouver de nouveaux défauts. Ces tests feront l’objet d’une revue à court terme, et seront peut-être obsolètes. On les mesure sous la forme d’un entier positif.
• Volumétrie des tests : cet indicateur mesure quantitativement le patrimoine de test. Il peut être intéressant si aucun test n’est encore formalisé dans un outil. Il peut se mesurer sous la forme d’un entier positif pour chaque type de test (voir diversification des tests).
• Diversification des tests : un petit indicateur qui exprime le nombre de types de tests implémentés dans le patrimoine de test : performance, fonctionnel, accessibilité, validation W3C etc. On l’exprime sous la forme d’un entier positif.

Indicateurs liés aux coûts des tests :

Pas de KPI, mais ces indicateurs sont comme le compte-tours du moteur

• Charge de test : effort du processus de test (manuel et automatisation). Ça représente le coût total (humain) des tests. En d’autres mots, le temps total passé par les équipes sur des activités de test. On l’exprime en jours-hommes (que l’on peut ensuite multiplier par un TJM) et en ETP.
• Charge d’automatisation : effort de test sur la partie automatisation, à savoir l’implémentation des scripts de test, le développement des briques (techniques et fonctionnelles), des étapes et des outils liés à l’automatisation. Cela permet de mesurer le coût d’automatisation des tests. Brice l’a découpée en 5 valeurs (respectivement pour 5 types d’activités dans l’automatisation) exprimées en jours-hommes.
• Coût interne d’une défaillance : c’est la charge de correction d’une anomalie. Cela dépasse le périmètre de tests mais permet de prendre un peu de hauteur en mesurant tout ce qu’une anomalie détectée par l’équipe des testeurs implique dans le service y compris en conception et développement.
• Coût de détection : c’est une extension de la charge de test à laquelle on ajoute les coûts de l’infra, les licences des outils, leur administration, leur maintenance etc.

Bibliographie

Pour clôturer cette série (déjà !), rien que pour vous, voici quelques ressources qui vous aideront à repenser la qualité de vos tests.

• Miserere nobis patrimonium – Ayions pitié de notre patrimoine, un article du wiki Fan de test qui donne encore plus envie de s’y mettre.
• Perfect Software, and other illusions about testing, Gerald M. Weinberg, 2008. Le chapitre 8 (« What makes a good test ? ») détruit les idées reçues sur la qualité des tests.
• Dear Evil Tester, Alan Richardson, 2016. En particulier la partie « What is the most evil metric ? »
• The way of the web tester de Jonathan Rasmusson, 2016. Cet ouvrage contient un grand nombre de bonnes pratiques de développement de tests fonctionnels automatisés (pour applications web). Peut-être pourra-t-il vous servir pour mettre en place en interne vos propres standards !
• Test logiciel en pratique de John Watkins, 2001. Le chapitre 12 est dédié à l’amélioration du processus de test.

Dans notre article précédent, nous donnions des pistes pour organiser le contrôle des tests par des instances extérieures à l’équipe de test. En effet, il n’est pas rare d’avoir à rendre des comptes sur les activités de test, et cela peut même être une bonne opportunité pour roder un peu mieux ses pratiques.

A force de discussions, de réflexions, de compromis et d’idées merveilleuses, nous avons désormais un cadre de travail qui nous permet de communiquer sur les tests et d’indiquer la valeur ajoutée des différents livrables de l’équipe de test. Cependant, ce sont des indicateurs globaux, et qui témoignent a posteriori de la qualité du travail produit. Maintenant, comment « tester les tests » au plus tôt, de façon à ce que ces indicateurs soient toujours votre plus grande fierté ?

On quitte maintenant la sphère de la communication inter-équipes, pour rentrer dans le (très) vif du sujet, à savoir dans la passionnante popotte interne de l’équipe de test.

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

Chercher les failles des tests plutôt que valider leur qualité

Comme l’indique Gerald M. Weinberg dans Perfect Software, and other illusions about testing (2008), la qualité d’un test ne peut pas être démontrée. Un référentiel de tests excellent aura d’ailleurs, selon son exemple, le même résultat qu’un référentiel de tests « sale » après une campagne passée sur un applicatif totalement dénué de bugs. Scénario purement théorique bien sûr…

En réalité, de même que les tests révèlent la présence de défauts d’une application (premier principe du test logiciel), la revue d’un test ne peut pas révéler sa qualité.

Ce n’est que l’analyse a posteriori qui pourrait permettre de déduire le niveau de qualité des tests, notamment en tenant compte des bugs qui n’ont pas été détectés par les tests. Et encore, cette analyse ne serait jamais complète, car nous ne pouvons jamais savoir combien de bugs existent sans avoir été détectés.

Gerald M. Weinberg préconise, plutôt que simplement attendre de pouvoir faire cette analyse a posteriori, de :

• revoir sa couverture et ses oracles en anticipant les erreurs
• créer de la variabilité dans les tests existants
• comparer en parallèle différentes façons de tester

Un poil diabolique, il raconte également, en tant que développeur, avoir gardé secret un bug pour voir à quel moment il serait détecté par l’équipe de test. A méditer !

En bref, il n’est pas possible de savoir si des tests sont bons, mais certains signes peuvent indiquer qu’ils ne le sont pas.

Une interrogation intériorisée par l’équipe…

Qui forme le formateur de formateurs de formateurs ? Qui relit le relecteur ? Qui coache le coach ?…

En tant qu’animateurs de la qualité, il appartient aux testeurs de toujours rester vigilants sur la qualité de leurs propres tests. Cela peut passer par des actions à mettre en œuvre dans son équipe :

• Validation croisée des cas de test
• Revue des scripts de tests automatisés, mise en place de bonnes pratiques de développement
• Amélioration des cas de test pendant l’exécution des campagnes
• Sessions de tests exploratoires
• Révision des tests en regard des anomalies trouvées en-dehors des scénarios de test écrits
• Maintenance et restructuration du patrimoine de tests

Tout cela vous semble évident ? Mais le faites-vous vraiment, ou seulement quand « il y a le temps » ? Ces activités sont-elles connues et reconnues par les autres parties prenantes ?

Ces validations internes peuvent donner lieu à des checklists permettant de valider tel ou tel livrable de test. Pourquoi ne pas imaginer également des Definition of Done spécifiques ?

Exemple de Definition of Done d’un ensemble de tests portant sur une exigence :

• Les tests comptent à la fois des « Happy paths », des « Sad paths » et des « Ugly paths » (cas passants, cas non passants et cas « tordus »)
• Les tests sont liés clairement à l’exigence dans un souci de traçabilité
• Les métadonnées des tests sont correctement renseignées
• Les jeux de données indiqués dans les tests sont facilement trouvables / facilement maintenables
• Le vocabulaire utilisé est conforme au lexique approuvé par l’ensemble des acteurs du projet (comment ça, votre équipe n’a pas encore de lexique ? :D)
• Les tests ont été révisés par un autre testeur
• N’importe quel autre critère qui vous semblera à la fois pertinent et simple à vérifier.

Etudier également chaque cas de découverte de bug en production pourrait aussi permettre à l’équipe de test d’identifier ses lacunes et de les corriger. Cette démarche gagnerait à être explicite, et non expédiée honteusement comme un enfant qui cache sous un meuble les fragments de l’assiette qu’il vient de faire tomber…

… et par chaque testeur individuellement

Certes, les équipes de testeurs ne sont pas toujours suffisamment fournies pour organiser des activités internes de révision et de validation croisée des tests. Dans bien des cas, c’est au testeur que revient la tâche de « tester » ses propres tests. Dans cette mesure, la question « Comment teste-t-on les tests ? » devrait être intériorisée par le testeur lui-même, de façon à animer ses activités.

En somme, « Comment teste-t-on les tests ? » pourrait bien être une question à poser à un testeur lors d’un entretien d’embauche. Un mélange de savoir-faire (techniques adaptées de revue des tests) et de savoir-être (esprit critique, crainte du bug en prod, etc.) pouvant être attendus.

Dans notre prochain article, nous nous pencherons sur ce qui constitue peut-être le point le plus épineux de cette série (et il y en a eu !), à savoir les KPI.

A très vite !

Addendum – novembre 2020 : un mot sur le mutation testing

Tester les tests unitaires est possible grâce à une pratique que l’on appelle le mutation testing. Cela consiste à générer des changements aléatoires dans le code et à vérifier si les tests unitaires repèrent ces changements. Cela simule en fin de compte des régressions qui pourraient être introduites par du nouveau code ou un réusinage (refacto) maladroit. Des outils sont spécialisés dans ce type de test, par exemple Pitest.

Quoi de plus parlant pour illustrer l’intérêt des tests unitaires ?

Quelques ressources

Si vous n’avez qu’une minute à consacrer à ce sujet, ce post LinkedIn de Michaël Azerhad résume très bien, et avec un exemple pratique, l’apport de cette technique.

Si vous avez 10 minutes, offrez-vous la lecture de cette présentation de la JFTL 2019 signée Vincent Huc, Amandine Jaufeeraully et Marie Isoard.

Enfin, vous avez une heure entière, le visionnage de cette vidéo vous profitera. Il s’agit d’une conférence en anglais signée Sven Ruppert.

Merci à la communauté LinkedIn francophone de la qualité logicielle pour ces précieuses suggestions de lecture !

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.

Ê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 !

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