Un Electron Libre...

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 27 août 2008

Intégration : Recette interne

La recette arrivant en bout de course d'un projet, elle est souvent sacrifiée pour compenser les retards de développements pour des bonnes et/ou mauvaises raisons. Il arrive donc souvent que la version livrée en recette a peu été testée (voir pas du tout ou pas de façon suffisamment significative).

Cela conduit à différentes choses :

  • Les jours payés par le client ne sont pas utilisés à cet effet,
  • L'effort de recette coté client explose puisqu'il doit assurer la recette en lieu et place du prestataire
  • L'effort de recette coté presta va également exploser coté prestataire et non être réduit comme escompté car il aura (souvent) tendance à :
    • multiplier les livraisons correctives partielles
    • générer de nombreux aller/retour pour cause de non-correction voir régression
    • exploser le cout de livraison (packaging, documentation, etc)
  • Désorganise tant le prestataire que le client du fait de cette charge à absorber dans des plannings qui ne le permettent pas forcément
  • Au final, une tension croissante va pourrir les relations entre le client et le prestataire, sans compter la démotivation croissante de part et d'autres pour faire avancer le projet. Sans compter que cela ternit l'image de marque du prestataire et peut mettre fin à tout travail potentiel entre le prestataire et le client.

Au final, tout le monde est clairement perdant.

Quelques pistes d'amélioration :

  • Mieux estimer les périodes de recette (structurellement sous estimée) et qu'elle fasse partie du budget du projet. A croire qu'annoncer une période de recette est une honte en matière de programmation... Attention, il faut quand même que cette durée reste cohérente avec la taille/complexité de l'application.
  • Etre transparent/honnête avec son client en disant qu'il y aura un retard de livraison le temps de faire la recette. Après tout, c'est logique, le temps perdu au niveau du développement ne se rattrappe jamais par magie...
  • Mieux résister à la pression interne de livrer "à tout prix et/ou au plus vite" au client
  • Prendre le temps de faire cette recette
  • Coté presta, prévoir des zones tampons si des projets doivent se succéder afin qu'un retard sur un projet n'en condamne pas un autre. Cela suppose aussi que le chef de projet remonte les infos à temps à sa hiérarchie.
  • Dans le cas de plusieurs itérations, faire en sorte d'en avoir le moins possible pour ne pas se démotiver dans les phases de recette,
  • S'il y a des applications auxquelles se connecte le projet, soit vous êtes en mesure de mettre en place réellement cette plateforme chez le prestataire, soit il faut venir faire des tests d'intégration chez le client
  • Faire venir le prestataire sur site pour pouvoir travailler de concert et éviter les parties de ping-pong par mail ou téléphone,
  • Se dire que ce retard sera compensé par le fait que tout ce qui a été dit dans le paragraphe précédent ne se produira pas... ou dans une moindre mesure

Enfin, si le jour de la livraison il y a un retard de dernière minute ou une opération plus longue que prévue, prévenir le plus tôt possible le client et le tenir informé des éventuels reports de livraison. Ou alors se donner une vraie marge pour tenir les horaires. Cela évite en outre que le client excédé vous appelle pour savoir où vous en êtes et à quelle heure vous allez livrer.

Tout cela suppose également que le chef de projet ait une visibilité suffisamment bonne sur le travail de ces développeurs et qu'il connaisse suffisamment bien le produit sur lequel il travaille pour que ces estimations soient les plus justes possibles. Faute de quoi, il risque de se trouver dans une fort mauvaise posture (vécu inside).

A ce jour, une telle méthode m'aurait épargné un gros nombre des 100 bugs trouvés juste en cliquant à droite et à gauche (sans prendre en compte les specs fonctionnelles d'un projet) et les 5 livraisons que j'ai réduit à 3 intégrations. Je tairais le nom de la SSII, vu que ce n'est pas propre à cette SSII et que j'espère que d'autres équipes projets de cette SSII travaillent de façon plus satisfaisante. Pour avoir de l'autre coté, j'en garde également des mauvais souvenirs et des conditions de travail déplorables, se retrouvant entre le marteau (le client) et l'enclume (sa hierarchie).

jeudi 21 août 2008

Intégration : Cahier de recette (cet ami qui vous veut du bien)

Je vais lancer une série "Intégration" dans laquelle je vais parler de points vue dans mon quotidien ou dans mon passé en SSII.

Cela faisait un moment que je voulais écrire ce billet, convaincu de plus en plus que le cahier de recette devient un élément de plus en plus crucial dans un projet informatique.

Idéalement, je vois une première version réalisée à l'issue de la phase des spécifications. Sans aller parler de "Test Driven Development" (Développement piloté par les tests, qui l'on peut résumer synthétiquement par le fait d'écrire les tests avant de coder quoi que ce soit), l'idée de rédiger le cahier de tests à l'issue de la phase de spécifications a tout son sens selon moi. Rédiger le cahier de recette (technique et/ou fonctionnel) à cette étape apporte les avantages suivants :

  • Cela permet de consigner par écrit ce qui semble parfois "tellement évident" à certains membres du projet et qui peut ne pas l'être pour d'autres ou bien pas si évident que cela (périmètre de tests, éléments à tester, conditions de tests, etc).
  • On peut s'apercevoir qu'il y a des manques dans les spécifications que l'on peut alors enrichir (règles de gestion, cas non imaginés de premier abord, etc) : imaginons par ex un intranet groupe avec une authentification intégrée, par défaut, on imagine très bien le cas du français se connectant sur l'application depuis son poste france, mais que se passe-t-il s'il se déplace dans une filliale pour laquelle l'authentification intégrée n'est pas en place ? L'utilisateur pourra-t-il se connecter malgré tout à l'application ?).
  • Dans le cas d'une relation avec un prestataire, cela évite les mauvaises surprises en phase de recette (le cas de recette 12, pourtant tellement évident coté client et absolument pas (pré)vu par le prestataire)
  • A l'issue de la phase de développement, vous pouvez demander au prestataire de vous indiquer le résultat de sa recette vis à vis de ce cahier de recette (qui aura pu être complété/détaillé entre temps).
  • Lors de la phase de recette, vous avez un référentiel sur lequel peut s'appuyer votre démarche de recette.

En tout état de cause, il est important de faire vivre votre cahier de recette : de test très macro (état initial > étapes > résultat) réalisés dans un premier temps, vous pourrez le compléter (nouveaux cas) ou bien le détailler/préciser ou encore définir des "sous-cas" de tests.

Il est également important de communiquer ce cahier de recette aux parties impliquées pour avoir leur réaction et échanger. Cela peut le cas échéant donner lieu à des avenants/aménagements des phases de développement (cas d'évolution). Le fait que ce soit dans votre cahier de recette ne veut pas forcément dire qu'il doit être accepté systématiquement par votre équipe de développement / prestataire ; en effet, si cela n'est pas dans le périmètre de départ ou a un impact trop significatif sur les développements, il vous faudra en discuter (c'est sur qu'en cas d'engagement au forfait...)

Pour être honnête, moi même en SSII, j'ai très peu appliqué cette méthode - seulement lors de mes dernières missions en AMOA lorsque j'étais en SSII ou pour un projet interne actuel chez mon actuel employeur. Dernièrement, lors d'un POC (Proof Of Concept / Prototype), j'avoue avoir été étonné que personne ne s'en est pré-occupé avant que j'en fournisse un - permettant d'ailleurs de découvrir le cas du français en déplacement dans une autre filliale par ex. Tout le monde savait qu'il fallait tester deux fonctions "authentification" et "indexation" et il a bien été démontré que cette soit-disant évidence des tests n'allait pas de soit sur de nombreux sujets ou tout bonnement sur le périmètre même du POC.

La seule explication au fait que cela ne soit pas plus utilisé à présent dans les méthodes de développement est un temps de spécification mal estimé conduisant à ce qu'il soit négligé / repoussé à la phase de tests. Vous en voyez d'autres (bonnes|mauvaises) raisons ?

lundi 23 juin 2008

Futilité de passage...

  • Le Chaudron, à défaut d'être complet est à jour coté Redmine - cf Annonce de Redmine 0.7.2
  • Ce blog, ainsi que celui de mon fils continuent de suivre le SVN de dotclear et sont donc sous Dotclear 2.0 RC2
  • Jungle Disk 2.0 est sorti
  • Le paramétrage du serveur est quasi fini, faut que j'injecte d'une facon ou d'une autre le backup des bases postgresql dans backup-manager
  • Mon nombre de flux RSS suivis est passé de 100+ à une 30aine (et ça pourrait encore diminuer) - que de bruit en moins et de temps de gagné. Déjà que j'arrive pas à faire le quart de la moitié de ce que je voudrais faire... et ça m'inspire aussi que la veille / course au hype en SSII consomme un temps monstrueux pour un intérêt qui me parait aujourd'hui bien relatif...
  • Intéressant de voir les projets depuis un client final. C'est là où on voit que les phases d'intégration, tests et documentation sont raremement à jamais appliquées en SSII, voir pas intégrées dans le process de développement pour des bonnes et mauvaises raisons - j'y reviendrais plus tard, ainsi que sur ce document qu'est le "cahier de tests". Pour éviter toute mauvaise interprétation : moi aussi jusqu'à peu encore, j'ai aussi mal fait quand j'étais en SSII... c'est d'ailleurs assez rigolo de prédire quasiment à coup sur ce qui a été fait/pas fait par une SSII et trouver à coup quasi certains les points de manque sur une livraison...
  • Diigo, c'est bientot fini car je trouve leur barre insupportable, la suggestion des tags est à chier et l'intrusion dans le menu en click droit est abusive. Pire que tout dans ce fameux menu, on ne peut pas faire juste "Bookmark" mais forcément "Bookmark & higlight", chose pour lequel je n'ai trouvé aucun intérêt pour le moment. Retour sur del.icio.us sous peu... (juste après la publication de ce billet en fait...)
  • Il a été vu ceci sur mon PC - il parait que je me serais remis à faire du code (à défaut de trouver un éditeur qui me convienne)
django-admin.py startproject atome
django-admin.py startapp journal
django-admin.py startapp links

mais un bug lié à la version SVN de Django et de django-tagging (dont j'ai trouvé la doc un peu limité sur l'intégration dans les modèles) m'a vite bloqué :-( -

Suite au prochain épisode...

Edit 1 : Pour django-tagging, faudrait lire la doc qui va bien aussi...

Edit 2 : Ajout de la sortie de Jungle Disk 2.0

samedi 26 janvier 2008

Selenium, testez fonctionnellement vos applications web (partie 2/2)

Billet publié initialement sur le blog de Clever Age

Suite de notre épopée sur Selenium, l’outil de test fonctionnel pour des applications web. Pour ceux qui auraient raté l’épisode 1 : Selenium, testez fonctionnellement vos applications web (partie 1/2)

Ce second volet suppose que vous avez lu l’épisode 1 et sera davantage axé sur l’implémentation de Selenium et Selenium RC.

Pré-requis

Pour Selenium IDE :

Pour Selenium RC :

  • Java Runtime Environment (JRE) >= 1.5.0 – Téléchargement
  • Selenium RC >= 0.9.2 - Téléchargement
  • Si vous comptez utiliser des scripts en Python, Ruby, Java, PHP, .Net ou Perl, il faut que le langage désiré soit installé sur votre ordinateur afin que les tests puissent être exécutés.

Enregistrer un test

Il suffit de procéder de la façon suivante :

  • Lancer Firefox
  • Menu Outils > Selenium IDE
  • Vérifier que le bouton d’enregistrement (bouton rond rouge) est bien pressé
  • Dans votre fenêtre Firefox, rendez-vous sur la page à tester
  • Exécuter les différentes étapes de votre scénario
  • Une fois votre scénario fini, stopper l’enregistrement en cliquant sur le bouton rond rouge)
  • Sauvegarder votre test (au format HTML)
  • Lancer le pour valider son bon fonctionnement (en cliquant sur la flêche verte)

Si besoin, fignoler votre test :

  • Ajouter des commandes "pause” si Selenium va plus vite que votre application ou détecte mal la fin de chargement de la page
  • Ajouter les commandes Selenium nécessaires si certaines parties de votre test n’ont pas pu être enregistrées par Selenium IDE (cas de certains menus/formulaire avec du javascript)
  • ...

Utiliser des valeurs dynamiques

Le besoin d’avoir des valeurs dynamiques se fait rapidement sentir dès lors que :

  • l’unicité d’une information est mise en place : une fois le test joué, on ne peut plus le rejouer sous peine de lever une erreur. Dans ce cas, le besoin peut être par exemple de pouvoir générer des listes de noms, prénoms et adresses email.
  • des mécanismes de cache sont en place : une fois le test joué, l’application a stocké les données demandées dans son cache. Rejouer le test est possible mais ce mécanisme de cache peut influer sur les résultats. Dans ce cas, le besoin peut être par exemple de pouvoir générer des dates aléatoires
  • des mécanismes temporels sont en place : si je teste une application de réservation de place de concerts avec pour date le 13 juin 2007, alors le test ne sera plus valide dès le 14 juin, puisque la date de l’événement sera passée.
  • ...

Selenium nous permet de définir des valeurs dynamiques, utilisables dans nos cas de test en créant des fonctions JavaScript.

Pour ce faire, il faut créer un fichier ’user-extensions.js’ qui contiendra par exemple pour la définition d’un jour et d’un mois compris entre aujourd’hui et la fin de l’année (les fonctions peuvent être améliorées, nous ne sommes pas à l’abri d’un 31 novembre par ex) :

function RandomNumber(value)
        {
        return Math.floor(Math.random()*value);  
        }
 
function RandomDay()
        {
        date = new Date();
        day = date.getDate();      
        return RandomNumber(31-day)+day;
        }
 
function RandomMonth()
        {
        date = new Date();
        month = date.getMonth(); //janvier = 0 -> décembre = 11
        return RandomNumber(11-month)+month;
        }

Il faut ensuite déclarer ce fichier dans Selenium IDE : Menu Option > Options... > Extensions de Selenium Core (user-extensions.js). Une fois votre fichier sélectionné, il vous faudra relancer votre instance de Selenium IDE pour qu’il soit pris en compte. Si votre fichier contient une erreur de syntaxe, Selenium IDE vous le dira.

Dans votre test Selenium, remplacez alors la valeur fixe par l’appel à la fonction javascript :

Ce que vous aviez initialement :

Commande Cible Valeur
type jour_arrivee 22
type mois_arrivee 12

Ce que vous obtenez au final :

Commande Cible Valeur
type jour_arrivee javascript{RandomDay()}
type mois_arrivee javascript{RandomMonth()}

Dans le cas d’une liste déroulante, il faudra procéder en deux étapes :

  • Génération de la valeur,
  • Selection de la valeur obtenue dans la liste.
Commande Cible Valeur
store mon_jour_arrivee javascript{RandomDay()}
select jour_arrivee label=${mon_jour_arrivee}

Conseils :

  • Créer une bibliothèque commune de fonctions JavaScript que chaque testeur/développeur viendra enrichir
  • Décomposer au maximum vos fonctions afin de pouvoir réutiliser rapidement certains morceaux pour construire d’autres fonctions.

Construire une Test Suite

Une Test Suite est un fichier HTML dans lequel chaque test est référencé dans une ligne du tableau, comme vous pouvez le constater dans l’exemple suivant :

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Selenium : CA Technical Meeting</title>
<script language="JavaScript" type="text/javascript">
   var DISABLED = true; // used to flag failing tests
   function filterTestsForBrowser() {
       var suiteTable = document.getElementById("suiteTable");
       var skippedTests = document.getElementById("skippedTests");
       for(rowNum = suiteTable.rows.length - 1; rowNum >= 0; rowNum--)
       {
           var row = suiteTable.rows[rowNum];
           var filterString = row.getAttribute("unless");
           if (filterString && eval(filterString))
           {
             var cellHTML = row.cells[0].innerHTML;
             suiteTable.deleteRow(rowNum);
             var newRow = skippedTests.insertRow(1);
             var newCell = newRow.insertCell(0)
             newCell.innerHTML = cellHTML;
           }
       }
   }
   function isFileURL() {
       var p = window.location.protocol;
       var result = ("file:" == p);
       return result;
   }
</script>
</head>
<body onload="filterTestsForBrowser()">
<table id="suiteTable" cellpadding="1" cellspacing="1" border="1" class="selenium">
        <tbody>
                <tr>
                        <td><b>Selenium : Test Suite</b></td>
                </tr>
                <tr>
                        <td><a target="testFrame" href="file:///chemin/des/tests/test1.html">Test 1</a></td>
                </tr>
                <tr>
                        <td><a target="testFrame" href="file:///chemin/des/tests/test2.html">Test 2</a></td>
                </tr>
        </tbody>
</table>
<br />
<em>Not supported in this suite</em>
<table id="skippedTests" cellpadding="1" cellspacing="1" border="1" class="selenium">
        <tbody>
                <tr>
                        <td><b>Skipped Tests</b></td>
                </tr>
        </tbody>
</table>
</body>
</html>

Le bloc qui nous intéresse particulièrement est :

                <tr>
                        <td><a target="testFrame" href="file:///chemin/des/tests/test1.html">Test 1</a></td>
                </tr>

A noter :

  • La référence au test se fait sous la forme d’un lien.
  • Le test doit avoir la référence target="TestFrame" pour qu’il puisse être lancé.
  • Il vous suffit d’ajouter autant de ligne dans votre tableau que vous avez de tests à intégrer dans votre Test Suite.

Executer une Test Suite depuis Selenium IDE

Vous pouvez lancer une Test Suite depuis Selenium IDE en utilisant Test Runner. Pour cela il vous suffit de cliquer sur l’icône suivante :

Selenium - TestRunner

Dans votre navigateur, une fenêtre s’est alors ouverte et elle est composée de 4 parties :

  • En haut à gauche, la zone contenant le détail de votre Test Suite
  • En haut au milieu : le contenu de votre cas de test
  • En haut à droite : le panneau de contrôle de Test Runner
  • En bas : un aperçu du site dans lequel est exécuté votre test.

Selenium - TestRunner 2

Pour que TestRunner prenne votre Test Suite en considération, il vous suffit de changer le contenu de la variable "test" dans l’url appelée. Une fois votre Test Suite chargée, il vous suffit de l’exécuter.

Exporter un test vers Selenium RC

Comme dit dans le précédent billet, un des intérêts de Selenium RC est de pouvoir exécuter des tests dans un langage de script. Ce langage permettant de réaliser des actions supplémentaires, impossibles à réaliser depuis Selenium IDE.

L’export se fait très simplement :

  • Fichier > Exporter le Test sous > Choisissez le format qui vous intéresse.
  • Sauver le fichier avec l’extension appropriée.

Optionel : vous aurez peut être besoin de modifier la valeur de la "base url" dans votre test. Par défaut, Selenium IDE considère que cela est "localhost", ce qui peut ne pas correspondre à votre environnement.

Ex pour un test exporté en python :

Avant :

self.selenium = selenium("localhost", 4444, "*iexplore", "http://localhost:4444")

Après :

self.selenium = selenium("localhost", 4444, "*iexplore", "http://test.server.tld")

Exécuter un test avec Selenium RC

Il vous faut d’un côté lancer le serveur Selenium RC :

java –jar c:\path\to\selenium-rc\selenium-server.jar

et de l’autre lancer votre fichier de test dans votre langage de script (ou de double-cliquer sur le fichier si votre système d’exploitation vous le permet) :

C:\path\to\your\language\language.exe c:\path\to\test\test_case.ext

Note : si votre test utilise les fonctions javascript définies dans user-extensions.js, il vous suffit d’ajouter le paramètre "–userExtensions c :\path\to\user-extensions.js" lors du lancement du serveur :

java –jar c:\path\to\selenium-rc\selenium-server.jar -userExtensions c:\path\to\user-extensions.js

Exécuter une Test Suite avec Selenium RC

Pour se faire, il vous suffit le serveur en utilisant le paramètre htmlSuite et de préciser :

  • le navigateur à utiliser parmi *chrome (firefox) et *iehta (Internet Explorer)
  • l’url à tester,
  • le chemin de votre Test Suite
  • le chemin où stocker les résultats de la Test Suite :
java –jar c:\path\to\selenium-rc\selenium-server.jar –htmlSuite *iehta http://your.server.tld c:\path\to\test\suite\YourTestSuite.html c:\path\to
esults.html

De la même façon que précédemment, si vous devez utilser vos fonctions javascript, il faut ajouter le paramètre userExtensions :

java –jar c:\path\to\selenium-rc\selenium-server.jar –htmlSuite *iehta http://your.server.tld c:\path\to\test\suite\YourTestSuite.html c:\path\to
esults.html -userExtensions c:\path\to\user-extensions.js

Exécuter des tests en parallèle avec Selenium RC

Il suffit de :

  • lancer autant d’instances de Selenium RC que nécessaire sur différents ports (en utilisant le paramètre "–port"
  • Adapter vos scripts pour qu’ils utilisent le port en question au lieu du port par défaut (4444)‏
  • Exécuter les scripts.

selectAndWait vs select

Dans le cas de formulaire avec des listes déroulantes conditionnelles, il se peut que votre test échoue si vous cherchez à selectionner la valeur par défaut d’une liste rafraichie par la liste précédente.

Cela s’explique par le fait que Selenium enregistre votre selection via la commande "SelectAndWait". Comme vous sélectionnez la valeur par défaut d’une liste, Selenium ne voit pas cet événement et attend en vain.

L’astuce consiste alors à remplacer "selectAndWait" par "select".

Ressources

Selenium IDE

Selenium RC

Nous arrivons au terme de ce second épisode sur Selenium. Le but était d’illustrer son fonctionnement au travers de différents exemples. Toutes les fonctionnalités de l’outil n’ont pas été présentées ici (exécution d’un test pas à pas, définition de nouveaux point de démarrage d’un test, etc), l’idée étant de faire avant tout une présentation rapide de l’outil. Il ne vous reste plus qu’à jouer avec pour mieux l’appréhender.

mardi 27 novembre 2007

Selenium : testez fonctionnellement vos applications web (partie 1/2)

Billet publié originellement sur le blog de Clever Age : selenium, testez fonctionnellement vos applications web (partie 1/2)

Ce premier billet a pour objectif de présenter Selenium et ses fonctionnalités. Le second sera d’avantage axé sur son implémentation et utilisation.

Vous avez dit Selenium ?

Selenium est une suite d’outils permettant de faire des tests fonctionnels d’une application web (et uniquement web). Ces outils sont distribués par OpenQA, sous la licence libre Apache 2.0.

Par outil de test fonctionnel d’une application web, j’entends :

  • La capacité à simuler l’action d’un internaute avec prise en charge des actions réalisées avec le clavier et la souris (click, saisie d’un champ, sélection dans une liste déroulante, etc),
  • Les simulations sont bien sûr basées sur des cas de tests, basés eux-mêmes sur des cas d’utilisation,
  • La capacité à enregistrer ces simulations,
  • La capacité à exécuter ces simulations de façon automatisée de manière individuelle ou collective (on parlera alors de Test Suite).

Selenium est composé de 3 éléments :

  • Selenium Core : coeur de Selenium. Le core doit être installé sur le serveur sur lequel tourne votre application pour pouvoir les tester,
  • Selenium IDE : extension Firefox capable d’enregistrer et d’exécuter des tests et des Test Suites (via TestRunner, composant de l’IDE capable de jouer des Test Suite),
  • Selenium Remote Control :
    • Serveur qui permet d’exécuter des tests sur différents navigateurs (firefox, internet explorer, opera, etc) et différents systèmes d’exploitation (MS Windows, GNU/Linux, Mac OS)
    • Serveur qui permet d’exécuter des Test Suites sur ces différents navigateurs,
    • Serveur qui permet d’exécuter des tests écrit dans des languages de script comme Ruby, Python, Java, .Net et Perl.

Contrairement à Selenium Core, Selenium RC et Selenium IDE s’installent sur le poste du développeur. Selenium RC peut aussi s’installer sur un serveur dédié à l’exécution des tests si l’on souhaite les exécuter de façon automatisée.

Petit aperçu d’un test enregistré dans Selenium IDE :

selenium.png

Le test consiste à :

  • Ouvrir la page Google.fr,
  • Taper le mot clé "clever age"
  • Cliquer sur "Rechercher’
  • Cliquer sur le lien "Clever Age, conseil en architecture technique"
  • Sur le site de Clever Age, vérifier la présence du texte "systèmes informatiques flexibles").

Avant d’aller plus loin, Selenium n’est pas fait pour :

  • Tester des applications non-web : client lourd, service web, etc.
  • Faire des tests de performance.

Et pour être totalement honnête, Selenium :

  • A quelques soucis avec les sites en Ajax ou avec beaucoup de JavaScript.
    • Il convient alors de vérifier la qualité du code javascript développé.
    • et si cela ne suffit pas et pour que le test se déroule correctement, il arrive de devoir entrer des commandes équivalentes à ce qui aurait du être fait en javascript (ouverture d’une page, saisie d’une valeur, etc)
  • Ne sait pas gérer plusieurs fenêtres d’un navigateur :
    • Selenium sait ouvrir une pop-up,
    • Selenium ne peut piloter deux fenêtres lancées indépendemment l’une de l’autre,
    • En travaillant un peu le contenu du test enregistré et si la seconde fenêtre est ouverte depuis la première (cas d’une pop-up par exemple), alors il est possible de les contrôler simultanément.

Dois-je utiliser Selenium ?

Les utilisateurs de Selenium ont le profil suivant (liste non exhaustive) :

  • Analyste programmeur : pour vérifier que les développements sont conformes aux besoins exprimés
  • Développeur et équipe d’assurance qualité : pour valider le bon fonctionnement de l’application (non-regression, etc) et le passage en production.

Comment intégrer Selenium dans votre campagne de test ?

Sauf à vouloir perdre du temps, il convient de procéder de la façon suivante :

  1. Lecture des besoins & spécifications,
  2. Définition du périmètre de test,
  3. Rédaction des cas de tests,
  4. Enregistrement des tests dans Selenium,
  5. Exécution des tests.

Ce test doit-il être un test Selenium ?

La réponse est oui, si :

  • le test doit être joué plus d’une fois,
  • le test peut être automatisé de bout en bout.

A quoi sert une Test Suite ?

Nous pouvons voir les Test Suites de deux façons :

  • Un ensemble de tests individuels que nous voulons jouer à chaque nouvelle version d’un projet. Chaque test correspond à un cas d’utilisation et permet de valider le bon fonctionnement de l’application dans son ensemble.
  • Un ensemble de composants qui seront utilisés pour construire un test.. Ces composants pourront être mutualisés entre les différents tests. Prenons un exemple : le test d’une application est souvent composé de trois étapes : connection à l’application, action à mener puis déconnexion de l’application. Je vais donc créer trois tests :
    • Un test "connexion" : sa portée se limite à aller sur l’écran d’authentification de l’application, saisir les identifiants et se connecter.
    • Un test "action" : le coeur du test, il contient la fonctionnalité à tester dans notre scénario
    • Un test "déconnexion", consiste à cliquer sur le lien "Déconnexion" et vérifier que cela est bien le cas.

Petite illustration : imaginons que notre application porte sur la gestion des congés.

selenium2.png

Dans le premier cas, ma Test Suite est composée de trois cas de test. Chaque test couvre l’ensemble du processus à tester.

Dans le second cas, chaque composant est une portion du process complet. Le "Test 1" pourrait tout à fait être représenté par ce second cas.

Comment s’intègre Selenium dans un processus d’intégration continue ?

Il "suffit" de s’appuyer sur la capacité de Selenium à exporter les tests enregistrés dans Selenium IDE dans un des formats supportés par Selenium RC et adapté à votre outil d’intégration continue.

Une fois exporté et intégré à votre outil, lors d’un commit, une tâche est lancée qui consiste à :

  • Lancer une instance du serveur Selenium RC
  • Lancer votre test qui se connectera à l’instance du Selenium RC et jouera le test.
  • Récupérer le fichier de log produit par Selenium RC
  • Traiter le fichier de log.

Vous pourriez objecter qu’il est possible de lancer Selenium RC avec un test au format HTML. Certes mais dans la mesure où vous allez vouloir probablement réinitialiser votre application suite à votre test, vous serez contraint de passer par un langage de script.

Nous arrivons au terme de ce premier billet qui avait pour objectif de planter le décor sur Selenium, ses capacités et son fonctionnement. Le prochain billet consistera à rentrer dans le vif du sujet et montrer comment Selenium IDE et Selenium RC peuvent être utilisés.