Selenium et Watir.
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 :
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 :
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" ...
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.
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.
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.