KI im Software-Testing und QABridge

In den ersten beiden Teilen dieser Serie ging es um Künstliche Intelligenz im Software-Testing im Allgemeinen: In Teil 1 („KI im Software-Testing: Wo sie heute schon wirkt“) um die Einsatzfelder, in denen KI heute nachweislich produktiv genutzt wird, von der Prüfung von Akzeptanzkriterien bis zur Fehleranalyse. In Teil 2 („KI im Software-Testing: Grenzen, Rollen und die richtige Tool-Wahl“) um die Grenzen dieses Einsatzes, neue Anforderungen an Testengineers und die Frage nach dem passenden Werkzeug.

Im dritten und letzten Teil der Serie „KI im Testing“ wollen wir die bisher beschriebenen Einsatzmöglichkeiten und Grenzen der KI an einem konkreten Beispiel zeigen und dabei unser eigenes Test-Framework vorstellen.

QABridge in Kürze

QABridge ist ein modulares Test-Automatisierungs-Framework, das aktuell in zwei Sprachvarianten existiert: Java und .NET.

Beide teilen dieselbe Grundidee: ein stabiles, treiberunabhängiges Interface, hinter dem sich austauschbare Engines für Selenium, Playwright, Appium und REST Assured verbergen.

QABridge selbst enthält keine KI-Funktionen. Die bewusste Entwurfsentscheidung, das Framework durch klar umrissene Schnittstellen zu strukturieren, ermöglicht es aber, die KI gezielt an diesen Stellen einzusetzen, ohne den Rest der Architektur verstehen zu müssen. Somit ist die Einführung des Test-Frameworks und einer KI in das kundenspezifische Umfeld simpel und zeitsparend.

Erweiterungen, sogenannte Connectors, lassen sich ebenso nahtlos in die Architektur einbringen und unterstützen dabei, QABridge in neue oder bestehende System-Landschaften einzusetzen.

QABridge ist ein kontextbasiertes Test-Framework: Es benötigt Input, um Testfälle ausführen zu können. Dieser Kontext kann unterschiedlich sein (kundenspezifisch), umfasst aber vor allem:

• Testdaten

• Testfallspezifikationen

• ggf. Locators (die Selektoren, mit denen ein Test UI-Elemente wie Buttons oder Eingabefelder eindeutig findet und ansteuert)

• Testfallcode

Wie Sie bereits gelesen haben, ist der Kontext einer der wichtigsten Parameter für einen sinnvollen Einsatz der KI. Und genau hier liegt die Schnittstelle, an der sich die von Kund*innen ausgewählte KI mit QABridge verbinden kann.

Testdaten generieren: JSON als Ankerpunkt

Wie schon in unserem Beitrag zu Testdaten und Testumgebungen erwähnt, sind gut ausgewählte Testdaten eine wesentliche Grundlage für automatisierte Tests. Viele Projekte beziehen ihre Testdaten aus generierten Datenquellen oder erzeugen sie sogar während der Laufzeit.

QABridge bietet folgende Mechanismen zur Testdaten-Anbindung an:

• Auslesen der Testdaten aus einer JSON-Datei

• Anbindung an eine bestehende Datenbank

Für die Anbindung aus einer JSON-Datei existiert ein eigener Testdaten-Import-Mechanismus, welcher als Input eine flache JSON-Objektliste erwartet. Dieses kanonische Zielformat ist die eine feste JSON-Struktur, auf die sich QABridge festlegt, unabhängig davon, woher die Testdaten ursprünglich stammen. Damit lassen sich die Feldnamen und deren Werte einfacher lesen, in Objekte umwandeln und mittels „findByKey“ finden und verwenden.

Genau an diesem kanonischen Format setzt KI-Generierung sinnvoll an, mit oder ohne Vorlage:

Mit Vorlage: Liegt bereits eine Beispiel-JSON-Datei oder das Ziel-Objekt vor, kann eine KI daraus zuverlässig neue, strukturell passende Datensätze ableiten. Feldnamen, Typen und Schlüsselfeld sind vorgegeben, das Risiko einer falschen Struktur sinkt entsprechend.

Ist die Vorlage keine JSON-Datei, ist eine Umwandlung in das richtige Format notwendig. Auch hier wird seitens Grüner IT Hilfe angeboten: Die bereits erwähnten Connectors, spezialisierte Python-Pakete, konvertieren externe CSV-, XLSX- oder JSON-Quellen in exakt das vordefinierte kanonische Format.

Ohne Vorlage: Fehlt eine Vorlage, muss die Struktur aus einer Beschreibung des fachlichen Bedarfs abgeleitet werden. Das gelingt bei diesem Format vergleichsweise robust, weil die kanonische Struktur bewusst einfach gehalten ist: flache Objekte, keine Verschachtelung. Es gilt aber derselbe Grundsatz. Ohne Review bleibt jeder KI-generierte Datensatz ein Entwurf, kein fertiges Ergebnis, insbesondere, wenn Feldnamen oder Wertebereiche nicht mit dem Ziel-Objekt übereinstimmen.

Voraussetzung für die Verwendung der Anbindung an eine Datenbank ist die erfolgreiche Einpflegung von Testdaten: Im besten Fall sind diese schon vor dem Teststart generiert und eingespielt. Ein Einsatz der KI ist an dieser Stelle allerdings mit Vorsicht zu genießen: Personenbezogene oder Produktivdaten sollten aus Datenschutzgründen nicht an externe KI-Dienste übergeben werden.

Testausführungscode generieren: vom Testfall zum lauffähigen Code

Wie wir bereits gelernt haben, lässt sich auch die Testfall-Generierung mit der KI sehr gut verheiraten, solange der Kontext ausreichend und klar definiert ist.

Bei der Testfall-Generierung unterscheiden wir allerdings zwischen zwei Stufen:

• Testfallspezifikation

• Testfallausführungscode

Beide sind relevant für eine Testautomatisierung, da der Testausführungscode der Testfallspezifikation entsprechen muss. Das heißt, im Idealfall existiert eine Testfallspezifikation als Testfalldokumentation in einem Testmanagement-Tool, anhand derer der Code implementiert werden kann.

Die Testfallspezifikation lässt sich ebenso gut durch die KI generieren, benötigt aber auch hier ein Review durch Tester*innen. Als Input für die KI zählen unter anderem: die User-Story, die Anforderungsanalyse, verknüpfte bestehende Testfälle, Definition of Ready, Akzeptanzkriterien und vordefinierte Strukturen bzw. Angaben für eine Testfall-Erstellung, die auch Tester*innen befolgen müssen (z. B., dass ein Testschritt immer ein erwartetes Ergebnis haben muss, dass eine Überprüfung des Erfolgs oder eines Fehlers als Ziel definiert ist, dass Vorbedingungen kein Teil eines Testschritts sind, etc.).

QABridge ist ein reines Testautomatisierungs-Framework und bietet auch kein Repository für die Testfallspezifikation, weswegen wir hier auf die Integration mit der KI nicht näher eingehen werden.

Was aber relevant ist, ist die Testfallausführungscode-Generierung durch die KI, denn QABridge ist so implementiert, dass weder eine Konfiguration noch eine Implementierung von WebDrivern und deren Interaktionsmethoden notwendig ist. Das Framework übernimmt diese Tätigkeiten vollautomatisch. Das einzige Doing für Testautomatisierer*innen ist nun tatsächlich die Implementierung von:

• Pages/PageObjects/ScreenObjects

• API-Requests

• Tests

Und diese Implementierung lässt sich ganz einfach mit einer KI generieren. Als Input wäre hier folgender Kontext nötig:

• Testfallspezifikation bzw. die Testschritte

• QABridge-BaseTest-Implementierung des ausgewählten Treibers (Selenium, Appium, Playwright oder REST Assured)

• DOM-Elemente (bei UI-Tests) bzw. API-Endpoints (bei API-Tests)

QABridge selbst enthält keine selbstheilenden Locators (Self-Healing Locators), wie sie in Teil 1 als eigenständige KI-Funktion beschrieben wurden. Ändert sich ein Element im DOM, bricht ein mit QABridge automatisierter Test wie jeder klassische Selenium- oder Playwright-Test ab. Demnach ist eine manuelle Änderung oder KI-unterstützte Anpassung der Testfälle, Locators und Endpoints etc. notwendig.

Auch hier gilt: Review durch Tester*innen bzw. Testautomatisierer*innen durchführen lassen.

Log-Analyse: strukturierte Fehlerklassifikation als Ausgangsbasis

QABridge liefert bereits vor jedem KI-Einsatz eine erste, regelbasierte Fehlerklassifikation: ErrorMessageHandler ordnet fehlgeschlagene Tests den Kategorien UI Framework Error, Assertion Error oder QABridge Framework Error zu. Screenshots werden bei einem Fehlschlag zusätzlich mitdokumentiert und gespeichert.

Diese Vorstrukturierung ist genau der Punkt, an dem sich eine in Teil 1 beschriebene Einschränkung von LLM-gestützter Log-Zusammenfassung entschärfen lässt: Dort wurde festgehalten, dass Sprachmodelle auf systemspezifischen Jargon in Rohlogs empfindlich reagieren und die Ergebnisqualität stark von der Formulierung der Anfrage abhängt. Wird der KI statt eines Rohlogs die bereits klassifizierte Fehlerkategorie samt zugehörigem Screenshot übergeben, verringert sich dieses Risiko: Die KI muss die Fehlerart nicht mehr selbst erkennen, sondern kann sich auf die inhaltliche Zusammenfassung innerhalb einer bereits bekannten Kategorie konzentrieren.

In der Praxis würde das bedeuten, den KI-Einsatz gezielt auf die am wenigsten eindeutige Kategorie zu konzentrieren. „QABridge Framework Error“ deckt laut Dokumentation Fehler ab, die weder eindeutig UI-Framework- noch Assertion-bezogen sind, also tendenziell die Fälle mit dem größten Klärungsbedarf. Bei einem „Assertion Error“ ist die fachliche Aussage durch die Assertion selbst meist schon hinreichend klar, eine zusätzliche KI-Zusammenfassung bringt hier tendenziell weniger Mehrwert.

Reporting: von der Ergebnisdatei zur geschäftsrelevanten Aussage

Auch beim Reporting gilt: QABridge exportiert strukturierte, deterministische Ergebnisse, KI liefert, falls gewünscht, die zusätzliche, sprachliche Einordnung. TestResultCollector sammelt PASSED-, FAILED- und SKIPPED-Ergebnisse für alle mit @TestCaseId versehenen Testmethoden und schreibt sie zusammengefasst in einen Report (inklusive Verweis auf einen möglicherweise vorhandenen Screenshot).

Zwei Aspekte sind hier für den KI-Einsatz relevant, wie bereits in Teil 1 zum Thema Reporting beschrieben: KI kann Testergebnisse zusammenfassen, Risiken hervorheben und technische Befunde in eine für Stakeholder*innen verständliche Aussage übersetzen. Bei QABridge liegt dafür bereits eine saubere Grundlage vor, weil jedes Ergebnis über @TestCaseId einem externen Testfall zugeordnet ist, und über die separate Connectors-Reihe potenziell auch einem Eintrag in Testiny, Zephyr Scale oder Xray. Eine KI-gestützte Zusammenfassung kann damit nicht nur „X von Y Tests fehlgeschlagen“ berichten, sondern auf Ebene einzelner Testfall-IDs formulieren, welche fachliche Anforderung betroffen ist, vorausgesetzt, dieser Kontext (welche Testfall-ID zu welcher Anforderung gehört) wird der KI mitgegeben.

Auch hier gilt der in Teil 2 beschriebene Grundsatz zum Umgang mit Nicht-Determinismus: Die exportierte PASSED-/FAILED-Information bleibt die deterministische, belastbare Quelle. Eine KI-generierte Zusammenfassung ist eine zusätzliche, nicht-deterministische Sprachschicht darüber. Sie sollte die Rohdaten ergänzen, nicht ersetzen, damit sich eine Aussage im Zweifel immer bis zum konkreten Testergebnis zurückverfolgen lässt.

Fazit

Alle vier Ansatzpunkte, Testdaten, Testausführungscode, Log-Analyse, Reporting, folgen demselben Muster: QABridge definiert an jeder Stelle eine schmale, stabile Schnittstelle (kanonisches JSON-Format, PageObject-Vertrag, Fehlerkategorien, @TestCaseId-Verknüpfung), KI liefert die variable, fachlich geprägte Ausfüllung dieser Schnittstelle. Das deckt sich mit der zentralen Empfehlung aus Teil 2, KI „in klar abgegrenzten Abschnitten des Testprozesses“ einzusetzen statt sie durchgehend und unbeaufsichtigt laufen zu lassen. Bei QABridge sind diese Abschnittsgrenzen durch die ServiceLoader-basierte, DI-freie (Dependency-Injection-freie) Architektur ohnehin schon vorgegeben, unabhängig davon, ob KI überhaupt zum Einsatz kommt.

Damit gilt für die Zusammenarbeit von KI und QABridge derselbe Grundsatz wie für KI im Software-Testing insgesamt: Die Qualität des Ergebnisses hängt direkt vom mitgelieferten Kontext ab, hier konkret von der vorhandenen JSON-Vorlage, der bestehenden Page-Object-Struktur, der bereits klassifizierten Fehlerkategorie oder der Testfall-ID-Zuordnung. Eine menschliche Prüfung bleibt in jedem der vier Bereiche notwendig, unabhängig davon, wie stabil die zugrunde liegende Schnittstelle ist.

QABridge selbst bleibt KI-frei, bewusst, um die Wartungslast eines Dependency-Injection- oder Modell-Layers zu vermeiden. Diese Zurückhaltung hat auch einen wirtschaftlichen Hintergrund: Anders als viele der in Teil 2 genannten Testmanagement- und Automatisierungs-Tools mit integrierter KI, die diese Funktionen über zusätzliche, oft kostenintensive Lizenzmodelle anbieten, verzichtet QABridge bewusst auf eine fest eingebaute, herstellergebundene KI-Anbindung. Kund*innen können stattdessen die KI ihrer Wahl über die offenen, dokumentierten Schnittstellen des Frameworks anbinden, ohne dafür eine zusätzliche, teure KI-Lizenz erwerben zu müssen. Die eigentliche Zusammenarbeit mit KI entsteht nicht innerhalb des Frameworks, sondern an dessen klar definierten Rändern: beim Erzeugen von Testdaten im kanonischen JSON-Format, beim Ausfüllen von Test- und Page-Klassen nach dem vorgegebenen Muster, bei der Zusammenfassung bereits klassifizierter Fehler und bei der sprachlichen Einordnung exportierter, testfall-verknüpfter Ergebnisse. In allen vier Fällen liefert QABridge die stabile Struktur, die KI den variablen Inhalt, und dieselbe menschliche Prüfung, die in Teil 1 und Teil 2 für KI im Software-Testing allgemein beschrieben wurde, bleibt auch hier Teil des Prozesses.

Sie planen den Aufbau Ihrer Testautomatisierung und überlegen, wie sich KI dabei sinnvoll einsetzen lässt? In einem unverbindlichen Austausch schauen wir gemeinsam darauf, ob und wie QABridge dafür der passende Rahmen sein könnte.

Kontaktieren Sie uns unter: office@gruener-it.at