La gestion de la qualité logicielle est une discipline qui a muté de manière profonde avec l’évolution des cycles de vie des projets informatiques. Si l’objectif reste constant, assurer la conformité d’un outil par rapport à un besoin métier, les méthodes pour y parvenir ont basculé d’un modèle de contrôle manuel rigoureux vers un modèle d’intégration continue où la donnée est vivante.
L’ère de la rigueur documentaire, la gestion des tests par référentiels statiques
Avant l'avènement des plateformes de gestion du cycle de vie des applications (ALM) modernes, la validation d'un système reposait sur une infrastructure documentaire massive. Cette approche, bien que perçue aujourd'hui comme rigide, offrait une traçabilité absolue et une base de preuve indispensable pour les projets critiques.
La centralisation par le document de liste des tests
Le pilotage de la recette technique et fonctionnelle était orchestré par un document maître: la liste des tests. Ce document ne se contentait pas de recenser des actions, Il structurait la pensée logicielle par modules. Chaque module (comptabilité, achats, gestion des stocks, etc.) était décomposé en unités fonctionnelles.
Cette organisation permettait une vision macroscopique de la santé du projet. La liste servait de pivot central, elle permettait de s'assurer qu'aucune régression n'était omise lors d'une montée de version. Une rigueur extrême était exigée de la part du gestionnaire de tests, chaque ligne de ce document représentait un engagement de conformité. L’absence de mise à jour de ce référentiel rendait immédiatement caduque toute la phase de recette.
L’anatomie de la fiche de test, une norme d'exécution
À chaque entrée de la liste correspondait une fiche de test individuelle. Ce niveau de détail visait à supprimer toute subjectivité lors de l'exécution. La fiche était composée de sections immuables:
- La définition des requis minimums: Avant toute action, les conditions d'éligibilité du test devaient être réunies. Cela incluait la disponibilité d'un environnement dédié, la présence de jeux de données spécifiques en base de données et l'accès à des profils utilisateurs particuliers. L'omission d'un seul prérequis invalidait la totalité de la procédure.
- Le scénario opératoire: Le testeur était guidé par une suite d'instructions précises. La neutralité du scénario garantissait que le test produirait le même résultat, quel que soit l'exécutant. Cette reproductibilité est le fondement de la méthode scientifique appliquée à l'informatique.
- Le résultat attendu: Cette section définissait la vérité terrain. Le comportement du système devait correspondre point par point à cette description. Tout écart devait être consigné.
Le facteur humain et l'organisation en équipe
La méthode traditionnelle reposait sur une séparation stricte des rôles. Une équipe dédiée à la recette, souvent distincte de l'équipe de développement, était chargée de l'exécution. Cette indépendance garantissait l'impartialité des tests.
Le processus de suivi était manuel et chronophage: Chaque exécution nécessitait de renseigner la date, le nom de l'exécutant et le statut (Passé, Échoué ou Bloqué). En cas d'erreur, un descriptif technique détaillé était rédigé. Ce descriptif devait permettre au développeur de reproduire l'anomalie sans ambiguïté. La communication entre l'équipe de test et les développeurs passait par ces fiches de suivi, créant un cycle de correction souvent long mais extrêmement documenté.
La révolution Azure DevOps, l’industrialisation du plan de tests
L’évolution vers Azure DevOps transforme ces documents statiques en objets numériques interconnectés. La gestion des tests n'est plus une étape finale déconnectée, mais un flux continu intégré au développement.
Prérequis et gestion des licences
L'accès aux fonctionnalités avancées de test dans Azure DevOps n'est pas ouvert par défaut à tous les utilisateurs. Contrairement aux tâches de base (Backlog, Boards), la gestion des plans de tests nécessite une licence spécifique: La licence Azure Test Plans.
Elle est généralement incluse pour les abonnés Visual Studio Enterprise. Pour les autres, une extension payante doit être activée au niveau de l'organisation. Sans ce droit d'accès, l'utilisateur ne peut que consulter les résultats ou exécuter des tests très basiques, mais la création et la structuration des plans lui restent inaccessibles.
Structuration du Plan de Tests (Test Plan)
Dans DevOps, le plan de tests remplace l'ancien document de liste. Il est créé pour un cycle spécifique (un Sprint ou une Release). À l'intérieur de ce plan, des Test Suites (Suites de tests) sont organisées. Il en existe trois types:
- Static Suite: Un dossier classique pour organiser les tests manuellement.
- Query-based Suite: Une suite dynamique qui regroupe automatiquement tous les tests répondant à un critère.
- Requirement-based Suite: La plus puissante, qui lie directement les tests à une User Story ou un besoin fonctionnel.
Création et configuration d'un Test Case
À l'intérieur de ces suites, les fiches de tests deviennent des Test Cases. La création d'un Test Case reprend les fondamentaux de l'ancienne fiche de test mais y ajoute de l'interactivité:
- Steps (Étapes): Chaque étape du scénario est saisie avec son action et son résultat attendu.
- Parameters (Paramètres): Il est possible d'injecter des variables pour tester un même scénario avec plusieurs jeux de données sans multiplier les fiches.
- Shared Steps: Si un processus est commun à plusieurs tests, il est créé une seule fois et partagé, facilitant la maintenance.
L’exécution via le Runner Web, une interface de contrôle dynamique
L'exécution des tests sous Azure DevOps s'opère via une interface dédiée qui guide l'utilisateur en temps réel. Le processus s'initie depuis l'onglet Execute du plan de tests. Après avoir sélectionné le test ou la suite de tests concernée, l'utilisateur lance la procédure via l'option “Run for web application”.
Cette action ouvre le Runner Web, une fenêtre interactive qui se superpose à l'application testée. Cette interface présente de manière séquentielle les étapes définies lors de la conception du Test Case:
- Validation interactive des étapes: Pour chaque étape du scénario, le testeur dispose d'un système de validation binaire. Un "check" positif est apposé si le comportement observé est conforme. Un marqueur négatif est utilisé en cas de divergence.
- Documentation instantanée de l'anomalie: Si une étape est marquée en échec, l'interface permet de générer immédiatement un bug. Grâce au bouton de création de bug intégré au runner, le système pré-remplit le ticket avec les étapes déjà effectuées, les résultats attendus et les écarts constatés.
- Capture de preuves multimédias: Le Runner Web offre des outils natifs pour documenter les dysfonctionnements de manière visuelle:[BL]
- Capture d'écran: Un bouton dédié permet de réaliser des clichés instantanés des erreurs d'affichage ou des messages système.
- Enregistrement vidéo: Une fonctionnalité d'enregistrement d'écran permet de filmer une séquence d'actions; C'est un atout majeur pour reproduire des bugs intermittents.
- Commentaires et pièces jointes: À chaque étape, l'utilisateur peut ajouter des notes contextuelles ou joindre des fichiers de logs.[IMG:img_1777305893489_4.png;Exécution d’un test manuellement][IMG:img_1777305893489_4.png;Exécution d’un test manuellement]
Visibilité et exploitation des résultats
Une fois la session d'exécution clôturée, les données sont immédiatement agrégées au niveau du plan de tests. La visibilité est totale et instantanée:
- Tableaux de bord de progression: Le statut global du plan est mis à jour en temps réel.
- Traçabilité de bout en bout: Il est possible de remonter depuis un bug jusqu'au test exact qui l'a généré.
- Historique des exécutions: Chaque exécution est archivée avec son contexte complet. On peut comparer les résultats d'un même test sur plusieurs versions du logiciel.
Conclusion
Le passage d'une gestion documentaire rigoureuse à une gestion intégrée sous DevOps ne supprime pas la nécessité de la rigueur, elle la déplace. La précision qui était autrefois dévolue à l'écriture de fiches papier est aujourd'hui investie dans la configuration de plans de tests dynamiques. Cette transition permet de réduire drastiquement le délai entre la découverte d'une erreur et sa résolution, tout en conservant l'héritage méthodologique des tests par module.