Kostenreduzierung durch containerbasierte Testdurchführung

1. Web-App-Testautomatisierung ist ein wesentlicher Faktor für Unternehmen

Wenn Unternehmen sich die Frage stellen, wo sie auf der einen Seite Kosten durch eine Begrenzung der Anzahl der Fat-Client-Lizenzen oder einer Reduzierung der Rollout- und Wartungskosten einsparen können, auf der anderen Seite aber auch sicherstellen müssen, dass bei der Vielzahl an Browsern und Versionen die Anwendungen stabil laufen, dann ist es an der Zeit, sich über eine Web-App-Testautomatisierung Gedanken zu machen. Denn:

• die Bedeutung von Web-Anwendungen ist hoch.
• die Nutzung von Browsern zur Bereitstellung von vielfältigen Anwendungen – im Intra- und Internetumfeld – nimmt täglich zu.
• die Qualitätsansprüche der Nutzer steigen.

Für genau diese Herausforderung gibt es eine Vielzahl von Lösungen auf dem Markt. Jede von ihnen hat ihre eigenen Vorzüge, aber auch Nachteile. Die Kosten sind dabei nur ein Faktor, der in die Entscheidung für oder gegen eine Lösung einfließt.

Eine beispielhafte Option ist die Nutzung einer Cloud-basierten Testplattform wie SAUCELABS. Diese bietet eine Möglichkeit, Software auf realen Geräten und/oder virtuellen Maschinen zu testen – dabei gibt es eine Vielzahl von Konfigurationsoptionen. Neben den Kosten für eine solche Testlösung müssen grundlegende Infrastrukturfragen geklärt werden. Der zu testenden Anwendung müssen Testgeräten zur Verfügung gestellt werden, die sich nicht in der lokalen Anwendungsumgebung befinden, sondern beispielsweise über SSL-Tunnel erreicht werden.

Dieser Lösungsansatz, einen browser- und geräteübergreifenden Test durchzuführen, ist valide, kann allerdings wesentlich einfacher durchgeführt werden.

Um die Problemstellung zu veranschaulichen, nehmen wir folgendes Szenario an: In der Bankenbranche wird eine neue Anwendung erstellt, die ein altes Portal ersetzen soll. Das neue Portal wird, wie das alte, von internen und externen Kunden benutzt. Es ist nicht möglich vorzugeben, welche Browser zum Einsatz kommen. Das Frontend wird mit Angular 8, TypeScript, und NodeJS entwickelt, während das Backend mit Java Microservices und Schnittstellen zu anderen Technologien entwickelt wird. Zusätzlich werden zwei mobile Apps entwickelt, die eine für Android und den Google Play Store, die andere für iOS und den App Store. Beide dienen als Wrapper für die gleiche Webseite, speichern aber Daten über Sessions hinweg für mehr Benutzerfreundlichkeit.

Die Bedeutung dieser Software für die Endkunden macht es notwendig, dass die Anwendung sehr gut getestet wird. Im schlimmsten Fall können Fehler zur Folge haben, dass die Bank oder ihre Kunden Geld verlieren. Es wurde bereits entschieden, dass keine Tests auf Geräten ausgeführt werden dürfen, die sich außerhalb der Firewall der Entwicklungslandschaft befinden. Die Kosten müssen so niedrig wie möglich gehalten werden. Dem Szenario und den Entscheidungen folgend ergeben sich drei Möglichkeiten:

1. manuelles Testen mit echter Hardware,
2. automatisiertes Testen mit virtuellen Maschinen oder
3. Container-basiertes Testen.

2. Virtuelle Maschinen vs. Container

Bevor der Soll-Zustand dieses Szenarios definiert wird, müssen wir verstehen, was Container sind und wie sie all dies vereinfachen werden. Sie sind mit der bekannteren Technologie der virtuellen Maschinen vergleichbar. Virtuelle Maschinen (oft auch VMs genannt) sind vor allem als Betriebssysteme bekannt, die in einem Programm auf einem Hostbetriebssystem laufen. VirtualBox von Oracle und VMware sind Beispiele für diese Art von Software. Sie ermöglichen es Videospielern, Windows XP für ältere Spiele auf ihrer Windows 10 Installation laufen zu lassen und erlauben es Entwickelnden für spezielle Anforderungen Linux auf Windows laufen zu lassen. Für Unternehmen bietet es eine Möglichkeit, ein Stück Hardware zu verwenden, um verschiedene Serverinstanzen für Software- und Rollenspezialisierung abzubilden. Dies sind nur einige Beispiele für den Einsatz von virtuellen Maschinen. Was diese Beispiele gemeinsam haben, ist, dass die VMs separate "Computer" sind, die in einem gemeinsamen Netzwerk mit ihrem Host laufen. Sie teilen sich keine kritische Software auf Betriebssystemebene mit dem Host und bieten eine komplette Umgebung für jede Art von Nutzung, aber benötigen eine größere Menge an Speicherplatz (irgendwo zwischen 5 - 25 oder sogar mehr GB Festplattenplatz) und sind damit schwieriger von einer Festplatte auf eine andere zu migrieren.

Container hingegen sind leichtgewichtig, werden für quasi jede Aufgabe verwendet und können jede Art von Software enthalten. Sie teilen sich aber wichtige Betriebssystemdateien mit dem Host. Software für die Verwendung von Containern gibt es beispielsweise von Docker, AWS und Google, um nur einige zu nennen. Diese Software ermöglicht es IT-Experten, ein Image der benötigten Software für ein System zu erstellen und dieses Image dann mit Kolleginnen und Kollegen zu teilen. Aus diesen Images werden Container erstellt, die für ihre Aufgabe verwendet und dann heruntergefahren werden. Ihre Größe reicht von ein paar KB bis zu ein paar hundert MB.

3. Containerbasiertes Testen mit Selenoid und Docker

Selenoid ist ein Open-Source-Projekt, das die lokale und parallele Ausführung von Selenium-Tests ermöglicht. Mit Selenoid können Tests in jedem Browser und jeder Version ausgeführt werden, für die ein Image erstellt wurde. Opera, Chrome, Firefox und weitere stehen zur Verfügung. Microsoft-Browser stellen eine Schwierigkeit dar, da Docker auf Linux basiert, aber sie können dennoch ausgeführt werden. Da Docker-Container verwendet werden, muss weder ein lokaler Rechner als VM erstellt werden, auf dem der spezifische Browser läuft, noch muss er im Testnetzwerk vorhanden sein. Das benötigte Image wird bei Bedarf heruntergeladen und ausgelagert. Das ist Einfachheit auf höchstem Niveau. Es ersetzt die Notwendigkeit, komplexe Selenium-Grid-Netzwerke aufzubauen oder Cloud-basierte Selenium-Grid-Netzwerke zu verwenden. Auch versehentliche Browser-Upgrades sind ausgeschlossen. Da es Open Source ist, fallen keine Lizenzkosten für das Unternehmen an und da Selenoid auf Linux läuft, fallen auch keine Lizenzkosten für das Betriebssystem auf dem Rechner an, auf dem die Tests laufen.

Die Tests selbst sind immer noch Selenium-Tests, die höchstwahrscheinlich ohnehin erstellt worden wären. Selenium bietet die Möglichkeit, verhaltensbasierte Tests in Programmiersprachen wie Java, TypeScript/JavaScript (mit Codecept.js), C#, Perl, Python, Ruby und vielen anderen durchzuführen. Die Tests können mithilfe der Gherkin-Syntax weiter in von Menschen geschriebene Texte abstrahiert werden, sodass die Autoren der Tests keine Programmierkenntnisse haben müssen, sondern sich stattdessen auf ein paar Programmierer verlassen können, die abstrakte Testschritte zur Verwendung an beliebiger Stelle in der Anwendung erstellen.

4. Beispiel-Szenario mit Selenoid

Kommen wir auf das Szenario vom Anfang zurück. Ein Unternehmen möchte seine Software intern testen, ohne dass auf externe Dienste zugegriffen wird. Dabei spielen die Kosten eine Rolle. Der folgende Plan wird ausgeführt.

• Entwickelnde werden weiterhin Unit-Tests für alle Teile der Anwendung schreiben (Microservices, Frontend, Schnittstellen, etc.) Diese Unit-Tests werden als Teil des CI/CD-Prozesses ausgeführt.
• Es wird ein Testinfrastruktur Team eingerichtet. Dieses Team ist für die Erstellung der Testumgebung verantwortlich und hat die folgenden Aufgaben:

  • Selenoid zu implementieren und zu konfigurieren
  • Den Server, auf dem Selenoid läuft, zu pflegen
  • Mit der Infrastrukturabteilung zu kommunizieren
  • Die Testenden zu unterstützen und zu schulen

Sie sind nicht für die Geschäftslogik oder für die Implementierung der Tests verantwortlich.

• Testentwickelnde sind für das Schreiben des Codes verantwortlich, der die Schritte im Browser durchführt. Jede Funktion, die diese Entwickelnden erstellen, wird so geschrieben, dass sie auf der gesamten zu testenden Website funktioniert. Wenn es nötig ist, werden sie die Entwickelnden informieren, dass bestimmte Änderungen auf der Webseite vorgenommen werden müssen, um solche allgemeinen Funktionen zu ermöglichen (z.B. ein Attribut hinzufügen oder melden, dass die Benutzeroberfläche nicht konsistent implementiert wurde). Sie unterstützen die Testautorinnen und -autoren bei Bedarf bei der Nutzung der vorhandenen Funktionen oder durch Schulungen.
• Testautorinnen und -autoren verwenden Gherkin (Cucumber), um Tests zu schreiben, die über die UI ausgeführt werden. Dies hat den Vorteil, dass sich diejenigen, die die Tests schreiben, auf die Geschäftslogik und die Benutzeroberfläche konzentrieren und nicht auf die Implementierung von Code. Diese Testdokumente dienen auch als lebendige Dokumentation der Fähigkeiten und des Verhaltens der Anwendung.
• Manuelle Tests werden auf ein absolutes Minimum beschränkt. Manuelle Tests sind zwar spezifiziert und können zu einem späteren Zeitpunkt wiederverwendet werden, können aber nicht für Regressionstests verwendet werden. Darüber hinaus sind diese Tests teuer, da sie von einer Person in Echtzeit durchgeführt werden müssen.

Manuelle Tests können bei der Entwicklung in einem agilen Team dazu verwendet werden, die für eine Definition of Done erforderlichen Prüfungen durchzuführen. Sobald das Entwicklungsticket geschlossen ist, werden neue Tickets für die Entwicklung von automatisierten Tests geschrieben.

• Integrationstests werden unter Verwendung von Industriestandards durchgeführt und sind automatisiert.
• Frontendtests

  • werden mit Selenium unter Verwendung der Codecept.js-Implementierung durchgeführt, weil es die gleiche Sprache wie die primäre UI (TypeScript) ist,
  • werden mit Selenoid in Containern ausgeführt, die auf Linux-Maschinen installiert werden.
  • werden in JIRA beschrieben und nachverfolgt. Es werden PDF-Dateien mit Details zu jedem Testschritt einschließlich Screenshots erstellt und hochgeladen.
  • Die Windows-Browser werden zudem auf einem Windows-Rechner ausgeführt, der offline ist, wenn nichts getestet wird, um die Kosten gering zu halten.
  • Es werden voraussichtlich 5 000 bis 10 000 Tests mit einer vollen Ausführungsdauer von 3 Tagen erstellt. Die Tests sollen parallel laufen und damit wird die tatsächliche Testdauer 5-7 Stunden betragen. Die Ausführung soll jede Nacht zwischen 1:00 und 8:00 Uhr stattfinden.

Die Gründe für die Bevorzugung von Selenoid gegenüber anderen Selenium-Grid-Lösungen, ob inhouse oder Cloud-basiert, sind:

• Durch die Container-basierte Architektur entfällt der Overhead für den Aufbau eines komplexen Netzwerks von Testmaschinen, wodurch die Kosten für diese Maschinen, ob virtuell oder physisch, entfallen. Die Kosten sinken noch weiter, weil auch die Anzahl der nötigen Administratoren geringer ist.
• Die Container-basierte Architektur erhöht die Anzahl der realitätsnahen Testmöglichkeiten, indem sie eine einfache Möglichkeit bietet, die Anzahl der Browser und Versionen, unter denen die Tests ausgeführt werden, zu erhöhen.
• Die Selenoid-Entwickelnden haben ein GUI erstellt, womit es möglich ist, ausgeführte Tests live anzuschauen. Das Testinfrastruktur-Team muss sich nicht allein auf Screenshots in PDF-Dateien verlassen, um mögliche Probleme zu diagnostizieren.
• Selenoid bietet eine Inhouse-Lösung ohne teure Cloud-basierte Abonnements.
• Es gibt keine Notwendigkeit für komplexe Änderungen an der Infrastruktur oder für SSH-Tunnel. Was hinter der Firewall ist, bleibt hinter der Firewall.

5. Fazit

An der Tatsache, dass Softwaretests ein Muss sind, führt kein Weg vorbei. Webbasiertes Testen wird zunehmend komplexer, da die Anzahl der verwendeten Browser steigt und die Anzahl der Versionen, die Unternehmen unterstützen wollen und müssen, stetig wächst. Komplexität, Kosten und Computerleistung dürfen Softwaretests aber nicht behindern. Software wie Selenoid wird umso wichtiger, um den Kostenfaktor für das Testen so gering wie möglich zu halten. Der Satz "Wir müssen testen, aber wir müssen die Anzahl der Tests begrenzen, weil es einfach zu verdammt teuer ist" sollte der Vergangenheit angehören und aus den Sprint-Retrospektiven verschwinden – denn mit Selenoid und Container-basiertem Testen stellen die Kosten kein Hindernis mehr dar.