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 ». [ISTQBM 2012]
Cette stratégie s’inscrit généralement dans une politique de test qui définit pourquoi l’entreprise teste et ses objectifs généraux. Cette politique pourra être élaborée en fonction de la configuration de l’entreprise.
L’intérêt d’un document qui décrit une stratégie de test est de définir l’approche sur les différents axes du test pratiqués afin d’aligner les parties prenantes de l’organisation et du projet. Il est important de souligner que pour le test, une approche globale est nécessaire, car selon SAFe, étant donné qu’une stratégie est une action dont la portée est de longue durée avec des impacts économiques importants, cette action est nécessairement centralisée. La stratégie délibérée qui en résultera pourra alors être déclinée suivant les circonstances locales pour potentiellement faire émerger des stratégies en provenance du terrain.
Figure 1 : Stratégies délibérées et émergentes
 |
Les sections qui composent une stratégie Dans une stratégie de test, on trouve généralement :
|
Stratégie...
Tests systèmes et bout-en-bout
|
|
Tests Systèmes / Bout-en-bout : le niveau macroscopique 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 [ISTBQ]. |
Dans une approche traditionnelle de type cycle en V, la notion de test système est une réalité qui intervient lorsque toutes les parties sont disponibles afin que des tests bout-en-bout puissent être réalisés.
Dans une approche agile, cette notion prendra un autre sens, car il est évidemment hors de question d’attendre que toutes les parties soient disponibles : dès qu’un sous-système est disponible, on le teste, quitte à ce que ce sous-système soit testé de multiples fois jusqu’au moment où l’intégralité des sous-parties est disponible.
Avec une telle approche, le test système est alors situé à la limite floue du test d’intégration.
De même avec la vision ISTQB du test unitaire où c’est « l’unité » qui est testée, la validation d’une partie du SI telle qu’un service web ou une application qui comprendrait une IHM correspondra aussi au test d’une unité alors que pour l’équipe de développement et les Testeurs qui en font partie, cet ensemble constituera l’opportunité de faire des tests système.
Nous sommes ici aussi à la limite floue du test d’unitaire…
La vision du niveau de test dont il est question sera dépendante :
-
des outils qui permettront l’isolation d’unités (quelle qu’en soit la taille) et l’automatisation des tests (voir la notion de « Harnais de test » dans le chapitre Versant technique du test - section Tests Unitaires) ;
-
de la connaissance du métier sur les Unités voisines - d’où l’importance de la connaissance comme enjeu du test - voir chapitre Facteurs de succès ;
-
d’un environnement qui met à disposition les Unités voisines avec le bon niveau de configuration....
Tests exploratoires
1. Préparation des tests exploratoires
|
|
Les origines du Test exploratoire 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). Le Test Exploratoire (TE) a émergé de cette école pour être publiquement partagé pour la première fois lors de la conférence de la 7e conférence LAWST (Los Altos Workshop on Software Testing) de 1999 [Kaner 2003]. |
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.
Cette approche est basée sur une charte qui définit les objectifs d’une session de TE qui, état d’esprit agile oblige, est bornée dans le temps (timeboxée).
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 créatrice.
 |
Les scénarios de tests ne servent à rien ! James Bach, adepte zélé du test exploratoire, proclame haut et fort que les scénarios de tests NE SONT... |
Ingénierie des Tests de recette
1. Préparation de la recette
La notion de recette est contractuelle. Sur une configuration de type cycle en V, elle est située au même niveau que l’expression des besoins par le client.
Véritables critères d’acceptation du produit (et de chacun de ses incréments), ils doivent être intégrés au projet le plus tôt possible, si ce n’est au démarrage.
|
|
Importance de la recette On notera que ces critères sont contractuels et sont logiquement intégrés à une annexe du contrat entre le client (même interne) et le fournisseur (l’équipe de réalisation) ; cependant, par ignorance, par négligence, par manque de temps (plus généralement par manque de maturité) ou dans un état d’esprit clairement agile, le client viendra élaborer ces critères avec l’évolution du projet. |
L’important est de disposer de critères de recette revus par les parties prenantes, même s’ils sont simples.
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://fr.wikipedia.org/wiki/Fonctions_dans_la_ma%C3%AEtrise_d%27ouvrage) :
-
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à !
Dans le cas où les utilisateurs sont internes à l’entreprise qui commandite...
Stratégies de gestion des anomalies
Au bout d’un certain temps, il devient inéluctable que la quantité d’anomalies devienne ingérable si on n’adopte pas une vision qui permet de gérer la masse des bugs connus. Cette section propose plusieurs stratégies.
1. Loi de Pareto
Une stratégie de diminution des anomalies peut consister à appliquer le principe de Pareto pour concentrer l’effort sur la plus forte occurrence des anomalies.
Le Tableau 1 : Répartition des anomalies suivant leur origine (voir sction Quelques chiffres de l’industrie), par exemple, fournit une répartition des anomalies par activité sur laquelle on peut concentrer les efforts de tests. Ce Pareto permet ainsi l’amélioration efficace des processus car il permet de s’occuper de 80 % des situations avec seulement 20 % d’effort.
On peut aussi mesurer le nombre d’anomalies sur des parties spécifiques du produit pour accentuer les efforts là où il y aura le plus de retours. Ce Pareto améliorera les points faibles d’un produit.
Une autre approche se base plutôt sur un point de vue d’exploitation : le standard ITIL distingue la notion d’incident de la notion de problème :
-
Un incident est un « événement qui ne fait pas partie du fonctionnement standard d’un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service » ; en d’autres termes, c’est un utilisateur qui va appeler le centre d’appels pour rapporter ce qu’il pense être un dysfonctionnement.
-
Un problème est une classe d’incidents ; autrement dit, c’est l’anomalie dont la correction permettra de répondre à tous les incidents similaires.
Ainsi, un Pareto basé sur la quantité d’incidents par problème pourra traiter les problèmes les plus fréquents en production et améliorer rapidement la satisfaction des clients.
Pour maximiser la valeur ajoutée produite par une correction, on peut par exemple combiner ce phénomène de fréquence/impact humain avec la notion de valeur ajoutée fonctionnelle ou la présence de méthodes de contournement du problème dont...
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 soit 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 .
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 importent :
-
une synthèse sur la bonne santé du produit sera suffisante pour un décideur ;
-
une vision sur la santé et les anomalies les plus critiques sera intéressante pour un comité de déploiement ou l’équipe de Support ;
-
une description détaillée sur le contexte d’une anomalie sera nécessaire pour une équipe de développement ;
-
une discussion sur cette anomalie avec un Développeur est aussi indispensable pour une bonne compréhension du problème.
Par ailleurs, lorsqu’il s’agit de réaliser une expertise telle qu’une analyse de cause racine, il faut aussi pouvoir connaître les conditions de test, et lorsqu’il s’agit de la hiérarchie ou d’une relation contractuelle (par exemple, dans le cas d’une TRA - Tierce Recette Applicative - https://fr.wikipedia.org/wiki/Tierce_recette_applicative), il faut être capable si nécessaire de montrer l’effort de test réalisé.
Tous...
Stratégies 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 1994].
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 activité consomme 15 à 20 % du temps [Infosys 2018] [Delphix] ; 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 développement 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. Selon [Delphix 2017], il faut en moyenne 3,5 jours et 3,8 personnes pour fournir un nouvel environnement.
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, qui réduisent plusieurs heures pour 2 To à transférer à 5 ou 6 minutes ; cependant :
-
cette approche peut s’avérer coûteuse en termes 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 qui sont mises à disposition de l’équipe sans aucune anonymisation ;
-
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 (un dossier 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 des données permet de traiter :
-
la question d’anonymisation des données ;
-
le cas des nouvelles données...
