De la complémentarité des démarches de test

Dans tout projet, les tests occupent une place très particulière. Leur vocation première est de s'assurer que le logiciel répond au besoin. Ils assurent ainsi le lien entre le monde des utilisateurs et le monde du développement. Les tests se retrouvent de manière très formelle - quasi juridique - dans le process de validation (le "PV de recette"). Ce rôle de point d'orgue du projet (sa conclusion) occulte très souvent la place réelle des tests, on oublie qu'ils ont participé très en amont à l'élaboration du livrable : derrière un PV de recette dûment signé, combien de bugs ont dû être préalablement corrigés, combien de chapitres a-t-il fallu revoir dans les spécifications ? Ces ajustements n'ont pas été produits ex nihilo, ils sont le résultat de la constatation d'une anomalie, d'un test en fait. S'ils ne sont pas formalisés, on les retrouve indirectement dans les écrits du projet : soit sous forme de complément de spécifications, soit aussi sous forme de correction de bug.

Lorsque le test n'est plus formalisé " sous le manteau " mais fait l'objet d'une démarche systématisée, on parle de démarche pilotée par les tests.

Trop souvent cette démarche est opposée à l'approche classique, et ce de façon manichéenne. Nous allons voir au contraire que les deux démarches sont complémentaires et que les outils correspondants peuvent être facilement intégrés. La démarche classique établit des cahiers de recette sous forme de scénarios qui seront joués, a posteriori, lors de la réception des développements. Ce travail est aujourd'hui outillé par des logiciels tels que Test Director.

De l'autre côté la démarche pilotée par les tests repose sur l'exécution de tests en continu comme partie du process de développement. L'outillage est bien distinct car il suppose dans ce second cas de figure une très forte proximité avec les développements produits, et non pas une vision de " surface ". Plutôt que des progiciels, cette démarche suppose donc des développements spécifiques qu'il convient de rationaliser autours d'une plateforme normalisée. Les outils de cette normalisation existent là encore, avec des logiciels tels que Fitnesse ou GreenPepper .

Force est de constater que les deux démarches ne sont pas opposables : les tests de recette sont considérés comme opposables au sens de l'utilisateur et des directions qualité, il n'est donc pas envisageable de les supprimer des phases de recette. De même il serait préjudiciable de se cantonner dans une approche à effet tunnel qui repousserait les tests en toute fin de projet au moment de la recette finale. Cette cohabitation des approches en amont et en aval du projet est souhaitable et heureusement possible. Nous allons voir ici comment les logiciels Greenpepper et Test director peuvent être utilisés conjointement, et ce malgré leur approche très différente du sujet.

Illustration par l'exemple de deux logiciels

Test Director

Test Director permet de constituer un référentiel de besoins fonctionnels qui rend compte des fonctionnalités attendues par les utilisateurs. A chacune de ces fonctionnalités sont associés des jeux d'essais. Le jeu d'essai à proprement parler comporte une description libre (de type word), accompagné d'un ensemble d'étapes qui devront être validées par les testeurs conformément à la description. Un automate permet, pour les tests qui s'y prêtent, de procéder à des validations en automatique, mais le fonctionnement par défaut repose sur la validation manuelle par un " utilisateur testeur ", dont le travail sera consigné.
Le logiciel apporte ici une formalisation sous forme de " workflow " des tests dénommé " plan de test ". L'outil offre également des fonctionnalités de " reporting " qui rendent compte de la couverture des tests. L'accent est donc porté sur la maîtrise du process de test (déclaration, planification, suivi, reporting).

Greenpepper

Greenpepper se présente sous la forme d'un espace collaboratif (" wiki ") où les concepteurs pourront saisir les scénarios de tests correspondant aux fonctionnalités attendues. Un vocabulaire commun est établi avec les équipes de développement afin d'établir une correspondance entre le vocabulaire métier et les API de l'application. Ce vocabulaire commun permettra par la suite de structurer la description des jeux d'essai. Pour chaque fonctionnalité un formalisme ad hoc est arrêté.

Dès lors, les équipes de développement et les utilisateurs vont travailler en parallèle. Les responsables des tests écrivent dans les pages wiki un ensemble d' " affirmations " sur des données métier, et cela conformément au formalisme retenu. Les développeurs pour leur part élaborent de petites portions de code, nommées fixture, qui permettront de faire le lien entre le formalisme retenu et les API techniques de l'application à tester. Le logiciel se charge d'interfacer les pages wiki aux fixture lorsque le responsable des tests appuie sur le bouton Execute, ce faisant les " affirmations " fonctionnelles seront confrontées aux résultats retourné par l'application. Les tests peuvent alors être reproduits très simplement. L'accent ici est porté sur l'industrialisation d'un volume -important- de tests unitaires.

Complémentarité

Devant ces différences de fonctionnement, proposer une intégration de ces deux outils peut paraître déroutant. De plus certains pourraient arguer que Test Director présente lui aussi des fonctionnalités de tests automatisés ou une intégration avec des outils de test automatisés d'IHM.

Cependant leur philosophie d'utilisation est différente. Des outils tels que Test Director apportent leur plus value sur une organisation des tests par fonctionnalité, une formalisation des workflows d'écran à parcourir pour tester une fonctionnalité. Fréquemment, avant de mettre en production une application, une nouvelle version est alimentée avec les données de production. Un ensemble d'écrans est alors comparé sur la version en production et sur la nouvelle version, afin de s'assurer que les données générées sont identiques. La formalisation de ces étapes de vérification est alors très bien assurée par un plan de test.

Ces tests restent pourtant " en surface ", dépendants de l'existence d'une IHM et de sa conception. Leur automatisation, lorsqu'elle est possible, est coûteuse, toute modification de présentation nécessite de reprendre les tests même si aucune règle métier n'a changé. A l'inverse des logiciels tels que Greenpepper permettent des tests en profondeur au niveau des API métier. Leur évolution n'est liée qu'à l'évolution des API métier, beaucoup plus rare que les changements d'IHM et quasi systèmatiquement lié à des ajouts de règles métier. L'interfaçage au niveau des API permet d'utiliser également des techniques de développement éprouvées, telles que le pattern adpateur, pour gérer la compatibilité d'un test avec une nouvelle API.

Enfin les tests portent directement sur les données métier ce qui facilite l'expressivité des tests. Prenons l'exemple d'une application bancaire de tenu de position. Celle-ci devra entre autres choses être capable de valoriser les obligations tenues en portefeuille. Un outil tel que Greenpepper permettra de tester cette fonctionnalité sous la forme du tableau suivant, qui contiendra en réalité des dizaines de combinaisons à tester.

A l'inverse, un test via l'IHM nécessiterait pour tester autant de cas de saisir un nombre très important de données. Cette saisie est fastidieuse, nécessite parfois d'utiliser une IHM non prévue pour de la saisie de masse, voire de générer des fichiers d'import lorsque les positions en portefeuille sont insérées par batch. Ces opérations sans valeur ajoutée dénaturent le test métier qui ne pourra pas se consacrer à la vérification des différents cas possibles.

Un projet peut donc tirer un bénéfice de l'utilisation conjointe des outils. Il convient alors de trouver un moyen de les intégrer afin d'assurer un seul point d'entrée dans le processus de test.

De par son approche en bout de chaîne et ses capacités de reporting avancées, Test Director sera ce point d'entrée. Nous verrons dans un prochain article comment les résultats des tests Greenpepper pourront apparaître dans ce dernier.

Par Raoul Emin et Marc Bojoly