SDTestLib

Présentation

SDTestLib est un framework d’automatisation de tests Web et Mobile que j’ai conçu et développé au sein de Stardust The Digital Testing entre 2018 et 2019.

À cette époque, les projets d’automatisation réalisés au sein de l’entreprise reposaient principalement sur des développements spécifiques réalisés pour chaque client. Cette approche entraînait une duplication importante des efforts, des architectures parfois hétérogènes et des difficultés de maintenance lorsque plusieurs projets devaient évoluer simultanément.

L’objectif de SDTestLib était de fournir une base technique commune permettant de mutualiser les composants récurrents, standardiser les méthodes de développement et accélérer la mise en œuvre des projets d’automatisation.

Le framework a été conçu pour répondre à des besoins variés :

• Automatisation de tests Web.
• Automatisation de tests mobiles Android.
• Automatisation de tests mobiles iOS.
• Exécution locale ou distante.
• Gestion multi-navigateurs.
• Gestion multi-devices.
• Réutilisation des composants techniques entre projets.

Objectifs du projet

Les principaux objectifs de SDTestLib étaient :

• Réduire le temps de démarrage des nouveaux projets d’automatisation.
• Mutualiser les composants techniques récurrents.
• Uniformiser les pratiques de développement.
• Faciliter la maintenance des campagnes automatisées.
• Simplifier la gestion des environnements Web et Mobile.
• Centraliser les mécanismes d’exécution et de reporting.
• Améliorer la réutilisation du code entre différents clients.

Positionnement dans l’entreprise

SDTestLib n’était pas un simple projet client mais un socle technique transverse destiné à être utilisé par plusieurs équipes et plusieurs projets.

Le framework constituait une bibliothèque interne sur laquelle pouvaient s’appuyer les automaticiens afin de concentrer leurs efforts sur les scénarios métier plutôt que sur les problématiques techniques récurrentes.

Cette approche permettait d’industrialiser davantage les activités d’automatisation tout en favorisant la cohérence entre les différents projets réalisés par l’entreprise.

Technologies principales

Le framework reposait notamment sur :

• Java.
• Maven.
• TestNG.
• Selenium WebDriver.
• Appium.
• BrowserStack.
• SauceLabs.
• Experitest.
• Android.
• iOS.

L’ensemble de ces composants était encapsulé derrière des couches d’abstraction destinées à simplifier leur utilisation au sein des projets.

Architecture générale

L’architecture de SDTestLib reposait sur plusieurs principes fondamentaux :

• Mutualisation maximale des composants.
• Séparation claire entre technique et métier.
• Réutilisation des mécanismes communs.
• Configuration centralisée.
• Compatibilité Web et Mobile.
• Extensibilité pour les futurs projets.

L’objectif n’était pas simplement d’automatiser des tests mais de créer une véritable plateforme technique réutilisable permettant d’accélérer durablement les activités d’automatisation de Stardust.

Bilan

SDTestLib représente mon premier véritable framework d’entreprise dédié à l’automatisation de tests.

Au-delà de son utilisation opérationnelle, ce projet a constitué une étape importante dans mon évolution professionnelle en me permettant d’aborder des problématiques d’architecture logicielle, de mutualisation, d’industrialisation et de maintenabilité à une échelle supérieure à celle d’un simple projet client.

Architecture technique

L’un des objectifs principaux de SDTestLib était de masquer la complexité technique des différents outils d’automatisation afin de permettre aux automaticiens de se concentrer principalement sur les scénarios métier.

Pour atteindre cet objectif, le framework reposait sur plusieurs couches d’abstraction et composants réutilisables.

Couche d’abstraction des navigateurs

SDTestLib intégrait une couche permettant de gérer différents navigateurs Web sans modifier le code des scénarios automatisés.

Les mécanismes d’initialisation des navigateurs étaient centralisés afin d’assurer :

• Une configuration homogène.
• Une simplification du démarrage des campagnes.
• Une réduction des duplications de code.
• Une meilleure maintenabilité.

Navigateurs supportés :

• Google Chrome.
• Mozilla Firefox.
• Internet Explorer.
• Microsoft Edge.
• Navigateurs distants via plateformes Cloud.

Couche d’abstraction Mobile

Le framework intégrait également une couche dédiée à l’automatisation mobile reposant sur Appium.

Cette architecture permettait de gérer :

• Smartphones Android.
• Terminaux iOS.
• Tablettes.
• Exécutions locales.
• Exécutions distantes.

L’objectif était de fournir une interface commune indépendamment du type d’appareil utilisé.

Les scénarios de tests pouvaient ainsi être réutilisés avec un minimum d’adaptation entre plusieurs environnements.

Gestion des plateformes Cloud

SDTestLib avait été conçu pour fonctionner aussi bien sur des terminaux physiques locaux que sur des infrastructures de tests distantes.

Le framework intégrait notamment des mécanismes facilitant l’exécution sur :

• BrowserStack.
• SauceLabs.
• Experitest.

Cette approche permettait :

• D’élargir la couverture de tests.
• De réduire les besoins matériels locaux.
• D’accéder à un grand nombre de configurations.
• D’automatiser des campagnes multi-devices.

Configuration centralisée

L’ensemble des paramètres techniques était regroupé dans des mécanismes de configuration centralisés.

Cette approche permettait de modifier facilement :

• Les environnements.
• Les navigateurs.
• Les terminaux.
• Les URLs applicatives.
• Les paramètres d’exécution.

Sans nécessiter de modification du code métier.

Mutualisation des composants

Un des principes fondateurs de SDTestLib était la mutualisation maximale des composants techniques.

De nombreux services étaient partagés entre les projets :

• Initialisation des drivers.
• Gestion des sessions.
• Mécanismes d’attente.
• Captures d’écran.
• Journalisation.
• Gestion des erreurs.
• Fonctions utilitaires.

Cette mutualisation permettait :

• De réduire fortement la duplication.
• D’améliorer la cohérence entre projets.
• De simplifier les évolutions futures.
• D’accélérer le développement des nouveaux scénarios.

Gestion des erreurs et robustesse

Le framework intégrait plusieurs mécanismes destinés à améliorer la robustesse des campagnes automatisées :

• Gestion centralisée des exceptions.
• Captures automatiques d’écrans lors des échecs.
• Journalisation détaillée des exécutions.
• Vérifications techniques avant lancement des scénarios.
• Contrôles de cohérence des environnements.

Ces mécanismes facilitaient considérablement l’analyse des anomalies rencontrées lors des campagnes automatisées.

Industrialisation des campagnes

SDTestLib avait été conçu dans une logique d’industrialisation.

L’objectif n’était pas uniquement d’exécuter des tests automatisés mais de fournir un socle permettant :

• La création rapide de nouveaux projets.
• La standardisation des pratiques.
• La réutilisation des composants.
• L’amélioration de la maintenabilité.
• L’augmentation de la couverture automatisée.

Cette philosophie constituera par la suite une constante dans mes différents projets d’automatisation réalisés chez MadSeven, Monext, Française des Jeux ou Voyage Privé.

Vision architecturale

Avec le recul, SDTestLib représente bien davantage qu’un framework technique.

Il s’agissait d’une première démarche d’architecture de solutions de validation visant à transformer des outils d’automatisation isolés en une plateforme cohérente, réutilisable et évolutive.

Cette expérience m’a permis d’aborder pour la première fois des problématiques d’architecture logicielle, de factorisation, de maintenabilité et d’industrialisation à une échelle dépassant largement celle d’un simple projet client.

Organisation du framework

Afin de faciliter sa maintenance et son évolution, SDTestLib reposait sur une organisation modulaire permettant de séparer clairement les responsabilités techniques.

L’objectif était d’éviter la création de projets monolithiques difficiles à maintenir et de permettre aux automaticiens de localiser rapidement les composants dont ils avaient besoin.

Cette structuration favorisait également la réutilisation des éléments communs entre plusieurs projets clients.

Gestion des projets Maven

Le framework s’appuyait sur Maven afin de gérer :

• Les dépendances techniques.
• Les bibliothèques tierces.
• Les versions des composants.
• Les phases de compilation.
• Les exécutions automatisées.

Cette approche permettait de garantir une homogénéité des environnements de développement entre les différents membres de l’équipe.

L’utilisation de Maven facilitait également la reproductibilité des exécutions et le partage des projets.

Organisation des composants

L’architecture était organisée autour de plusieurs catégories de composants :

• Gestion des navigateurs.
• Gestion des terminaux mobiles.
• Fonctions utilitaires.
• Gestion des données.
• Gestion des rapports.
• Gestion des captures d’écran.
• Gestion des environnements.
• Services communs.

Chaque composant pouvait être utilisé indépendamment ou combiné avec d’autres selon les besoins du projet.

Séparation entre technique et métier

L’un des principes majeurs du framework consistait à séparer autant que possible :

• Les mécanismes techniques.
• Les règles métier.
• Les scénarios de validation.

Cette approche présentait plusieurs avantages :

• Réduction de la duplication.
• Meilleure lisibilité.
• Maintenance simplifiée.
• Réutilisation facilitée.

Les automaticiens pouvaient ainsi se concentrer davantage sur la logique métier à tester plutôt que sur les détails techniques d’exécution.

Gestion des données de tests

Les campagnes automatisées nécessitaient souvent l’utilisation de données variées afin de couvrir différents scénarios fonctionnels.

SDTestLib intégrait des mécanismes permettant :

• D’isoler les données de tests.
• De réutiliser les jeux de données.
• De faciliter l’ajout de nouveaux scénarios.
• De limiter les modifications du code lors des évolutions fonctionnelles.

Cette approche favorisait la maintenabilité des campagnes et leur adaptation à de nouveaux besoins.

Exécution des campagnes TestNG

Le framework reposait largement sur TestNG pour l’organisation des campagnes automatisées.

Les mécanismes mis en œuvre permettaient notamment :

• L’exécution de suites de tests.
• Le regroupement logique des scénarios.
• La gestion de dépendances entre tests.
• Le lancement ciblé de campagnes spécifiques.
• La génération automatisée de résultats.

Cette organisation facilitait l’intégration des campagnes dans les processus de qualification de l’entreprise.

Reporting et traçabilité

Une attention particulière avait été portée à la traçabilité des exécutions.

Les campagnes produisaient différents éléments permettant d’analyser les résultats :

• Rapports d’exécution.
• Journaux techniques.
• Captures d’écran.
• Informations de contexte.
• Historique des campagnes.

Ces informations facilitaient les investigations en cas d’échec et amélioraient la communication avec les équipes projet.

Réutilisation inter-projets

L’une des ambitions initiales de SDTestLib consistait à devenir un socle commun réutilisable entre plusieurs projets clients.

Cette mutualisation permettait :

• De réduire les temps de démarrage.
• D’accélérer la création de nouvelles campagnes.
• D’uniformiser les pratiques d’automatisation.
• De limiter les développements redondants.

Au fil du temps, plusieurs composants du framework ont ainsi été réutilisés sur différents projets au sein de Stardust.

Transmission des connaissances

Au-delà de son aspect purement technique, SDTestLib constituait également un support de montée en compétences pour les automaticiens.

Le framework permettait :

• D’illustrer les bonnes pratiques.
• De standardiser certaines approches.
• De faciliter l’intégration de nouveaux collaborateurs.
• De diffuser des mécanismes éprouvés entre plusieurs équipes.

Cette dimension de capitalisation et de transmission était particulièrement importante dans un contexte où les projets et les équipes évoluaient régulièrement.

Impact sur mon parcours professionnel

Avec le recul, SDTestLib constitue probablement le premier projet sur lequel j’ai réellement commencé à raisonner en termes d’architecture de solution plutôt qu’en termes de développement isolé.

La conception du framework m’a amené à réfléchir à des problématiques telles que :

• La maintenabilité.
• La factorisation.
• La réutilisation.
• La robustesse.
• L’évolutivité.
• L’industrialisation.

Ces notions deviendront ensuite des constantes dans l’ensemble des projets que je réaliserai par la suite, qu’il s’agisse de Mood Messenger, Appy, PayAvenue, des projets de la Française des Jeux ou encore des travaux menés plus récemment autour des API et des architectures de validation.

Bilan

SDTestLib représente l’une des réalisations les plus marquantes de mon parcours chez Stardust.

Au-delà de l’outil lui-même, ce projet a constitué une véritable école d’architecture logicielle appliquée à la qualité. Il m’a permis de passer progressivement d’une logique d’exécution de tests à une logique de conception de solutions de validation complètes, capables d’être réutilisées, maintenues et enrichies au fil du temps.

Avec le recul, je considère SDTestLib comme le point de départ de mon évolution vers les activités d’architecture de solutions de test et d’analyse de systèmes complexes.

Retour d’expérience

Avec plusieurs années de recul, SDTestLib reste l’un des projets professionnels les plus marquants de mon parcours.

Au-delà de ses aspects techniques, ce framework représente une période durant laquelle j’ai commencé à dépasser le simple rôle d’utilisateur d’outils d’automatisation pour devenir concepteur de solutions destinées à être utilisées par d’autres collaborateurs.

Cette évolution a profondément influencé ma manière d’aborder la qualité logicielle, l’automatisation et plus généralement la conception de systèmes techniques.

Une première expérience d’architecture

Avant SDTestLib, la majorité de mes activités étaient principalement orientées vers l’exécution, l’analyse et la validation.

La conception du framework m’a progressivement amené à raisonner différemment :

• Comment simplifier le travail des automaticiens ?
• Comment éviter la duplication de code ?
• Comment faciliter la maintenance ?
• Comment améliorer la robustesse des campagnes ?
• Comment mutualiser les composants techniques ?
• Comment rendre une solution réutilisable par plusieurs projets ?

Ces problématiques m’ont conduit à adopter une vision davantage orientée architecture et industrialisation.

Un framework conçu pour durer

Contrairement à un projet développé pour répondre à un besoin ponctuel, SDTestLib avait été conçu avec une ambition plus large.

L’objectif n’était pas seulement de résoudre un problème immédiat mais de créer un socle technique capable d’évoluer dans le temps.

Cette approche m’a amené à porter une attention particulière à :

• La lisibilité du code.
• La maintenabilité.
• La modularité.
• L’extensibilité.
• La réutilisation.
• La robustesse.

Ces principes continuent aujourd’hui encore à guider ma manière de concevoir des solutions techniques.

Capitalisation et transmission

L’un des aspects les plus enrichissants du projet résidait dans sa vocation à être utilisé par d’autres collaborateurs.

Le framework ne devait pas uniquement fonctionner ; il devait également être compréhensible, documenté et suffisamment structuré pour permettre sa réutilisation par différentes équipes.

Cette dimension de transmission des connaissances m’a sensibilisé très tôt à l’importance :

• De la documentation.
• De la standardisation.
• Des bonnes pratiques.
• De la cohérence architecturale.
• De la capitalisation du savoir-faire.

Impact sur les projets futurs

Les enseignements tirés de SDTestLib ont directement influencé les projets que j’ai réalisés par la suite.

On retrouve notamment cet héritage dans :

• Les frameworks d’automatisation développés chez MadSeven.
• Les travaux de refonte réalisés sur PayAvenue chez Monext.
• Les projets menés à la Française des Jeux.
• Les architectures de validation API plus récentes.
• Mes projets personnels liés à l’automatisation et aux outils de test.

La recherche de mutualisation, de factorisation et de réutilisation restera un fil conducteur de l’ensemble de ces réalisations.

Ce que je referais aujourd’hui

Avec l’expérience acquise depuis la création de SDTestLib, plusieurs axes d’amélioration me paraissent aujourd’hui évidents.

Je chercherais notamment à intégrer davantage :

• Les principes modernes d’architecture logicielle.
• Les mécanismes avancés de reporting.
• Une gestion plus poussée de la configuration.
• Une intégration plus étroite avec les chaînes CI/CD.
• Des tableaux de bord de suivi qualité.
• Des mécanismes avancés de traçabilité.
• Une meilleure intégration des API et services Web.

Néanmoins, compte tenu du contexte technologique et organisationnel de l’époque, les choix réalisés ont pleinement répondu aux objectifs fixés.

Une étape fondatrice

Avec le recul, SDTestLib représente bien davantage qu’un framework d’automatisation.

Ce projet marque le moment où j’ai commencé à considérer les activités de qualification non plus uniquement comme une succession de campagnes de tests mais comme un ensemble cohérent de processus, d’outils et d’architectures pouvant être optimisés, mutualisés et industrialisés.

Il constitue également la première manifestation concrète de plusieurs compétences qui caractérisent aujourd’hui mon parcours professionnel :

• Analyse de systèmes complexes.
• Conception de solutions de validation.
• Architecture de frameworks.
• Industrialisation des processus.
• Développement d’outils techniques.
• Capitalisation des connaissances.

Conclusion

SDTestLib demeure l’une des réalisations dont je suis le plus fier au cours de mon parcours chez Stardust.

Au-delà des lignes de code produites, ce projet m’a permis de développer une vision plus globale de la qualité logicielle et de la conception d’outils destinés à améliorer durablement le travail des équipes.

Il représente une étape charnière dans mon évolution professionnelle, entre le rôle de testeur et celui de concepteur de solutions de validation, une orientation qui continuera ensuite à se renforcer tout au long de ma carrière.