Cela fait maintenant plusieurs mois que je voulais faire cet article sur la rédaction des tests selenium (et en plus, c’était plutôt bien noté dans mon backlog :p). J’espère que les commentaires seront nombreux !
Voici un exemple de scénario que l’on peut facilement générer avec Sélénium et son IDE. C’est déjà chouette ! On a largement de quoi repenser notre manière d’organiser les projets ; comme mettre en place du Développement Piloté par le Comportement (BDD).
Après quelques projets, quelques points négatifs demeurent :
1 – Peut-on dire que la lisibilité est suffisante ? Peut-on échanger avec un P.O ou des fonctionnels sur la pertinence de tel ou tel scénario ?
2 – Lorsque l’application évolue, il faut reprendre beaucoup de tests : il n’y a aucune factorisation du « code » des tests.
Je vous propose donc un exemple d’organisation des tests Selenium. Pour cela, je vous propose de « tester » la vente en ligne du site fnac.com (J’ai choisi ce site pour sa célébrité et sa « complexité » ergonomique) (suite…)
Comme on me l’a fait remarqué dans un précédent article, l’entretien d’un jeu de test est une problématique à part entière.
Je n’ai pas la prétention d’avoir trouvé « LA » solution miracle, mais disons que nous avons trouvé une organisation qui nous simplifie grandement l’entretien de nos cas de test : « nous n’en avons pas » ! (suite…)
La mise en place « des tests » au sein de l’équipe est un vrai challenge : nous partons de 0. Les réactions ont rarement été positives : « Ca sert à rien », « De tout façon, je ne fais pas de Bug », « Le projet existe depuis 5 ans sans tests, donc soit on fait tout, soit on fait rien … Et comme on n’a pas le temps de faire des tests sur tout l’existant, ca sert en rien d’en faire » et le dernier « De toute façon, tout ne peut tester : on n’est pas dans la tête des utilisateurs ».
Bon, une fois qu’on a dit ca, qu’est-ce que l’on fait ? Et bien pour ma part, je prend mon bâton de pèlerin et on essaye d’expliquer :
Bref, on est parti pour faire œuvre de pédagogie avec l’équipe (Est-ce le rôle du ScrumMaster ?). (suite…)
Ahhhh, les outils ! Voilà LE sujet qui fait le plus souvent discuter ! Entre les « geek », prêts à tester tous les derniers outils en version béta et les frileux — on peut aussi dire « puriste » :) — ; on est sur d’avoir des discutions animées dans l’équipe !
Nous développons des applications web, avec une technologie J2EE.
Mais quels sont les outils qui nous aident à être agile ?
Pour ce qui est de la partie « Suivi de projet » (backlog, burndownchart et autres indicateurs) nous utilisons pour le moment un joli fichier Excel : simple, efficace.
Pour ce qui est de la partie intégration continue (et déploiement automatisé en recette et production), nous utilisons Hudson et des scripts Ant. Dans un prochain article, je détaillerai notre organisation, les difficultés et les solutions que nous avons trouvés ! (Nous avons réduit de 90 % le temps passé à la construction et l’installation des applications et sensiblement amélioré notre qualité de livraison).
Enfin, ce qui est une nouveauté dans nos équipes, nous faisons des tests automatisés ! Pour cela, nous utilisons JUnit et Selenium pour la gestion des tests automatisés. Là aussi, différents articles sont prévus. Il existe de nombreux très bons tuto pour « installer » Sélenium and co. En revanche, peu de retour d’expérience sur la rédaction (et le lien avec les User Stories), la maintenance et l’organisation des tests ! Je vais modestement essayer d’apporter ma contribution :)
Loading ...
