Häufig kommt die Frage auf, wie sich Qualitätssicherungsmaßnahmen (z.B. Performance Regression Testing oder Load Testing) im Hinblick auf Performance (z.B. Antwortzeit eines Dienstaufrufs oder den Ressourcenverbrauch von CPU und Speicher) in der agilen Softwareentwicklung berücksichtigen lassen. In dieser Hinsicht bietet die agile Softwareentwicklung gegenüber klassischen Softwareentwicklungsmodellen interessante Chancen. Iterative und inkrementelle Ansätze wie Scrum sehen nämlich eine regelmäßige Neubewertung der Situation vor. Mit den Erkenntnissen kann eine Adaption der bestehenden Planung erfolgen. Dadurch werden notwendige Änderungen in der Priorisierung, im Umfang oder auch in den Anforderungen berücksichtigt. Dieses Vorgehen ist auch unter dem Stichwort “Inspect and Adapt” bekannt. Für unseren Anwendungsfall zur Sicherstellung von Qualität in punkto Performance ergeben sich dadurch entscheidende Vorteile. So lassen sich Performance-Tests regelmäßig ausführen, Performance-Probleme frühzeitig erkennen und durch die Adaption der Planung auch lösen. Wir fokussieren uns bei der Beschreibung dieses Vorgehens auf Scrum als Framework, da es nach wie vor die größte Verbreitung aufweist. 

Aus der Praxis lässt sich berichten, dass die klassischen Gründe, weshalb Performance-Tests in der Qualitätssicherung häufig vernachlässigt werden, auch bei einem agilen Vorgehen weiterhin ihr Dasein pflegen. Hierzu zählen unter anderem, dass:

  • Performance-Tests aus Zeitgründen häufig nicht ausgeführt werden, da neue Funktionalitäten häufig höher priorisiert werden als Qualitätssicherung, sowie
  • Performance-Anforderungen als nicht-funktionale Anforderungen fehlen und geeignete Akzeptanzkriterien nicht abgeleitet werden können.

Empfehlungen

Im ersten Fall muss bei allen Projektbeteiligten ein Bewusstsein für die Wichtigkeit von Qualität im Allgemeinen und Performance im Speziellen geschaffen werden. Dabei ist es zunächst egal wer die Priorisierung durchführt: ein Product Owner in Scrum, Projektleiter oder ein Gremium. Dem jeweiligen Entscheider sollten die möglichen Auswirkungen einer Priorisierung von Funktionalität zu Lasten von Qualität jedoch unmissverständlich klar gemacht werden. Die technischen Schulden, die man sich auf diese Weise aufbaut, gefährden in der Regel eher früher als später den Projekterfolg und erschweren es immer mehr, weitere Funktionalität zu implementieren.

Aber selbst wenn das Bewusstsein geschaffen und der Wille zur Adressierung von Performance vorhanden ist: Oft tun sich – gerade wenig technisch geprägte – Product Owner schwer, diesbezüglich Anforderungen an ihr Produkt zu formulieren. Dies ist das zweite unserer eingangs beschriebenen Probleme. Doch auch wenn konkrete Performance-Anforderungen nicht verfügbar sind kann mit Hilfe von Performance Regression Testing eine grundlegende Qualitätssicherung durchgeführt werden.

Performance Regression Testing

Performance Regression Testing ist wie Load Testing oder auch Smoke Testing eine Art die Performance einer Softwareanwendung durch simulierte Nutzer zu untersuchen. In ihrer einfachsten Form geben Performance Regressionstests eine Rückmeldung darüber, ob sich die Performance der Anwendung aufgrund der vorgenommenen Änderungen verändert hat. Für diesen Erkenntnisgewinn wird in der Regel eine Version mit und eine Version ohne die vorgenommenen Änderungen miteinander verglichen. Eine Performance Regression ist besonders dann unerwünscht, wenn es zu einer unbegründeten Verschlechterung der Performance gekommen ist, wohingegen eine Verbesserung gerne wohlwollend aufgenommen wird.

Integration

Die grundsätzlichen Aktivitäten zur Integration von Performance Regression Testing in der Softwareentwicklung nach Scrum sind:

Formulierung geeigneter nicht-funktionaler Anforderungen durch den Product Owner, aus denen die Akzeptanzkriterien abgeleitet und in der Definition of Done dokumentiert werden können. Dadurch werden Performance Regressionstests regelmäßig durchgeführt (z.B. durch Verankerung in der Definition of Done nach Fertigstellung einer User Story). Ein abgeleitetes Akzeptanzkriterium kann beispielsweise formuliert werden als: “Performance Regessionstests wurden ausgeführt und es wurde keine unbegründete signifikante Verschlechterung der Antwortzeit und des Ressourcenverbrauchs für das Mengengerüst M und die Testumgebung T festgestellt.”

Erstellung geeigneter User Stories für die Erstellung der Performance-Testskripte selbst, Mengengerüste, sowie für das Setup notwendiger Testumgebungen.

Empfehlung aus der Praxis: Einsatz eines Application Performance Management Werkzeuges zur Aufzeichnung von aussagekräftigen Daten, welche für eine anschließende Analyse der Ursache verwendet werden können, sobald eine signifikante Regression erkannt wurde. Hierzu können kommerzielle Werkzeuge bekannter Hersteller wie AppDynamics, Dynatrace oder CA Introscope eingesetzt werden aber auch freie Werkzeuge wie inspectIT.

Bei der Durchführung von Performance Regression Testing muss die Vergleichbarkeit zwischen zwei Testläufen gegeben sein. Dadurch sollte zwischen zwei Testläufen sich der Ausgangszustand der Testumgebung nur in der verwendeten Version der zu testenden Anwendung unterscheiden.

Alternative

Alternativ kann auch Canary Testing zum Regression Testing eingesetzt werden. Hierbei wird die neue Version auf einen Teil der Infrastruktur ausgerollt (Canary Release). Ein Bruchteil der Nutzer wird dann auf die neue Version geleitet. Dadurch kann die vorherige und die neue Version miteinander verglichen werden.

Ausblick

Performance Regression Testing kann zu großen Teilen automatisiert werden. Der nächste Artikel zum Thema wird auf die Automatisierung und technische Umsetzung anhand eines konkreten Beispiels eingehen und eine Übersicht über die verwendeten Werkzeuge geben.

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close