Agile / DevOps / Projektmanagement / Testautomatisierung

Service Virtualisierung: Keine Macht der Abhängigkeit!

Wenn komplexe Software-Projekte zeitverzögert auf den Markt kommen, liegt es häufig nicht an der Leistung von Mitarbeitern und Mitarbeiterinnen oder an der Organisationsstruktur, sondern an Hürden, die den Softwareentwicklungsprozess behindern. Eine auf dem österreichischen Markt noch wenig verbreitete neue Technik zur Simulation von Systemschnittstellen erfreut sich international bereits seit einigen Jahren großer Beliebtheit. Als wichtige Ergänzung zu Mocking, ermöglicht diese – unter den Namen „Service Virtualisierung“ bekannte – Technik auch in komplexen System-Landschaften – eine über alle Testebenen hinweg – komplett agile Software-Entwicklung.

Keine Macht der Abhängigkeit

 

Agile Software-Entwicklung in komplexen System-Landschaften

Die Nachfrage nach agilen Techniken bei der Organisation von Teams hat sich in den letzten Jahren mindestens verdoppelt.[1] Davon ist Scrum die am häufigsten eingesetzte Methode.[2] Dieser Trend wird mit dem DevOps Ansatz weiter verstärkt, indem die Häufigkeit von Release-Zyklen erhöht wird. Dies ist besonders bei jenen Software-Produkten wichtig, bei denen die Time-To-Market stärker im Vordergrund steht. Wobei Mischformen zwischen klassischen (z.B. Wasserfallmodell) und agilen Methoden ebenfalls zunehmen[3], wie die „Bimodale IT.

Auch Tools für die Software-Erstellung haben sich diesem Trend angepasst und ermöglichen sogar erst die konsequente Umsetzung agiler Methoden in Teams. Im Zuge der wachsenden Verbreitung von IT-Dienstleitungen nahm die Geschwindigkeit beim Entwickeln von Software drastisch zu. Das macht die Automatisierung wiederholter Arbeitsschritte notwendig. „Continuous Delivery“ beugt späteren Integrationsproblemen vor, indem das Produkt mit jedem Build einem automatischen Qualitätscheck unterzogen wird. Bei einer hohen Abdeckung mit automatisierten Testfällen kann „Continuous Deployment“ eingesetzt werden. Dabei werden der Bau einer stabilen Version, Regressionstests und das Deployment auf die Produktivumgebung voll automatisiert abgewickelt.

Die oben erwähnten sozialen und technischen Praktiken der Softwareentwicklung funktionieren sehr gut, solange die Entwicklungsumgebung stabile Testdaten liefert. In Projekten für unsere Kunden und Kundinnen finden wir häufig mangelhafte Testumgebungen vor. Agile Softwareentwicklung braucht eine stabile realitätsnahe Testumgebung um bereits während der Entwicklung testgetriebene Methoden anwenden zu können (wie etwa „Acceptance Test Driven Development“). Folgende technische Faktoren können ein agiles Vorgehen in Bezug auf die Testumgebung blockieren:

  • Wechselseitige Abhängigkeit mehrerer instabiler Systeme
  • Nicht verfügbare externe Systeme
  • Hohe Nutzungskosten und daher für einen Test nicht verfügbar
  • Kein oder unzureichendes Konfigurationsmanagement
  • Aus Datenschutzgründen keine verfügbaren Testdaten
  • Verzögerungen in der Entwicklung von Systemen, zu denen eine Abhängigkeit besteht
  • Parallelisierung der Entwicklung mehrerer Systeme ist aufgrund von Schnittstellen und Abhängigkeiten zueinander nicht möglich
Komplexe Prozessketten, schwieriger Test 1/2

Abb: Komplexe Prozessketten, schwieriger Test 1/2: Die mit Blitzen markierten Applikationen können, aufgrund nicht verfügbarer Systeme oder unvollständiger Testdaten, auf Integrationsebene nicht getestet werden.

Komplexe Prozessketten, schwieriger Test 2/2

Abb: Komplexe Prozessketten, schwieriger Test 2/2: Mit Service Virtualisierung wurden komplexe Abhängigkeiten aufgelöst.

 

Zusätzlich verhindern soziale Faktoren – wie z.B. lange Kommunikationswege – dass Teams ihre Aktivitäten untereinander koordinieren. Ein Fremdsystem kann durch eine Code-Änderung morgen bereits andere Daten liefern als heute. Änderungen kommen häufig ohne Vorwarnung. Instabilitäten können testgetriebene Softwareentwicklung behindern.

 

Stoßen agile Vorgehensmodelle in komplexen IT-Umgebungen an ihre Grenzen?

Es hat häufig den Anschein, doch stellt sich bei genauerer Betrachtung heraus, dass diese Grenzen mit Service Virtualisierung überwindbar sind. In diesem zweiteiligen Blogbeitrag gehe ich genauer darauf ein, wie agile Teams wieder „in Fahrt kommen“.

 

Hohe Qualität durch realitätsnahe Softwareentwicklung

800px-Simulator-flight-compartment

Abb. Flugsimulator

Angehende Piloten und Pilotinnen durchlaufen schon längst Trainings mit Simulatoren. In einem Flugsimulator können normale und ungewöhnliche Manöver trainiert werden. Der Vorteil liegt auf der Hand. Mit dem Training kann noch während der Ausbildungsphase begonnen werden, Trainingseinheiten können unabhängig von verfügbaren realen Flugzeugen durchgeführt werden, Fehler werden verziehen, und Learning by Doing ist möglich. Warum nicht das gleiche Konzept auf die Softwareentwicklung übertragen?

Ein genauso effektives Konzept steht bereits hinter Service Virtualisierung. „Service Virtualisierung“ meint die zentrale, möglichst einfach gehaltene Simulation von Softwarekomponenten in heterogenen Systemlandschaften. (Sie ist nicht, wie der Name vielleicht vermuten ließe, die Virtualisierung von Server-Hardware!) Genauer gesagt, werden nur die Reaktionen der Softwarekomponenten auf Nachrichten simuliert. Dies ermöglicht eine realitätsnahe Softwareentwicklung und in Folge einen End-To-End-Test. Im Gegensatz zu Mocking können intelligentes Verhalten und schreibende Operationen einfach nachgestellt werden. Die Nachrichten-Simulationen sind in den höheren Teststufen wiederverwendbar, eine bedienungsfreundliche GUI wird mitgeliefert, und für die Bedienung genügt ein geringes technisches Wissen.

Die Einführung von Service Virtualisierung senkt Testkosten, erhöht die Team-Produktivität und steigert die Qualität der entwickelten Software.[4]

 

Wenn alles virtualisiert ist, kann doch nichts mehr getestet werden?

Im Gegenteil. Abhängig vom Test-Ziel wird das „System-Under-Test“ bestimmt. Erst durch kontrollierte Testdaten kann nach strengen Kriterien getestet werden um Fehler verlässlich zu identifizieren. Leicht wiederherstellbare Testdaten ermöglichen häufige Testdurchläufe, und sind die Voraussetzung für ein unkompliziertes Debugging.[5]

 

Alle profitieren von Service Virtualisierung

Jede Rolle in einem Unternehmen profitiert von Service Virtualisierung:

 

Funktion Mit Service Virtualisierung Ohne Service Virtualisierung
Team Bereits auf der Integrationsebene kann die volle Funktionalität getestet werden. Im Review-Meeting kann eine Live-Demo präsentiert werden. Erst bei der System-Integration kann die volle Funktionalität getestet werden. Im Review-Meeting können aus Zeitgründen manchmal nur Screenshots oder Videos präsentiert werden.
Development Bessere Zusammenarbeit zwischen Backend und Frontend auf Integrationsebene. Service Virtualisierung unterstützt beim Debugging. Wichtige Komponenten können nur teilweise oder ungetestet implementiert werden.
Kunden / Kundinnen, Abnehmer / Abnehmerinnen, Management Hands-On bereits beim Review möglich. Time-To-Market und Qualität wird nicht eingehalten.
Operation Hands-On bereits beim Review möglich. Fachliches Feedback ist möglich. Mit mangelhafter Software muss Tagesgeschäft abgewickelt werden.
Product Owner Einschätzungen des Fortschrittes durch Hands-On. Einschätzung des Fortschrittes aufgrund Erzählungen.
System-Admin Stellt einmalig Server-Platz für Service Virtualisierung zur Verfügung. Für jedes Teststadium muss Testumgebung neu aufgesetzt werden. Für jeden Nachtest oder Regressionstest sollten die Testdaten zurückgesetzt werden.
Testperson Kann Fehler im „System-Under-Test“ besser identifizieren und früher entdecken. Hoher Stresslevel in letzter Testphase. Keine Zeit für Nachtests.

 

Mehr dazu, wie einzelne Rollen im Unternehmen von Service Virtualisierung profitieren, wird im zweiten Teil dieses Blogartikels zu lesen sein. Weiters werde ich auf typische Problemlösungen eingehen.

 

Service Virtualisierung – der Enabler

Abschließend zu Teil 1 möchte ich den Nutzen nochmals unterstreichen: Service Virtualisierung ist der zeitgemäße „Enabler“ agiler Teams bei der Herstellung von Software in komplexen System-Landschaften. Auftraggeber und Auftraggeberinnen wollen eine schnelle „Time-To-Market“ bei gleichzeitig hoher Produktqualität. Praktiken wie „Continuous Delivery“ unterstützen dabei. Die dafür notwendigen kurzen Iterationen werden durch kontrollierte und automatisierte Qualitätssicherung erreicht. Service Virtualisierung schafft die Voraussetzung dafür, indem Abhängigkeiten zu Systemschnittstellen abgebaut werden.

 

[1] http://www.bernhardschloss.de/blog/?p=3072

[2] http://blogs.forrester.com/diego_lo_giudice/13-10-29-faster_sooner_better_whats_changing_in_agile_development

[3] http://www.silicon.de/41615602/immer-mehr-agiles-projektmanagement/

[4] Kaufman/Hurwitz (2013): Service Virtualization For Dummies. S. 1.

[5] Bucsics (2014): Service Virtualisierung – Bekommen Sie Ihre Testumgebung in den Griff!

Passende Artikel

Kommentare gesperrt.