Stay Simple avec Selenium IDE

Ayant récemment accompagné avec Archriss l’un de mes clients lors de la mise en place des tests automatisés, je souhaite partager mon retour d’expérience sur l’outil Selenium IDE car si mettre en place une bonne stratégie de tests est un véritable numéro d’équilibriste, Selenium IDE, s’il connait des limites, apporte de bonnes solutions à cette problématique.

Comme le résume Brian Marick dans le schéma ci-dessous il est en effet nécessaire de trouver le bon équilibre entre les compostantes de testing suivantes : couverture de test, granularité des tests et maintenabilité afin que la mise en place des tests automatisés soit la moins douloureuse et la plus performante possible.

 

En effet, l’expérience et les best-practice de testing indiquent qu’il est préférable d’utiliser plusieurs typologies de tests automatisés : des test unitaires (TU), des tests fonctionnels, et éventuellement des tests passant par l’IHM.

Les tests unitaires et fonctionnels (Fitness) étant déjà très bien décrits sur le web je vais dans cet article vous faire part de mon retour d’expérience sur la mise en place des tests IHM avec l’outil Selenium IDE.

Contexte du projet

Le projet consistait à mettre en place une stratégie de test pour le site marchand d’un des grands opérateurs télécoms Français.

• Environnement technique : Java
• Méthodologie projet : Scrum / Scrumban
• Outil de test : Fitness

L’exécution des tests automatisés avait lieu chaque jour, assurant une suivi régulier et historisé. De tests manuels supplémentaires étaient effectués par ailleurs par une équipe dédiée. La charge de tests manuels s’élevait à une dizaine de J/H par itération de deux semaines.

Constat après 2 mois

Deux mois après la mise en place de Fitness, le nombre d’anomalies livrées en production n’avait pas significativement diminué. De plus, nous constations d’autres points douloureux :

• Ecrire un test qui marche prend du temps, 30 à 40% de la charge de DEV.
• L’exécution des tests échouait régulièrement, sans que la raison soit claire (échec car le site n’avait pas répondu à temps aux commandes, dysfonctionnement ponctuel du serveur intégration, stabilité des autres systèmes…) .

Le gain apporté par les tests automatisés ne paraissait donc pas évident à l’équipe compte tenu de la charge (et donc du coût) associée.

Amélioration continue

Cependant, grâce en partie à Scrum (et à Pascal Poussard 😉 ) nous avons pu, d’itération en itération, résoudre ces problèmes :

Une approche KISS ainsi qu’un projet pilote ont été sélectionné pour mettre en place Selenium IDE et des tests IHM.

Pour information, Selenium IDE est un plugin Firefox qui permet d’enregistrer des tests, les modifier, les exécuter. Cet outil fonctionne sur de nombreuses plateformes de développement Java, .Net …

Sa mise en place est extrêmement rapide et ne demande pas de compétences particulières grâce au recorder (on ne compile pas et on ne code pas les tests 🙂 ) et si l’enregistrement automatique du test reste perfectible, il constitue un premier support pour créer un test.

Stratégie de testing & Cohérence du cahier de test

Selenium IDE permet de tester beaucoup de choses dans les pages Web : Le déroulement des scénarios utilisateurs, la présence de tel ou tel élément, le déclenchement d’une règle de gestion, les contrôles de surface, etc.

Un anti-pattern classique est de vouloir tout tester, et finalement d’essayer de remplacer la recette par les tests Selenium.

Pour définir cette stratégie, plusieurs questions se posent :

Quel est l’objectif des tests ?

Avant de savoir comment faire les tests, il faut fixer ce qu’ils vont apporter. Un principe directeur de test, sur lequel on pourra s’appuyer pour mettre en balance le coût du test (réalisation + maintenance) et le gain du test.

Le gain du test est ce que son succès/échec nous apprend sur l’application.

Au moins un utilisateur peut il vraiment se logguer ? Des tests unitaires nous indiqueraient seulement que les différents composants d’authentification sont OK.

Sur cette mission, nous avons produit des tests de non régression, sur un périmètre d’un test par fonctionnalité majeure du site.

Par exemple :  »Un client effectue un versement en ligne sur tel type de contrat », ou « Un utilisateur utilise le formulaire de contact pour envoyer un email à son conseiller »

Comment est structuré le plan de test ?

La structuration du plan de test fut basée sur une contextualisation des tests,  pour maximiser la vitesse d’exécution de l’ensemble des tests.

Les tests sont jouables uniquement dans un contexte précis. Par exemple, le test du versement part du principe que le navigateur affiche déjà la page d’accueil d’un client loggué sur le site. Le test déroule le versement et retourne sur la page d’accueil.

Le test suivant déclenche le processus d’arbitrage, qui démarre aussi sur la page d’accueil, et ainsi de suite.

Certains tests étaient donc dépendants d’autres tests, l’enchaînement étant orchestré par la suite de tests.

Cette inter-dépendance n’était pas systématique. Finalement, seul le test de login était critique : S’il échouait, le reste des tests échouaient dans la foulée, nous remontant que l’application était totalement KO. Un retour un peu exagéré, mais qui s’approchait assurément du retour qu’aurait fait des utilisateurs sur une même constatation.

L’ensemble des tests était finalement assez proche de ce que ferait un testeur pressé : Il se loggue avec le client, et effectue autant de scénarios que possible dans ce contexte.

Quelle granularité pour ce qui est testé ?

Pour valider une fonctionnalité, le test correspond à l’automatisation d’un scénario utilisateur sur le site.

Dit autrement, le test est réussi si l’enchaînement des étapes du scénario s’est déroulé sans heurts.

Mais ce n’est souvent pas suffisant.

Arrivé à la dernière étape d’un formulaire, le site peut notamment afficher à l’utilisateur une information décrivant la réussite de son action. (« Votre versement a bien été effectué »)

Il convient alors que le test Selenium scrute la présence de cette information sur la page.

Cette nécessité de tester des éléments dans les pages amène la fameuse question : « Jusqu’à quel point on teste ce qui s’affiche ? »

Dans la mission, on a commencé par tester le minimum, à savoir seulement si on arrive bien sur la bonne page du formulaire, et que la donnée essentielle de la fonctionnalité est présente. La présence d’un texte, rien de plus.

Il fallait être vigilant pour ne pas dévier vers l’automatisation de la recette, ou de faire doublon avec les tests fonctionnels.

Moins d’industrialisation….

Nos tests sont enregistrés dans le contrôleur de sources, dans leur format d’enregistrement (Html).

Ils sont directement utilisables depuis le plugin de n’importe quel membre de l’équipe, qui peut jouer les tests sur l’url de son choix (son poste, le serveur d’intégration, etc.)

Utiliser des tests au format de SeleniumIDE (Html) n’empêche pas de les intégrer dans un build.

Il y a deux solutions envisageables :

• Exécuter en ligne de commande le serveur SeleniumRC sur la suite de test ( C’est une fonctionnalité obsolète, basée sur l’option -htmlSuite de Selenium1).
• Exporter les tests Html en code (C#, Java, …), afin de les intégrer proprement dans un build.

Aucune de ces deux approches n’a été mises en place, car:

• Elles sont soit obsolètes, soit lourdes (doublons de tests)
• Elles nécessitent un effort de paramétrage des environnements de test
• Elles nécessitent une gestion sans faille des temporisations dans les tests
• En cas d’erreur, il y a vraiment peu d’éléments de debugging
• Dès lors que toutes les couches de l’application et son environnement d’hébergement sont testées, la probabilité d’un bug non reproductible n’est pas négligeable. Ce type de bugs nuit fortement à l’appréciation de l’outil

Malgré l’écriture de tests aussi robuste que possible (« waitForElement » avant d’appeler une commande sur un élément, Xpath évolué avec du contains, …), il arrive couramment d’avoir un test où il manque une temporisation, générant un bug en apparence inexplicable.

S’en apercevoir sur son poste en cours d’usage est assez différent de constater l’échec surprise d’une build d’intégration pourtant déjà passée précédemment. Ce genre de constatation dégrade fortement la confiance en l’outil.

…Plus d’organisation

Lors de la revue de code d’une story, le relecteur exécute les tests et constate une éventuelle régression.

Le Definition Of Done entre les colonnes « En cours » et « Fait » impose une exécution réussie des tests Selenium.

L’exécution des tests manuellement implique le relecteur, qui devra analyser l’échec et résoudre le sujet, éventuellement avec le développeur de la story en cours de relecture.

Egalement, pour le rituel de fin d’itération, les tests sont joués pour confirmer

la viabilité du package d’itération, avant la démonstration et/ou la livraison.

Conclusion après 5 mois supplémentaires :

Cette refonte fut une réussite, améliorant la productivité et remotivant l’équipe sur l’outil.

L’utilisation des tests Selenium au format HTML est une solution très simple à mettre en oeuvre. Elle impose cependant plus de configuration pour chacun des environnements sur lesquels ils doivent s’exécuter.

Il est bénéfique d’assurer un complément IHM aux tests fonctionnels.

[new_royalslider id=”8″]