Le cas de test est mort, vive le cas de test !

Depuis un certain temps et au regard de mes différentes lectures, j’ai le sentiment que la notion de cas de test évolue. Parfois, j’ai l’impression qu’il est vu comme un boulet que l’on traîne, parfois comme le Saint Graal, parfois il est juste inexistant. Alors qu’est-ce que le cas de test dans le monde logiciel d’aujourd’hui ?

Pour m’aider à répondre à cette question, j’ai lancé un sondage début mars interrogeant les testeurs du groupe LinkedIn « Le métier du test », du slack français « La test communauté » et le groupe LinkedIn « Ministry of testing ».

Même s’il y a eu peu de votants, on peut voir que l’approche traditionnelle d’écrire des cas de test dans un ALM reste la plus utilisée avec 49% des votants.
Je note que l’approche consistant à concevoir des cas de test pour servir un besoin d’automatisation et de faire tests exploratoires atteint le beau score de 33%.
Le reste étant constitué, au regard des commentaires que j’ai reçus, de 100% tests automatisés, 100% tests exploratoires ou une approche hybride qui allie à la fois le design de TC (ALM et automatisation) et du test exploratoire.

Au regard de ces réponses et de ma propre expérience, je vous propose de distinguer deux notions: la conception du cas de test d’une part et la rédaction d’autre part.

Conception et rédaction : Le yin et yang du cas de test

Pour bien comprendre comment le cas de test peut prendre des formes aussi diverses, je vous propose les deux définitions suivantes:
– Conception: activité d’analyse de l’information qui permettra de déterminer les tests à réaliser pour atteindre un certain degrés de qualité
– Rédaction: activité d’écriture des cas de tests à l’aide d’outils permettant l’exploitation et la réutilisation des cas de test.

Du point de vue du processus fondamental du test décrit par l’ISTQB, ce que j’appelle « Conception » correspondrait à « l’analyse et conception » et la « Rédaction » à « l’implémentation ». On peut aussi comparer ma proposition au courant Rapid Software Testing (RST) que Mickael Bolton et James Bach promeut. Dans cette approche, la conception serait appelée « testing » et la rédaction « checking ».

Ce qu’il faut comprendre, c’est qu’on a trop tendance à assimiler le cas de test à la forme qu’il prend et non au fond qui lui donne sa vraie valeur. C’est ce que RST cherche à mettre en perspective: l’intelligence humaine pour déterminer le fond (testing) et l’usage d’outil qui détermine la forme (checking). Et il est vrai qu’il est difficile de s’imaginer de parler de cas de test sans visualiser sa forme.

Et si on reprend les résultats de mon sondage, les réponses diffèrent uniquement sur la forme !!!
Mais avant de parcourir les formes possibles et dans quels contextes je les préconise, je souhaite aborder tout de même la conception qui peut prendre des aspects différents.

Différentes façons d’aborder la conception !!!

Je vous propose 3 visions:

• issue de la documentation: le testeur va analyser les documents qu’il a sa disposition (spécifications, manuels utilisateur, diagrammes des cas d’usage, cahiers d’exigences, etc ..) pour dériver les cas de tests. Souvent le testeur utilisera des techniques de tests boites noires de manière assez formalisés.
• issue de l’expérience: le testeur va utiliser sa connaissance du produit, l’expérience passée sur le projet, son intuition sur les défaillances possibles mais aussi ses compétences testing pour dériver les cas de test. Souvent, il va utiliser des techniques boites noires et boites blanches de manière informelle et implicite.
• issue de la collaboration: Le testeur sera surement dans un contexte favorable à la collaboration (comme dans des projets agiles) et les cas de tests seront pensés collectivement. Cela peut se faire par exemple après une rencontre des amigos ou d’exemple mapping qui aura décrit la nouvelle fonctionnalité avec des exemples. Ces exemples serviront de base au testeur pour dériver les cas de test.

Et aussi différentes formes de rédaction !!!

Tout comme la conception, la rédaction des cas de test peut prendre plusieurs formes. Je vous propose de distinguer celles-ci:

• forme fonctionnelle: forme privilégiant le fonctionnel du produit sous test. La rédaction du cas de test sera suffisamment détaillée pour qu’une autre personne que le rédacteur puisse l’exécuter. En général, un ALM ou format documentaire (texte ou tableur) sera utilisé pour capitaliser cette rédaction. Un ALM apportera aussi le confort de supporter l’exécution du test ainsi que le reporting de son résultat.
• forme métier : forme privilégiant les cas d’usage métier. Le testeur utilisera très probablement un DSL (Domain Specific Language) comme Gherkin. Cette forme peut se retrouver dans un ALM mais aussi sous forme de fichiers texte stockés dans un gestionnaire de conf (avec le code de l’application). Ces fichiers peuvent ensuite être scriptés par les développeurs. On parlera parfois de spécification vivante et exécutable.
• forme scriptée: Cette forme s’appuie en général sur la forme fonctionnelle ou métier mais est parfois directement utilisée avec l’usage immédiate d’outil d’automatisation. Personnellement, je ne suis pas un grand fan de cette forme seule car souvent sujette à des défauts de maintenabilité. Je préfère l’utiliser en combinaison avec la forme métier ou fonctionnelle.
• forme exploratoire: forme beaucoup plus libérée que les précédentes et ne cherchant pas à vérifier que le produit décrit est bon. On cherche plutôt à se mettre à la place d’un utilisateur du système (utilisateur métier, les opérations, utilisateurs finaux, etc …) pour en découvrir des incohérences dans les solutions proposées: ergonomie, utilisabilité, parcours utilisateurs atypiques, …). Souvent, cela prend la forme de chartes pour cadrer les sessions de tests. Cette forme de rédaction est particulièrement favorable pour une exécution en pair testing ou mob testing.

Alors, quelles formes utiliser ?

Il va de soit que je n’aurais pas de bonne réponse à cette question. Chaque contexte est différent et chacune des formes proposées de conception et de rédaction sont tout à fait respectables.

Je pense tout de même que certaines formes sont plus adaptées à certains contextes que d’autres. Je vous propose cette grille de lecture qu’il conviendra de challenger au regard de votre contexte.

Le cas de test est mort, vive le cas de test !

Comme vous l’avez surement compris, le cas de test peut prendre différentes formes que ce soit dans sa conception comme dans sa rédaction. Les approches traditionnelles sont toujours présentes et cohabitent avec d’autres approches issues entre autre des méthodes agiles.

Il me parait évident que les évolutions des méthodes projets que l’on verra émerger dans le futur feront aussi évoluer le cas de test.

Ce qui importe à mon avis est de garder à l’esprit pourquoi un testeur conçoit des tests. Chacun d’entre nous devra prendre du recul sur son contexte projet et adapter la conception et la rédaction de ses cas de test pour qu’ils soient les plus pertinents et efficients possibles.

Un énorme merci à Zoé Thivet qui m’a fait l’honneur de dessiner l’image de cet article.