Archive

Articles taggués ‘Tests automatisés’

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

La semaine dernière, je vous expliquais comment j’avais été amenée à utiliser Selenium IDE, dans quel contexte, et comment faire les premiers pas (c’est ).

Rentrons maintenant dans les détails et étudions, en particulier, les sujets suivants : les commandes les plus utiles, la gestion du multi-plateformes, l’organisation des tests, le problème de leur maintenance et l’outillage à mettre en place pour pouvoir les lancer en « batch ».

Les commandes les plus utiles

Voici les commandes que j’ai le plus utilisées dans le contexte de mon projet. Comme vous pouvez le constater, il n’y en pas plus d’une dizaine… Lire la suite…

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 !).

Lire la suite…

Mix It, fin d’après-midi

Phone Gap (Pamela Fox)

Pamela Fox@pamelafox
“ I hate the Android browser. I even prefer IE6 ”

Autant enchainer les présentations en anglais. Après Petra Cross, c’était au tour de Pamela Fox, ex Googleuse et même ex Google Advocate, avec son look si… particulier (les chaussures… J’ai adoré! ), mais surtout une énergie et un enthousiasme impressionnants. Pour l’anecdote, Petra est venue à la présentation de son ex-collègue, mais moins pour la suivre que pour prendre quelques photos, une vraie passion pour elle.

Je pensais apprendre pas mal de trucs sur Phone Gap, mais sa présentation était loin d’être axée sur ce framework. Mais je n’ai cependant absolument pas été déçu : le talk était axé sur un cas concrès : quelle a été sa démarche et ses critères de choix technologiques pour développer sa propre application mobile à utiliser pendant les repas : eat different.

Pour choisir quelles technologies elle allait utiliser pour créer son application, elle s’est notamment posé les questions suivantes :
Pour l’application : quels systèmes peuvent la faire tourner? Dois-je accéder à des couches basses du système (téléphonie, photo, GPS, etc.)? Quelle niveau de performance dois-je atteindre?
Pour l’équipe (de dev) : quels languages connait-on? Quel argent peut-on dépenser? Combien de codes source?
Elle nous a ensuite présenté les différentes familles de solutions :

Les applications écrites nativement ont tous les avantages du point de vue de l’application, mais adressent naturellement un seul système cible. Si on veut couvrir toutes les plate formes, elles cumulent donc les inconvénients pour les développeurs (languages et IDE hétérogènes, nombreux codes source, donc beaucoup de temps nécessaire)

Une autre approche est d’utiliser un framework qui va servir de source unique et permettre de compiler l’application pour plusieurs plateformes natives. Les performances restent correctes, bien que l’accès aux couches basses des téléphones soient plus limitées. Selon le framework choisi, on peut ainsi atteindre les principales plate formes du marché.

Enfin, et c’est l’approche qu’elle a finalement choisie, on peut écrire une application en HTML5 et utiliser un framework qui va servir de bridge, permettant à la fois d’accéder à certaines couches basses du téléphone, mais aussi de packager l’application web dans une application native pour chaque système : c’est ce que fait PhoneGap.

Son choix étant fait, elle nous a expliqué comment elle avait essayé plusieurs solutions et fait un petit peu son marché parmi plusieurs librairies JS et CSS. Après expérimentations, son choix s’est finalement porté sur Bootstrap et Zepto JS.

Au final, de sa propre expérience et des frameworks utilisés, Pamela a notamment apprécié le fait de ne pas avoir eu à apprendre de nouvelles technologies et donc de pouvoir réutiliser du code existant et ses propres connaissances.
Elle regrette néanmoins le temps nécessaire pour résoudre des bugs, plus long sur mobile (elle déteste notamment le navigateur d’Android), et trouve tout de même difficile avec cette approche d’avoir une IHM qui ressemble réellement à celle d’une écrite nativement.

Au final excellent talk, qui donne envie de creuser un peu tout ceci. La seconde approche me paraissait également intéressante…

Automatisation des tests : le mythe du ROI

Gilles Mantel@gmantel
“ Une minute d’indisponibilité chez un voyagiste coûte en moyenne 20 000 € ”
“ Un bug en production dans une banque de finance coûte 300 000 € ”

Et en avant pour la dernière session de la journée!  Gilles a commencé par nous résumer les différents types de tests : unitaires, d’intégration, fonctionnels, de charge, de performance, d’ergonomie, etc.
Parmi tous ces types de test, il a distingué ceux qui sont forcément automatisés, ceux qui sont forcément manuels et ceux qui sont potentiellement automatisables.

Un test automatisé a plus de chances de détecter plus tôt des bugs, mais coûte au départ plus cher à mettre en place. Pour ceux-ci, la question d’un responsable de projet va donc être : au bout de combien de temps suis je gagnant en automatisant mes tests, et donc mon ROI (Return On Investment) est-il positif?

En faisant des calculs, on peut établir une courbe montrant qu’on est “gagnant” à automatiser des tests au bout de 2-3 ans : un objectif qui peut paraitre lointain et peu motivant.

Le problème de ce calcul, pour Gilles, est qu’il n’intègre pas un coût caché pourtant indiscutable : combien coûtent les bugs? Et comment réintégrer ce coût? Pour répondre à la première question, Gilles conseille à chacun de se renseigner auprès des départements concernés (marketing, vente, etc.) pour permettre d’évaluer combien coûte un bug sur le système en production. Et en fonction du nombre de bug, ceci permet d’évaluer le coût des bugs du système.

C’est là que Gilles s’inspire du modèle des options d’achat dans le monde financier. Pour lui, la question est : combien consent-on à investir (coût de l’automatisation) pour essayer d’améliorer les choses (coût actuel des bugs), sachant que chaque bug évité découvert avec les tests correspond à un gain d’argent? Ceci donne une courbe ayant ce modèle :

L’intérêt de l’automatisation des tests dépend globalement du type de projet : un projet agile, ayant généralement 80-90% de test unitaires, 5-15% de test fonctionnels et 1-5% de tests d’interface, a moins d’intérêt à l’automatisation : on peut en effet prévoir une bonne qualité générale de code, baissant ainsi le coût qu’on est prêt à investir.

Pour des projets basés sur des cycles en V, les bugs sont généralement trouvés plus tard, et on peut avoir des projets dont les tests reposent à 80-90% sur des tests de type “End to End” à partir de l’interface, 5-15% en tests d’intégration et 0-5% de tests unitaires.
Gilles recommande sur ce type de projet de permettre d’automatiser en priorité les tests d’interface, créant ainsi un matelas de sécurité permettant de refactorer un peu le code sans prendre trop de risques, et finalement d’éventuellement constituer à terme un ensemble de tests unitaires. C’est en tout cas dans ce genre de projet que l’intérêt de l’automatisation est le plus important.

Cette vision de l’intérêt de l’automatisation m’a plû pour son orientation très pragmatique visant à permettre d’armer tout développeur à avoir un argumentaire convaincant pour pousser à l’automatisation des tests, en mettant en avant tant les gains de qualité que financiers.

Keynote finale

Pamela Fox@pamelafox
“ Teach the World to Code! ”

“Why are we here? Because we love programming!” Une bonne introduction de Pamela pour la keynote finale bien dans le ton de cette journée.
Après avoir rappelé qu’il y a tout de même environ 30 millions de développeurs dans le monde, elle a remis le chiffre en perspective avec les presque 7 milliards de personnes sur la planète.
Soutenant que la programmation est un support de la création et de l’innovation, elle espère que de plus en plus de personnes deviendront développeurs. Les façons d’apprendre à programmer sont nombreuses : pendant les études supérieures évidemment, mais Pamela nous a rappelé les nombreuses autres façons qui rendent l’accès au savoir plus facile, comme les cours en ligne, accessibles par tous, y compris de références comme le MIT, les ateliers de partage de connaissance, etc.
Tout ceci pour le petit défi qu’elle nous a lancé à tous : cette année, apprenez à une personne de votre entourage à programmer, pour que nous devenions toujours plus nombreux.

Et pour finir…

Et voilà, fin de journée! J’ai été ravi de la journée, et je remercie tous les organisateurs pour le boulot effectué et l’organisation sans failles : locaux agréables, pause repas de bonne qualité, wifi accessible et sans déconnexions intempestives, super site web (avec un excellent exemple de ce que peut apporter la “gamification” d’ailleurs), etc. Un grand merci naturellement aux speakers pour toutes ces présentations.
J’espère vous avoir donné envie d’assister à la prochaine session, en tout cas j’y serai également en 2013.
Pour information, certains slides des présentations sont disponibles sur le site du Mix It. Certaines n’y sont pas, mais sont facilement disponibles en cherchant sur Google.
A l’année prochaine!

soapUI et les tests de Web Services

SoapUI est un outil de test de Web Services développé par Eviware. Il existe en 2 versions dont une entièrement gratuite. Je le trouve très utile pour le debug et les tests unitaires de web services, mais aussi pour les tests automatisés et les tests de charge.

Je vous propose de découvrir dans cet article comment utiliser SoapUI pour réaliser des tests unitaires.

Lire la suite…

Tests unitaires pour Google App Engine

google-app-engine Les développeurs Cloud le savent, tests unitaires et Google App Engine ne sont pas franchement compatibles : si on veut exécuter les tests unitaires sur le GAE depuis un script ou son IDE préféré, on est obligé de les invoquer via http (ou xmpp) et on est vite limité par le timeout de 30 secondes.

Le projet App Engine Unit tente de combler le vide. Le principe est de découper une suite de tests JUnit en tâches asynchrones et de les empiler ensuite dans la Task Queue.

Sur le papier, ça semble plutôt prometteur. Mais le projet en est encore à ses balbutiements (version 0.0.6 !). A suivre de près néanmoins.

Séminaire à l’Université de Savoie : tests automatisés et intégration continue

Voici un rêve qui vient de se réaliser : animer un cours à l’Université de Savoie aux étudiants de deuxième année de Master Technologies de l’information et des communications. Pour la petite histoire, j’ai suivi ce cursus il y a déjà quelques années.

Le séminaire portait sur la mise en place de tests automatisés et de l’intégration continue dans un projet de développement logiciel. Ce sont 2 sujets qui prennent toute leur importance dans un développement itératif et incrémental mais qui ne sont pas toujours traités dans un cursus universitaire. C’est là l’intérêt de la démarche de l’Université de Savoie: demander à des intervenants spécialisés dans le génie logiciel de venir partager des retours d’expérience avec les étudiants.

Seul bémol : cette intervention est arrivée un peu tardivement dans le cursus et les étudiants vont avoir du mal à mettre en place les bonnes pratiques présentées dans leur projet de fin d’année. L’année prochaine, on essaiera de la planifier un peu plus tôt. Il est également envisagé de programmer une journée de type « Travaux dirigés », dans laquelle les étudiants pourront se confronter concrètement à cette mise en place sous l’œil vigilant d’un consultant.