Client
Notre client est un fournisseur de services canadien qui permet aux organisations en Amérique du Nord d'exploiter la valeur des données sensibles à diverses fins sans compromettre les informations personnelles. Ils sont spécialisés dans la dé-identification des données et la création d'ensembles de données meilleurs, plus rapides et plus propres qui peuvent répondre à des besoins spécifiques pour une utilisation secondaire comme la recherche et l'analytique.
Grâce à notre client, les entreprises disposent d'une technologie éprouvée pour permettre l'utilisation de données exploitables qui peuvent être liées en toute sécurité et mises en œuvre conformément à la réglementation mondiale et soutenues par des preuves vérifiables.
Description du Projet
Elinext a fourni des services de développement de logiciels de santé à ce client sur plusieurs projets à long terme. Le premier est une application qui pouvait être installée localement en mode autonome ou en cluster. Le logiciel supportait l'installation AWS et utilisait Apache Spark pour transformer rapidement de grands ensembles de données contenant des milliards d'enregistrements. Il possède sa propre interface utilisateur exclusive.
Le second est une application avec plusieurs services importants (Traitement, Catalogue, Configuration, Orchestration-AirFlow) qui ne supporte que l'installation AWS et possède sa propre interface utilisateur unique.
Nos équipes fournissent des services de QA Automatisé et Manuel pour ces projets. Comme le qa dans la santé est notre spécialité, nous sommes leur entreprise de tests qa de référence depuis le deuxième trimestre 2017.
Défis
La demande initiale de notre client était de recevoir le support QA Automatisé pour leur produit. Le QA Manuel n'était pas suffisant, et le client était confronté à plusieurs défauts dans l'application. L'idée était d'avoir un CI/CD solide et d'identifier les bugs le plus tôt possible.
L'équipe Elinext a immédiatement remarqué des processus CI/CD déficients de leur côté.
Nous avons fourni 2-3 QA Automatisation et commencé à utiliser NodeJS-binary recommandé par Google pour tester les applications Angular.
Nos défis initiaux n'ont pas beaucoup changé et se présentaient ainsi au départ :
- Amélioration de la stabilité du produit
- Minimisation des défauts du côté client
- Établissement de processus CI/CD purs
- Test de différents environnements
Pendant le travail, ces défis sont apparus de manière inattendue, et nous avons dû y faire face :
- Migration du framework de test initial (Protractor) en raison de sa dépréciation
- Problèmes de connexions aux environnements sur AWS
- Gestion des comptes dans Teams. Nous avons encore quelques problèmes entre nos périmètres et ceux du client
Processus
Notre équipe utilise des approches communes pour équilibrer entre les tests manuels et automatiques. Nous avons une sorte d'image mentale de ce que devrait être un CI/CD classique. Certains changements ont été apportés pendant l'implémentation des solutions.
Avec le temps, nous avons mis à jour la version du framework et amélioré les rapports, par exemple en ajoutant certaines données requises sur les versions de release, etc. Dans certains cas, l'équipe Elinext a amélioré nos algorithmes pour la vérification du produit.
Pour les tests, nous utilisons des environnements de test séparés. Dans certains cas, cela inclut des tests automatisés dédiés, des tests manuels, des tests de vulnérabilité, etc. Il est important de noter que nous n'utilisons que des utilisateurs de test et ne manipulons pas de données clients réelles.
En ce qui concerne la communication, nous avons des réunions quotidiennes stand-up, des emails et des chats dans Teams, des sessions Retro et Demo. Nos ingénieurs et chefs de projet expérimentés décriraient la coopération comme "plutôt étroite".
Le processus habituel de test des nouvelles fonctionnalités se déroule de la manière suivante :
Étape 1 : Nouveaux Epics et Stories du côté développeur. Les développeurs commencent à implémenter la fonctionnalité des nouvelles features. Si possible, l'équipe QA Manuel commence à créer des cas de test pour ces stories, sinon plus tard.
Étape 2 : Tous les cas de test concernant la nouvelle fonctionnalité sont créés. La fonctionnalité est dans le Produit.
Étape 3 : Les cas de test peuvent être automatisés et sont poussés dans la 'file d'attente pour automatisation' (backlog de l'équipe Automatisation)
Étape 4 : Les cas de test sont automatisés. Marqués dans le plugin Zephyr comme automatisés, pour éviter l'exécution manuelle. Les cas de test sont inclus dans la suite appropriée et deviennent partie du processus CI quotidien.
Étape 5 : Surveillance des résultats du CI quotidien. En cas de bons résultats, fournir des rapports au client. En cas d'échec, investiguer, soulever le(s) défaut(s) ou mettre à jour le cas de test ou le code source.
Initialement, toutes les activités étaient gérées par une équipe QA Automatisation dédiée, plus tard l'équipe s'est agrandie avec des QA Manuels puis quelques Développeurs.
Solution
Nous avons fourni la solution basée sur la fonctionnalité du projet et ce que nous devions réaliser.
Dans le cas de notre projet initial, nous savions qu'il s'agissait d'un projet multiplateforme qui supportait de nombreuses sources de données et des cas de migration complexes. De plus, une partie importante de l'application est la vérification des rapports PDF et des données CSV.
Un Grand Serveur a été acheté pour garder tous les environnements au même endroit. Pour de meilleures performances et un serveur de support, OS Esxi y a été installé, et WM Ware a été utilisé comme opérateur de virtualisation. Une telle solution nous apporte de grands avantages :
- Plusieurs OS au sein de l'application testée ont été installés pour les tests (comme les systèmes Unix : RedHat x-versions, CentOS x-versions, et systèmes Windows)
- Support pour les installations en cluster de l'application, où nous avons 1 maître et 1+ machines workers
- Support pour tester les sources de données et les origines de données, comme Oracle, MSSQL, Postgres, DB2, etc
- Grâce à la virtualisation, les efforts de migration ont été réduits car nous avons simplement gardé la version précédente comme snapshots
- Jenkins avec les jobs d'Automatisation est également l'une des machines sur le serveur
Comme mentionné précédemment, la demande initiale du client était d'utiliser Protractor comme framework d'Automatisation pour les tests. À cette époque, c'était un framework facile à comprendre, rapide à adopter et à démarrer, avec toutes les intégrations requises, comme les systèmes de rapport, etc.
Malheureusement, après 2-3 ans, Google a décidé d'arrêter le support du framework et plus tard il a été déprécié.
En conséquence, avant sa dépréciation, une investigation des meilleurs frameworks d'Automatisation et des efforts imaginés devait être faite pour passer de Protractor à celui-ci. Nous avons décidé d'utiliser WebdriverIO comme framework de test pour l'Automatisation.
Nous pouvons souligner les avantages suivants de WebdriverIO :
- Basé sur JS, facile à migrer depuis Protractor, et support
- Framework ancien et stable, contrairement à Protractor, nouveau et moderne mais oublié après 5 ans
- Supporte toutes les fonctionnalités sensibles dont nous avons besoin pendant les tests des produits PA, comme l'exécution parallèle dans plusieurs navigateurs, et l'intégration avec le système de rapport, c'est-à-dire Jasmine runner
Pour les besoins d'Automatisation, une machine avec Jenkins installé a été déployée. Pour être exécutés quotidiennement, nous avons créé des jobs comme :
- Déployer une version fraîche du produit de l'application, avec/sans nettoyage de sa base Mongo DB
- Exécution de test Smoke avec un rapport valable
- Exécution de test de Régression avec un rapport valable
- Avoir des jobs utilitaires pour mettre à jour les conteneurs Docker (les tests d'automatisation sont exécutés dans Docker), notifier du succès/échec de l'exécution de la suite dans un canal Slack spécial, et même avoir un job pour exécuter l'automatisation + ZAP et obtenir les rapports ZAP.
Quant à la fonctionnalité d'un autre projet, elle diffère un peu. Pour l'instant, ce projet plutôt jeune a environ un an. Il ne peut être installé qu'avec l'aide d'AWS, et à cause de cela, les ingénieurs Elinext peuvent avoir besoin d'utiliser d'autres approches pour le tester. Nous gardons l'environnement Jenkins sur le réseau DMZ (Zone Démilitarisée) dans AWS.
En plus des tests pour ces deux projets majeurs, nous avons également aidé avec plusieurs autres projets annexes gérés par notre client, mais ces coopérations ont cessé à ce jour pour diverses raisons.
Les tests les plus courants exécutés par notre équipe :
Tests fonctionnels : exécuter des cycles de test avec de nouveaux cas de test pour les nouvelles fonctionnalités. Les tests de régression avant la livraison de la version font également partie de ce type. Réaliser des cas de test de Migration pour supporter la mise à jour des versions précédentes vers les versions actuelles. Cas de test UI, API, etc. Cette partie est très probablement la prérogative de l'équipe QA Manuel. L'équipe Elinext utilise Zephyr (plugin Jira) comme référentiel pour les cas de test.
Tests d'automatisation : tous les cas de test que nous pouvons automatiser du type précédent en deviennent partie intégrante. En conséquence, les exécutions CI quotidiennes de l'automatisation incluent des tests e2e, des tests API et des scripts d'installation. L'équipe Elinext utilise Jasmine pour l'API, et WebdriverIO pour l'UI (dans le cadre de l'e2e). Nous utilisons JavaScript pour écrire les tests automatisés.
Tests de vulnérabilité : Utilisation de l'outil OWASP ZAP pour les tests de pénétration.
Comme mentionné, notre projet majeur est celui permettant de partager des données sensibles sans crainte d'être compromis. Vous pouvez exécuter l'application depuis l'interface utilisateur ou l'exécuter par programmation en utilisant l'API REST.
Résultats
L'automatisation CI a beaucoup aidé, depuis le début de notre fourniture de services de test logiciel automatisé. Les défauts critiques et catastrophiques ont été découverts avant la version officielle. Depuis que l'équipe manuelle est devenue partie prenante de la coopération avec notre client, la qualité des cas de test écrits et la stabilité du produit final ont augmenté jusqu'au standard de ce que nous considérons excellent pour le qa dans la santé et maintenu jusqu'à présent.
Le niveau de satisfaction de l'équipe Elinext est mieux vu à travers le fait qu'elle est passée de 3 personnes à plus de 15 sur plusieurs projets. Nous pouvons confirmer que le client apprécie nos approches en AQA, QA et Développement.
En ce qui concerne la communication, nous devons maintenir un équilibre entre les exigences du client et les périmètres que nous pouvons vouloir tester. Tout doit être discuté et approuvé du côté client.
Le plus ancien projet que nous avons avec le client est maintenant principalement sous notre support, rien de plus. Les versions pour ces solutions d'analyse de données de santé sont devenues rares, passant de 4 fois par an à une ou deux au cours de l'année.
Un autre projet actif plus récent a des versions plusieurs fois par an (~3-4). Nous n'excluons pas l'opportunité d'étendre notre coopération car le client est intéressé par nos services d'analyse de données.
