Endress+Hauser betreibt eine weltweit genutzte Website mit integriertem Webshop, der in den letzten Jahren zur zentralen Plattform der „Customer Journey“ ausgebaut wurde. Da hierbei das Kundenerlebnis mitsamt der Kundenzufriedenheit im Mittelpunkt steht, führt Endress+Hauser eine Vielzahl von Modulen und Backends im Webshop zusammen.
Beispiele für diese komplexe Multi-Tier-Architektur sind die personalisierte Anmeldung, die geführte Produktauswahl, ein von vielen Anwendungen gemeinsam genutzter Konfigurator sowie die Integration in die Prozesse des ERP-Systems. Die Komponenten werden zum Teil selbst gehostet als auch in der Cloud bereitgestellt.
Durch entwicklungsbegleitende Last- beziehungsweise Stresstests soll die mehrstufige Architektur auf ihre Belastungsfähigkeit getestet werden. Dafür nutzen wir Micro Focus LoadRunner Enterprise mit dem Tru Client-Protokoll in Kombination mit cloudbasierten Lastgeneratoren.
Durch das gleichzeitige Monitoring der Front- und Backends kann quasi live – also bereits während des Tests – erkannt werden, ob die Anwendung an ihre Belastungsgrenze stößt. Idealerweise wird über die genutzten Dashboards direkt analysiert, wo die Probleme liegen. Dies ist deutlich effektiver, als nach dem Lasttest zu versuchen, die Ursachen zu finden.
Aufgrund der dynamischen und agilen Entwicklung, sowohl auf Frontend- als auch auf Backend-Seite, verfolgen wir den Ansatz einer anpassbaren und Release-unabhängigen Objekterkennung. Gleichzeitig müssen wir die Performanz der an den Webshop angeschlossenen Datenbanken im Blick behalten.
Anspruchsvoll ist, die passenden Zeitpunkte für aussagefähige Tests zu finden, denn erst wenn alle benötigten Testressourcen zur Verfügung stehen und ausreichend Zeit eingeplant wird, lassen sich erfolgreiche Testläufe gestalten. Ein später Gesamt-Lasttest ist, wenn Performanzengpässe aufgedeckt werden, ein extremes Projektrisiko für Budget und Zeitplan. Daher setzen wir auf kleinteilige Komponententests, um dieses Risiko zu minimieren. Zur besseren Planbarkeit splitten wir das Projekt in ein pauschal budgetiertes Vorprojekt und ein dynamisches Hauptbudget für den eigentlichen Testteil. Letzteres wird beantragt, sobald Umfang, Aufwand und Risiko beurteilt sind.
Ebenso wichtig ist die fachbereichsübergreifende Kommunikation zwischen den beteiligten Teams: Unterschiedliche Entwicklungsgeschwindigkeiten erfordern eine präzise Steuerung der Tests. Bedingt durch die heterogene Anwendungslandschaft ergibt sich ein entsprechend hoher Pflegeaufwand für die Testskripte. Dies resultiert nicht zuletzt aus der ständigen Weiterentwicklung der interagierenden Systeme und Komponenten.