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)
