Démarches de tests fonctionnels

Si vous êtes un habitué de notre blog, vous saurez à quel point les démarches de développement piloté par le test (TDD) nous sont chères. Allié à un bon outil de test fonctionnel le TDD s’avère être un levier de productivité très important.

L’objectif de cet article est de vous présenter les différents types d’outils de tests fonctionnels puis de donner quelques perspectives sur les outils de tests du futur.

Approche centrée sur l’IHM

Très souvent chez nos clients, les personnes avec qui nous parlons de tests fonctionnels automatisés pensent immédiatement aux outils de tests d’IHM. Cette approche est en effet la plus naturelle car elle consiste en fait à simuler l’utilisateur final par un outil qui reproduit son comportement.

Prenons le cas des applications web, on pourra par exemple distinguer deux types d’outils :

  • Ceux qui pilotent un navigateur et reproduisent les interactions de l’utilisateur avec ce dernier. On citera notamment les outils Selenium et Watir.

TF IHM 2

  • Il existe aussi des outils, de type robots HTTP, qui eux se substituent au navigateur et reproduisent les requêtes produites par ce dernier. Cette approche est surtout utilisable lorsque l’application est peu adhérente à un navigateur spécifique et possède peu de code Javascript. Elle a alors l’avantage d’être beaucoup plus rapide car ne nécessitant pas le lancement d’un navigateur. Canoo webtest ou Webrat utilisent cette approche.

TF IHM 1

L’avantage évident du test fonctionnel d’IHM est qu’il permet de reproduire en intégralité les cas d’utilisation d’une application (vu de l’utilisateur); sa nature exhaustive le rend plutôt rassurant pour les maitrises d’ouvrages.

Cette approche a néanmoins de nombreux défauts :

  • Les tests sont décrits dans un formalisme technique peu compréhensible par des utilisateurs, leur rédaction requiert donc l’intervention systématique d’informaticiens.
  • Pour palier à ce manque, certains outils proposent un « recorder » permettant de créer un scenario de test en enregistrant les manipulations d’un utilisateur dans son navigateur. Mais on perd alors l’un des principes clé des démarches de développement piloté par les tests : la capacité à écrire ses tests en amont des développement.
  • Ces tests semblent exhaustifs mais ne le sont pas. Par exemple toute la partie batch des applications est exclue de ce type d’approche et de manière générale des pans entiers des applications ne peuvent pas être traités par les tests d’IHM.
  • La difficulté à bouchonner certains services. Par exemple prenons le cas d’une chaine d’impression où l’on sera obligé d’imprimer les données pour les vérifier à la main ensuite.
  • De surcroît ces tests ont le défaut d’être en général long à exécuter ce qui peut devenir réellement gênant sur une volumétrie importante.

Spécifications exécutables

Une autre approche que nous avons largement mis en oeuvre chez nos clients est celle des spécifications exécutables. Ainsi des outils comme Fitnesse ou GreenPepper permettent à des utilisateurs fonctionnels de décrire au sein d’un wiki le comportement métier attendu pour leur application en testant directement les services métiers et les différentes règles de gestion (en court-circuitant l’IHM). Afin de tester l’application cette approche requiert le développement d’une fine couche logicielle permettant de faire le pont entre les pages de test et les services de l’application testée : il s’agit des fixtures.

spec exe 1

On remarque que l'IHM n'est pas testée. Une couche de fixture s'y substitue

Cette approche a de réels avantages :

  • Le formalisme utilisé pour rédiger les spécifications exécutables est compréhensible par des populations fonctionnelles.
  • Il est possible, au sein même des tests, d’écrire de la documentation fonctionnelle avec toutes les possibilités de mise en page d’un wiki moderne.
  • Les atouts précédents, alliés à la possibilité d’écrire les tests avant l’application testée, font de ces pages de wiki de vraies spécifications exécutables qui peuvent tout à fait se substituer à des spécifications Word.

Au delà d’une simple démarche d’automatisations des tests, il faut percevoir les spécifications exécutables comme une véritable opportunité de rapprocher les populations techniques et fonctionnelles autour d’une vision partagée et non ambiguë du produit logiciel.

Un exemple de spécifications exécutables venant d'être exécutées et en succès.

Un exemple de spécifications exécutables venant d'être exécutées et en succès.

On rencontre cependant des limites lorsqu’il s’agit de tester des applications dont une part importante de la valeur réside dans la présentation et la restitution de l’information et pour lesquelles tester l’IHM est primordial. Il est alors possible de compléter l’outil en l’intégrant avec un outil comme Selenium ou Canoo. Il suffit d’écrire une fixture « passe-plat » permettant de piloter ces outils depuis des pages de spécifications exécutables ; mais alors gare à l’effet « usine à gaz » …

specs exe 2

Mix entre les approches spécifications exécutables et tests d'IHM

Le Behavior Driven Development

Nous allons maintenant parler d’une dernière approche : le Behavior Driven Development (BDD). Ecrire un test en BDD consiste à décrire une fonctionnalité selon un formalisme « Given / When / Then » dont voici un exemple :

Exemple bdd

L'expressivité du BDD en image. Il s'agit pourtant bien d'un test exécutable !

Le test ci-dessus est écrit en langage naturel (et en français !) et gagne donc beaucoup en expressivité. On perd en revanche beaucoup en terme de collaboration, car à ce niveau les outils de BDD ne proposent rien : au mieux les tests sont écrits dans des fichiers texte gérés en configuration au côté des sources logicielles.

Les pionniers en la matière sont les outils Cucumber dans le monde Ruby et jBehave dans le monde Java. Chacun de ces deux outils s’intègre  aussi (et cette fois ci de manière native) avec des frameworks de tests d’IHM permettant ainsi d’interagir avec des interfaces web en langage naturel. Si vous êtes intéressés par la mise en oeuvre de ces outils, des articles sur le sujet ne vont pas tarder à paraitre sur le blog.

Concernant les référentiels de tests …

Dans cet article il n’est pas fait mention des référentiels de tests comme Quality Center ou encore Rational Test. Ces outils, dont l’objectif principal est surtout d’organiser les campagnes de test, peuvent souvent être complétés avec des automates de test. Nous vous encourageons à consulter cet article qui illustre comment intégrer ce type de référentiel avec un outil de spécification exécutables.

La suite ?

Quelle est la suite ? J’imagine que vous m’avez vu venir : il s’agit d’allier les avantages de chacune de ces trois approches au sein d’un même outil. Ainsi un outil qui combinerait  l’expressivité des tests BDD, les fonctionnalités collaboratives d’un wiki et la possibilité de tester les IHM serait extrêmement prometteur.

Aujourd’hui LowDown (interface web pour éditer des tests Cucumber) et Twist sont les outils plus avancés que nous connaissons, mais ils sont loin d’être au maximum sur les axes collaboration et expressivité.

Il reste une place à prendre ;-)

Si le sujet vous a intéressé, nous ne pouvons que vous recommander d’aller visionner la session Innovations techniques au service du test de recette automatisé présentée à USI2009.

10 commentaires sur “Démarches de tests fonctionnels”

  • très intéressant, merci pour cet article. Au delà des exemples simples, serait-il possible de publier un peu plus d'informations sur ces tests dans vos projets réels ? du style nombre total de tests Fitnesse ? Ou d'autres infos qui permettraient de sortir des exemples classiques type "calculette" et qui nous encourageraient à utiliser ces approches ? Bruno
  • Salut Bruno, Je te repndrai parce les chiffres que m'a donné Elisabeth à Grenoble : 3 ou 4 tests d'IHM, une trentaine de tests ATDD (robotframework en l'occurence) et environ deux cents tests unitaires. Ca donne un bon rapport des diffférents niveaux de la pyramide de Mike Cohn. Emmanuel
  • Bonjour Reflexion intéressante. L'outil que vous évoquez rejoint ce que nous aons essayé de construire avec Visual Studio 2010 (test fonctionnel, BDD et collaboration). Ca serait intéressant d'en parler de vive voix.
  • Merci Bruno Voici quelques métriques que je viens de réunir dans différents contextes : - secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper - secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d'une centaine de tests par an - encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d'une semaine - secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d'exp complet est disponible ici : http://usievents.com (session A10) - secteur open source ;-), octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home
  • Bonjour Blaise, tu peux me contacter à mon mail : cblavier at octo dot com
  • J'en profite pour vous faire part de ce Workshop dédié aux tests à Paris avec du beau monde: http://agile.csc.ncsu.edu/tdd/#WorkshopDescription (Via Eric Lefevre-Ardant et Michael Feathers)
  • Merci Christian pour ces chiffres, ce sont les premiers que je vois sur la question. Bravo pour la transparence. Bruno
  • Hello Christian, encore une question : est-ce que les développeurs font également des tests unitaires dans les projets que tu cites ? Dans quelle proportion par rapport aux tests GP ou fitnesse ? Bruno
  • Bruno: De mon expérience avec GreenPepper pour le produit Talia que nous développons (un produit sans réelle interface utilisateur), nous avions une proportion d'environ 80 spécifications exécutables (GreenPepper) pour plus de 200 tests unitaires et intégrés (mstest). Les deux peuvent cohabiter (et doivent!) sans aucun problème. Les spécifications exécutables étaient même utilisées en tant que conditions de succès à nos user stories. Elles étaient écrites régulièrement durant nos sprint planning et vérifiées (exécutées en direct) durant nos reviews. Difficile de faire plus explicite comme démonstration de la complétion des stories!
  • Christian, pour info je cite ton billet ici : http://blog.developpez.com/bruno-orsier/p8534/developpement-agile/pourquoi-sarsquo-interesser-au-bdd-behav/ Bruno
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha