Leadership dans le Test : Modélisation et Couverture
Dans le domaine des tests logiciels, un leadership efficace sait comment définir une direction claire pour que les stratégies de test soient alignées avec les objectifs de développement. À mesure que les systèmes logiciels deviennent de plus en plus complexes, les méthodes de test traditionnelles peinent à suivre le rythme.
C’est là qu'interviennent des approches innovantes telles que la modélisation des tests et l’analyse de la couverture. Ces pratiques garantissent que les équipes couvrent les chemins critiques ainsi que les cas limites, et permettent une meilleure collaboration, une réduction des risques et une livraison plus rapide.
Dans cet article, nous explorerons ce que signifie diriger en tenant compte de la modélisation et de la couverture. Nous verrons comment les responsables des tests peuvent tirer parti de ces stratégies pour optimiser leurs processus, améliorer la qualité du produit et garantir une couverture de test complète — tout en favorisant une culture de l’excellence et de la responsabilité. Que vous soyez responsable QA, chef d’équipe, ou simplement désireux d’approfondir votre compréhension du leadership en matière de tests, ce guide vous offrira des conseils concrets et des techniques pour élever votre pratique des tests au niveau supérieur.
Allons-y.
Qu’est-ce qu’un modèle de test ?
Le test est un processus dans lequel nous créons des modèles mentaux de l’environnement, du programme, de la nature humaine et des tests eux-mêmes. Chaque modèle est utilisé soit jusqu'à ce que nous acceptions que le comportement est correct, soit jusqu’à ce que le modèle ne soit plus suffisant pour l’objectif visé.
Boris Beizer, Software Test Techniques, 1990
La conception des tests est le processus par lequel nous sélectionnons, parmi la galaxie d’options disponibles, les tests que nous pensons être les plus précieux pour nous et nos parties prenantes. Les modèles de test nous aident à sélectionner les tests de manière systématique et sont fondamentaux pour toute démarche de test.
La manière dont les testeurs utilisent les modèles :
- Nous identifions et explorons les sources de connaissance afin de construire des modèles de test.
- Nous utilisons ces modèles pour challenger et valider nos sources, améliorer nos sources et nos modèles.
- Nous utilisons ces modèles pour orienter les tests mais aussi le développement.
Une fois la mission de test définie, notre première tâche est d’identifier les sources de connaissance. Celles-ci peuvent être :
- Documentation : spécifications, conceptions, exigences, normes, directives, etc.
- Personnes : parties prenantes, utilisateurs, analystes, concepteurs, développeurs et autres.
- Expérience : votre propre connaissance et expérience de systèmes similaires (ou non), vos préférences, préjugés, suppositions, intuitions, croyances, et biais.
- Nouveau système : le système à tester, s’il existe, disponible et accessible.
- Ancien système : le système à remplacer constitue évidemment une source — il peut, dans certains domaines fonctionnels, servir d’oracle pour le comportement attendu.
Il est important de noter que toutes nos sources de connaissance sont faillibles et incomplètes, tout comme nos modèles. Les testeurs utilisent expérience, compétence et jugement pour trier ces sources, comparer, contraster et les challenger, puis parvenir à un consensus.
Tous les modèles sont faux, certains sont utiles
George Box, économiste.
Un modèle de test peut être une liste de contrôle ou un ensemble de critères. Il peut aussi s’agir d’un schéma tiré d’un document de conception ou de l’analyse d’un texte narratif. De nombreux modèles de test ne sont jamais couchés sur papier — il peut s’agir de modèles mentaux construits spécifiquement pour guider le testeur pendant l’exploration du système à tester.
Le but des modèles est de simplifier des situations complexes en omettant les détails non pertinents à l’instant T. Nous utilisons les modèles pour simplifier un problème — par exemple, la sélection des éléments à tester. Le modèle oriente notre réflexion et nous sélectionnons les tests en identifiant la survenue de certains aspects clés du modèle.
On pourra par exemple sélectionner des embranchements d’un organigramme ou d’un diagramme de flux de contrôle, des transitions d’états dans un modèle d’états, des bornes dans un modèle de domaine d’entrée (ou de sortie), et des scénarios dérivés de récits utilisateurs écrits en langage Gherkin.
Mais attention, certains modèles peuvent faire des omissions risquées : le modèle simplifie parfois trop la situation — il faut rester vigilant face à cela. Pour rendre vos modèles de test plus efficaces, il est essentiel d’utiliser un logiciel de gestion de tests spécialisé.
Si nous ne disposons pas de modèles directement issus de nos sources, nous devons les inventer. Par exemple, si les exigences sont présentées sous forme de texte narratif, il nous faut extraire les fonctionnalités et la logique de leur comportement à partir du langage employé. Cela peut être difficile pour les développeurs et les testeurs, et, souvent, il s’agit d’un effort collaboratif — mais il faut persévérer.
Utiliser les modèles pour tester
Nous utilisons les modèles de test pour :
- Simplifiez le contexte du test. Les détails non pertinents ou négligeables sont ignorés dans le modèle.
- Concentrez l'attention sur une perspective du comportement du système. Il peut s'agir de fonctionnalités critiques ou risquées, d'aspects techniques, d'opérations utilisateur d'intérêt, ou d'aspects de la construction ou de l'architecture du système.
- Générez un ensemble de tests uniques (dans le contexte du modèle) et diversifiés (par rapport à ce modèle).
- Permettez d'estimer, planifier, surveiller et évaluer l'exhaustivité (couverture) du test.
Du point de vue du testeur, un modèle nous aide à reconnaître les aspects du système qui pourraient faire l'objet d'un test.
Modèles et couverture
La couverture est le terme que nous utilisons pour décrire la rigueur ou l'exhaustivité de nos tests par rapport à notre modèle de test. Un élément de couverture est quelque chose que nous souhaitons exercer lors de nos tests.
Idéalement, notre modèle de test devrait identifier les éléments de couverture de manière objective. Lorsque nous avons planifié ou exécuté des tests qui couvrent les éléments identifiés par notre modèle, nous pouvons quantifier la couverture atteinte et, en tant que proportion de tous les éléments du modèle, exprimer cette couverture en pourcentage.
Tout modèle permettant d’identifier des éléments de couverture peut être utilisé.
Les modèles sont souvent graphiques, avec des exemples tels que des organigrammes, des cas d'utilisation, des diagrammes de séquence, etc. Ces modèles et bien d'autres disposent d’éléments (ou « bulles ») reliés par des lignes ou des flèches. On parle généralement de graphes orientés.
Imaginez un modèle graphique composé de bulles et de flèches. Au moins deux cibles de couverture pourraient être définies :
- Couverture de toutes les bulles
- Couverture de toutes les flèches
- Et ainsi de suite
Ainsi, tout modèle qui est un graphe orienté peut être traité de la même manière.
Un modèle formel permet d’identifier de façon fiable les éléments de couverture. Une mesure quantitative de couverture peut donc être définie et utilisée comme objectif mesurable.
Les modèles informels tendent à être des listes de contrôle ou des critères utilisés pour générer une liste d’éléments de couverture, pour susciter des idées de tests ou lors de séances de test exploratoire. Ces listes ou critères peuvent être prédéfinis ou préparés dans le cadre d’un plan de test, ou adoptés lors d'une session de test exploratoire.
Les modèles informels diffèrent des modèles formels en ce que la dérivation des éléments de couverture dépend de l’expérience, de l’intuition et de l’imagination du praticien, de sorte que la couverture selon ces modèles ne peut jamais être quantifiée. Nous ne pouvons jamais savoir ce que signifie une couverture complète par rapport à ces modèles.
Les tests issus d’un modèle informel sont tout aussi valides que ceux issus d’un modèle formel s’ils accroissent notre connaissance du comportement ou des capacités du système.
Les modèles simplifient, alors utilisez-en plusieurs
Un bon modèle fournit un moyen de comprendre la complexité et y parvient en partie en excluant les détails non pertinents. Votre modèle peut utiliser le concept d'état, de modes de défaillance ou de flux, de combinaisons d'entrées, de valeurs de domaine, etc.
Un seul modèle ne suffit jamais à tester complètement un système. Tous les modèles font des compromis, il nous faut donc plusieurs modèles : ce concept est souvent appelé « demies-mesures diversifiées ». Cela signifie que nous avons besoin d’une diversité de modèles partiels pour tester un système convenablement.
Bien que cela ne soit généralement pas formulé en ces termes, les étapes de test dans un projet en cascade utilisent des modèles selon différentes perspectives. Les tests unitaires, l'intégration des sous-systèmes, les tests au niveau système et les tests utilisateurs ont tous des objectifs différents ; chacun utilise un modèle et une perspective différents – c'est ce qui crée la diversité.
Utiliser les modèles pour gérer
Les modèles sont au cœur des tests et aussi de la gestion des tests. Quatre aspects clés en découlent :
- Engagement des parties prenantes
- Périmètre
- Couverture
- Estimation et suivi de la progression
Engagement des parties prenantes
Lorsque nous planifions et définissons le périmètre des tests et expliquons la progression et la signification de la couverture aux parties prenantes, nous devons utiliser des modèles compréhensibles et signifiants pour les objectifs des parties prenantes.
Si nous prévoyons un test utilisateur, nous adopterons probablement le flux du processus métier comme modèle et comme trame pour tracer des parcours afin d'exercer les fonctionnalités du système pertinentes pour l'utilisateur. Si nous testons l'intégration de composants de service pour le compte d'un architecte technique, nous utiliserons le modèle architectural, les diagrammes de collaboration, les spécifications d'interface, etc., comme base de nos tests. Si nous testons des fonctionnalités définies par les utilisateurs, nous utiliserons les user stories issues des travaux collaboratifs de recueil des besoins réalisés antérieurement.
Si les parties prenantes ne comprennent pas vos modèles, elles ne comprendront pas, ne feront pas confiance, ni n'investiront dans vos tests. Elles peuvent même ne pas vous faire confiance.
Gestion de la portée
La première activité de la discipline de la pensée systémique consiste à définir une frontière de système. En test, le premier modèle que vous définissez vous aidera à délimiter la portée du test. Le schéma ci-dessous illustre l’architecture du système – un « système de systèmes » – dans une organisation.
Chaque système (les cercles concentriques) appartient à un domaine applicatif comme la gestion de la relation client (CRM), la comptabilité ou le site web. L'ensemble des systèmes et domaines applicatifs sont contenus dans ce « système de systèmes ». Il n’y a bien sûr aucun détail sur ce modèle, mais il est facile de voir comment chaque système s’intègre dans l’architecture globale.
Nous pourrions facilement définir la portée de nos tests comme étant, par exemple, les systèmes ERP.
Sur le second schéma ci-dessous, nous avons ajouté plus de détails à l’architecture système et proposé trois façons de définir plus précisément la portée.
- Les systèmes colorés en jaune sont les fameux systèmes d’enregistrement. Par exemple, ces systèmes peuvent partager une base de données, et les modifications du schéma de base de données pourraient avoir un impact négatif sur ces systèmes — et ils seraient alors inclus dans le périmètre du test.
- Les systèmes entourés par la ligne violette peuvent partager des fonctionnalités ou une infrastructure commune — ils utilisent peut-être tous le même ensemble de web services, le même système de messagerie, ou s’exécutent sur le même serveur.
- La ligne bleue en pointillés représente un parcours utilisateur qui exploite les systèmes connectés par cette ligne. Peut-être que ce parcours utilisateur a changé et que notre attention se porte sur la cohérence et la précision du flux de données entre ces systèmes.
Un modèle peut montrer ce qui est dans le périmètre du test mais, tout aussi important, ce qui n’y est pas.
Un modèle aide à définir la portée d’un test et à expliquer cette portée aux parties prenantes dans des termes qu’elles comprennent, apprécient et (on l’espère) valident.
Lorsque nous utilisons un modèle pour définir la portée, il définit le territoire tandis que les éléments inclus dans la portée identifient les lieux que nous souhaitons explorer et tester.
Gestion de la couverture
La mesure de la couverture peut aider à rendre les tests plus gérables. Si nous n’avons pas de notion de couverture, il peut nous être impossible de répondre à des questions telles que : « qu’est-ce qui a été testé ? », « qu’est-ce qui ne l’a pas été ? », « avons-nous terminé ? », « combien de tests reste-t-il ? » Cela est particulièrement délicat pour un responsable des tests.
Le niveau de couverture que nous prévoyons d’atteindre est l’étape logique suivante une fois le périmètre défini.
Nous utilisons le modèle de délimitation pour définir les endroits à tester. Notre modèle de couverture indique aux parties prenantes à quel point nous prévoyons de tester ces endroits en profondeur.
Les modèles de test et les mesures de couverture peuvent servir à définir des objectifs quantitatifs ou qualitatifs pour la conception et l’exécution des tests. À des degrés divers, il est alors possible d’utiliser ces objectifs pour planifier et estimer. Ils servent aussi à mesurer la progression et à déduire l’exhaustivité ou la complétude des tests programmés ou réalisés. Cependant, nous devons être très prudents avec toute mesure ou tout pourcentage de couverture quantitatives utilisés.
Une mesure de couverture (fondée sur un modèle de test formel) peut être calculée objectivement, mais il n’existe pas de formule ou de loi qui indique que tel niveau de couverture garantit telle qualité ou telle confiance. Toutes les mesures de couverture n’offrent que des indications indirectes, qualitatives et subjectives sur l’exhaustivité ou la complétude de nos tests. Il n’existe aucune relation significative entre la couverture et la qualité ou l’acceptabilité des systèmes.
Les objectifs quantitatifs de couverture servent souvent à définir les critères de sortie en fin de tests, mais ces critères restent arbitraires. Un objectif de couverture plus strict pourrait générer deux fois plus d’éléments à couvrir. Toutefois, réaliser deux fois plus de tests, coûtant deux fois plus cher, ne signifie pas qu’un système sera deux fois mieux testé ni deux fois plus fiable. Une telle interprétation n’a aucun sens et serait stupide.
Parfois, les modèles formels utilisés pour définir et construire un système peuvent être imposés aux testeurs pour qu’ils les utilisent afin de définir les objectifs de couverture. À d’autres moments, les testeurs peuvent disposer de peu de documentation et doivent inventer leurs propres modèles. Le choix de tout modèle de test et d’objectif de couverture est en partie arbitraire et subjectif. Par conséquent, les modèles de test informels et les mesures de couverture peuvent être tout aussi utiles que les modèles formels établis.
Exercice rapide de modélisation
Un petit exercice pour finir. Dans les exemples suivants, esquissez ce à quoi le modèle pourrait ressembler — uniquement sa forme — sous forme de dessin/diagramme, tableau, ou liste :
- Les utilisateurs se préoccupent des parcours de bout en bout dans le système.
- Un service de messagerie peut se trouver dans quatre états : arrêté, en fonctionnement, en démarrage et en arrêt progressif.
- Un calculateur de prime d’assurance possède 40 valeurs d’entrée, qui, en combinaison, influent sur le calcul ; il existe des dépendances entre certaines entrées.
- Un processus d’extraction/transformation/chargement comporte sept étapes. Après l’extraction, chaque étape rejette des enregistrements, les envoie dans un fichier de réserve, ou les transforme et les transmet à l’étape suivante. La dernière étape est un processus de chargement, qui gère les rejets. Tester que tous les enregistrements extraits sont bien pris en compte.
Abonnez-vous à la newsletter du CTO Club pour davantage d’idées sur les tests !
