Kunde
Unser Kunde ist ein kanadischer Dienstleister, der Organisationen in Nordamerika dabei unterstützt, den Wert sensibler Daten für verschiedene Zwecke zu nutzen, ohne persönliche Informationen preiszugeben. Er ist auf die De-Identifizierung von Daten spezialisiert und erstellt optimierte Datensätze, die speziell für die sekundäre Nutzung wie Forschung und Analysen geeignet sind.
Dank der Technologie unseres Kunden können Unternehmen verwertbare Daten sicher verknüpfen und unter Einhaltung globaler Vorschriften nutzen – mit nachweisbarer Auditierbarkeit. Sie suchten nach Qualitätssicherung im Gesundheitswesen.
Projektbeschreibung
Das zweite Projekt war eine App mit mehreren wichtigen Services (Behandlung, Katalog, Konfiguration, Orchestrierung-AirFlow), die nur auf AWS installiert werden konnte und eine eigene, einzigartige Benutzeroberfläche hatte.
Unsere Teams bieten sowohl automatisierte als auch manuelle QA Services für diese Projekte. Da Qualitätssicherung im Gesundheitswesen unsere Spezialität ist, sind wir seit dem zweiten Quartal 2017 der bevorzugte QA-Dienstleister.
Herausforderungen
Die ursprüngliche Anfrage unseres Kunden war, Automation QA-Unterstützung für ihr Produkt zu erhalten. Manuelle QA war nicht ausreichend, und der Kunde stieß auf mehrere Fehler in der Anwendung. Das Ziel war es, ein starkes CI/CD zu implementieren und die Bugs so schnell wie möglich zu identifizieren.
Das Elinext-Team mit umfangreicher Erfahrung in Qualitätssicherung im Gesundheitswesen bemerkte sofort schwache CI/CD-Prozesse auf der Seite des Kunden.
Wir stellten 2-3 Automation QA-Experten bereit und begannen, den von Google empfohlenen NodeJS-Binary für das Testen von Angular-Anwendungen zu verwenden.
Unsere anfänglichen Herausforderungen haben sich nicht allzu sehr verändert und sahen ursprünglich folgendermaßen aus:
- Verbesserung der Produktstabilität
- Minimierung der Fehler auf der Kundenseite
- Etablierung reiner CI/CD-Prozesse
- Testen verschiedener Umgebungen
Während der Arbeit traten unerwartete Herausforderungen auf, mit denen wir uns befassen mussten:
- Auswahl des Test-Frameworks (Protractor). Der Kunde forderte dies, da es zu dieser Zeit eine Priorität war.
- Migration vom ursprünglichen Test-Framework (Protractor) aufgrund seiner Abkündigung.
- Probleme mit der Verbindung zu den Umgebungen auf AWS.
- Verwaltung von Konten in den Teams. Es gibt immer noch einige Probleme zwischen unserem und dem Kundenbereich.
Prozess
Unser Team, das sich auf Qualitätssicherung im Gesundheitswesen spezialisiert, verwendet gängige Ansätze, um ein Gleichgewicht zwischen manuellen und automatisierten Tests zu finden. Wir haben eine Vorstellung davon, wie klassisches CI/CD aussehen sollte. Einige Änderungen wurden während der Implementierung der Lösungen vorgenommen.
Mit der Zeit haben wir die Version des Frameworks aktualisiert und Berichte verbessert, z.B. erforderliche Daten zu Release-Versionen hinzugefügt. In einigen Fällen hat das Elinext-Team unsere Algorithmen zur Produktverifizierung verbessert.
Für die Tests verwenden wir separate Testumgebungen. In einigen Fällen umfasst dies dedizierte Automatisierungstests, manuelle Tests, Sicherheitstests usw. Es ist erwähnenswert, dass wir ausschließlich Testbenutzer verwenden und keine echten Kundendaten verarbeiten.
Was die Kommunikation betrifft, haben wir tägliche Stand-up-Meetings, E-Mails und Chats in Teams sowie Retro- und Demo-Sessions. Unsere erfahrenen Ingenieure und Projektmanager würden die Zusammenarbeit als „eher eng“ beschreiben.
Der übliche Prozess für das Testen neuer Funktionen sieht folgendermaßen aus:
Stufe 1: Neue Epics und Stories auf der Entwicklerseite. Die Entwickler beginnen mit der Implementierung der Funktionalität neuer Features. Wenn möglich, beginnt das manuelle QA-Team mit der Erstellung von Testfällen für diese Stories, falls nicht, später.
Stufe 2: Alle Testfälle für das neue Feature wurden erstellt. Die Funktionalität ist im Produkt.
Stufe 3: Testfälle können automatisiert werden und kommen in die „Warteschlange für Automatisierung“ (Automation-Team-Backlog).
Stufe 4: Testfälle werden automatisiert. Sie werden im Zephyr-Plugin als automatisiert markiert, um eine manuelle Ausführung zu vermeiden. Testfälle werden in die entsprechenden Suiten aufgenommen und Teil des täglichen CI-Prozesses.
Stufe 5: Überwachung der Ergebnisse des täglichen CI. Bei guten Ergebnissen werden Berichte für den Kunden bereitgestellt. Bei Fehlschlägen werden die Fehler untersucht, Defekte gemeldet oder der Testfall bzw. der Quellcode aktualisiert.
Zunächst wurden alle Aktivitäten von einem dedizierten Automation QA-Team durchgeführt, später wuchs das Team mit manuellen QAs und dann einigen Entwicklern.
Lösung
Wir haben die Lösung basierend auf der Projektfunktionalität und den angestrebten Zielen bereitgestellt.
Im Fall unseres ersten Projekts wussten wir, dass es sich um ein plattformübergreifendes Projekt handelte, das viele Datenquellen und komplexe Migrationsszenarien unterstützte. Ein wichtiger Bestandteil der App war auch die Überprüfung von PDF-Berichten und CSV-Daten.
Ein großer Server wurde gekauft, um alle Umgebungen an einem Ort zu halten. Für bessere Leistung und einen unterstützenden Server wurde das Betriebssystem ESXi installiert, und VMware wurde als Virtualisierungsoperator verwendet. Diese Lösung bietet uns folgende Vorteile:
- Mehrere Betriebssysteme innerhalb der getesteten App wurden für Tests installiert (z. B. Unix-Systeme: RedHat x-Versionen, CentOS x-Versionen und Windows-Systeme).
- Unterstützung für Cluster-Installationen der App, bei denen wir 1 Master- und 1+ Worker-Maschinen haben.
- Unterstützung für die Tests von Datenquellen und -ursprüngen wie Oracle, MSSQL, Postgres, DB2 usw.
- Durch Virtualisierung wurden Migrationsaufwände reduziert, da wir die vorherige Version als Snapshots beibehalten konnten.
- Jenkins mit Automatisierungsjobs ist ebenfalls auf einer der Maschinen des Servers installiert.
Wie oben erwähnt, war die anfängliche Anfrage des Kunden, Protractor als Automatisierungs-Framework zu verwenden. Zu dieser Zeit war es ein leicht verständliches, schnell einsetzbares Framework mit allen erforderlichen Integrationen, wie z. B. Berichtssystemen.
Leider entschied Google nach 2-3 Jahren, die Unterstützung für das Framework einzustellen, und es wurde später eingestellt.
Daher wurde vor der Deprecation eine Untersuchung des besten Automatisierungs-Frameworks durchgeführt, und es wurden die notwendigen Anstrengungen bedacht, um auf ein anderes Framework umzusteigen. Wir entschieden uns, WebdriverIO als neues Test-Framework für die Automatisierung zu verwenden.
Die folgenden Vorteile von WebdriverIO können hervorgehoben werden:
- JS-basiert, einfach von Protractor zu migrieren und gut unterstützt.
- Altes, bekanntes und stabiles Framework, im Gegensatz zu neuen modernen, aber nach fünf Jahren vergessenen Frameworks wie Protractor.
- Unterstützt alle sensiblen Funktionen, die wir während des Testens von PA-Produkten benötigen, wie parallele Ausführung in mehreren Browsern und Integration mit dem Berichtssystem, z. B. Jasmine Runner.
Für Automatisierungszwecke wurde eine Maschine mit Jenkins eingerichtet. Täglich wurden folgende Jobs ausgeführt:
- Bereitstellung einer neuen Version des App-Produkts, mit/ohne Bereinigung der Mongo DB.
- Ausführung von Smoke-Tests mit einem wertvollen Bericht.
- Ausführung von Regressionstests mit einem wertvollen Bericht.
- Verschiedene Utility-Jobs zur Aktualisierung von Docker-Containern (Automatisierungstests werden in Docker ausgeführt), Benachrichtigung über den Erfolg der Ausführung der Testsuite in einem speziellen Slack-Kanal und sogar ein Job für die Ausführung von Automatisierung + ZAP und die Erstellung von ZAP-Berichten.
_
In Bezug auf die Funktionalität des anderen Projekts gibt es einige Unterschiede. Dieses noch junge Projekt, das etwa ein Jahr alt ist, kann nur mit Hilfe von AWS installiert werden, weshalb die Ingenieure von Elinext möglicherweise andere Ansätze für die Tests verwenden müssen. Wir halten die Jenkins-Umgebung im DMZ-Netzwerk (Demilitarized Zone) in AWS.
_
Neben den Tests für diese beiden Hauptprojekte halfen wir auch bei mehreren anderen Nebenprojekten unseres Kunden. Diese Zusammenarbeit im Bereich Qualitätssicherung im Gesundheitswesen wurde jedoch aus verschiedenen Gründen eingestellt.
_
Am häufigsten durchgeführte Tests durch unser Team:
Funktionale Tests: Durchführung von Testzyklen für neue Testfälle zu neuen Funktionalitäten. Regressionstests vor der Veröffentlichung gehören ebenfalls dazu. Migrations-Testfälle zur Unterstützung der Aktualisierung von früheren Versionen auf die aktuellen Versionen. UI-, API-Testfälle usw. Dieser Teil ist hauptsächlich das Aufgabenfeld des manuellen QA-Teams.Das Elinext-Team verwendet Zephyr (Jira-Plugin) als Platzhalter für Testfälle.
Automatisierungstests: Alle Testfälle, die wir aus dem vorherigen Typ automatisieren können, werden Teil dieses Prozesses. Infolgedessen umfasst die tägliche CI-Ausführung der Automatisierung End-to-End-Tests (e2e), API-Tests und Installationsskripte.Das Elinext-Team verwendet Jasmine für API-Tests und WebdriverIO für UI-Tests (im Rahmen von e2e). Wir verwenden JavaScript zum Schreiben der automatisierten Tests.
Sicherheitstests: Verwendung des OWASP ZAP-Tools für Penetrationstests.Wie bereits erwähnt, ist unser Hauptprojekt dasjenige, das es ermöglicht, sensible Daten ohne Angst vor Kompromittierungen zu teilen. Die App kann entweder über die Benutzeroberfläche oder programmgesteuert über die REST-API ausgeführt werden.
Ergebnisse
Die CI-Automatisierung hat seit Beginn der Bereitstellung unserer Services im Bereich des automatisierten Software Testens enorm geholfen. Kritische und katastrophale Fehler wurden vor der offiziellen Veröffentlichung entdeckt. Seitdem das manuelle Team Teil der Zusammenarbeit mit unserem Kunden wurde, hat sich die Qualität der geschriebenen Testfälle und die Stabilität des Endprodukts auf das Niveau erhöht, das wir als hervorragend für Qualitätssicherung im Gesundheitswesen ansehen und das bis heute unterstützt wird. Das Zufriedenheitsniveau des Elinext-Teams zeigt sich am besten durch die Tatsache, dass es sich mittlerweile von 3 Personen auf über 15 in mehreren Projekten ausgeweitet hat. Wir können bestätigen, dass der Kunde unsere Ansätze in den Bereichen AQA, QA und Entwicklung schätzt. Sie halten uns für ausgezeichnet im Bereich QA-Tests im Gesundheitswesen. Was die Kommunikation betrifft, müssen wir ein Gleichgewicht zwischen den Anforderungen des Kunden und den Bereichen, die wir testen möchten, finden. Alles muss mit dem Kunden besprochen und genehmigt werden. Das älteste Projekt, das wir mit dem Kunden haben, befindet sich jetzt hauptsächlich unter unserer Unterstützung, ohne weitere Entwicklungen. Die Veröffentlichungen für diese Lösungen im Bereich Analytik im Gesundheitswesen sind seltener geworden und haben sich von viermal jährlich auf ein oder zwei pro Jahr reduziert. Ein weiteres, jüngeres aktives Projekt hat mehrere Veröffentlichungen pro Jahr (~3-4). Wir schließen nicht aus, unsere Zusammenarbeit weiter auszubauen, da der Kunde an unserem Datenanalyse Unternehmen interessiert ist.
