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.

• 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.

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.

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.

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" ...

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 :

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.