Softwaretestverfahren im Zusammenhang mit Continuous Deployment

Der Erfolg einer Anwendung wird nicht alleine von der Idee und dem potentiellen Nutzen bestimmt. Sie muss zudem möglichst vollständig, korrekt und anwenderfreundlich sein. Doch wie oft, wann und womit soll die Software getestet werden?

Welche Softwarefehler gibt es?

Programmfehler (auch Bugs genannt) bezeichnen in der Softwareentwicklung ein Fehlverhalten von Computerprogrammen. Sie können beispielsweise anhand von Änderungen an der Software aber auch durch die Integration neuer Hardware entstehen.

Fehlerquellen in der App Entwicklung:

Neben Programmfehlern, die während der Entwicklung der Anwendungen durch unsere Entwickler:innen entstehen können, gibt es auch andere Fehlerquellen, die einen Mehraufwand erfordern können.

Nicht selten starten wir mit der Entwicklung neuer Software, während sich die dazugehörige Hardware ebenfalls noch im Aufbau befindet. Unsere Software wird in diesem Fall während der Entwicklung in einer virtuellen Hardware getestet. Bei der Zusammenführung von Hardware und Software kann es dann zu Problemen kommen, wenn die simulierte Hardware sich anders als die echte Hardware verhält.

Auch die Betriebssysteme von mobilen Endgeräten (z.B. Android und iOS) werden stetig weiterentwickelt. Neuerungen der Fremdsoftware haben somit auch Auswirkungen auf unsere Software. Die darauf basierenden Probleme müssen dann von uns identifiziert und behandelt werden.

Eine weitere Herausforderung stellt das Aneignen neuer Technologien dar. Gerade im Bereich der Softwareentwicklung ist es wichtig, den Status quo regelmäßig in Frage zu stellen und das Wissen in neuen, besseren Technologien aufzubauen. Die Einschätzung des potentiellen Aufwands stellt sich vor allem hier oft schwierig dar. Auch an dieser Stelle kann es zu Fehlern oder Nachjustierungen kommen. Je nach Erfahrungsstand der Entwickler:innen kann die Einarbeitung dann unterschiedlich viel Aufwand erfordern.

Softwaretestverfahren

Um Software zu testen, können verschiedene Verfahren genutzt werden. Die nachfolgende Grafik veranschaulicht die optimale Verteilung unterschiedlicher Testarten zur Prüfung von Software.

Die Basis der Pyramide bilden die Unit-Tests. Sie können vergleichsweise schnell entwickelt werden und geben ein zeitnahes Feedback über die Qualität des Quellcodes. Integrationstests sind aufeinander abgestimmte Einzeltests, welche voneinander abhängige Komponenten miteinander testen. Automatische End-to-End-Tests (kurz: E2E-Tests) bilden die Spitze der Pyramide. Bei diesen automatisierten Tests wird ein reales Anwendungsszenario simuliert. Überprüft werden dabei nicht nur die Funktionen an sich (also definierter Input zu definiertem Output), sondern auch das Verhalten der Software in Kombination zur Hardware. Gerade in Szenarien, in denen die Hardware sich selbst noch in der Entwicklungsphase befindet, bietet die virtuelle Prüfung eine Möglichkeit potentielle Fehlerquellen frühzeitig abzufangen. Da ein automatisierter End-to-End-Test aber möglichst viele Makel aufdecken soll, kann das Schreiben eines einzelnen Tests genauso viel Zeit in Anspruch nehmen wie die neu hinzugefügte Funktion der Anwendung selbst.

Die Kombination von Softwaretestverfahren

Je öfter und feingranularer eine Software getestet wird, umso höher ist die Wahrscheinlichkeit, dass Fehler noch vor der Auslieferung der Software rechtzeitig aufgedeckt werden können. Eine Garantie auf eine absolut fehlerfreie Software kann allerdings nie erteilt werden. Es ist daher gemeinsam mit dem Kunden zu entscheiden, welcher Mittelweg angestrebt werden sollte.

Zu berücksichtigen ist an dieser Stelle, welche Auswirkungen potentielle Fehler haben können. Software wie etwa die von Autonomen Fahrzeugen, die über Leben und Tod entscheiden, erfordern ein sehr viel gründlicheres Testen als z.B. Unterhaltungs- oder Informationsanwendungen. Leistungseinbußen oder Ausfall können aber auch hier unerwünschte Nebeneffekte haben. Um also auch bei diesen Apps die Frustration seitens des Nutzers möglichst gering zu halten, muss auch diese Form der Software getestet werden. Da wir bei den PROJEKTIONISTEN° nach Scrum arbeiten und unsere Aufgaben weitestgehend in App-Features unterteilen, gehen wir wie folgt vor:

Bei der Entwicklung eines neuen Features werden diese von den Entwickler:innen vor dem Zusammenführung in die Hauptsoftware standardmäßig immer getestet. Bei dieser Art des Testens bleibt aber undurchsichtig, wie sich die Integration des neuen Features auf die bestehende ganzheitliche Software verhält. Um dies abzufangen werden, im nächsten Schritt manuelle Integrationstests durchgeführt. Diese Form des Testens wird spätestens bei einem Releasekandidaten durchgeführt. In der Regel testen wir die Software aber bereits vor und auch nach dem Release immer weiter, um den Freiraum für Fehler möglichst gering zu halten.

Etwas mehr Planung erfordert die Ein- und Durchführung von automatischen End-to-End-Tests. Da das Schreiben eines Tests mindestens genauso lange dauern kann wie das Schreiben der Funktion selbst, scheuen daher viele Kunden eine Investition in die vergleichsweise aufwendigen E2E-Tests. Je komplexer und größer die Anwendung allerdings wird, umso schwieriger gestaltet sich im Nachhinein die Fehlersuche. Gerade bei E2E-Tests können beispielsweise automatisch erzeugte Screenshots von Fehlern schnell eine Information darüber liefern in welchem Szenario ein Fehlverhalten vorgelegen hat. Diese Tests können bereits bei der Integration neuer Features ein unerwünschtes Fehlverhalten aufdecken und so auf Nachbesserungen hinweisen. Positiv zu vermerken ist, dass viele unserer Kunden die Relevanz dieses Testverfahrens erkannt haben und diese Investition wagen. Je näher allerdings der angesetzte Release-Termin rückt, desto mehr verdrängt der Zeitdruck aber auch hier die angestrebte Fehlerquote. Wichtig ist deshalb auch, die Entwicklungszeit für die Tests frühzeitig einzuplanen.

Auslieferung der Software

Das agile Vorgehen verfolgt den Anspruch an eine hohe Automatisierung bei der Auslieferung der Software. Um den Auslieferungsprozess von Software verbessern zu können, werden kombinierte Praktiken der kontinuierlichen Integration und Bereitstellung genutzt. Das Rückgrat bildet die CI/CD-Praxis, die im Folgenden genauer vorgestellt wird.

Continuous Integration
Eine App wird i.d.R. von mehreren Entwickler:innen zeitgleich programmiert. Bei der Zusammenführung verschiedener Features kann es daher zu Konflikten kommen. Bevor die verschiedenen Quellcode-Erzeugnisse zusammengeführt werden können, wird daher bei der Continuous Integration automatisch geprüft, an welchen Stellen Probleme bestehen. Der Entwickelnde ist dann in der Verantwortung diese Hindernisse zu beheben bevor er seinen Quellcode zur bestehenden App hinzufügen kann.

Continuous Delivery
Sobald die neuen Features überprüft und in die App integriert werden konnten, sind sie bereit zur Auslieferung. Continuous Delivery beschreibt also den Ansatz, dass der Kunde jederzeit eine aktualisierte, lauffähige Version der Software erhalten kann.

Continuous Deployment
Während die Software beim Continuous Delivery erst nach Freigabe in Produktion geht, geschieht dies beim Continuous Deployment automatisch. Continuous Deployment verfolgt also das Ziel, neue Features und Optimierungen beschleunigt und ohne Ausfallzeiten ausliefern zu können. Voraussetzung dafür ist allerdings, dass die Software lauffähig und frei von Fehlern ist. Eine Möglichkeit um die ständige Auslieferungsbereitschaft zu ermöglichen, ist die ständige Testung der Software.

Fazit

Um das Idealbild der ständigen Auslieferungsbereitschaft der Software zu ermöglichen, ist eine ebenso ständige Testung der Software erforderlich. Die Kombination von regelmäßigen Unit- und Integrationstests ermöglichen eine schrittweise Einarbeitung neuer Features in die Hauptsoftware. Die Freigabe der Software geschieht anschließend manuell. Erst die Integration vollständiger E2E-Tests ermöglichen die Zielvorstellung, dass Features automatisch ins Produktivsystem geladen werden, wenn alle notwendigen Tests erfolgreich durchlaufen wurden.

Die Bereitschaft in eine frühzeitige Investition in umfassendere Softwaretests kann dabei augenscheinlich aufwendig und teuer wirken. Die Erfahrung zeigt jedoch, dass eine vorausschauende Entwicklung am Ende effizienter ist, als das Programmieren auf Sicht.