Plus d’estime pour le test design – un plaidoyer

Obtenir des « bons » tests

L’objectif de la conception des tests est de concevoir de « bons » tests. Dans ce contexte, « bon » signifie
généralement “complet, précis et pas trop cher ».
C’est ici que le premier piège se présente. « Complet » est souvent lié à la couverture des exigences.
Techniquement parlant, il suffit de lier un cas de test à une exigence ou une user story pour que
l’exigence soit considérée comme « couverte ». Le cas de test pourrait être vide ou contenir 1=1 ;
l’exigence serait considérée comme testée avec succès.
Les testeurs le savent bien-sûr et appliquent donc des techniques de conception de test
systématiques afin de couvrir au mieux le contenu des exigences. Les techniques les plus connues
sont la classification par partition d’équivalence et l’analyse des valeurs limites. On trouve moins
souvent des tables de décision ainsi que des techniques avancées telles que le test par paires.

Pas de test sans test design

Le test design se fait toujours, quelque soit le processus de test. En voici quelques exemples de
différentes approches dans lesquelles le test design est plus ou moins apparent :
● Tests manuels par rapport aux exigences ou aux user stories
Pour chaque exigence ou user story, le test doit couvrir tous les critères d’acceptation. Une
conception de test minutieuse garantit que tout ce qui a été exigé est testé. En outre, les
testeurs imaginent des scénarios d’erreur et des cas particuliers pour pousser le système à
ses limites. Selon le niveau de documentation requis, ces tests sont écrits au préalable
(comme spécification de test explicite) ou juste sommairement esquissé dans la description
de cas de test.
● Tests automatisés
Les tests automatisés nécessitent également un test design. En cela, ils ne se distinguent pas
du tout des tests manuels. En effet, la qualité d’un script de test dépend de la qualité des
tests qui y sont automatisés. La documentation de la conception des tests n’est cependant
souvent que rudimentaire, souvent sous forme de commentaires dans le code. Ceux-ci se
concentrent alors souvent sur la conception du script de test en lui-même. Or, le test design
et le design de code sont deux choses différentes ! Dans le premier cas, il s’agit de l’idée de
test, dans le second de la manière dont le script est programmé.
● Tests exploratoires
Même les tests exploratoires reposent sur une sorte de conception de test, car les testeurs
exploratoires réfléchissent eux aussi aux partitions d’équivalence, aux valeurs limites et aux
scénarios d’erreur. Les testeurs expérimentés sont imprégnés de cette approche. Cela fait
d’eux des « critiques » doués du produit. Cette expertise est rarement consignée par écrit.
C’est justement le peu de documentation sur la conception des tests qui fait que cet important travail
intellectuel n’est pratiquement pas perçu. C’est même le cas lorsqu’il existe une spécification de test
explicite. Ces spécifications contiennent généralement les détails de l’exécution des tests, dans
lesquels se perdent les réflexions sous-jacentes.
Or, la qualité des tests dépend de la conception des tests. Pourquoi cela ne se reflète-t-il pas dans le
niveau de soutien et la valorisation de l’activité ?

L’estime se manifeste par un soutien

Il est temps que les managers prennent conscience de la conception des tests. Après tout, nous ne
parlons pas seulement ici d’une activité décisive dans le processus de test, mais aussi d’un énorme
potentiel d’amélioration.
La comparaison avec la programmation, c’est-à-dire l’implantation de code source, montre à quel
point la productivité pourrait être augmentée dans la conception des tests. Personne n’attendrait des
développeurs qu’ils écrivent du code source dans Notepad++. Comment le pourrait-il ? La ou les
personnes concernées auraient démissionné en quelques mois. Les développeurs ont leur
environnement de développement intégré (IDE) avec vérification syntaxique, auto-complétion de
texte, outils d’analyse de code statique et dynamique, etc.
Les testeurs semblent plus enclins à souffrir. Nous sommes déjà heureux de disposer d’un outil ALM
(Application Lifecycle Management), car il nous permet de relier les cas de test aux exigences /
stories. Sinon, nous avons des champs pour les étapes de test, les résultats attendus et les résultats
réellement observés. Avec un peu de chance, un correcteur d’orthographe permet d’éviter les fautes
les plus évidentes. Tous les autres champs, comme par exemple la priorité, servent déjà à la gestion
des tests. Une conception de test réalisée avec un outil dédié aurait une toute autre allure !

Les outils de test design

Pourtant, ces outils existent bel et bien, comme le montre la liste ci-dessous.
● Visualisation de relations complexes
Tous les outils qui permettent de représenter graphiquement des relations complexes
contribuent à la clarification des exigences et donc à la conception des tests. Il s’agit
d’éditeurs simples de parcours graphiques (par ex. Yest for Jira…) ainsi que d’outils de
modélisation plus complexes.
● Détermination des règles / scénarios à tester
Les coachs agiles disposent de diverses méthodes qui aident de manière simple et efficace à
entamer la discussion sur les nouvelles fonctionnalités et à définir les besoins en matière de
test. Les exemples les plus connus sont le mapping d’exemple et les storyboards. Pour ces
deux méthodes, je n’ai besoin que d’un crayon et d’un papier, même s’il est évidemment
utile de conserver les résultats sous forme digitale.
● Vérification systématique des classes d’équivalence et des valeurs limites
La systématisation peut être obtenue de différentes manières. Les arbres de classification, les
tables de décision, la modélisation explicite des valeurs – tout ce qui permet de visualiser les
pensées dans la conception du test est utile. La méthode prise en charge dépend de l’outil
choisi. Les tables de décision dans Yest et tous les outils dites « Model-Based Testing » (MBT)
en sont des exemples.
● Génération de tests combinatoires
Les générateurs de cas de test basés sur des modèles génèrent des cas de test à partir de
modèles. Les nombreux outils MBT disponibles sur le marché se distinguent non seulement
par leur mode de génération, mais aussi par le degré d’assistance pour la création et la
révision des modèles et des cas de test générés. Par exemple, Yest de Smartesting propose
un environnement de développement complet pour les testeurs.
Cette liste est loin d’être exhaustive. Elle illustre simplement le fait que les moyens techniques ne
manquent pas.

De quoi avons nous besoins ? Plus d’estime pour le test design

Le tableau dressé ici est peut-être trop pessimiste. Le développement révolutionnaire de l’IA
générative contribuera certainement à l’avenir à mieux soutenir la conception des tests. Mais l’IA a
besoin de données de départ de bonne qualité – et c’est justement ce qui fait souvent défaut.
En effet, les testeurs rattrapent lors de la conception des tests ce qui a été omis lors de
l’identification des exigences ou simplement reporté aux sessions de définition du backlog. Il n’est
pas judicieux de séparer ces deux activités. Les approches test-first comme Behavior-Driven
Development (BDD) ou Visual ATDD (une forme agile du MBT) l’ont bien compris. En plaçant la
conception des tests au début du processus, on fait d’une pierre deux coups. Nous ne devrions pas
considérer la conception des tests comme un facteur de coût gênant, mais comme une forme de
clarification des exigences à valeur ajoutée, qui a besoin et mérite le support d’un outillage
approprié. Ce dont nous avons vraiment besoin, c’est d’une plus grande appréciation de la
conception de tests ! Cette appréciation devrait se manifester de deux manières : une plus grande
attention et un meilleur soutien par des outils.