Auto-évaluer la qualité de ses tests

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 !

Organiser le contrôle des tests logiciels

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 ?

Cette question peut être prise 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 seulement 30 % des tests de la campagne prévue ont été exécutés, l’équipe de test 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 qui est en train d’être développée.

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 les jeux de données qui sont créés et comment ils sont utilisés.

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 sur 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 demandé, mais :

  • D’approfondir l’inquiétude quant à la User Story évoquée : on dirait 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, afin 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 réfléchissant dès le départ à des façons d’évaluer les tests et de communiquer sur la qualité des tests. 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 ?

Le crowdtesting met-il en danger les testeurs professionnels ?

Rappel : qu’est-ce que le crowdtesting ?

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

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

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

A l’heure actuelle, les crowdtesters sont largement cantonnés à l’exécution des cas de test manuels et à la rédaction de rapports d’anomalies. En ce sens, le crowdtesting ne menace pas le cœur de métier du testeur, qui correspond à une famille d’activités très large :

Les activités menées par les crowdtesters (en jaune sur le schéma) sont en petit nombre par rapport à l’ensemble des autres activités.

Une activité nécessaire de coordination

Afin d’orchestrer ces activités, des testeurs qualifiés sont bien souvent requis, pour concevoir les cas de test à soumettre aux crowdtesters ainsi que valider leurs rapports de test.

Cela nécessite un recul important sur la solution, car 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 l’attention et la qualité d’analyse qu’elles méritent.

En réalité, on se retrouve pratiquement avec le même type de réflexion à mener 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 (et éventuellement automatisent) un grand nombre de tests sur un nombre limité d’environnements et de configurations
  • 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 ?

Dans la mesure notamment où la plupart des plateformes rémunèrent les testeurs au bug, le modèle actuel du crowdtesting peut donner une vision erronée du métier. En effet, et tout testeur le sait, l’activité de test ne se limite jamais à l’exécution de fastidieux cas de test, et 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é, alors qu’il aurait 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, mais qui tend à 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, peu guidés dans leur pratique et en quelque sorte traités comme des mercenaires du test, il y a fort à parier que le potentiel des crowdtesters pourrait être décuplé en accompagnant et en valorisant davantage cette population.

Faut-il sauver le plan de test ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Revoir la définition du plan de test ?

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

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

Un plan de test au service des testeurs

Comment s’en sort Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Un exemple de plan de test ACC

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

Voici le support commercial de FromageZone :

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

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

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

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

 

Intelligent

Sécurisé

Simple

Social

Achat

 

Payer en ligne en toute sécurité

Passer commande en suivant un parcours simple

 

Gestion du compte utilisateur

 

Gérer de manière sécurisée ses préférences de paiement

Modifier simplement ses informations utilisateur

 

Liste des fromages

Visionner en premier les fromages les plus pertinents par rapport à mon profil

 

Naviguer dans la recherche de fromages en étant efficacement guidé

Partager les résultats d’une recherche de fromage

Détails d’un fromage

Visionner mon pourcentage de chances d’aimer ce fromage

Visionner les commentaires les plus pertinents sur le fromage

 

Visionner simplement toutes les informations du fromage

Donner son avis sur le fromage

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

Comment utiliser le plan de test ACC ?

Visualiser les risques

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

Guider les tests exploratoires

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

Limites du plan de test ACC

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

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

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

Conclusion

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

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

 

Le Véritable Plan de Test

Le Bingo des Recettes à la Noix

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

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

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

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

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

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

Le grand gagnant : le manque de communication formelle

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

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

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

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

Qui a peur de la mise en prod ?

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

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

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

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

Le cauchemar du testeur

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

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

Des tests dysfonctionnels ?

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

Ce constat a été fait par 8 personnes.

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

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

Routine contre passion

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

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

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

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

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

Le bug pas bien méchant

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

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

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

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

Un rapport de bug :

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

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

Et les autres…

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

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

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

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

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

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

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

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

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

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

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

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

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

Y a-t-il de nouveaux chapitres ?

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

Les sous-chapitres totalement nouveaux sont les suivants :

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

Qu’est-ce qui a disparu ?

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

La nouvelle version du syllabus est-elle plus agile ?

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

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

Exemples de termes apparus entre 2011 et 2018 :

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

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

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

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

Quid de l’aspect psychologique des tests ?

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

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

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

Cartographie des biais cognitifs

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

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

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

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

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

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

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

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

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

Autres remarques stylistique

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

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

Faut-il relire le syllabus ?

Oui, allez-y ! Bonne lecture à vous !

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

Utilisateur par droit, testeur par devoir ?

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

Premier constat : rapporter des bugs n’amuse personne

(… sauf les testeurs ?)

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

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

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

Une question de confiance ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Une question de responsabilités ?

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

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

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

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

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

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

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

Un jeu pour sensibiliser aux tests unitaires

Dans l’article précédent, nous parlions d’un de nos jeux permettant de clôturer un projet en faisant le point dans la bonne humeur. Aujourd’hui ça continue ; l’hiver (ou l’été, ça dépend d’où vous nous lisez…) sera ludique ou ne sera pas !

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écideurs comprennent précisément l’intérêt d’un tel chantier. Le problème : les tests unitaires sont généralement dans la partie invisible de l’iceberg.

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

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

Le jeu : « Avec ou sans tests unitaires ? »

Nombre de joueurs

De 2 à N, la seule limite étant l’espace et le nombre de jeux de cartes dont vous disposerez !

Une personne doit endosser le rôle de maître du jeu. 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 aux joueurs 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.

Le maître du jeu lance un chronomètre, ce qui va constituer un levier de pression en cas de bavardage entre les participants !

A chacun des 10 tours, une règle est lue par le maître du jeu. La règle du tour est lue par le maître du jeu uniquement pendant le tour N. Elle peut être répétée à volonté au cours du tour, mais en aucun cas après. Le maître du jeu peut être assez tranchant sur ce point : « Vous devriez vous en souvenir ! ». On passe au tour suivant dès que les « développeurs » considèrent qu’ils ont terminé.

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

Une autre phrase peut être retenue à toutes fins utiles, par exemple si les joueurs 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 le maître du jeu est invité à presser et stresser les développeurs. La durée visée est de 10 minutes par session.

Tous les membres de l’équipe des participants ont le même rôle. C’est à eux 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, les participants comptent le nombre de règles qu’ils ont et n’ont pas respectées.

Après cela, le maître du jeu peut éventuellement interroger les joueurs. Quelques idées de questions :

  • En un mot, comment vous êtes-vous sentis pendant cette session ?
  • Qu’avez-vous pu observer pendant la suite des 10 sprints ?
  • Avez-vous été plus véloce au début ou à la fin des 10 sprints ?
  • La qualité était-elle meilleure au début ou à la fin des 10 sprints ?
  • Est-on plus stressé au début ou à la fin ?
  • Parle-t-on plus calmement au début ou à la fin ?
  • Que faudrait-il améliorer ?
  • Que pourrait-on changer ?

NB : si des joueurs 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, le maître du jeu mettra à disposition des joueurs chaque RG énoncée. Ainsi, au tour 4, les joueurs 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 ! 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 des joueurs et les tests unitaires (beaucoup plus rapides soit dit en passant !)

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

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

Bon jeu et bons échanges autour des tests unitaires !

Vous aimerez peut-être…

Nos autres jeux :

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

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

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

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

Principe du jeu

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

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

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

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

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

Matériel nécessaire

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

Les cartes du jeu

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

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

Cartes d’activités

La loterie de la qualité

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

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

La transfusion de cerveaux

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

Le génie des ressources humaines

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

Le génie logiciel (le fameux !)

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

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

L’Oscar de la Meilleure Recette

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

La machine à remonter le temps

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

Un colis pour eux

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

Un colis pour vous

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

Faites-vous plaisir !

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

Une carte postale éclair

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

Cartes bonus

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

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

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

Pour aller plus loin

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

Vous aimerez peut-être…

Nos autres jeux :

Mais aussi :

5 graphiques Jira pour mieux communiquer sur les anomalies

Testeur en contexte Agile

Les 7 principes généraux du test en illustrations

Remerciements préalables

EDIT (paragraphe ajouté le 20 septembre 2018)

Ces illustrations ont été réalisées grâce au réjouissant projet open-source Historic Tale Construction Kit, version Bayeux. Merci à leurs concepteurs Leonard Allain-Launay, Mathieu Thoretton et Maria Cosmina Etegan !

Dans notre enthousiasme nous avions omis de les citer dans la première mouture de cet article, datée du 14 septembre 2018. Merci à l’un de nos lecteurs de nous avoir signalé cet impardonnable oubli !

Les tests montrent la présence de défauts

Et non leur absence. Comme le dit l’adage, l’absence de preuve n’est pas la preuve de l’absence…

Un testeur se faisant questionner par une équipe produit, et résistant à leur besoin d'entendre qu'il n'y a aucun bug dans l'application.

Les tests exhaustifs sont impossibles

D’où la nécessité d’une stratégie de test basée sur les risques et d’un ciblage pertinent de l’effort de test.

Un testeur tentant vainement d'atteindre les cimes de l'exhaustivité.

Tester tôt

Il est plus simple, plus rapide et plus économique de corriger une ambiguité dans une user story ou un cahier des charges, que d’improviser un patch après la découverte d’un bug majeur en pré-production. C’est en ça que le test représente, contrairement à l’idée reçue, un gain de temps pour les équipes. Reste à trouver un moyen de quantifier ce temps gagné pour convaincre les derniers sceptiques !

Il vaut mieux corriger un petit bug aujourd'hui qu'un gros bug demain.

Le regroupement des défauts

Après avoir éprouvé vos cas de test une première fois sur l’application, vous pourrez certainement identifier les fonctionnalités les plus « buggantes ». L’effort de test pourra alors être accru sur ces zones. Attention, les bugs peuvent changer de planque au fil du temps, ce qui nous amène au principe suivant…

Un testeur, cherchant en vain une colonie de bugs, qui se calfeutre à son insu dans une masure?

Le paradoxe du pesticide

De même que les insectes développent des résistances contre les pesticides, les cas de tests répétés à l’identique au fil du temps perdent de leur efficacité. Garder un référentiel de tests trop statique tend à laisser les bugs proliférer dans les friches. Il est essentiel de revisiter périodiquement sa combinatoire : le Docteur Lenoir ne se fait pas toujours tuer par le Colonel Moutarde avec un chandelier dans la véranda ! 

Testeurs cherchant en vain des bugs là où, à force d'être traqués, ils ne s'aventurent plus.

Les tests dépendent du contexte

Le contexte métier, le moment de l’année, le nombre et les caractéristiques des utilisateurs constatés au cours des derniers mois… sont autant d’éléments précieux qui permettent d’identifier les types de tests à prévoir.

Il ne faut pas tester la voile si le bateau est sur la plage.

L’illusion de l’absence d’erreur

Ce principe est certainement celui qui en dit le plus long sur le rôle du testeur. L’exigence de qualité nécessite de comprendre en profondeur le besoin des utilisateurs finaux, c’est pourquoi le testeur doit endosser un rôle proactif d’interface entre équipe technique et équipe métier. Sans cela, on aboutira à un produit bien fait, qui ne sera pourtant pas le bon produit.

Qui construit un arc parfait doit s'assurer que son client n'attend pas une harpe.

Bonne chance

… si vous passez prochainement votre examen ISTQB Foundation !

Vous pouvez librement utiliser ces images en citant Hightest et en indiquant un lien vers notre blog.

Vous reprendrez bien un peu d’humour testeur 🙂

Ce n’est pas un bug, c’est un poème

3 maladies de l’automatisation des tests

Le kit de secours métaphorique du testeur agile

Et un supplément de memes inédits ? C’est par ici !

… et d’ISTQB !

Performance, charge, stress… quelle différence ?