Apps sollen vor allem schnell produziert werden und in der Entwicklung wenig kosten. Das Kostendiktat steht dabei im Gegensatz zu den hohen Qualitätsvorgaben - denn der Erfolg von App-basierten Marketingaktionen und Geschäftsmodellen hängt nicht zuletzt vom reibungslosen Funktionieren der Software ab. Eine auf Anhieb flüssige Performance ist daher Minimalanforderung für mobile Anwendungen.

Dies sicherzustellen, ist eine komplexe Aufgabe angesichts der Heterogenität der Endgeräte und Betriebssysteme mit ihren unterschiedlichen Versionen. Hinzu kommen Schwankungen in den verfügbaren Datenraten - jeweils in Abhängigkeit von regionalen Netzqualitäten, Zugriffen und Tageszeiten.

Es empfiehlt sich, die hohen Leistungs- und Qualitätserwartungen für Apps mit umfassenden Last- und Performance-Tests abzusichern. Dabei verdienen sechs wesentliche Bestandteile besondere Berücksichtigung:

Methodik: Agile - frühes Testen mit hoher Frequenz

Silodenken aufgeben: Tester sollten sich kontinuierlich im Team abstimmen und verständlich aufbereite Resultate mit den Entwickeln teilen

Für eine hohe Prozesseffizienz müssen App-Entwickler und -Tester ihre Zusammenarbeit enger aufeinander abstimmen als früher. Qualitätsmanagement ist nicht mehr nur retrospektiv, sondern begleitet "live" die Entstehung neuer Software. Die Performance-Prüfung sollten daher schon im Vorhinein eng mit Entwicklern koordiniert werden.

Fachübergreifende Interaktion: Performance-Prüfung in einem Tool konsolidieren.

"Agile" steht für interaktive Problemlösungen jenseits von Bereichsdenken. Damit Teammitglieder mit ihrer jeweiligen Expertise Hand in Hand bei Prüfroutinen zusammenwirken, sollten Test-Tools kollaborativ genutzt werden. Die Option, Elemente wie virtuelle Benutzer, Überwachungskonfigurationen, Lastprofile und Testergebnisse mit Teammitgliedern zu teilen, unterstützt diese Arbeitsweise. Grafische Nutzeroberflächen für eine intuitive Definition auch von komplexen Szenarien und die Wiederverwendbarkeit grundlegender Skripte (z.B. An- und Abmeldevorgänge) helfen "Performance-Laien" (z.B. Entwicklern) sich in die Qualitätssicherung einzubringen.

Lasthärte nachweisen: Leistungs-SLAs in den "Definition of Done"-Listen hinterlegen

Agile-Teams widmen der Performance-Optimierung häufig zu wenig Aufmerksamkeit. User Stories werden dann typischerweise aus funktionaler Perspektive geschrieben, z. B: "Als Benutzer kann ich auf die Schaltfläche 'Warenkorb anzeigen' klicken und die Seite 'Mein Warenkorb' anzeigen." Vollständig wäre die User Story allerdings erst, wenn sie auch messbare Performance-Anforderungen spezifiziert, z. B: "Als Benutzer kann ich auf die Schaltfläche 'Warenkorb anzeigen' klicken und die Seite 'Mein Warenkorb' in weniger als einer Sekunde anzeigen, während bis zu 1.000 andere Benutzer gerade dasselbe tun." Ähnlich wie Funktionstests sind Leistungschecks ein verbindlicher Punkt in der "Definition of Done"-Agenda. Eine Story- und Code-Modifikation sollte erst als "erledigt" gelten, wenn sie die SLA-Vorgaben erfüllt, z. B: "Jede Webpage muss mit allen Funktionserweiterungen auch weiterhin in weniger als einer Sekunde geladen sein."

CI-Integration: Testläufe automatisieren, um Produktionsprozesse möglichst wenig zu belasten

Kontinuierliche Integration (CI) und der direkte Übergang zwischen Agile-Entwicklung und Betrieb (DevOps) verlangen einen intensiven Austausch zwischen Produktion und Qualitätskontrolle. Prüfroutinen (Performance-, Rauch- und Regressionstests) sollten daher für jeden Entwicklungsschritt hinterlegt, automatisiert und am besten direkt mit dem Build-Server integriert werden. Eine vollständige Testeinbettung sieht vor, dass die Ergebnisse sofort im Build-Tool angezeigt und mit den aktuellen Entwicklungsleistungen bzw. Build-Operationen korreliert werden. Auf diese Weise werden Ursachen für Performance-Schwächen leicht eingegrenzt und zügig beseitigt.

Schnell-Tests: Prüfroutinen an die unterschiedlichen Build-Größen anpassen

CI-Builds, nächtliche Builds und zum Sprint-Abschluss erstellte Builds unterscheiden sich deutlich in ihrem Umfang. Daher sollten Lasttests an Art und Größe des ausgeführten Builds angepasst werden. Generell hat es sich bewährt, im kleinen Rahmen zu beginnen.

Bei CI-Builds sollten Tests umgehend nach der Übergabe einer Änderung ausgeführt werden, damit der Entwickler direkt die Auswirkungen auf das System erkennt. Dazu eignen sich am besten begrenzte Performance- und Rauch-Tests, die die am weitesten verbreiteten Szenarien abdecken, wobei die Last üblicherweise von internen Lastgeneratoren (On-Premise-Servern) erzeugt wird.

Bei nächtlichen Builds sollten bereits Ausnahmefälle simuliert werden, um Performance-Probleme zu ermitteln, die bei CI-Tests unentdeckt blieben. Am Ende des Sprints werden Anwendungen "gestresst", indem das Team Last aus der Cloud maximal skaliert, um Belastungsgrenzen, Fehlerbilder und Erholungszeiten einer Anwendung nach einem Absturz festzustellen.