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.