Komplexe B2B-SaaS testen: Wie die Agenten von QA.tech Rollen, Berechtigungen und datengetriebene Abläufe handhaben

Einfache Produkte lassen sich leicht testen, und heutzutage entwickelt kaum noch jemand einfache Produkte. Die B2B-SaaS-Plattformen, mit denen wir bei QA.tech arbeiten, haben ein gemeinsames Profil: mehrere Benutzerrollen mit unterschiedlichen Berechtigungen, Bildschirme, deren gesamte Struktur von den dahinterliegenden Daten abhängt, Arbeitsabläufe, die sich über ein Dutzend Schritte und mehrere Abhängigkeiten erstrecken, und zunehmend auch Funktionen, die innerhalb einer einzigen Benutzerreise Web, API und Mobilgeräte umfassen.

Genau hier verursacht skriptbasierte Testautomatisierung die höchsten Kosten und erzielt die geringste Abdeckung. Jede Rolle vervielfacht die Pfade. Jeder Datenzustand vervielfacht sie erneut. Eine Testsuite, die die Kombinationen wirklich vollständig abdecken würde, wäre größer als das Produkt selbst – daher erstellen Teams in der Praxis Skripte für die Standardabläufe, prüfen den Rest stichprobenartig manuell und akzeptieren die Lücke.

Dieser Artikel zeigt auf, wie die Agenten von QA.tech mit jeder dieser Komplexitätsdimensionen unterschiedlich umgehen. Die Erkenntnisse stammen aus der Einführung bei Teams in Finanztechnologie, HR-Technologie, E-Commerce-Infrastruktur und Gesundheitswesen – also bei Produkten, bei denen „einfach den Ablauf aufzeichnen“ niemals funktionieren würde.

Das richtige Denkmodell: Sie arbeiten einen neuen Kollegen ein

Die Perspektive, durch die alles Folgende verständlich wird, stammt tatsächlich von einem Kunden. Ein QA-Leiter, der beobachtete, wie der Agent die Plattform zum ersten Mal erkundete, fragte: „Verhält er sich also wie ein Neuling im Unternehmen?“ Genau so ist es. Der Agent wird Teil Ihres Teams, so wie es ein aufgeweckter neuer QA-Mitarbeiter wäre – er erkundet das Produkt, entwickelt ein mentales Modell, stellt Fragen, wenn er auf etwas Mehrdeutiges stößt, und wird in den ersten Wochen gelegentlich korrigiert. Der Unterschied zeigt sich danach: Das aufgebaute Verständnis ist ein dauerhaft bestehender Wissensgraph, er vergisst keine Korrektur und wendet jeden Kontextbaustein auf jeden zukünftigen Test an.

Dieses Denkmodell ist wichtig, weil gerade bei komplexen Produkten die „Neulingsphase“ Früchte trägt. Ein Skript kennt einen Weg durch Ihr Produkt. Ein trainierter Agent kennt Ihr Produkt.

Rollen und Berechtigungen: Zeigen Sie ihm die gesamte Karte und geben Sie ihm dann jeden beliebigen Schlüssel

Berechtigungssysteme sind der Bereich, in dem skriptbasierte Testsuiten stillschweigend aufgeben. Wenn Ihre Plattform über die Rollen Administrator, Manager und Mitglied verfügt – oder über fünfzig kundenspezifische Rollenkonfigurationen –, benötigt ein skriptbasierter Ansatz für jede Rolle eine separat erstellte Abdeckung, die in dem Moment veraltet, in dem sich Berechtigungen ändern.

Der agentenbasierte Ansatz kehrt dieses Vorgehen um. Zuerst erkundet der Agent Ihr Produkt mit einem Administratorkonto, sodass sein Wissensgraph die gesamte Oberfläche abdeckt: jeden Bildschirm, jede Aktion und jeden vorhandenen Ablauf. Danach geben Sie ihm Konten mit eingeschränkten Rechten. Wenn sich der Agent als Mitglied anmeldet, sieht er weniger Optionen – und weil er die vollständige Karte kennt, versteht er, was fehlt und warum, anstatt durch eine kleinere Benutzeroberfläche verwirrt zu sein.

Von dort an wird Berechtigungstests zu einem Gespräch. Sagen Sie dem Agenten: „Als Benutzer dieser Kategorie solltest du nur X, Y und Z sehen“, und er überprüft diese Grenze. Und hier ist das Detail, das Teams besonders schätzen: Wenn ein Benutzer mit eingeschränkten Rechten einen Bildschirm tatsächlich nicht erreichen kann, verzeichnet der Agent einen erfolgreichen Test – als Beleg dafür, dass das Berechtigungssystem seine Aufgabe erfüllt. Sie bestätigen diese Erwartung einmal, der Agent hinterlegt sie, und eine ganze Klasse sicherheitsrelevanter Überprüfungen läuft kontinuierlich, ohne dass jemand dafür ein Skript erstellen muss.

Datengetriebene Abläufe: dasselbe Ziel, andere Daten, keine Neuerstellung

Bei datenintensiver SaaS ist der Ablauf selten der schwierige Teil – es sind die Varianten. Einen Datensatz zu erstellen, ist ein Test; ihn mit fünfzig verschiedenen Datenprofilen zu erstellen, von denen einige erfolgreich sein und andere abgelehnt werden sollten, führt beim manuellen Testen zur Überlastung und verwandelt Skripte in nicht wartbare Parametersammlungen.

Da der Agent auf Grundlage von Zielen statt aufgezeichneter Schritte arbeitet, reicht für Datenvariationen eine einzige Anweisung: „Führe diesen Testfall mit diesen Daten erneut aus.“ Das Wissen über den Ablauf bleibt erhalten; nur die Eingaben ändern sich. Negative Fälle funktionieren auf dieselbe Weise – beschreiben Sie, was abgelehnt werden sollte, und der Agent überprüft, ob das Produkt wie vorgesehen Nein sagt. Für die Freitextfelder, von denen jedes komplexe Produkt viele enthält, greift der Agent auf den von Ihnen bereitgestellten Produktkontext zurück, um sinnvolle Werte einzugeben. Wenn er falsch rät, korrigieren Sie sein Verständnis einmal, statt ein Skript zu überarbeiten.

Lange Arbeitsabläufe: Der Agent kennt die Voraussetzungen bereits

Arbeitsabläufe in Unternehmens-SaaS haben Abhängigkeitsketten – Sie können einen Vorgang erst bearbeiten, wenn ein Vorgang vorhanden ist, können eine Anfrage erst genehmigen, wenn jemand sie eingereicht hat, und Sie können den zehnten Schritt nicht testen, ohne die ersten neun durchlaufen zu haben. In skriptbasierten Testsuiten wird daraus Einrichtungscode: Testumgebungen, Datensätze und Hilfsskripte, die selbst einen erheblichen Wartungsaufwand verursachen.

Der Agent verarbeitet Abläufe so wie ein Mensch: indem er sich erinnert. Sobald er einen Ablauf abgeschlossen hat, baut alles Weitere auf diesem Wissen auf. Bitten Sie ihn, Unteraufgaben für ein Geschäft zu testen, weiß er, dass zuerst das Geschäft erstellt werden muss – weil er es bereits getan hat und der Pfad in seinem Wissensgraphen gespeichert ist. Voraussetzungen wie die Anmeldung werden einmal konfiguriert und überall wiederverwendet. Je komplexer Ihre Workflows sind, desto wichtiger wird dieser kumulative Effekt, denn jeder Schritt, den der Agent bereits kennt, ist ein Schritt, den niemand erneut erstellen muss.

Oberflächenübergreifende Abläufe: Web, API und Mobilgerät in einem Test

Echte Nutzerabläufe in modernen SaaS-Produkten halten sich nicht an die Grenzen von Testwerkzeugen. Ein Nutzer konfiguriert etwas im Web, ein Webhook wird ausgelöst, ein Datensatz wird über die API aktualisiert und eine Benachrichtigung kommt in der mobilen App an. Die meisten Teams testen jede Oberfläche in einem separaten Werkzeug mit separaten Skripten und hoffen, dass die Übergänge funktionieren.

QA.tech führt diese als einzelne End-to-End-Tests aus: Ein Ablauf kann im Webprodukt beginnen, in der Mitte API-Testschritte enthalten und in der nativen iOS- oder Android-App enden, wobei der Ablauf so überprüft wird, wie Ihre Kunden ihn tatsächlich erleben. Bei Plattformen, bei denen sich Fehler genau an den Übergängen zwischen den Oberflächen verstecken – etwa bei Zahlungen, Benachrichtigungen und der Synchronisierung –, schließt dies eine Lücke, die Werkzeuge für einzelne Oberflächen strukturell nicht schließen können.

Was sich daraus ergibt

Das Muster in Teams mit komplexen Produkten ist einheitlich. Die ersten Wochen sind von Zusammenarbeit geprägt – der Agent erkundet, fragt nach und wird korrigiert, während Ihr Team lernt, wie es ihn anleitet. Danach nehmen die Fragen ab, und der Testaufwand entkoppelt sich von der Produktkomplexität: Neue Rollen, neue Datenzustände und neue Workflow-Schritte werden in den Wissensgraphen aufgenommen, anstatt neue Skripterstellungsarbeit zu verursachen.

Das Ergebnis zeigt sich in Stunden. Pricer, ein Unternehmen für Einzelhandelstechnologie, dessen Plattform genau diese Art von komplexem, datenintensivem Produkt ist, ermittelte nach der Verlagerung der Verifizierung auf QA-Agenten eine Einsparung von 390 QA-Stunden pro Quartal – Kapazität, die wieder in die Entwicklung statt in die Wartung der Testinfrastruktur floss.

Und es gibt einen weniger auffälligen Vorteil, den technische Führungskräfte erwähnen: Die Erkundung durch den Agenten bringt Kombinationen zutage, an die niemand gedacht hatte. Wenn Ihre Abdeckung von einem System stammt, das das gesamte Produkt erfasst hat, statt von einem Rückstand an Test-Tickets, wird aus „Haben Sie daran gedacht?“ eine Frage, die die Plattform Ihnen stellt.

Häufig gestellte Fragen

Können die Agenten von QA.tech die rollenbasierte Zugriffskontrolle in B2B-SaaS testen?

Ja. Der Agent erfasst die gesamte Anwendung über ein Administratorkonto und testet anschließend als beliebiger Benutzer mit eingeschränkten Rechten, wobei er überprüft, dass jede Rolle genau das sieht, was sie sehen sollte. Erwartete Berechtigungssperren werden als erfolgreiche Ergebnisse codiert.

Wie gehen die Agenten von QA.tech mit datengesteuerten Testszenarien um?

Derselbe Testfall wird auf Anweisung mit unterschiedlichen Daten ausgeführt – “Führen Sie dies noch einmal mit diesen Daten aus” – ohne erneute Erstellung. Positive und negative Fälle leiten sich gleichermaßen aus dem von Ihnen beschriebenen Ziel ab.

Unterstützt QA.tech Tests über Web, API und Mobilgerät in einem Ablauf?

Ja. Ein einzelner QA.tech-Test kann Webschritte, API-Testschritte sowie native iOS- oder Android-Schritte kombinieren und oberflächenübergreifende Abläufe von Anfang bis Ende überprüfen.

Wie lange braucht QA.tech, um ein komplexes SaaS-Produkt zu erlernen?

Die anfängliche Erfassung dauert Minuten; ein gut trainiertes Verständnis von Rollen, Daten und Workflows entwickelt sich typischerweise über einige Wochen normaler Nutzung. Dabei nehmen die Fragen des Agenten ab, sobald sich sein Wissensgraph füllt.

---

Haben Sie ein Produkt, an dem Testwerkzeuge scheitern? Richten Sie die Agenten von QA.tech auf Ihre Staging-Umgebung – für komplexe Produkte wurden sie entwickelt.