Accueil > Outillage > Comment j’ai fiabilisé mon projet avec Selenium IDE (1/2) !

Comment j’ai fiabilisé mon projet avec Selenium IDE (1/2) !

Logo Selenium IDEQuel chef de projet n’a pas rêvé de pouvoir faire une mise en production en toute sérénité ? Oui, mais pour ça, il faut tester et les tests, ça coûte cher si ça n’est pas automatisé. Vrai. C’est pour ça qu’on fouette les développeurs pour qu’ils mettent en place un maximum de tests unitaires, automatisés comme il se doit. Mais ce qui apparait clairement, c’est que les tests unitaires, ça ne suffit pas. Pour bien faire, il faut, de  même, mettre en place des tests automatisés à un niveau plus applicatif. C’est dans cette optique que j’ai utilisé Selenium IDE (et ça a changé ma vie !).

LE CONTEXTE

Au début était une appli Web, à peine éclose, un joli moteur de recherche inspirationnel touristique, dont le but était de répondre à des recherches du type : « week-end à Paris », « marchés de noël », « route des vins en Alsace », etc.

En fonction de ces recherches, il s’agissait de :

  • proposer des produits pertinents (hébergements, transports, activités, articles)
  • rediriger l’utilisateur vers le type de page le plus pertinent (une dizaine de templates de pages différents)

Je suis arrivée sur le projet alors que l’appli sortait de sa version bêta (à peine éclose, je vous dis), avec une double casquette d’AMOA et de Chef de Projet.

L’ENNEMI, C’EST LA REGRESSION !

Roulez, jeunesse, nous voilà partis pour une première version (le rythme était alors d’une tous les trois mois) : je travaille avec le métier, qui non seulement demande des évolutions nécessitant des développements (dingue !), mais a également la main sur tout un tas de référentiels  (appelés ontologies).

Je spécifie (light), les développeurs développent et le métier modifie les ontologies à tour de bras. Les développeurs testent de manière unitaire (c’est en tout cas ce qu’ils disent), le métier teste (concentré sur ses évolutions), et moi je veille à ce qu’on tienne les délais.

Quand le métier donne son GO, on package, on livre, on déploie, les tests de charge passent (alleluia !), on met en prod.

A peu près deux heures plus tard, le métier constate ses premières régressions !!!!!

Stress, stress, stress… identifier au plus vite la source de l’ano, la corriger, repackager, redéployer… ouf, la prod est réparée… argh une autre régression est repérée, induite par la correction qu’on vient juste de mettre en prod (parce que le métier a profité du patch pour corriger des ontologies)… stress, stress, stress… corriger, repackager, redéployer… ouf, la prod est réparée ? Peut-être… en fait, on n’est sûr de rien, on va dire que tant qu’on n’a pas vu d’ano, on peut considérer qu’il n’y en a pas.

LES TESTS AUTOMATISES SONT TES AMIS !

Quand tout se reproduit à l’identique à la version suivante, je décide qu’il est temps de faire quelque chose ! Moi, AMOA et Chef de Projet, je veux pouvoir garantir le niveau de qualité de la version livrée.

Et pour ça, je décide de mettre en place des tests automatisés, de niveau applicatif, avec Selenium IDE, un plugin Firefox qui enregistre et reproduit les interactions de l’utilisateur avec le navigateur.

Pourquoi Selenium IDE ?

  • parce que c’est l’outil utilisé chez mon client (j’avoue ne pas connaitre les produits concurrents et ne peux dire si Selenium est LE meilleur outil. En tout cas, il a répondu à mon besoin)
  • parce que c’est facile à utiliser pour des gens comme moi (comprendre : qui ne sont pas champions du code)

Ces tests auront une double utilité : tester la non régression (tests écrits lors des versions précédentes) et compléter les spécifications (tests écrits pour la version en cours).

COMMENT DÉMARRER AVEC SELENIUM IDE ?

Pour installer le plugin, aller sous : http://docs.seleniumhq.org/download/, télécharger et installer.

A la suite de quoi, sous Firefox, je peux lancer Selenium IDE à partir du menu Outils de FireFox :

Pour enregistrer un test, rien de plus facile (pour les premiers pas, en tout cas) :

  • quand le bouton rouge (en haut, à droite) est enclenché : toutes les actions exécutées dans le navigateur sont enregistrées (ouverture de page, saisie de champ, clic sur des boutons, …)
  • pour ajouter des contrôles (vérifier que telle chaine de caractères est dans la page, que l’URL courante est telle URL, etc.) : en faisant un clic droit dans le navigateur, un nouvel item « Afficher toutes les commandes disponibles » apparait dans le menu contextuel (ainsi que les contrôles les plus souvent utilisés). A noter que la liste des contrôles proposés n’est en fait pas exhaustive.

  • quand j’ai terminé, je stoppe l’enregistrement (bouton rouge). Mon scenario est enregistré. Je peux le sauvegarder (« Sauver le test » dans le menu Fichier), je peux le rejouer (flèche verte).

Voilà pour les premiers pas. Dans le prochain article, j’aborderai les points suivants :

  • commandes les plus utiles (d’après mon expérience)
  • organisation des tests
  • gestion du multi-plateformes (pouvoir lancer les tests en dév, recette, etc.)
  • outillage du lancement des tests
  • maintenance des tests


sept + 3 =