Ein Angebot von

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

| Autor / Redakteur: Arthur Hicken / Sebastian Gerstl

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)

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?

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.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44950738 / Test & Qualität)