Aber wo wollen Sie all diese Tests durchführen?

In QA-Teams tut sich gerade etwas Spannendes. KI-Agenten und MCP-basierte Tools ermöglichen es Testern, Automatisierungen schneller als je zuvor zu erstellen. Was früher eine Woche Skripting in Anspruch nahm, lässt sich jetzt an einem Nachmittag grob skizzieren. Testabdeckung, die einst unerreichbar schien, ist plötzlich zum Greifen nah. Das ist wirklich aufregend. Und es schafft still und leise ein Problem, über das niemand spricht.

Wenn die Testerstellung schneller wird, dreht sich die Diskussion fast immer nur um die Erstellung selbst: Welches Tool soll verwendet werden? Wie sollen die Testaufforderungen strukturiert werden? Wie erhält man zuverlässige Locators? Die Frage, die dabei nie gestellt wird, ist die, die letztendlich darüber entscheidet, ob das Ganze überhaupt veröffentlicht wird.

Wo genau werden Sie all diese Tests durchführen?

KI kann Hunderte neuer Tests in der Zeit generieren, die früher für das Schreiben von zehn Tests benötigt wurde. Das ist ein echter Vorteil. Doch dieser Vorteil verstärkt auch die zugrundeliegenden Probleme, einschließlich einer Infrastruktur, die nie für diese Last ausgelegt war. Die Teams, die dies gerade feststellen, scheitern nicht an der Automatisierung. Sie sind damit schneller erfolgreich, als ihre Ausführungsebene mithalten kann.

Die Gebäudeautomation ist ein Meilenstein. Sie zuverlässig und in großem Umfang umzusetzen, ist jedoch eine ganz andere Herausforderung.

Das Muster, dem fast jedes Team folgt.

Es fängt meist recht harmlos an. Ein paar Android-Geräte auf dem Schreibtisch. Ein iPhone, das sich zwei Entwickler teilen. Appium-Skripte, die vor der Veröffentlichung auf einem Laptop ausgeführt werden. Es funktioniert. Und eine Zeit lang reicht das auch.

Dann wächst der Umfang. Mehr Gerätemodelle, mehr Betriebssystemversionen, browserübergreifende Testabdeckung, mehrere Teams, die Tests parallel ausführen müssen. Und fast über Nacht verschiebt sich die Einschränkung. Die Frage lautet nicht mehr „Können wir das automatisieren?“, sondern „Haben wir die nötigen Kapazitäten, um das tatsächlich auszuführen?“ Die meisten Teams sind auf diesen Moment nicht vorbereitet, nicht weil sie die Automatisierung nicht vorhergesehen haben, sondern weil sich das Ausführungsproblem unbemerkt einschleicht.

Wie „Maßstab“ tatsächlich aussieht

Ab einem gewissen Punkt ist nicht mehr das Testvolumen selbst das Problem. Es sind die damit verbundenen Herausforderungen: die Gerätefragmentierung, die verschiedenen Betriebssystemkombinationen, die sich ändernden Browserversionen, Teams in verschiedenen Zeitzonen, die gleichzeitig auf denselben Gerätepool zugreifen. Die Anzahl der Tests wächst stetig. Die Infrastruktur war dafür nicht ausgelegt.

Und das, bevor die komplexeren Szenarien überhaupt ins Spiel kommen: Barrierefreiheitsfunktionen, die sich auf realer Hardware anders verhalten, netzbetreiberabhängige Funktionen, die auf einem reinen WLAN-Emulator schlichtweg nicht verfügbar sind, und die Integration von Android Auto oder CarPlay in vernetzte Fahrzeuge, die sich auf einem Desktop-PC nicht simulieren lässt. Das sind keine Sonderfälle. Es sind reale Bestandteile realer Anwendungen, an denen die meisten Ausführungsumgebungen stillschweigend scheitern.

So sieht Ausführungsschuld in der Praxis aus: Das QA-Team hört auf, Tests zu schreiben, und kümmert sich stattdessen um Betriebssystem-Updates, die Behebung von Kapazitätskonflikten und die Bearbeitung von Beschwerden über fehlerhafte Ergebnisse, die sich als Konfigurationsprobleme herausstellen. Automatisierung, die eigentlich Releases beschleunigen sollte, erzeugt letztendlich zusätzlichen Aufwand.

Das eigentliche Problem ist nicht der Besitz von Geräten – sondern die darüberliegende Schicht.

Viele Teams besitzen ihre Geräte bereits, und das ist auch gut so. Die Geräte selbst sind nicht das Problem. Das Problem liegt vielmehr in der gesamten Infrastruktur, die darum herum aufgebaut werden muss: die Orchestrierung, die Integrationen, die Zugriffskontrollen und der zuverlässige Betrieb bei wechselnden Betriebssystemversionen und alternder Hardware. Das ist keine einmalige Einrichtung, sondern eine fortlaufende Aufgabe, für die jemand die Verantwortung übernehmen muss.

Wenn Teams versuchen, diese Managementebene selbst aufzubauen, wird sie unbemerkt zu einem zweiten technischen Produkt ohne Roadmap, ohne festen Verantwortlichen und mit der Angewohnheit, im ungünstigsten Moment auszufallen. Das ist der Preis, den niemand zahlen wollte.

Der Besitz von Geräten ist gut und schön. Die wahren Kosten verbergen sich jedoch im Aufbau einer eigenen Geräteverwaltungsplattform von Grund auf.

Was die richtige Plattform tatsächlich löst

Wenn QA-Verantwortliche mit der Evaluierung von Testplattformen beginnen, dreht sich das Gespräch meist nur um Geräteverfügbarkeit und CI-Integration. Diese Aspekte sind zwar wichtig, bilden aber lediglich die Grundlage. Die entscheidendere Frage ist, ob die Plattform die tatsächlichen Testanforderungen Ihrer Anwendung vollständig abdeckt.

Beginnen wir mit der Bereitstellung. Manche Teams benötigen Geräte bedarfsgerecht und ohne Beschaffungsaufwand – eine Cloud-Lösung ist hierfür ideal. Andere verfügen bereits über ein Gerätelabor und benötigen die passende Softwareebene für den skalierbaren Einsatz; hierfür eignet sich eine On-Premise-Lösung. Die Wahl sollte keinen Kompromiss zwischen Komfort und Kontrolle erfordern. Eine empfehlenswerte Plattform sollte beides unterstützen und in beiden Fällen die gleichen Funktionen bieten.

Groupe BPCEDie zweitgrößte Bankengruppe Frankreichs ging genau diesen Weg. Sie hatte uneinheitliche manuelle Tests an verschiedenen Standorten, keine Nachverfolgbarkeit und ein Team, das eine zentrale Testdurchführung benötigte, ohne dabei auf eigene Geräte verzichten zu müssen. Mit einer On-Premise-Lösung testen sie nun 700 Nutzer auf 102 Geräten und 32 Browserversionen. Die Tests laufen rund um die Uhr alle 5 bis 15 Minuten. Lesen Sie die vollständige Fallstudie.

Doch die Flexibilität bei der Einsatzplanung ist nur der Anfang. Schwieriger zu bewerten – und etwas, wonach die meisten Teams erst fragen, wenn es zu spät ist – ist die Abdeckungstiefe.

Denken Sie an die zuvor genannten Szenarien. Barrierefreiheitsfunktionen, die auf TalkBack oder VoiceOver basieren, müssen auf realen Geräten getestet werden, da nur dort die korrekte Funktion von Bildschirmleseprogrammen gewährleistet ist. Die Leistung unter realen Bedingungen wie CPU-Auslastung, Speichernutzung und Akkuverbrauch zeigt sich nur auf der physischen Hardware. Audioabhängige Funktionen, Mobilfunkanbieter-Funktionen, die eine SIM-Karte voraussetzen, und die Integration von Android Auto oder CarPlay in Fahrzeuge: Dies sind wesentliche Bestandteile realer Apps, die von den meisten Plattformen entweder nicht unterstützt oder als Nischen-Add-ons behandelt werden.

Bei der Evaluierung einer Plattform sollten Sie daher nicht nur die Frage „Kann sie unsere Appium-Tests ausführen?“ berücksichtigen, sondern auch prüfen, ob sie die Szenarien abdeckt, die Ihr Team bisher aufgeschoben hat. Kann sie diese Tests standortübergreifend ausführen, ohne dass Sie regionale Testumgebungen einrichten müssen? Lässt sie sich nahtlos in Ihre CI-Pipeline integrieren, sodass ein zusammengeführter Pull Request Build, Upload, Ausführung und Reporting durchläuft, ohne dass jemand manuell eingreifen muss?

Die Teams, denen das gelingt, reduzieren nicht nur den operativen Aufwand. Sie erreichen eine Abdeckung, die sie zuvor nicht rechtfertigen konnten, nicht weil die Tests zu schwierig zu schreiben waren, sondern weil es keine zuverlässige Umgebung gab, um sie auszuführen.

Die Frage, die es wert ist, jetzt gestellt zu werden

Bevor Sie Ihre nächste Automatisierungsplanungssitzung abhalten, bevor Sie die nächste Sprint-Überprüfung abhalten, bei der jemand das Erreichen einer 80%igen Abdeckung feiert, stellen Sie die schwierigere Frage.

„Wo werden wir all diese Tests in sechs Monaten durchführen?“

Denn die Mathematik ist unerbittlich:

100 Tests können nahezu überall ausgeführt werden. 5,000 Tests erfordern eine Orchestrierung. 50,000 Tests – die Szenarien in den Bereichen Funktionalität, Barrierefreiheit, Leistung, Audio, Mobilfunkanbieter und vernetzte Fahrzeuge abdecken – benötigen eine Architektur.

Die konkrete Umsetzung – ob Cloud, On-Premise oder Hybrid – bleibt Ihnen überlassen. Doch alle Teams, die erfolgreich im großen Maßstab arbeiten, haben eines gemeinsam: Sie haben die Frage der Umsetzung früh genug gestellt, um sie gut beantworten zu können.