Témoignage: changer son framework de tests automatisés

Témoignage: changer son framework de tests automatisés

Interview Didier Birenbaum (contact : didier.birenbaum@crossknowledge.com)

Recontextualisation: Didier travaille chez Crossknowledge (https://www.crossknowledge.com),  entreprise leader dans le domaine du digital learning . Il est Test Automation lead et a concu et implémenté l’architecture des tests automatisés IHM sur la plateforme d’e-learning de Crossknowledge.

 Bonjour Didier, peux-tu décrire votre solution actuelle pour l’automatisation des tests ?

Actuellement nous utilisons une solution avec TestComplete de chez Smartbear. Nous avons une centaine de tests qui sont tous exécutés sur 3 navigateurs Web qui représentent la majorité d’usage Web chez nos clients (ce qui fait 300 tests en tout). Ces tests peuvent être assez complexes notamment du point de vue de leur initialisation et du nombre d’écrans à parcourir pour couvrir un test de bout en bout.

J’ai créé le framework actuel de test. Ce framework repose sur l’encapsulation des objets webs (pages, boutons, liens, champs textes) pour décrire chaque page de l’application. Cet architecture logicielle permet de se découpler de l’automate de test et garantit un effort de maintenance réduit. Les changements sont faits à un seul endroit dans le code (le script de modélisation de la page) et tous les tests qui utilisent cette page bénéficient des changements. Les scripts Testcomplete sont écrits en javascript, langage qui permet la programmation orientée objet.

En l’état actuel nous avons 3 licences Testcomplete pour développer les tests et 5 licences pour leur exécution ce qui permet d’exécuter les tests en parallèle sur 5 machines Windows. L’exécution de notre campagne de test de non régression est gérée en automatique par notre serveur Jenkins nécessite plus de 3 heures en répartissant la charge sur les 5 Virtual Machines Windows.

Comment êtes-vous arrivé à ce niveau d’automatisation ?

Le projet d’automatisation a démarré il y a 5 ans lorsque l’on a commencé à structurer le test et embaucher des testeurs. J’ai été recruté pour mon background technique de développeur et d’automatisation. J’ai ensuite appris le contexte du développement d’applications Web et gestion des environnements de test – sans une bonne gestion et une automatisation des environnements de test on ne peut pas tester efficacement. A l’époque j’ai introduit Jenkins pour remplacer le serveur CruiseControl.

Nous avons tout d’abord opté pour une solution de Model Based Testing (MBT) afin de permettre une automatisation plus simple et surtout plus accessible aux personnes peu techniques et de coupler cette solution avec la génération de scripts javascript/TestComplete.

Au bout d’un an et demi nous sommes arrivés à la conclusion que le MBT n’était pas approprié à notre contexte : Beaucoup de pages Web à tester, des tests assez complexes nécessitant une configuration technique (appel web services, création de données en Base, …). Nous n’avons pas pu bénéficier du principal bénéfice du MBT de la génération des cas de tests en fonction des différents chemins tout en étant contraints de modéliser ces chemins et de faire des allers et retours entre l’outil de MBT et JavaScript/Testcomplete pour l’implémentation. Cela reste une super expérience et je suis convaincu de l’utilité des outils de type MBT. Nous n’avions à l’époque qu’une connaissance très partielle de l’application à tester et des contraintes techniques qui nous ont amené à choisir un bon outil MBT mais pas adapté à notre contexte.

Nous avons donc décidé de ne plus utiliser le MBT mais de conserver nos tests et de continuer à les maintenir directement ce qui nous a amené à notre situation actuelle.

Quelles sont les limites de votre solution actuelle et pourquoi souhaitez-vous la changer ?

Depuis notre rachat par l’entreprise américaine Wiley (https://www.wiley.com), nous avons été amenés à converger vers l’utilisation d’outils communs. En ce qui concerne l’automatisation des tests, j’ai découvert que Selenium était préconisé et déjà utilisé dans la communauté de nos testeurs.

Quel outil souhaitez-vous utiliser et pourquoi ?

J’ai donc proposé à ma direction un plan de migration vers Selenium pour :

• converger vers un engine de test unique,
• augmenter le nombre de postes de développements de tests,
• augmenter la scabilité du nombre de machines d’exécution des tests, sans avoir à payer pour des licences de développement et d’exécutions supplémentaires.

J’ai choisi Python comme langage de programmation, car il était déjà utilisé par nos équipes de développement pour certains produits et aussi pour sa facilité d’utilisation, de lisibilité et de maintenabilité (Pas besoin de compiler le code pour exécuter les tests, un git pull, checkout suffit).

Grace au découplage de mon framework actuel basé sur Javascript/TestComplete et l’utilisation de la modélisation des pages et objets Webs, j’ai pu rapidement en 2 mois migrer mon framework de test sur Python/Selenium et le tester en migrant un script de test simple.

La migration vers python/Selenium est importante car :

• J’espère pouvoir rendre l’accès au développement de scripts d’automatisations au plus grand nombre, bien sur les QAs, QEs en priorité, mais aussi pourquoi pas aux développeurs et aux Products Owners s’ils le souhaitent.
• J’espère réduire le temps d’exécution des tests en mettant en service plus de VMs n’ayant plus de contraintes de  couts de licences supplémentaires.
• J’espère du coup pouvoir lancer plus de campagnes de non régression par journée.  Tester plus tôt, sur nos branches de dévelopement pour anticiper les régressions avant l’intégration.

Comment se passe votre migration ?

Grace au découplage de mon framework actuel basé sur Javascript/TestComplete et l’utilisation de la modélisation des pages et objets Webs, j’ai pu rapidement en 2 mois migrer le framework de test sur Python/Selenium et le tester en migrant un script de test existant de complexité moyenne. A posteriori je suis très satisfait du choix de la paire Python/Selenium.

Je suis en cours de préparation d’un Workshop pour permettre à nos testeurs de monter en compétences rapidement sur notre nouveau framework de test, grâce à la réutilisation de patterns de conception de tests déjà utilisés et connus.

Il reste maintenant à livrer les tests et nous prévoyons une fin de migration pour avril prochain. Pour la phase de transition, nous allons faire des mises à jour dans notre ALM du champ « automation engine » lié à chaque test. J’ai développé un petit service web me permettant de savoir à partir de Jenkins si le test doit s’exécuter sous Testcomplete ou Selenium permettant d’assurer une transition facile au niveau de l’execution. Cette méthode permet également d’avoir un état précis du backlog de tests à migrer en filtrant sur le champ « automation engine de l’ALM ».

Quelles sont les compétences nécessaires pour mener un bien un projet d’automatisation comme le tien?

L’automatisation c’est du développement. Les compétences nécessaires sont donc principalement techniques. Dans notre migration les compétences nécessaires sont:

• Jenkins ou autre pour l’intégration continue,
• Développement d’outils comme pour l’intégration avec ALM (remontée résultats de Test dans ALM à l’aide d’une API), ou développement de petits web services pour la communication entre applications (ex : jenkins/ALM)
• Maitrise des environnements de tests et des technologies utilisées (ex : Apache/Linux/MySQL,…)

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles