Wie ein führendes Finanzdienstleistungsunternehmen den Zugriff auf Testumgebungen für Agile skalierte

Der Übergang zu Agil Bei einem führenden Finanzdienstleistungsunternehmen bedeutete dies, dass die Entwicklungsorganisation in viele kleinere funktionsübergreifende Gruppen (Entwickler / Test) umstrukturiert wurde. Ironischerweise führte dieser Versuch, den SDLC zu beschleunigen, tatsächlich zu neuen Verzögerungen. Ein Beispiel: Eine Testumgebung, die einst einem einzelnen Team gewidmet war, musste plötzlich von 9 kleineren Teams gemeinsam genutzt werden. Aufgrund der komplexen Datenkonfiguration konnte die Umgebung jeweils nur von einem Team verwendet werden - die anderen mussten warten.

Da die Testumgebung eine Drittanbieteranwendung enthielt, die 250 US-Dollar pro Instanz kostete, wäre das Erstellen von 9 separaten Instanzen dieser physischen Testumgebung unerschwinglich teuer gewesen. Durch die Servicevirtualisierung konnten sie 9 simulierte Testumgebungen einrichten, die jedem Team sofortigen, flexiblen Zugriff auf das Verhalten dieses Systems ermöglichten – ohne Auswirkungen auf die anderen Teams.

Die Herausforderung: Skalieren des Zugriffs auf eine vollständige Testumgebung einschließlich einer teuren Drittanbieteranwendung

Die Mission dieses Unternehmens ist es, Privatanlegern direkten Zugang zu Anlage- und Maklerdienstleistungen zu bieten. Sie konzentrieren ihre Forschungs- und Entwicklungsanstrengungen darauf, Kunden die Recherche und Auswahl von Wertpapieren zu erleichtern, die ihren finanziellen Zielen entsprechen, sowie die Portfolio-Performance zu überwachen und zu optimieren. Anstatt das Rad neu zu erfinden, nutzen sie eine bewährte Drittanbieteranwendung, um Kernfunktionen nach Industriestandard zu verwalten, z. B. die Durchführung von Marktkäufen und -verkäufen.

Vor dem Übergang zu Agile konnte das für die Handelsfunktionalität zuständige Team seine Entwicklungs- und Testaufgaben in einer gemeinsam genutzten Testumgebung ausführen. Nachdem das Team jedoch in 9 verschiedene Teams aufgeteilt worden war, von denen jedes versuchte, verschiedene Entwicklungs- und Testaufgaben parallel auszuführen, stellte sich der Zugriff auf die Testumgebung schnell als Problem heraus. Da für jede Gruppe die Testumgebung auf eine ganz bestimmte Art und Weise eingerichtet werden musste, führten alle Versuche, gleichzeitig auf diese Testumgebung zuzugreifen, dazu, dass die Gruppen sich gegenseitig auf die Zehen traten - was Zeit verschwendete, die ständig erforderlichen Bedingungen und Daten zu konfigurieren und neu zu konfigurieren erledigen ihre besonderen Aufgaben.

Die Beschränkung des Zugriffs auf die Testumgebung auf jeweils eine Gruppe war nicht gut für das Ziel geeignet, den SDLC durch parallele Entwicklung zu beschleunigen. Es war jedoch nicht möglich, jeder Gruppe eine eigene physische Testumgebung zur Verfügung zu stellen. Da jede Instanz der Drittanbieter-Handelsanwendung 250 US-Dollar kostete, mussten sie 2 Millionen US-Dollar ausgeben, um diese Anwendung in acht zusätzlichen Testumgebungen verfügbar zu machen. Diese Option wurde als unerschwinglich teuer angesehen.

Die Lösung: Simulation des Verhaltens und der Daten der eingeschränkten Abhängigkeit in mehreren Sandboxen ohne Auswirkungen

Das Unternehmen konnte nutzen Parasoft Service Virtualisierung und Parasoft Testumgebungsmanager um das Verhalten und die Daten dieser Drittanbieteranwendung zu simulieren und sie bei Bedarf in 9 unabhängigen Testumgebungen verfügbar zu machen, die jedes Team nach Bedarf konfigurieren und neu konfigurieren kann - ohne Auswirkungen auf die anderen Teams.

Durch die Interaktion des AUT mit der Drittanbieteranwendung konnten sie das Verhalten und die Daten ihrer Kernanwendungsfälle erfassen und in „virtuellen Assets“ verfügbar machen. Parasoft Environment Manager wurde dann verwendet, um eine Master-Testumgebungsvorlage zu entwerfen, die diese virtuellen Assets enthielt. Mit dieser Vorlage können beliebig viele Teams ihre eigene Testumgebung sofort ausstempeln - wobei das virtuelle Asset auf den entsprechenden Status konfiguriert ist und zusätzliche Daten hinzugefügt werden können, um die Testabdeckung zu erhöhen oder die Antwortzeiten nach Bedarf für Leistungstests anzupassen . Auf diese Weise konnte jedes Team sofort auf eine vorkonfigurierte Umgebung zugreifen und diese dann an seine eigenen speziellen Testanforderungen anpassen - ohne die Entwicklungs- / Testaktivitäten anderer Teams zu stören.

Das Ersetzen des eigentlichen Drittanbieter-Systems durch virtuelle Assets brachte zusätzliche Vorteile, die es den Agile-Teams nicht nur ermöglichten, parallel zu entwickeln und zu testen. Zuvor konnten handelsbezogene Transaktionen nur während der Handelszeiten von 9:30 bis 4:6 Uhr Eastern Time getestet werden, wenn ihre Testumgebung eine reale Instanz der Handelsanwendung enthielt. Da die Entwicklungs- und Testteams in Kalifornien ansässig waren, konnten sie nur von 30:1 bis 50:24 Uhr testen, was nur etwa 7% ihres typischen Arbeitstages entspricht. Mit den virtuellen Assets, die für das eigentliche System stehen, können Tests rund um die Uhr durchgeführt werden, sodass das Team nach Belieben Sondierungstests durchführen und diese Transaktionen im Rahmen seines kontinuierlichen Integrationsprozesses ausführen kann.

Ein weiterer Vorteil war, dass die Testausführungszeit erheblich verkürzt wurde. Tests gegen das tatsächliche System dauerten aufgrund einer verzögerten (asynchronen) Antwort des Handelssystems über 20 Minuten. Durch Anpassen der Leistung des virtuellen Assets konnte das Team fast sofort Antworten erhalten, was sowohl automatisierte als auch explorative Tests beschleunigte.