Agile / DevOps / Projektmanagement / Testautomatisierung

Service Virtualisierung: „Ich sehe was, was du nicht siehst …“

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. Im Blog Keine Macht der Abhängigkeit haben wir Service Virtualisierung bereits als „Enabler“ agiler Teams kennengelernt. Das entstehende Softwareprodukt kann bereits in einem frühen Entwicklungsstadium mit einer realitätsnahen Funktionalität ausgestattet werden, wie sie eigentlich erst nach der Systemintegration verfügbar ist. Der Entwickler und die Entwicklerin profitieren davon für das komponentennahe Debugging. Der Kunde und die Kundin können sich sehr früh ein realistisches Bild vom Produkt machen. Wiederholt auftretende Problemfälle ließen sich dadurch vermeiden. Besonders bei der Herstellung von Software in komplexen System-Landschaften ist Service Virtualisierung eine elegante Lösung und stiftet rasch Nutzen. Auf drei repräsentative Problemlösungen in agilen Projekten will ich nun genauer eingehen.

Titelbild Service Virtualisierung

 

Kostspielige Anschaffung und Pflege einer produktionsnahen Entwicklungsumgebung

Kontinuität im Entwicklungs- und Testbetrieb ist wichtig. Testumgebungen bereiten vielen Kunden und Kundinnen Kopfzerbrechen. Weder Entwicklung, Test noch Betrieb fühlen sich so richtig dafür zuständig. Systeme sind noch nicht entwickelt, nicht verfügbar, instabil, lizenz- oder kostenpflichtig oder liegen gar außerhalb der Organisation. Testdatenprobleme, Wartungs- und Reservierungsfenster, und Ausfälle sind Alltag. Ein reibungsloser Entwicklungs- und Testbetrieb ist fernab der Realität. Das verursacht Frust, Kosten und Stillstand.

Um mit dem anhaltenden Trend der kürzer werdenden Release-Zyklen mithalten zu können, kann in leistungsfähige Testumgebungen investiert und ein Testdatenmanagement eingeführt werden. Eine leistungsfähigere reale Umgebung beinhaltet die Investition in Rechner, Datenbanken, Datenleitungen und Server-Architektur. Diese gestiegene Investition muss durch einen höheren Profit zurückerwirtschaftet werden.[1] Service Virtualisierung ist eine verhältnismäßig preiswerte Möglichkeit agile Praktiken zu leben.[2] Da „nur“ Nachrichten – auf intelligente Weise – simuliert werden, kann auf den Ausbau, bzw. Duplizierung der realen Testumgebung verzichtet werden.

Mittlerweile bieten viele Firmen Tools, bzw. Frameworks zur Service Virtualisierung an. Zu den bekanntesten zählen: CA Lisa, IBM, HP, Tricentis, SmartBear, Parasoft

Viele Faktoren beeinflussen die Anschaffungskosten:

  • Bedienbarkeit
  • Funktionsumfang
  • Bekanntheitsgrad

Diese Tools implizieren bereits eine Art Testdatenmanagement. Manche Teams verbringen 40 bis 60 Prozent ihrer Zeit für Tests mit dem Setup und „Cleaning Out“ von Testdaten.[3] Mit Service Virtualisierung kann auf eine zusätzliche Applikation zur Koordination von Testdaten, mehrere Testumgebungen, Test-Systeme und viel Arbeitszeit zur Instandhaltung, verzichtet werden. ANECON unterstützt gerne bei der Auswahl des richtigen Tools und bei einer nachhaltigen Einführung in ein Team.

Schauen wir die Lösung für ein weiteres typisches Problem in agilen Teams an.

 

Abhängigkeit zu anderen Teams oder Services auflösen

Heutige IT-Landschaften bestehen häufig aus hunderten Systemen. An einzelnen Geschäftsprozessen sind dutzende Applikationen unterschiedlicher Art beteiligt. Oft sind Prozesse und Anwendungsfälle organisationsübergreifend. Diese Komplexität macht ein isoliertes Testen schwierig. Bei manchen Produkten sind mehrere Organisationen beteiligt, Schnittstellen nicht sauber abgestimmt, Datenformate unterschiedlich interpretiert. Hierbei kann man getrost von einem Problem in der Kommunikation sprechen.

Im schlimmsten Fall tritt im Entwicklungsprozess ein Blocker auf. Häufig wird das Team durch eine nicht vermeidbare Abhängigkeit zu einem zweiten Team oder eine Fremdanwendung am Vorankommen gehindert. Schlimmstenfalls muss das Entwicklungsteam teilweise Wochen auf die Instandsetzung warten, wenn eine Fremdanwendung nicht verfügbar ist oder falsche Daten liefert. Werden Systeme in Fremdfirmen bei der Produktentwicklung benötigt, können zusätzliche Kosten für Transaktionen anfallen. Regelmäßige Tests sind für eine effiziente Softwareentwicklung unerlässlich. Umso schwerer wiegen festgesetzte Zeitfenster für eine Testdurchführung, wofür ein Fremdsystem benötigt wird. Nicht selten wird ein Workaround als schnelle Lösung gewählt, und eine Software-Komponente wird ungenügend getestet implementiert. Dadurch können Wartezeiten entstehen, die im Widerspruch zum agilen Konzept stehen. Teams sind so versucht, wieder auf vertraute, traditionelle Vorgehensmodelle zurückzugreifen.

 

Abb: Nicht erfüllbare Storys führen zu einer Abweichung vom Sprint-Ziel.

Abb: Nicht erfüllbare Storys führen zu einer Abweichung vom Sprint-Ziel.

 

In Scrum-Teams können sich zukünftige Blocker wie folgt ankündigen: Durch Abhängigkeiten zu externen Systemen oder durch die Anforderung, unvollständig getestete Features zu implementieren. Aus der Perspektive eines Kunden oder einer Kundin ist ein Feature erst dann fertig entwickelt, wenn die Sichtbarkeit gegeben ist. Oft ist bereits in der Story-Beschreibung absehbar, dass in einem frühen Entwicklungsstadium die volle Funktionalität im Review nicht präsentiert werden kann. Der Kunde oder die Kundin kann somit nur ein bedingtes Okay geben. Diese Story bleibt somit offen.

Wie oben bereits beschrieben, gehören technische Abhängigkeiten von anderen Teams, fremden Anwendungen oder Services in komplexen System-Landschaften zur Normalität. Eine insgesamt kostengünstige Lösung ist die Einführung einer Service Virtualisierung. Sämtliche Schnittstellen zu Fremdanwendungen können mit „Response-Request-Pairs“ simuliert werden. Die Nachrichten-Ausprägungen können in einem zentralen „Repository“ liegen und das Team passt sie auf die eigenen Bedürfnisse flexibel an. Idealerweise hat das agile Team alle Zugriffsrechte auf das Repository – es einzurichten und zu warten.

 

Abb: In komplexen System-Landschaften findet die größte Testaktivität erst bei der System-Integration statt.

Abb: In komplexen System-Landschaften findet die größte Testaktivität erst bei der System-Integration statt.

 

Im konkreten Fall kann ein Feature uneingeschränkt entwickelt werden, während Nachrichten von Fremdsystemen (z.B. SOAP Transaktionen) simuliert werden. Bereits auf der Integrationsebene kann das Feature realitätsnah getestet werden. Die korrekte Interpretation von Schnittstellenbeschreibungen wird ebenfalls nachrangig, denn es liegt ein „lebendes Beispiel“ (eine echte Implementierung der Schnittstelle mit simulierter Businesslogik) vor.

Die Service Virtualisierung wird zum „Enabler“ von Testautomation. Das Testdatenmanagement wird drastisch vereinfacht, (oft sogar beinahe trivial). Für spätere Regressionstests kann das gleiche „Repository“ verwendet werden. In Kombination mit „Continuous Integration“ kann das Team ungestört produktiv arbeiten. Wenn Sie Näheres zu Continuous Integration erfahren möchten, kann ich Ihnen den Blogartikel Continuous Delivery als Verschmelzung von Integration und Testing meines Kollegen Dominik Schildorfer empfehlen.

Natürlich ist ein produktionsnaher Test weiterhin sinnvoll und notwendig. Doch soll dieser auf seine Testziele fokussiert sein – am günstigsten ist es, wenn erst der System-Integrationstest gezielt die Komplexität eines produktionsnahen Systems untersucht. Bei richtig aufgesetzter Service Virtualisierung wurden die meisten funktionalen Fehler bereits im Entwicklungsstadium oder beim Integrationstest gefunden, spätestens aber im Systemtest. Der System-Integrationstest beginnt mit einer stabilen und gut getesteten Ausgangsbasis. Dank Beseitigung der technischen Abhängigkeiten kann bereits im Entwicklungsstadium zum Testen angefangen werden, Fehler früh gefunden und behoben werden, und das agile Team den Zeitplan einhalten.

Ohne Service Virtualisierung werden Hauptfunktionalitäten in komplexen System-Landschaften erst sehr spät auf der System-Integrationsebene getestet. Die Fehlerbehebung muss auf einer frühen Teststufe passieren. Viel Zeit vergeht bis der Nachtest auf der System-Integrationsebene durchgeführt werden kann. Beim nächsten Fehler auf der System-Integrationsebene wiederholt sich dieser Rücksprung. Es kommt zu Verzögerungen in der Time-To-Market und zu Personal-Stehzeiten.[4] Das Projektmanagement steht nun vor einem Dilemma. Gibt es ein Produkt trotz mangelnder Qualität frei und riskiert dadurch einen Imageverlust, oder wird das Budget für die Fehlerbehebung und Nachtests aufgestockt, und spart diese Mehrkosten an anderer Stelle ein? Service Virtualisierung ermöglicht den Testbeginn bereits in der Entwicklungsphase. Damit erfolgt auf der Zeitachse eine Linksverschiebung des Testaufwands in eine frühe Testphase (siehe Graphiken).

 

Abb: Dank Service Virtualisierung kann die Haupt-Testaktivität bereits auf der Integrationsebene stattfinden.

Abb: Dank Service Virtualisierung kann die Haupt-Testaktivität bereits auf der Integrationsebene stattfinden.

 

Wenden wir uns einem dritten typischen Problem in agilen Teams zu.

 

Ergebnisse werden spät sichtbar

Wer kennt nicht Review-Meetings bei denen Zwischenergebnisse mangelhaft präsentiert werden – in Form von Screenshots oder Videodemonstrationen. Gerade in agilen Teams erfüllt das Sichtbarmachen der Arbeit zwei Funktionen: Der Kunde und die Kundin kann Feedback geben, und das Team kann seine Leistung sichtbar machen. Am Markt erhältliche Tools zur Service Virtualisierung unterstützen bereits eine Vielzahl an Technologien:

  • Nachrichtenprotokolle und Formate: HTTP, HTTPS, MQ-Formate, SOAP, REST, JMS, JBoss
  • Datenbank-Anbindungen: JDBC, gängige SQL-Standards
  • Kompatibel zu Produkten von: Cordys, IBM, Microsoft, Oracle, Progress Sonic, SAP, TIBCO.

Entsprechende Tools oder Frameworks unterstützen ein Team dabei, während der Entwicklungsphase eine Simulation der Schnittstellen für den anschließenden Integrationstest zu bauen. Die virtuellen Ausprägungen können bei jedem Testlauf für alle höheren Testebenen weiterverwendet werden. Auf ein gesondertes Testdatenmanagement kann somit verzichtet werden. Das Review kann mit einer realitätsnahmen Demo stattfinden.

 

Die kostenbewusste Lösung

Wie wir anhand der drei Problemfälle gesehen haben, stellen komplexe System-Landschaften agile Teams vor spezielle Herausforderungen. Abhängigkeiten zu anderen Teams oder Services, kostspielige Anschaffung und Pflege einer produktionsnahen Entwicklungsumgebung oder späte Sichtbarkeit der Teamarbeit. Für Problemfälle dieser Art bietet sich Service Virtualisierung als kostenbewusste Lösung an. Zwischenergebnisse helfen beim Debugging und Endergebnisse werden für den Kunden und die Kundin früher sichtbar. Überträgt man das Spiel „Ich sehe was, was du nicht siehst …“ auf die Softwareentwicklung, sieht man Dank Service Virtualisierung entschieden früher die Funktionalität des zu testenden Produkts und einhergehend die Abweichungen von den Abnahmekriterien.

 

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

[2] Kaufman/Hurwitz (2013): Service Virtualization For Dummies. S. 30.

[3] Michelsen/English (2012): Service Virtualization. Reality Is Overrated. S. 83.

[4] Mohr (2016): Alles was Sie über SV wissen müssen.

Passende Artikel

Ein Kommentar

  1. Thomas Ankerl sagt:

    Lesenswerter Artikel 🙂