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 ?