Je voudrais partager avec vous le retour d’expérience sur un projet chaotique dans le domaine de l’automatisation des tests que l’un de nos collaborateurs Kevin D a mené “vaillamment”
Parfois, même une entreprise comme la notre riche d’une longue expérience exclusivement dans le domaine de l’automatisation des tests peut se faire embourber dans un piège sans fin…
Enjeux du projet
L’objet de ce projet est d’automatiser des scénarios de simulation de montage de prêts dans le cadre de tests de non régression actuellement effectués de façon laborieuse par des testeurs manuels qui se retrouvent à court de temps disponible au vu de la charge de travail nécessaire. Pour ce POC, nous avons établi avec le client deux scénarios type à faire tourner ainsi que des données à contrôler et à exporter. Elles reposent toutes les deux sur le même type de montage de projet à la différence que l’un renseigne les données d’un emprunteur seul et l’autre additionne également une personne emprunteuse.
Le Challenge operationnel
Le premier écueil, et le plus contraignant, est celui de l’installation des outils face a un manque de réactivité de la division responsable de la sécurité. Node JS est autorisé, mais tout complément installé via NPM demande une autorisation spéciale sur laquelle personne n’accepte de s’engager. De nos jours les moyens susceptibles de permettre ou refuser ces installations sont tout de même assez courants et permettent rapidement de trancher.
Le second écueil, un cruel manque de disponibilité des sachants qui nous pousse à définir de nous même la couverture des tests au risque d’être hors sujet. A ce jour nous avons opéré un transfert de connaissances à la personne responsable de l’initiative dans le but d’arriver à une montée en compétence. Malheureusement un délai si long sans maintenance des scripts rend le package livré inexploitable.
Le dernier écueil enfin, est le manque de compréhension des futurs utilisateurs. La demande incessante restant d’avoir une interface simplifiée permettant de lancer et de maintenir les scripts.
La solution mise en place
Nous somme dans un environnement FullWeb , dans un soucis d’innovation nous décidons de benchmarker Cypress et Playwright.
Bref comparatif, en quelques mots:
Playwright :
Prise en charge multi-navigateur: Playwright prend en charge plusieurs navigateurs tels que Chrome, Firefox et WebKit, ce qui offre une plus grande flexibilité pour tester les applications web sur différentes plates-formes.
Langages de programmation: Playwright prend en charge plusieurs langages de programmation, notamment JavaScript, TypeScript, Python et C#. Cela permet aux équipes de développement d’utiliser le langage qui correspond le mieux à leur stack technologique.
Prise en charge des appareils mobiles: Playwright offre une prise en charge intégrée des émulateurs de dispositifs mobiles, ce qui facilite le test des applications sur différents appareils.
Automatisation du navigateur, de la page et du contexte: Playwright permet l’automatisation non seulement du navigateur et de la page, mais aussi du contexte, offrant ainsi plus de contrôle sur l’environnement de test.
Capture d’écran et enregistrement vidéo intégrés: Playwright offre des fonctionnalités intégrées pour capturer des captures d’écran et enregistrer des vidéos pendant l’exécution des tests, ce qui peut être utile pour le débogage.
Cypress :
Architecture centrée sur le navigateur: Cypress a une architecture centrée sur le navigateur, ce qui signifie qu’il s’exécute dans le navigateur aux côtés de l’application. Cela offre un accès direct au DOM et aux événements du navigateur, simplifiant le débogage.
Écriture en JavaScript uniquement: Cypress est principalement basé sur JavaScript, ce qui peut être un avantage si votre équipe de développement travaille déjà avec ce langage, mais peut être une limitation si vous préférez utiliser d’autres langages de programmation.
Facilité d’utilisation: Cypress est souvent loué pour sa facilité d’utilisation et sa configuration simplifiée. Il offre un ensemble d’outils et de fonctionnalités conçus pour rendre les tests plus simples à écrire et à comprendre.
Tests en temps réel: Cypress offre une fonctionnalité unique appelée “Time Travel” qui permet de visualiser l’état de l’application à chaque étape du test en temps réel, facilitant le débogage.
Community et documentation: Cypress a une communauté active et une documentation approfondie, ce qui peut être un avantage pour résoudre rapidement les problèmes et accéder à des ressources utiles.
En conclusion, le choix entre Playwright et Cypress dépend des besoins spécifiques de votre projet, de vos préférences en matière de langage de programmation et de la complexité de vos scénarios de test. Les deux outils sont puissants et ont leurs forces, il peut donc être utile de les évaluer en fonction des caractéristiques spécifiques de votre projet.
Dans notre cas le multi-fenêtre indispensable pour accomplir la plupart des processus, nous décide à choisir Playwright, même si Cypress pourrait paraitre plus convivial.
Pourtant le pré-requis du client étant d’avoir un IHM simple et maitrisé de tous, et nous sommes donc forcés de développer une sur-couche.
Deux solutions s’offrent à nous, la premiere: utiliser un outils de tests embarquant un éditeur d’IHM: Auto IT. Et la seconde, plus directe : Microsoft excel. Notre but étant de permettre aux utilisateurs de sauvegarder leurs jeux de données et les processus métiers qui les utilisent dans Excel et notre outil saura générer des données Json et des appels au suites de test automatiques de Playwright. Enfin les données générées dans les tests seront intégrées dans ce même Excel en tant que résultats obtenus.
Bref notre client se retrouve avec une solution clé en main permettant de lancer des campagnes de non régression de manière optimale. J’ai pourtant le facheux pressentiment que personne sur ce projet n’est capable de comprendre l’avantage que pourrait offrir notre solution.
French 
English 
Hebrew
Le parcours du consultant
Je voudrais partager avec vous le retour d’expérience sur un projet chaotique dans le domaine de l’automatisation des tests que l’un de nos collaborateurs Kevin D a mené “vaillamment”
Parfois, même une entreprise comme la notre riche d’une longue expérience exclusivement dans le domaine de l’automatisation des tests peut se faire embourber dans un piège sans fin…
Enjeux du projet
L’objet de ce projet est d’automatiser des scénarios de simulation de montage de prêts dans le cadre de tests de non régression actuellement effectués de façon laborieuse par des testeurs manuels qui se retrouvent à court de temps disponible au vu de la charge de travail nécessaire. Pour ce POC, nous avons établi avec le client deux scénarios type à faire tourner ainsi que des données à contrôler et à exporter. Elles reposent toutes les deux sur le même type de montage de projet à la différence que l’un renseigne les données d’un emprunteur seul et l’autre additionne également une personne emprunteuse.
Le Challenge operationnel
Le premier écueil, et le plus contraignant, est celui de l’installation des outils face a un manque de réactivité de la division responsable de la sécurité. Node JS est autorisé, mais tout complément installé via NPM demande une autorisation spéciale sur laquelle personne n’accepte de s’engager. De nos jours les moyens susceptibles de permettre ou refuser ces installations sont tout de même assez courants et permettent rapidement de trancher.
Le second écueil, un cruel manque de disponibilité des sachants qui nous pousse à définir de nous même la couverture des tests au risque d’être hors sujet. A ce jour nous avons opéré un transfert de connaissances à la personne responsable de l’initiative dans le but d’arriver à une montée en compétence. Malheureusement un délai si long sans maintenance des scripts rend le package livré inexploitable.
Le dernier écueil enfin, est le manque de compréhension des futurs utilisateurs. La demande incessante restant d’avoir une interface simplifiée permettant de lancer et de maintenir les scripts.
La solution mise en place
Nous somme dans un environnement FullWeb , dans un soucis d’innovation nous décidons de benchmarker Cypress et Playwright.
Bref comparatif, en quelques mots:
Playwright :
Cypress :
En conclusion, le choix entre Playwright et Cypress dépend des besoins spécifiques de votre projet, de vos préférences en matière de langage de programmation et de la complexité de vos scénarios de test. Les deux outils sont puissants et ont leurs forces, il peut donc être utile de les évaluer en fonction des caractéristiques spécifiques de votre projet.
Dans notre cas le multi-fenêtre indispensable pour accomplir la plupart des processus, nous décide à choisir Playwright, même si Cypress pourrait paraitre plus convivial.
Pourtant le pré-requis du client étant d’avoir un IHM simple et maitrisé de tous, et nous sommes donc forcés de développer une sur-couche.
Deux solutions s’offrent à nous, la premiere: utiliser un outils de tests embarquant un éditeur d’IHM: Auto IT. Et la seconde, plus directe : Microsoft excel. Notre but étant de permettre aux utilisateurs de sauvegarder leurs jeux de données et les processus métiers qui les utilisent dans Excel et notre outil saura générer des données Json et des appels au suites de test automatiques de Playwright. Enfin les données générées dans les tests seront intégrées dans ce même Excel en tant que résultats obtenus.
Bref notre client se retrouve avec une solution clé en main permettant de lancer des campagnes de non régression de manière optimale. J’ai pourtant le facheux pressentiment que personne sur ce projet n’est capable de comprendre l’avantage que pourrait offrir notre solution.
Dommage…
Partager :
J’aime ça :
Articles similaires
Archives
Recent Post
Categories
Portfolio
Méta
Calender