Editions ENI Livres | Vidéos | e-Formations
Versant industriel du test
Introduction
Une fois qu’on sait ce qu’il faut tester, on arrive au constat que le chantier est énorme et qu’il faut organiser potentiellement plusieurs groupes de personnes de façon efficace. Ce chapitre abordera aussi la question de ce qui est produit par les tests : les anomalies et les rapports des sessions de test qui seront conditionnés par les données et les environnements mis à disposition.
Les éléments présentés dans ce chapitre vous apporteront des solutions et autant de questions qui devraient trouver des réponses dans la pratique.
Stratégie de test
1. Vision académique de la stratégie de test
Selon l’ISTQB,
« La stratégie de test décrit la méthodologie générale de l’organisation. Cela inclut la façon d’utiliser le test pour gérer les risques produit et les risques projet, la séparation en niveaux de test et les activités de haut niveau associées au test » [ISTQB 2012].
Cette stratégie s’inscrit généralement dans une politique de test qui définit pourquoi l’entreprise teste ses objectifs généraux. Cette politique pourra être élaborée en fonction de la configuration de l’entreprise et inclura notamment [ISTQB 2012] :
-
les raisons, valeurs et objectifs des tests dans l’entreprise avec ses impacts sur la hiérarchie et les processus ;
-
l’évaluation de l’efficacité du test ;
-
l’approche du test telle que :
-
l’application du « tester tôt » et les conséquences sur la participation générale à la qualité du produit,
-
la vision sur les risques liés aux tests comme l’approche du « Risk-Based Testing », pilotage des tests par le risque (voir plus bas) ; les risques acceptables et ceux qui doivent être absolument traités,
-
les normes et règlements applicables.
-
-
les moyens d’améliorations du test.
 |
Vision de la stratégie de test selon l’ISTQB Pour l’ISTQB, la panoplie complète des documents est une structure en poupée russe [ISTQB 2012] :  Cette approche peut être déclinée comme suit :
En matière de valeur ajoutée, le document majeur serait évidemment la stratégie... |
Tests systèmes / bout-en-bout
L’ISTQB positionne la notion de test système comme le processus de vérification du système intégré, c’est-à-dire avec l’intégralité des sous-parties rendues disponibles pour une session de test afin de permettre le déroulement des processus métier [ISTQB 2023].
Pour aller un peu plus loin dans cette définition, on peut se rendre compte que la notion de tests « bout-en-bout » peut s’entendre de façon :
-
verticale, lorsqu’une équipe tente de voir si l’interface publique de son produit (une IHM, une API, un protocole, etc.) fonctionne à travers toutes les couches logicielles ;
-
horizontale, lorsqu’on tente de passer au travers d’un ensemble d’interfaces publiées afin de dérouler un processus métier.
Les tests bout-en-bout verticaux sont concentrés sur la validation fonctionnelle des couches et leurs interactions. Lorsque l’organisation est basée sur des Feature Teams, ces tests sont centrés sur une seule équipe qui a alors toute autonomie pour :
-
en faire leur ingénierie ;
-
gérer les environnements et données de test ;
-
et traiter les anomalies.
Dans ce cas, lorsque cette équipe fournit une fonctionnalité parmi des dizaines, voire des centaines d’autres, on est sur une problématique de test unitaire lorsque l’on considère la globalité du système.
Les tests horizontaux vont impliquer, en revanche :
-
la connaissance du métier avec un regard plus centré vers l’utilisateur ;
-
le travail de plusieurs équipes, voire plusieurs départements de l’organisation, lorsque le produit impliqué dans des tests horizontaux est de grande taille, et potentiellement, sur différentes applications.
Ces seconds types de tests système sont naturellement plus difficiles à appréhender de par la complexité des interactions techniques, humaines et métier.
1. Stratégies de tests bout-en-bout
a. Approche « WaterScrumFall »
Dans une organisation de type A [Takeuchi 1986], on attend d’avoir terminé chaque étape comme dans l’approche traditionnelle de type Waterfall ou cycle...
Tests exploratoires
|
|
Les origines du Test exploratoire En 1984, Cem Kaner mentionnait pour la première fois le terme de « Test Exploratoire » [Kaner 2008] [Bach 2015-1] pour être publiquement partagé pour la première fois lors de la 7e conférence LAWST (Los Altos Workshop on Software Testing) de 1999 [Kaner 2003]. Par la suite, James Bach, Brian Marick, Bret Pettichord et Cem Kaner ont créé une école du test nommée « Context Driven-Testing » (voir chapitre Facteurs de succès). Avec le temps, cette approche est devenue très populaire dans le test agile. Elle fait même partie des outils cités dans le syllabus ISTQB sur le test agile [ISTQB 2014]. |
Le TE est sans doute l’approche du test la plus agile, car le TE est une démarche qui consiste à réaliser en même temps :
-
la conception d’un scénario de test ;
-
son exécution en gardant les traces des tests ;
-
et l’apprentissage sur le produit et des erreurs commises.
Par ailleurs, le TE se concentre sur le produit et non sur l’application d’une procédure.
L’intérêt de cette approche revêt plusieurs aspects :
-
En mode réactif en testant au plus tôt, elle permet de conserver une vision de la qualité du produit, même lorsque seulement quelques heures restent disponibles avant l’échéance.
-
Pour compléter la vision analytique des tests générés en conformité avec les spécifications, le TE permet de produire une sorte de liant entre les bouts de fonctionnalités et de prendre du recul sur le Produit afin de savoir si ce qui va être potentiellement livré correspond au « Bon Produit » plutôt qu’à un produit conforme.
-
Face au paradoxe du pesticide, le TE permet de sortir de l’ornière du test scénarisé pour trouver d’autres bugs que ceux qui ont été imaginés en théorie.
-
Le TE est LA pratique de test qui permet au testeur d’exploiter tout son savoir-faire, d’utiliser son intuition et sa connaissance du métier pour trouver les anomalies ; de toutes les pratiques du test, celle-ci est sans doute la plus gratifiante et la plus...
Ingénierie des tests de recette
La notion de recette est contractuelle. C’est le pendant du test concernant l’expression des besoins par le client. Elle constitue les véritables critères d’acceptation du produit, voire de chacun de ses incréments. Ces critères doivent être intégrés au projet le plus tôt possible, si ce n’est avant les premières lignes de code.
|
|
Tout commence par les tests On notera que l’approche sur la recette pousse par nécessité au « Test First » de l’Extreme Programming [Beck 2002] afin de connaître les conditions d’acceptation d’une livraison ; partant de là, ses critères peuvent être déclinés. |
1. Création des critères d’une recette
Pour établir les critères de recette, le PO sera en relation notamment avec les parties prenantes telles que celles que l’on peut trouver dans les fonctions dans la maîtrise d’ouvrage (voir https://tinyurl.com/wikipediaMaitriseOA) :
-
Le maître d’ouvrage stratégique (MOAS) : en véritable patron, il aidera à définir sa vision, les axes importants de la recette et le bon dosage par rapport au milieu du projet et de l’entreprise.
-
Le maître d’ouvrage opérationnel (MOAO) : c’est lui qui connaît le mieux les contraintes opérationnelles, ce qui est nécessaire aux opérations pour que le service rendu aux utilisateurs soit optimal.
-
L’expert métier (EM) : il connaît les standards du métier et pourra donner les critères attendus pour répondre aux attentes du métier.
-
L’architecte métier (AM) : il fournit les critères d’acceptation en rapport avec les moyens existants.
-
Le juriste : si vous en avez les moyens, il en faut toujours un pour ces choses-là !
|
|
Une recette agile On notera que ces critères sont contractuels et sont logiquement intégrés à une annexe du contrat entre le client, qu’il soit externe ou interne à l’organisation. Cependant, par ignorance, par négligence, par manque de temps, ou plus généralement par manque de maturité, ces critères sont souvent absents. Dans un état... |
Stratégies de gestion des anomalies
 |
Une marée de bugs en chiffres Il paraît qu’un développeur émettrait une hypothèse toutes les 10 lignes de code. Pas de quoi remettre en question la relativité restreinte ou générale d’Albert Einstein, mais plutôt sur des choses en apparence banales comme :
Néanmoins, il en résulterait la génération de 8 bugs par jour avec un reliquat après correctifs de 12,5 bugs par milliers de lignes code avec un langage comme Java. Étant donné qu’une équipe Scrum fait environ 10 personnes qui travaillent sur 2 sprint, soit 10 jours ouvrés, on a une production d’environ 10*10*8 bugs, soit 800 bugs générés par sprint ! Des chiffres du même ressort ont été publiés dans une infographie fournie par InitialState.com, dont on peut déduire, sur la base de 50 lignes de code produites par jour, la découverte de 50 bugs découverts d’une équipe sur chaque sprint [Initial State 2014]. Une autre estimation, nous est fournie par Steve McConnell qui a partagé des ratios de l’industrie du logiciel [McConnell 2004] :
Selon Watts Humphrey, les développeurs ajoutent en moyenne 1 à 3 bugs par heure dans leurs conceptions, et 5 à 8 défauts par heure dans leur code [Humphrey 1997]. Dans le cas d’une stratégie DevOps, l’anticipation des problèmes avant injection du code dans la plateforme d’intégration continue (voir chapitre Versant technique du test) indique à quelle vitesse les bugs arriveront sur les postes des utilisateurs, d’où l’importance d’une bonne stratégie de test en amont du PIC, mais aussi en aval (voir chapitre Versant technique... |
Rôles
Dans une stratégie de tests, les rôles et les responsabilités de chacun sont d’une aide précieuse lorsqu’il s’agit de faire bouger les choses ; ainsi, il est bon d’identifier :
-
les rôles présents dans le projet ;
-
les objectifs de chacun d’entre eux ;
-
la part de chacun sur les activités et les moyens liés aux tests (par exemple avec un RACI qui est aligné avec les objectifs).
Sur cette partie d’une stratégie de test, le versant humain et le contexte organisationnel (voir chapitre Facteurs de succès) seront d’une aide précieuse.
Dans cette section, nous donnerons les rôles majeurs dans une organisation autour du testing ; cependant, il vous faudra les adapter au contexte de votre organisation.
1. Rôle du Product Manager dans le test
Le Product Manager (PM) fournit aux équipes les intentions du métier. Ces intentions seront alors découpées en éléments de backlog plus petits, gérables dans une itération par les équipes.
Sur cette partie, on constate généralement les travers suivants :
-
la volonté de demander plus de valeur ajoutée aux équipes de réalisation ;
-
un découpage des intentions métier affectées par avance aux équipes en place en fonction de leurs spécialisations ;
-
l’absence de critères d’acceptation voire de testabilité.
Lorsqu’on est loin du terrain de la réalisation, il est facile de faire des demandes, mais celles-ci se retrouveront vite bloquées en aval, notamment par les activités de développement et testing. Cette configuration est typique d’une organisation où les flux sont poussés. Dans ce contexte, il est nécessaire de faire émerger la notion de « juste-à-temps » vue dans le chapitre Quelques rappels afin de permettre aux équipes de faire un travail soutenu et soutenable, en intégrant la qualité suffisante à leur réalisation pour ne pas avoir un produit assemblé qui empilerait tellement de problèmes qu’il serait impossible de trouver la cause d’une anomalie en production.
Quand les intentions métier sont prédécoupées...
Reporting
1. Généralités
Le reporting est une partie indispensable de l’activité de test. Il peut prendre différents aspects suivant le contexte.
Bien qu’il puisse prendre une forme écrite ou verbale, le rapport doit viser le public pour lequel il est prévu ; ainsi, le niveau de détails et le formalisme comportent notamment :
-
Une synthèse sur la bonne santé du produit sera suffisante pour un décideur.
-
Une vision sur les anomalies les plus critiques sera intéressante pour un comité de déploiement ou l’équipe de Support.
-
Une vision sur la dette technique liée au produit permettra au PO de prendre la mesure de son patrimoine fonctionnel et des risques qu’il comporte.
-
Une description, ou encore mieux une discussion, détaillée sur le contexte de chaque anomalie sera nécessaire pour une équipe de développement pour une bonne compréhension du problème.
-
Une vision sur la productivité, comme le nombre de tests, et les moyens mis en œuvre pour le test manager ou le PO qui s’intéresseront à la productivité des tests.
Formalisme du rapport de test
Bien souvent, le rapport de test s’attache à présenter en premier les moyens et les éléments de productivité des tests alors que la plupart des parties prenantes...
Living Documentation
1. Généralités
Dans un projet, la documentation est un pilier qui permet le transfert de la connaissance à travers l’espace et le temps. Cependant, l’agilité préfère des solutions opérationnelles à une documentation exhaustive. Il y a donc un juste milieu à trouver. Il dépend bien évidemment du contexte du projet. Par exemple, pour un projet de logiciel embarqué dans un avion de ligne ou un dispositif médical, la quantité de paperasse impliquée par la norme est évidemment sans comparaison avec celle d’un site marchand. Par ailleurs, l’envergure et l’âge du projet vont augmenter la masse documentaire.
En fonction des profils, la rédaction est souvent perçue comme une tâche fastidieuse car elle n’est qu’une image mentale d’un produit ou d’une de ses parties, d’une activité passée ou future, mais sans vraiment être la chose décrite ; par ailleurs, après un an, moins de 1 % des documents sont encore utilisés [Ortega 2009]. Elle pose ainsi des difficultés :
-
sur la motivation et l’appétence à faire de la documentation ;
-
sur des choses qui existent déjà par ailleurs, et qui semblent redondantes [Beck 2004] [Clear 2016] [Moustier 2021-8] ;
-
sur des possibilités qu’il faut tenter de formuler suffisamment clairement, avec un souhait d’exhaustivité implicite ou explicite ;
-
sur la structuration d’une pensée qui a pour seul cadre la fameuse « page blanche », ce qui a pour effet de devoir refaire une conception.
Par ailleurs, tandis qu’un code peut être considéré comme « fini » lorsqu’il fonctionne, la documentation semble ne pas avoir de limite, rarement poursuivie de feedbacks d’appréciations car rarement lue.
Nous sommes tous capables d’allonger la liste des raisons capables d’expliquer les raisons d’une documentation hasardeuse [Reales 2022] [Satish 2016] et peut se résumer par :
|
« La documentation, c’est l’huile de foie de morue de la programmation : Les Managers pensent que c’est bon pour les Programmeurs, et les Programmeurs détestent... |
Stratégies sur les données et environnements de tests
La gestion des données de test est LE sujet le plus délicat du test ; en effet, selon Boris Beizer, les données seraient la deuxième cause d’anomalies (presque 23 % des cas) [Beizer 1990].
Traditionnellement :
-
Le test (fonctionnel) est le parent pauvre du développement.
-
La gestion des exigences non fonctionnelles est le parent pauvre du test fonctionnel.
-
Et la gestion des données de test est l’enfant très souvent oublié du test.
Pourtant, cette dernière activité consomme 15 à 20 % du temps [Infosys 2018] [Delphix 2022]. Autre fait alarmant, 15 % des anomalies sont dues aux données.
Pour tenter de répondre à ce problème, il existe plusieurs approches.
1. Clonage des données de production
Pour disposer de données de test et pour déboguer, l’approche la plus simple consiste à disposer d’un environnement de test le plus proche possible de la production ; ainsi, la première des stratégies qui soit mise en application est la duplication des bases de données. Dans un rapport de 2017 qui n’est plus disponible, l’éditeur Delphix avait mesuré qu’il fallait en moyenne 3,5 jours et 3,8 personnes pour fournir un nouvel environnement [Delphix 2017].
En conséquence, certains produits sont spécialisés dans le clonage de bases de données à la demande et de façon extrêmement rapide. Ces outils réduisent les temps de clonage de plusieurs heures à 5 ou 6 minutes pour 2 To à transférer.
Cependant :
-
Cette approche peut s’avérer coûteuse en matière d’espace disque et de licence de produit.
-
Suivant le contexte lié au produit, il peut y avoir un problème de confidentialité des données mises à disposition aux équipes.
-
Sur les nouvelles fonctionnalités, les données peuvent ne pas exister.
-
Les données de production sont mises à jour et peuvent changer d’état, voire se périmer - par exemple, un dossier client peut ne plus être disponible pour un test.
2. Gestion des données de test
a. Génération des données
La génération...
Testing et DevOps
1. Culture et généralités
Considéré comme le nouveau Graal des stratégies de développement qui succèdent à l’agilité, le DevOps introduit ses propres bouleversements dans le rôle du testeur ; en d’autres termes, si vous aviez acheté ce livre en vous disant qu’il fallait vous mettre à la page pour l’agilité, vous aviez en fait deux trains de retard, car à ce jour, la majorité des entreprises ont adopté DevOps comme socle de leur agilité. Même si le niveau de maturité peut être contestable, il n’est pas rare de trouver une plateforme d’intégration continue (PIC) dans l’équipe.
|
|
Plateforme d’Intégration Continue (PIC) Une PIC est un ensemble d’outils et de processus qui enchaînent de façon automatique la compilation, préparent les binaires pour le déploiement, et lancent les tests et les contrôles qualité sur ces binaires. Les outils les plus connus sont Jenkins, Gitlab-ci, Azure DevOps, Bamboo. Une PIC intègre des conditions liées aux contrôles qualité et les tests pour déterminer si le processus peut continuer. Depuis les premières fois où la notion de PIC a été imaginée, avec les travaux de Gardy Booch, puis à la création de la méthode Extreme Programming [Beck 2004] avec un mécanisme d’intégration sur une machine cible dédié à la vérification continue des « CRC Cards », c’est-à-dire des US [Booch 1991], les pratiques ont évolué pour se décliner en :
|
En effet, tandis que l’agile tient principalement sur [Digital.ai 2024] :
-
la satisfaction des clients finaux ;
-
le Time to Market ;
-
un avantage compétitif ;
L’apport de DevOps dans l’industrie logicielle permet de déployer le code trente fois plus fréquemment et 200 fois plus vite, avec...