Fallstudie zur Testautomatisierung

Einführung

Moderne, digital fortschrittliche Unternehmen und Organisationen benötigen zuverlässige, informative, vertrauenswürdige, wiederverwendbare und optimale automatisierte Tests, um eine maximale Abdeckung der User Journey in Softwareprojekten zu erreichen.

Für viele Unternehmen ist die Entwicklung, Wartung und Abdeckung automatisierter Tests eine Schwachstelle, da die Kosten für eine korrekte Durchführung zu hoch sind.

Immer mehr Unternehmen und Projekte investieren jedoch Ressourcen in die Testautomatisierung über den gesamten Softwareentwicklungszyklus (SDLC) hinweg, da dies die Projektqualität spürbar verbessert.

Große Anwendungen sind praktisch auf eine Testautomatisierung angewiesen. Eine manuelle Durchführung würde eine große Anzahl manueller QS-Experten erfordern, um alle Änderungen und Aktualisierungen zu testen und zu verifizieren, was die Kosten in die Höhe treibt.

Die Vorabinvestition in ein robustes automatisiertes Testsystem bedeutet, dass Softwareentwicklungsteams und andere Beteiligte sich auf die Qualität und Zuverlässigkeit strategisch wichtiger Anwendungen verlassen können.

Und obwohl dies im Vergleich zum Einsatz manueller QS-Ingenieure die Kosten in die Höhe treibt, spart es auf lange Sicht Geld – sowohl bei den Tests als auch potenziell durch weniger zuverlässige, qualitativ minderwertige Softwaresysteme.

Warum K&C?

Die Softwareentwickler und QS-Ingenieure von K&C sind hochqualifizierte und ausgereifte Fachleute, die in der Lage sind, Lücken, Einschränkungen und Möglichkeiten viel schneller als andere zu erkennen.

Zu den K&C-Teams gehören Full-Stack-Ingenieure, die in der Lage sind, eine breite Palette von Anwendungstypen zu entwickeln, zu warten und zu testen.

Was hat K&C gemacht?

• Analyse des Geschäftsbedarfs und des Entwicklungsfahrplans

• Kostenanalyse der Entscheidung zwischen der Beibehaltung der bestehenden Lösung und der Bereitstellung einer neuen Lösung, einschließlich der Kosten für Support und Wartung

• Analyse des aktuellen Technologie-Stacks und der Skalierbarkeit

• Analyse und Auswahl gängiger und gut unterstützter Technologien und Tools für den Technologiestack

• Mitteilung der Ergebnisse an Informa und Handlungsempfehlungen der Teamleiter

• Nachdem Informa seine Entscheidungen zu den strategischen Optionen getroffen hatte, die ihm im Zusammenhang mit der Analyse und den Empfehlungen zur Verfügung standen, bereiteten wir die Entwicklungs- und Testpläne vor

• Beginn der Entwicklung und Implementierung

• Iteration der Entwicklung bei gleichzeitiger Pflege, Aktualisierung und Verbesserung des CRM

Hintergrund der Fallstudie

Unser Kunde, Informa, ist das größte Veranstaltungsunternehmen der Welt. Bei dem Projekt, an dem wir mit diesem zusammenarbeiten, handelt es sich um ein skalierbares und modulares White-Label-CMS, das von führenden Online-, Offline- und Hybrid-Konferenzen sowie anderen Veranstaltungen, einschließlich Festivals, genutzt wird.

Die Anwendung wurde ursprünglich vor über 6 Jahren in einer monolithischen Architektur entwickelt. Das ursprüngliche Team bestand aus erfahrenen, qualifizierten Softwareentwicklern, aber die monolithische Architektur war nicht skalierbar und konnte nicht angemessen an die aktuellen und geplanten zukünftigen Anforderungen angepasst werden.

Das ursprüngliche Softwareentwicklungsteam übernahm neben der Entwicklungsverantwortung auch die Rolle der Qualitätssicherung und richtete automatisierte Tests für das monolithische CRM ein.

Da die Funktionen der Anwendung jedoch auf Wunsch des Unternehmens ständig erweitert wurden, traten immer mehr Fehler und andere Probleme auf.

Es wurde die strategische Entscheidung getroffen, ein Softwareentwicklungsteam von K&C hinzuzuziehen, um die Legacy-Anwendung von einer monolithischen zu einer Microservices-basierten Architektur zu migrieren. Zunächst wurden manuelle QS-Ingenieure als eigenständige Funktion in das Team aufgenommen.

Zu einem späteren Zeitpunkt wurde beschlossen, das CRM als SaaS zu entwickeln, das für die verschiedenen Veranstaltungsmarken unter dem Dach von Informa lizenziert werden sollte. Neben den erforderlichen architektonischen Änderungen wurde auch die Entscheidung getroffen, ein umfassendes automatisiertes Testsystem einzuführen.

Ohne dieses System hätten manuelle Regressionen der Anwendung bis zu 2 Wochen gedauert, gefolgt von erneuten Tests und den erforderlichen Korrekturen.

Dies kam für den agilen Entwicklungsansatz des CRM nicht in Frage.

Die Lösung – automatsierte Teytpyramide

Unsere Lösung bestand darin, eine automatisierte Testpyramide mit den folgenden Komponenten zu entwickeln:

• Unit-/Komponententests

• Tests zur Dienstintegration

• API-Tests für Dienste

• Funktionstests für Merkmale

• Nicht-funktionale Tests von Funktionen

• End-to-End-Tests

Die Tests für die Einheiten/Komponenten und die Dienstintegration wurden von den Softwareentwicklern und die übrigen Komponenten von den QS-Automatisierungsingenieuren entwickelt.

Der Technologie Stack

Das in diesem Projekt verwendete Technologiepaket umfasst unter anderem folgende Komponenten:

Programmiersprachen

Java & Typescript

Frameworks

Spring & React.js

Test-Frameworks

Puppeteer, Percy, Junit, Artillery, Lighthouse und Postman

Puppeteer bietet eine High-Level-API zur Steuerung von Google Chrome (oder einem anderen auf dem Chrome DevTools Protocol basierenden Browser), der von Google entwickelt wurde.

Jest ist ein von Meta Platforms (ex-Facebook) entwickeltes Framework.

Beides sind beliebte, gut unterstützte und ständig in Entwicklung befindliche Tools, die von einer Vielzahl von Anwendungen verwendet werden, die eine Browser-Automatisierung erfordern.

Die Wahl dieser Tools und Technologien machte das Projekt zukunftssicher und bedeutete, dass ein großer Pool von Spezialisten zur Verfügung steht, aus dem neue Teammitglieder eingestellt werden konnten, während gleichzeitig ein hohes Maß an Anpassung möglich war.

Herausforderungen

Bei der Einrichtung der E2E-Automatisierung hatten wir mehrere Probleme mit End-to-End-Test-Frameworks, und zwar aus folgenden Gründen:

• Unterstützung und Entwicklung des Frameworks

• die Abhängigkeit der Legacy-Anwendung von lokal und nicht in der Cloud gehosteten Tools

• Beschränkungen des Browser-Protokolls und dessen mangelnde Ausgereiftheit.

Wir mussten unsere Lösung implementieren, ohne die bestehende Anwendung neu zu entwickeln und neue Funktionen hinzuzufügen.

Außerdem waren unseren Möglichkeiten Grenzen gesetzt, z. B. wollte man keine Python-Test-Frameworks in eine Java/Javascript-Codebasis einfügen.

Die Erfolge

• Unser Team besteht aus 2 PO, 3 QS, 16 Entwicklern und es kommen ständig neue hinzu

• Zweiwöchentliche Releases mit nur Smoke-Tests, die manuelles Eingreifen erfordern

• 80% Testabdeckung der Codebasis

• 60% der Hotfixes sind auf Geschäftsanfragen und nicht auf Systemfehler

Das Resultat

Dieser Ansatz hat uns geholfen, die Qualität des Projekts und die Effizienz der laufenden Arbeit zu verbessern, da die Entwickler nicht zusätzlich die Rolle der Qualitätssicherung einnahmen und sich somit ausschließlich auf die Entwicklung konzentrieren konnten, während die Ingenieure der QS-Automatisierung die automatisierten Tests entwickelten, warteten und optimierten.

Das Ergebnis war eine erhebliche Reduzierung der Überstunden, die das Team leisten musste, sowie der Anzahl der Hotfixes und Produktionsprobleme. Außerdem wurde die Anzahl der pro Sprint freizugebenden Funktionen reduziert, während die Qualität dieser Releases stieg, was wiederum mehr Nutzer des CRM anlockte.

Die Entscheidung zwischen Java- und JavaScript-Testframeworks für End-to-End-Tests

Wir hatten die Wahl zwischen Java- und JavaScript-Testframeworks für End-to-End-Tests. Zunächst entschieden wir uns für Selenium+Mocha+Chai als preiswerten und gut unterstützten Stack für die Browser-Testautomatisierung.

Wir verglichen den Stack mit dem Serenity BDD-Framework, das von Haus aus wertvolle Funktionen bietet, die in den Selenium+Mocha+Chai-Stack erst durch Bibliotheken von Drittanbietern oder durch Eigenentwicklung eingeführt werden mussten.  Serenity BDD zeigte auch eine bessere Leistung und wir dachten, wir hätten unseren Test-Stack.

Wir kamen jedoch zu dem Schluss, dass Serenity die beste Option für unseren Kontext war, da wir BDD nicht einsetzen wollten, und kehrten zum Zeichenbrett zurück.

Wir haben dann CodeceptJS bewertet, das ein Superset für alle Protokolle als Devtools oder Webtreiber bereitstellt und Typescript von Haus aus unterstützt. Wir kamen jedoch zu dem Schluss, dass es noch nicht die von uns benötigten Funktionen bietet, die wir selbst entwickeln müssten. Außerdem bietet das Tool nur begrenzten Support.

Schließlich entschieden wir uns für die gleiche Kombination aus Puppeteer + Jest + Java/Typescript, die wir in anderen Tests verwendet hatten. Dies führte zu einer klareren und konsistenteren Testreihe, die in Entwicklung und Wartung denselben technischen Stack erfordert.

Was Informa gesagt hat

„Ohne das Umdenken des K&C-Teams in Bezug auf die Projektarchitektur und die Testautomatisierung in den verschiedenen Phasen des SDLC wäre das Projekt möglicherweise an eine Grenze gestoßen, da die Entwicklung einer neuen Funktion bis zur Freigabe x2-x3 Zeit in Anspruch nehmen kann.“

„Ursprünglich hatte unser CRM nur einen Mandanten und jetzt haben wir 11 Mandanten mit einzigartigen Stilen und Funktionen, wobei die Zahl vierteljährlich weiter wächst!„