Agile Performance Testing by Alexander Podelko

Als leidenschaftlicher Last- und Performancetester waren meine Erwartungen an den Vortrag von Alexander Podelko groß. Wie Last- und Performancetest in einem agilen Projekt positionieren? Ist ein Last- und Performancetestprojekt nicht selbst ein Entwicklungsprojekt, das es gilt agil abzuwickeln? Wie damit umgehen, dass die Software zu Beginn nur teilweise verfügbar ist? Wie damit umgehen, dass eine möglichst produktionsnahe Testumgebung im agilen Umfeld schwer zu bekommen ist? Fragen über Fragen, auf die ich Antworten erhoffte und großteils auch bekommen habe.

Alexander arbeitet bei Oracle, also eigentlich bei Hyperion, und ist dort laufend in Performancetests der Oracle Business Intelligence Enterprise Edition Plus involviert. In seinem Vortrag demonstriert er seine tiefgehende Erfahrung und sein Wissen im Bereich des Performancetests. (Anmerkung: der Einfachheit spricht Alexander und auch ich hier in der Zusammenfassung von Performancetests in Abkürzung zu Last- und Performancetests)

Nun zu seinem Vortrag: zu Beginn ging Alexander auf die aus seiner Sicht notwendigen Grundlagen ein:

• Ein Performancetest ist ein Entwicklungsprojekt, Record & Replay reicht gerade im Lasttestumfeld nicht aus, Korrelation, Parametrisierung, Verifikation des Testskripts sind Entwicklungsaufgaben, die tiefgehendes Wissen zu dem zu testenden Protokoll erfordern
• Performancetests sind iterativ, die Anzahl der Iterationen ist von vornherein unklar und kann nicht vorhergesagt werden
• warum? Weil meist gefundene Probleme, z. B. ein Bottleneck in einer Suchfunktion weitere Tests verhindern
• hier ist es Alexanders Meinung nach fraglich, ob es Sinn macht, gefundene Performanceprobleme einem normalen Defectlösungszyklus zuzuführen, da es meist schwierig ist, die gesamte Testumgebung 4 Wochen nach Priorisierung und Fix des Defects wieder herzustellen und die Tests zu wiederholen
• Die Stakeholder müssen laufend mit eingebunden werden

All diese Eigenschaften eines Performancetests entsprechen denen eines eigenständigen agilen Entwicklungsprojektes, was Alexander zu der Schlussfolgerung bringt, dass Performancetestprojekte auch jetzt schon immer agil abgewickelt werden (müssen), auch wenn meist der Projektablauf als Wasserfall dem Management präsentiert wird.

Dies deckt sich auch mit meiner persönlichen Erfahrung, ein wichtiger Unterschied ist aus meiner Sicht jedoch, dass gerade die Planbarkeit eines normalen agilen Projektes besser gegeben ist, als bei einem Performancetestprojekt. Warum? Bei einem agilen Projekt hat man zumindest die fixe Taktung und einen Scope den man schieben kann. Beim Lasttest hat man die vollkommene Unplanbarkeit. Die Software, die Testumgebung, die Testdaten, alles muss gleichzeitig für einen meist kurzen Test verfügbar gemacht werden. Die Abhängigkeiten sind so groß, dass es immer wieder zu Verschiebungen kommt  (kommen muss) auf die der geneigte Performancetester agil reagieren muss.

Das bringt mich zu einem wichtigen Punkt, den Alexander in seinem Vortrag ebenfalls sehr tiefgehend angesprochen hat: Performance Testing zu früh wie möglich. Oft wird dies in agilen Teams nicht gemacht, da der Einwand kommt: geht erst, wenn die Software fertig ist. Alexanders Antwort darauf ist: gerade im agilen Umfeld hat man nach jedem Sprint eine fertige "working software", warum nicht diese zu diesem Zeitpunkt schon einem Performancetest unterziehen. Ich empfehle hier über Alexanders Empfehlung hinausgehend die prototypenhafte Verifikation der Basisarchitekur in Bezug auf Performancetragfähigkeit in der Iteration 0. In einem agilen Team ist also über die gesamte Projektlaufzeit ein Teammitglied notwendig, das "Performance Engineering" betreibt und so früh wie möglich die Performance absichert. Teure Änderungen am Ende des Projektes werden dadurch eingespart.

Damit hat Alexander auch die Frage nach Performancetest im agilen Projekt beantwortet.

Ein Detail, dass ich sehr interessant fand: Alexander machte sich für "Single User Performance Tests" stark. Diese auch automatisiert, also frühzeitig mit Skript, aber eben nur Single User. Warum: in 99,99 % der Fälle ist die Applikation im Multi-Userbetrieb noch langsamer als im Single-Userbetrieb. Wenn nun der Single-User schon langsam ist, kann man hier bereits mit dem iterativen Performance-Engineering beginnen.

Interessant war auch der Ausflug in LoadRunner-Skriptauszüge, die ein falsches Ergebnis als richtig erscheinen ließen, weil auf Programmierarbeit und Skriptqualitätssicherung vergessen wurde.

Insgesamt ein interessanter Vortrag, der versucht hat viele Fragen anzuschneiden.

Referenzen: http://www.alexanderpodelko.com/