Selenium 2 et son écosystème

Pour ce retour d’expérience, je vous propose une forme d’article assez différente de ce que je propose habituellement. Certains trouve cette approche agréable, les codeurs sont tristes de ne pouvoir copier/coller…
Dans tous les cas, j’attends vos commentaires avec une réelle impatience.

14 Réponses à “Selenium 2 et son écosystème”

  1. Thomas :

    Bonjour,
    Super article, j’utilise Selenium 2 pour mes tests. Je vais bientôt configurer tout ça avec grid2.
    Mais ce que j’aimerai savoir c’est la fréquence de lancement des tests lorsque l’on est en méthode agile ( SCRUM ou autre ). Devons-nous lancer les tests toutes les nuits, afin de vérifier qu’aucun développement lors de la journée ai provoqué de régression? Ou devons-nous les lancer à chaque fin d’itération?
    Merci

  2. Thierry Vallée :

    Séparer le jeu de test du test… Mais c’est évident ! Alors pourquoi je ne l’ai pas fait avant :-(

  3. Thierry Vallée :

    @Thomas : toutes les nuits c’est un minimum… Un bug identifié peu de temps après qu’il ait été écrit est vite corrigé (on se se souvient).
    Idéalement à chaque commit, mais c’est une autre histoire (cf. Continuous Delivery)

  4. dibus :

    Merci pour le retour.Thierry a tout dit. De notre côté, testng est plugged avec Hudson (Jenkins). On réalisé au moins un build par nuit… Et certains jours 4 builds dans la journée. L’approcher est toujours la meme : on avance à petit pas et on fait régulièrement des builds avec de petites evolutions, et on regarde avec les tests ce que cela donne.

  5. dibus :

    1,5 an de pratique pour en arriver à cette evidence :)

  6. @LLeseigneur :

    100% raccord avec ma présentation (bientot en ligne) & la session open space live démo sur l’échantillonnage des données de test pendant :

    https://twitter.com/#!/search?q=%23ASEGrenoble

    @Thomas : réponse Coluche la bonne taille c’est quand les pieds touchent le sol.

    mon retour c’est qu’on teste quand il y a des choses à tester.

    dans notre courbe d’apprentissage on a laissé tombé « a chaque commit  » et « chaque nuit » parce que chaque commit ne le vaut pas et nos sprint ne durent pas 1 journée.

    @thierry : on fonctionne en continous delivery mais pour comme on met pas en prod toutes les nuits…

    L.

  7. Laurent Bossavit :

    Mes 2cts sur la forme (rien de spécial à dire sur le fond): ça reste encore un peu text-heavy – sauf la petite « surprise » (OMG) qui est très bien venue :)

    Oui pour des copies d’écran pleine page de codes source, après tout c’est le sujet… Mais par contre ce qui ressort comme l’exemple à prendre pour le reste de la préz’ c’est le cadre « Performances », visuel et percutant.

  8. dibus :

    Merci Laurent pour ce retour. Je suis conscient du côté verbeux. Tes commentaires me seront utiles. Je suis ravi que le omg ai fait rire au moins une personne : tu es le premier à m’en parler :)

  9. jean pierre BONNAFOUS :

    Merci Arnaud pour cette précision autour de Selenium.
    Je me permet de relayer ton article sur notre réseau social interne pour sensibiliser les qq Agilistes qui me suivent à investiguer vers plus de test auto efficaces.
    « Il y a un univers au delà de Selenium IDE ».
    C’est vrai qu’on a vite fait d’imaginer qu’avec 2 scripts selenium dans FFX l’affaire est faire ;)

    NB : sympa & efficace ce petit PREZI

  10. Xavier NOPRE :

    Salut Arnaud,

    Excellent article, un bon complément avec ce que nous avons vu aujourd’hui, vous m’avez vraiment convaincu, mais je crois que j’avais testé Selenium trop tôt … la nouvelle version me semble beaucoup plus mature, et tes pistes de bonnes pratiques sont précieuses !

    @Thomas : toutes les nuits me semble un minimum. Comme l’a dit Thierry, plus un bug est détecté tôt, moins il y a eu de modifs (commits), plus il sera facile à trouver. Il faut pour cela que ça ne dure pas trop longtemps, au besoin se pencher sur les tests longs pour les optimiser, simplifier ou épurer. Mais la fréquence de tests fonctionnels « haut niveau » sera certes moins élevée que pour des tests unitaires pour lesquels j’ai tendance à lancer un build à chaque changement …

    Merci Arnaud (et les autres) !

    Xavier

    PS : sympa Prezi, fun, mais pas pratique pour cliquer sur les liens, sans parler de copier-coller le code ;-), à bon entendeur, pour les « bons » chasseur de liens :-D

  11. dibus :

    Merci Xavier pour ce retour,
    Je serai ravi de binomer avec toi prochainement sur selenium.

    Tu es un très bon chasseur :)

    -=dibus=-

  12. sym :

    Bonjour
    je suis debutante en programmation, ils m’ont demandé de travailler avec outil de tests fonctionnels qui doit tester le code sous plusieurs navigateurs!
    j’en ai aucune idée par où commencer? pourriez vous m’aider a demarrer??

  13. Ethan G. May :

    Ça vaut la peine de regarder en directe les textures d’Eve Otto. Vous pouvez trouver ses tableaux à la Galerie Art’et Miss jusqu’au 31 octobre.

  14. Ca Scrum ! » Blog Archive » Seleniu... :

    […] Un prezi sur Selenium, outil d'automatisation de test d'IHM.  […]

Mettre un commentaire