Test-Chaos vermeiden mit der Deploy-and-Destroy-Strategie

Autor / Redakteur: Arthur Hicken / Sebastian Gerstl

Software ist oft die primäre Schnittstelle zwischen Unternehmen und ihren Kunden. Einbußen in der Qualität zugunsten der Durchlaufzeit sind hier keine Option. Wie ist also hohe Qualität zu garantieren?

Firma zum Thema

Eine der Möglichkeiten, wie Container zur Umsetzung einer Deploy & Destroy Strategie genutzt werden können.
Eine der Möglichkeiten, wie Container zur Umsetzung einer Deploy & Destroy Strategie genutzt werden können.
(Bild: Parasoft)

Auf die in der Einleitung gestellte Frage gibt es leider keine einfache Antwort: Wie können Entwickler und Tester, angesichts enormem Zeitdruck und dem Anspruch, mehr und immer innovativere Software immer schneller zu produzieren, hohe Qualität abliefern?

Als eine wesentliche Voraussetzung allerdings kann der ungehinderte Zugang zu realistischen Testumgebungen (z.B. die Anwendung und ihre abhängigen Komponenten unter Test) angesehen werden. Fehlt dieser, lassen sich die Änderungen und deren Auswirkungen nicht gründlich auswerten, und man kann nicht sichergehen, dass die daraus entstehende Anwendung die Benutzererfahrung verbessert. Der Zugang zu vollständigen Testumgebungen verhilft nicht nur zu einer höheren Durchsatzgeschwindigkeit. Sondern er ermöglicht auch das Einschätzen des Risikos eines Freistellungskandidaten während des CI/ CD (Continous Integration / COntinuous Delivery) und somit Kandidaten mit einem hohen Risiko bereits früh in der Lieferkette zu identifizieren.

Aber in modernen komplexen Systemen ist der Zugang zu vollständigen Testumgebungen eher die Ausnahme als die Regel. Eine Möglichkeit, um eine 100% realistische Testumgebung zu erstellen, ist das Testen in der Produktionsumgebung, was meist aus mehreren Gründen nur ungern gesehen wird. Einer Parasoft Umfrage zufolge war es nur 12% von insgesamt 316 Befragten erlaubt, in der Produktionsumgebung zu testen.

Obwohl es für Testabteilungen früher normal war, eine komplette physische Testumgebung einzurichten, verbietet sich diese Möglichkeit heute aus Kostengründen und aufgrund der Komplexität moderner Anwendungen. Dies belegt folgende Statistik:

  • Die Durchschnittszeit zur Bereitstellung einer Testumgebung beträgt 18 Tage [1]
  • Die Zeit, die Testumgebung zu konfigurieren beträgt weitere 12 bis 14 Tage [1]
  • Die Durchschnittskosten für ein Pre-Production Lab belaufen sich auf ca. 12 Millionen Dollar [2]
  • 79 % aller Teams sahen sich mit Einschränkungen durch Dritte, Zeitbeschränkungen oder Gebühren beim Versuch konfrontiert, Zugang zu den für die Tests notwendigen abhängigen Systeme zu erhalten [3]
  • Teams benötigen im Schnitt Zugang zu 52 abhängigen Anwendungen oder Systemen, um vollständige Tests durchführen zu können, wobei die meisten nur Zugang zu 23 oder weniger haben.

Unter diesen Umständen überrascht es nicht, dass 81% der Entwicklerteams und 84% der Qualitätsprüfer Verzögerungen als Folge des eingeschränkten Zugangs zu Testumgebungen erleben.

Die moderne Technologie ermöglicht die Bereitstellung realistischer simulierter Testumgebungen auf Bedarf. Dank der Verfügbarkeit von Technologien wie z.B. Cloud (für flexible Skalierbarkeit), Container (für schnellen Einsatz) und Service-/ Anwendungs-Virtualisierung (für das Simulieren und den Zugriff auf abhängige Systeme) besteht kein Grund mehr, warum eine realistische Testumgebung nicht verfügbar sein sollte. Hier setzt die „Deploy and Destroy“ Strategie an.

Was versteht man unter „Deploy and Destroy“?

Im Wesentlichen handelt es sich hierbei um die Fähigkeit, eine vollständige Testumgebung in weniger als 10 Minuten bereitzustellen (to deploy). Die meisten abhängigen Komponenten (wie APIs, Services von Dritten, Datenbanken, Anwendungen oder andere Endpunkte), die zu einem bestimmten Zeitpunkt verfügbar sein müssen, werden in einem zentalen Repositorty zusammengefasst und dann automatisch bereitgestellt. Oft ist der realistischste Satz an Abhängigkeiten eine Kombination aus realen und simulierten Komponenten, der mit Hilfe von Service-Virtualisierung bereitgestellt wird.

Eine Deploy and Destroy Umgebung ist typischerweise leicht und Cloud-kompatibel und daher einfach und nach Bedarf skalierbar. Und sie ist auch leicht wieder zu entsorgen. Sie kann direkt von einem Golden Template generiert, genutzt und anschließend wieder verworfen werden (to destroy). Die Testumgebung und Testdaten lassen sich sofort und ohne zeitlichen Aufwand wieder in ihren ursprünglichen Zustand versetzen. Müssen beispielsweise Fehler reproduziert oder verifiziert werden, ist es möglich, die gleiche Umgebung unmittelbar bei Bedarf zu erstellen.

Technische Umsetzung einer Deploy-and-Destroy-Strategie

Der erste Schritt einer Deploy and Destroy Umgebung ist das Erstellen einer Bibliothek an Service Virtualisierungs Assets. Üblicherweise erfolgt dies durch die Aufnahme des Zusammenspiels einer tatsächlichen Anwendungen, aber auch andere Methoden können zum Einsatz kommen (z.B. durch das Kreieren von Swagger oder anderer Definitionen, durch Traffic Dateien). Falls gewünscht, können diese Assets mit weiteren Daten, Leistungsprofilen oder Response Logik erweitert und verbessert werden.

Ist ein Fundament an virtuellen Assets erstellt, lassen sich diese in einer ‚Umgebung‘ zusammenfassen. Ausgehend von einem Kernsystemplan definiert eine Umgebung, welche Zustände die Abhängigkeiten der Anwendung unter Test (AUT) einnehmen dürfen. Ein Beispiel dafür: Ein 3rd Party Dienst der Umgebung könnte durch 10 verschiedene virtuelle Versionen dieses Assets dargestellt werden, jede mit verschiedenen Kombinationen aus Leistungs- und Datenprofilen, als auch der realen Version dieses Services. Umgebungen mit den verschieden Kombinationen aus Abhängigkeitskonfigurationen lassen sich dann auf Abruf bereitstellen (z.B. eine virtuelle API, die eine Netzwerküberlastung simuliert, mit Fehlerrückmeldungen und einer realen Datenbank und einem virtuellen Mainframe, der positive Rückmeldung liefert).

Um den Bereitstellungsprozess zu verfeinern und zu beschleunigen, ist die Verknüpfung der bereitgestellten Umgebungen mit einer Containertechnologie wie. z.B. Docker sinnvoll. Das ermöglicht das Verpacken der Umgebungen und deren Bereitstellung auf laufende Container, wodurch komplette Testumgebungen in Sekundenschnelle zur Verfügung stehen.

Die Wertschöpfung von „Deploy and Destroy“

Eine Deploy and Destroy Strategie bietet Entwicklern und Testteams viele Vorteile:

Frühes und kontinuierliches Testen – Dank unmittelbarem Zugriff und der simultanen Verfügbarkeit von realistischen und flexiblen Testumgebungen können Teams eine ganze Reihe von End-to End Tests ausführen. Sobald ein Anwendungsfall (User Story) vollständig ist, kann mit dem Testen begonnen und eine Vielzahl von User Stories gleichzeitig während des Continuous Testing Prozesses validiert werden, jede in der für die jeweiligen Tests benötigten spezifischen Testumgebung.

Größere Flexibilität - Im Vergleich zu einer realen, physischen Testumgebung erlaubt die Simulation die flexiblere Bereitstellung von Testumgebungen. Mit realen, physischen Testumgebungen ist es schwierig, das Verhalten oder die Leistung von abhängigen Anwendungen zu beeinflussen, beispielsweise von Mainframes oder ERPs. Denn dies erfordert üblicherweise eine zeitintensive Konfiguration der Hardware, die Verteilung von Speicherkapazitäten, das Einrichten von VMs, usw., um nur einige Beispiele zu nennen. Beim Einsatz von Simulationstechnologien, wie der Service Virtualisierung, kann dieser Aufwand eingespart werden. Ganz einfach lassen sich Bedingungen herstellen, die in einer Produktions- oder physischen Testumgebung unmöglich zu konfigurieren wären. Das erweitert den Testhorizont enorm und ermöglicht auch das Testen von extremen Fällen wie z.B. Concurrency, Ausfälle, Resiliency, Failover oder Load Balancer Probleme.

Realistischer als die tatsächliche Testumgebung - In vielen Fällen ist eine Deploy and Destroy Umgebung realistischer als reale, physisch eingerichtete Umgebungen, die in der Regel von Hardware-Restriktionen geprägt sind und deren Leistung beschränkt ist. Service Virtualisierung verleiht Testern bessere Kontrolle darüber, wie die abhängigen Systeme und Anwendungen reagieren. Rückmeldezeiten wie in einer Produktionsumgebung sind erzielbar, was die Wiedergabetreue der Testumgebungen erhöht.

Mithilfe der Service Virtualisierung lassen sich Fehler und Ausfälle in realen Testumgebung kompensieren, beispielsweise wenn Tests ausgeführt werden müssen, aber die abhängigen Systeme gerade dann nicht verfügbar sind. Eine Deploy and Destroy Umgebung kompensiert dies automatisch, in dem es den Verkehr auf simulierte Endpunkte umleitet und dadurch die Durchführung oder Fortführung der Tests ermöglicht, so als wären die realen Systeme oder Anwendungen verfügbar.

Datensicherheit und Privatsphäre - Durch die simulierte Umgebung wird der Zugriff auf Datensätze gewährt, die bereits gesäubert, bzw. verdeckt sind, daher spielen Sicherheitsbedenken keine Rolle. Selbst wenn sich jemand unbefugt Zugang verschafft, oder ein Asset angreift, gibt es keine Grund zur Befürchtung, da es nicht real ist und unmittelbar nach dem Test wieder zerstört wird.

Konsistenz und Genauigkeit - Deploy and Destroy stellt sicher, daß alle Beteiligten übereinstimmend ihre Aktivitäten durch Zugriff auf die neuesten Testobjekte / Daten und virtuellen Artefakte koordinieren können. Jedes Mal bei der Bereitstellung einer neuen Testumgebung wird diese über den Zugriff auf den Masterdatensatz, die virtuellen Assets und Testobjekte in der Repository von grundauf neu kreiert. So lässt sich verhindern, dass Tests in „verunreinigten“ Umgebungen ausgeführt werden, und veraltete Daten oder nicht autorisierte Versionen von virtuellen Assets zum Einsatz kommen.

Die Implementierung einer Deploy and Destroy-Strategie wirkt sich schnell auf die Geschäfte von Entwicklungs- und Testunternehmen aus. Kosten und Wartezeiten durch den Zugriff auf abhängige Systeme oder Datenbanken können reduziert bzw. eliminiert werden. Das Risiko für Release-Kandidaten wird minimiert, agile und iterative Entwicklungsmethoden werden effizient unterstützt, und Entwicklungs- bzw. Testzyklen erheblich verkürzt. In einer Zeit, in der Entwickler Anwendungen immer schneller und fehlerfrei abliefern sollen, spielt die Service-Virtualisierung eine zunehmend wichtige Rolle, um Engpässe während der Testphase zu verringern. Das beschleunigt letztlich die Time to Market und bringt Wettbewerbsvorteile. Somit kann Deploy and Destroy für Unternehmen und Anwendungsanbieter eine Strategie sein, sich von Mitbewerbern zu unterscheiden und dazu beitragen, den eigenen finanziellen Erfolg abzusichern.

Quellenverweise:

[1] voke Research, Market Snapshot Report: Virtual and Cloud-Based Labs

[2] Skytap, Transform Your SDLC with Parallel Development and Testing in Cloud Environment

[3] voke Research, Market Snapshot Report: Service Virtualization

* Arthur Hicken ist Chief Software Evangelist bei Parasoft

(ID:44950738)

Über den Autor

 Arthur Hicken

Arthur Hicken

Parasoft® Deutschland GmbH