Des idées de test qui révèlent les problèmes qui comptent

Le test commence avant l’implémentation. Il commence par mieux comprendre et remettre en question l’idée d’une modification logicielle ou d’une nouvelle fonctionnalité. Il commence par la collecte d’informations et par une connaissance plus fine des conséquences qu’elle peut avoir sur le système existant. Il commence par la construction d’une vraie compréhension commune et par le travail en commun de toutes les personnes impliquées.

Ce n’est qu’alors que des idées de test pertinentes me viennent à l’esprit.

Recueillir l’information en posant des questions

Quand je démarre sur un nouveau projet ou que j’étudie une nouvelle fonctionnalité, je commence par répondre à une liste de questions. Ces questions m’aident à creuser, à prendre conscience de ce que je ne sais pas et à identifier les hypothèses que j’ai faites, ainsi que les faits avérés que je connais.

6 questions pour l’onboarding

Comment le projet gagne-t-il de l’argent ?
Qui sont les concurrents sur le marché ?
Quelles sont les fonctionnalités les plus importantes ?
Quelles sont les fonctionnalités les plus utilisées ?
Quels sont les défis actuels ?
Comment le test peut-il aider ?

6 questions sur une fonctionnalité

Qui peut me donner un point de vue métier et un point de vue technique ?
Quel problème essayons-nous de résoudre ?
Quels sont les cas d’usage et les scénarios importants ?
Quel est l’impact pour l’utilisateur et pour l’entreprise si la fonctionnalité ne marche pas ?
Des services tiers ou de partenaires sont-ils impliqués ?
De quelles données de test et de quel environnement de test ai-je besoin, et sont-ils déjà en place ?

Chacune de ces questions a une intention. Ces intentions m’aident à recueillir des connaissances sur les aspects métier, opérationnels et techniques.

J’utilise ensuite ces questions pour relier les points entre eux :

les règles métier et les exigences ;
l’architecture du système et ses dépendances ;
les responsabilités ;
les risques.

En partant de ces questions, je peux me faire une première vue d’ensemble, puis décider de ce qu’il faut tester en m’appuyant sur les connaissances et sur les risques.

Donner l’élan à votre réflexion

En plus des questionnaires, j’utilise des aide-mémoire, des cartes mentales, des tableaux et des visualisations de processus pour organiser mes pensées. Avoir un point de départ facilite beaucoup la recherche d’idées de test.

Tout cela m’aide à comprendre le comportement des vrais utilisateurs, le comportement du système et les risques les plus importants que nous voulons réduire par le test et par d’autres activités.

La plupart des bonnes idées viennent de la réalité

Trouver des idées de test peut être facile. Mais certaines de ces idées sont très théoriques et ne correspondent à aucun comportement ni à aucun risque réels. Vous avez alors investi du temps, de l’argent et des efforts dans quelque chose qui n’apporte que peu ou pas de valeur. Il est donc important de comprendre la réalité.

Les données font partie de ce qui m’aide à comprendre cette réalité. Je consulte nos métriques et les avis des utilisateurs, et je parle avec les product owners et le support client pour comprendre comment nos clients utilisent notre produit ou notre service. J’examine les bases de données pour comprendre les données réellement produites par notre système. J’utilise notre outil de suivi des bugs pour voir quels bugs nous ont fait perdre de l’argent par le passé.

Tout cela me permet de comprendre ce qui compte vraiment.

Le test guidé par les cauchemars

Au fond, ma façon de trouver des idées de test est guidée par le risque. Une technique que j’utilise souvent s’appelle « Nightmare Headlines ». J’imagine le pire titre de presse possible sur notre produit ou notre service, en lien avec une nouvelle fonctionnalité ou une modification.

Des utilisateurs ne sont pas facturés pour leurs achats.
Les collègues du service financier doivent faire des heures supplémentaires pour réparer des données corrompues.
Des données sensibles sur nos clients ont fuité.

C’est un exercice simple, mais il change la conversation. Il nous oblige à réfléchir :

Qu’est-ce qui pourrait mal tourner ?
À quel point ce serait grave ?
Quelle est la probabilité que cela arrive ?

C’est fascinant de voir la diversité des idées que les gens trouvent quand ils font cet exercice en équipe.

Partager, c’est gagner

Même si je commence souvent par esquisser des idées seul, je les garde rarement pour moi. Je les partage dans les discussions.

Les développeurs m’aident à comprendre les contraintes techniques.
Les product owners précisent l’impact sur le métier.
Les parties prenantes remettent en question les hypothèses.

Parfois, les idées en sortent renforcées. Parfois, elles sont abandonnées. Les deux résultats sont utiles. Le but n’est pas d’avoir plus d’idées de test. Le but est d’avoir les bonnes.

L’expérience compte

Même si tout cela m’aide à faire du bon travail en tant que testeur, l’expérience compte toujours. J’ai besoin de vivre ce que signifie planifier, développer, livrer et exploiter un logiciel au sein d’une organisation. Je peux alors apprendre de nos erreurs et reconnaître des schémas. Ces schémas m’aident à repérer les zones sujettes aux erreurs ou complexes. Ils m’aident aussi à rattraper des erreurs du passé.

Des exemples concrets

Sur un projet, nous avons testé un système de vente de billets proposant de nombreux types de billets et de combinaisons de billets. J’ai créé une matrice de ces combinaisons et j’ai commencé à les explorer. C’est là que nous avons découvert :

des plantages de l’application ;
des prix incorrects.

Dans un autre cas, quelque chose d’important a failli passer inaperçu. Il y avait un problème de prix lorsque les utilisateurs sélectionnaient deux billets ou plus du même type. Comme j’avais déjà vérifié que le backend fonctionnait correctement, j’ai supposé qu’il continuerait à le faire une fois intégré au frontend.

Ce n’était pas le cas. Cette hypothèse a failli provoquer un vrai problème en production. Heureusement, un développeur l’a trouvé quelques heures seulement avant la release. C’est un bon rappel que même des hypothèses logiques peuvent être fausses.

Mon regard actuel sur l’IA dans le test

Pour l’instant, j’utilise rarement l’IA pour trouver des idées de test. En revanche, j’utilise mes propres idées de test, mes connaissances et ma liste de questions pour donner plus de contexte aux agents IA quand ils analysent ou génèrent du code.

J’utilise aussi l’IA pour mieux comprendre des bases de code existantes :

À quoi ressemble le flux de données d’un endpoint jusqu’à la base de données.
Où certaines décisions sont prises pendant le traitement.
Quels autres systèmes pourraient être impliqués ?

L’IA me donne un point de départ. Je vérifie ensuite ce qu’elle affirme et je creuse davantage. Pour moi, combiner l’IA avec mon approche méthodique m’aide à apprendre et à comprendre plus vite, surtout dans des environnements complexes.

Alors, qu’est-ce qui fait vraiment un bon testeur ?

Si je devais le résumer, je dirais qu’un bon testeur :

cherche à comprendre avant d’agir ;
pense en termes de risques, pas seulement de scénarios ;
s’appuie sur une structure pour nourrir sa créativité ;
apprend des vrais utilisateurs et des vraies données ;
collabore avec les autres ;
accumule de l’expérience en continu.

Car au bout du compte, les meilleures idées de test ne s’inventent pas. Elles se découvrent.

À propos de La boîte à outils du testeur

C’est cette façon de penser que j’apporte dans mon atelier « La boîte à outils du testeur ». L’atelier montre comment lancer et structurer votre réflexion, comment gérer vos connaissances et comment utiliser tout cela pour trouver des idées de test pertinentes.

Voici une brève présentation de l’atelier (en anglais).