La taverne du testeur

Test design

Plus d’estime pour le test design : un plaidoyer – Anne Kramer

Info: cet article a été publié initialement sur le blog de Smartesting.

Introduction

On pourrait se croire dans Harry Potter. Les bons tests semblent tomber du ciel. Il suffit de brandir la baguette magique et de les écrire ou de les programmer. C’est pourtant un métier que de concevoir de bons tests – un métier qui n’est malheureusement pas assez valorisé.

Conception versus implémentation de test

Très souvent, le test design passe sous le radar de managers qui ont tendance à confondre la phase de conception de tests avec la phase d’implémentation. Cela pour plusieurs raisons :

  1. La conception de tests ne mène pas forcément à une documentation étendue. Créer des items du type “cas de test” dans un outil ALM avec une description succincte de l’objectif du cas de test, de la situation à provoquer et du résultat attendu peut suffire comme documentation. Mais vu de l’extérieur, cela à l’air de n’être que le début de quelque chose.
  2. L’implémentation des tests est une activité lourde et chère. Elle monopolise les ressources et est la source de coûts de maintenance considérables. Rien que pour cela, elle attire l’attention des managers qui cherchent des moyens de réduire les coûts et d’augmenter l’efficacité.

Il est important de comprendre que les deux phases ont des objectifs bien distincts. La conception de test a pour objectif de produire des tests pertinents permettant de couvrir un ensemble de règles métier, mais sans se soucier des détails pourtant nécessaires lors d’une exécution manuelle ou automatisée. A priori, elle est complètement indépendante du choix de la façon d’exécuter les tests. Ce n’est qu’au cours de la phase d’implémentation que nous devons fournir les détails et les données de test nécessaires à l’exécution.

En forçant un peu le trait, on peut dire que la conception des cas de test est un travail intellectuel et que l’implémentation est souvent plutôt un travail besogneux sans défis intellectuels particuliers.

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 besoin ? – 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.

À propos de l’autrice: Anne Kramer

Au cours de sa carrière passée dans des industries fortement régulées (paiement électronique, sciences de la vie), Anne a accumulé une expérience exceptionnelle des projets IT, notamment dans leur dimension QA et test. Experte des approches de conception de test à base de représentations visuelles, Anne est passionnée par le partage de ces connaissances et de son expertise.
En avril 2022, elle a rejoint Smartesting en tant que Global CSM. Depuis, elle trouve toujours de nouvelles façons de faire découvrir la puissance de l’approche ATDD (Acceptance Test-Driven Development) supportée par YEST. Plus récemment, elle s’est lancée dans l’aventure de l’IA générative et anime une formation à ce sujet.

Une réponse

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Automatisation

Gérer et centraliser ses automates de tests avec JIRA et Xray – Simon Champenois

Même si aujourd’hui les automates de tests sont souvent intégrés dans des pipelines, ils sont aussi souvent « dispersés » sur différents projets en fonction des outils et des équipes de test. Ainsi, le rejeu des automates et l’obtention des résultats peuvent être compliqués à appréhender pour les personnes dont l’automatisation des

Lire la suite »
non-fonctionnel

Développer des tests de charge avec K6 – Vianney Maerte

K6 est un outil gratuit et open source de test de charge orienté développement disponible ici. Il permet d’exécuter des tests contenant des appels vers une ou plusieurs requêtes http avec différentes options telles que le nombre ou le temps d’itération, le nombre d’utilisateur virtuel devant exécuter le test, …

Lire la suite »