KI verändert die Art und Weise, wie Software entwickelt wird – und das mit enormer Geschwindigkeit. Entwicklungsteams können heute innerhalb weniger Tage das liefern, wofür früher Wochen nötig waren. Wenn du in der Qualitätssicherung arbeitest, stellt diese Geschwindigkeit keine Bedrohung für deinen Arbeitsplatz dar. Sie ist jedoch eine Bedrohung für bestehende Prozesse. Denn ein QA-Prozess, der für das Entwicklungstempo von gestern konzipiert wurde, wird schnell zum Engpass den neuen.
Bei SABO IT war die Qualität des Codes für mich dabei nie das größte Problem. Erfahrene Entwickler arbeiten bereits mit etablierten Prüfmechanismen: Code wird von Menschen und Tools überprüft – unabhängig davon, ob KI beim Schreiben unterstützt hat. Dieser Teil der Pipeline verfügt seit Jahren über klare Prozesse und Sicherheitsmechanismen - und das schon lange vor dem Einzug der KI.
Das eigentliche Problem lag schon immer woanders: beim Verständnis fachlicher Anforderungen.
Anforderungen werden meist von Menschen mit tiefem Fachwissen formuliert. Was dabei häufig übersehen wird: Ein großer Teil dieses Wissens existiert nur in ihren Köpfen. Für die Autoren ist der Text eindeutig. Für alle anderen enthält er Lücken, unausgesprochene Annahmen und stillschweigende Voraussetzungen.
Aus diesen Lücken entstehen Missverständnisse. Aus Missverständnissen entstehen Fehler.
Genau dieses Problem hat mich vor Jahren zu BDD geführt: Gherkin-Szenarien, die Verhalten so beschreiben, dass Fachbereich und Entwicklung dieselbe Sprache sprechen. Gemeinsame Beispiele statt mehrdeutiger Prosa. Diese Prinzipien sind nach wie vor richtig.
Wenn sich die Entwicklungsgeschwindigkeit jedoch drastisch erhöht, müssen Business-Analyse und Testanalyse Schritt halten. Andernfalls entsteht ein Paradoxon: Das Team arbeitet schneller und testet besser, produziert am Ende aber lediglich gut getestete Missverständnisse in höherem Tempo.
Deshalb begann ich, die Engpässe unseres Testprozesses systematisch zu analysieren und zu prüfen, an welchen Stellen KI Arbeit reduzieren kann, ohne menschliche Entscheidungsfähigkeit zu ersetzen.
Ein Kollege sagte mir einmal, er sei überrascht, dass unser Team KI so erfolgreich einsetzt. Schließlich habe er mich immer als skeptisch und misstrauisch gegenüber KI wahrgenommen. Meine Antwort war einfach: Er hat recht.
Er hat recht. Ich vertraue KI und ihren Ergebnissen nicht. Aber ich vertraue auch Entwicklern und ihren Ergebnissen nicht. Ich wäre ein schlechter Tester, wenn ich einfach alles für richtig hielte, was mir jemand präsentiert. Meine Aufgabe ist es, zu überprüfen, was tatsächlich ausgeliefert wird. Und das gilt für KI genauso wie für Menschen.
Das bedeutet nicht, dass ich KI ablehne – ganz im Gegenteil. Ich sehe darin eine enorme Chance. Aber KI kann keine Verantwortung übernehmen, wie es ein Mensch kann und gerade im QA-Bereich ist Verantwortung das eigentliche Produkt.
Diese Überzeugung wurde zum Grundprinzip für alles, was wir entwickelt haben: Ein Mensch muss immer das letzte Wort über ein Ergebnis haben.
KI erstellt Entwürfe, prüft, schlägt vor und formatiert. Die endgültige Entscheidung trifft sie nie.
Mit genau diesem Gedanken haben wir SaTI (Sabo Tester Intelligence), unsere interne KI-gestützte Testing-Plattform, entwickelt. Nicht, um Tester zu ersetzen, sondern damit sie mehr Zeit für die Aufgaben haben, die tatsächlich menschliches Denken erfordern.
Der zentrale Ablauf folgt der natürlichen Kette unserer QA-Arbeit:
Anforderungen → Testfälle → Testautomatisierung
1. Anforderungen verstehen, bevor sie teuer werden
Alles beginnt bei der Anforderung. Wer schon einmal ein Feature auf Basis einer Anforderung umgesetzt hat, die eigentlich nur für ihren Autor wirklich verständlich war, weiß, wie teuer solche Missverständnisse werden können, wenn sie erst spät entdeckt werden. Genau hier setzt SaTI an. Analysten erhalten eine KI-gestützte Prüfung der Anforderung. Das System bewertet sie, stellt Rückfragen und weist auf Unklarheiten, fehlende Informationen und nicht definierte Akzeptanzkriterien hin – bevor überhaupt jemand darauf aufbaut. Das ist der kostengünstigste Zeitpunkt im gesamten Entwicklungsprozess, um ein Missverständnis aufzudecken.
Ein kleines Beispiel aus der Praxis:
Bei der Anforderungsprüfung stellt SaTI gezielte Fragen und weist auf Unklarheiten hin. Meine Tester sagen mir immer wieder, dass diese Fragen erstaunlich treffsicher sind – so treffend, dass sie direkt mit Business-Analysten und Stakeholdern diskutiert werden. Das Ergebnis sind klarere und bessere Anforderungen.
Genau das ist für mich der entscheidende Punkt: Die KI hat nichts entschieden. Sie hat lediglich dafür gesorgt, dass die richtige menschliche Diskussion früher stattfindet. Genau dafür möchte ich KI einsetzen.
2. Testfälle erstellen und überprüfen
Genehmigte Anforderungen bilden die Grundlage für die Testfallerstellung.
Wer unter Zeitdruck Testfälle schreibt, kennt die typischen Opfer knapper Zeit: Edge Cases, Duplikatsprüfungen und der zweite kritische Blick auf die eigenen Tests.
Deshalb haben wir auch diesen Bereich teilweise an KI delegiert.
Eine Pipeline aus spezialisierten KI-Agenten erstellt Testfälle, überprüft die eigenen Entwürfe, vergleicht sie mit bereits vorhandenen Tests auf mögliche Duplikate und verbessert das Ergebnis iterativ. Das Ziel ist nicht, automatisch perfekte Testfälle zu produzieren. Das Ziel ist, einen Entwurf zu liefern, der die Aufmerksamkeit eines Testers verdient. Auch von Menschen erstellte Testfälle können durch die KI geprüft werden. Dabei geht es beispielsweise um Stil und Konsistenz oder – wenn eine Verknüpfung zu einer Anforderung besteht – um die Abdeckung der Anforderung.
3. Von genehmigten Testfällen zur Automatisierung
Nach der Freigabe der Testfälle kommt die Automatisierung. Zwischen einem genehmigten Testfall und ausführbarem Testcode steckt oft viel Routinearbeit. Genau diese Routineaufgaben sollte die KI übernehmen.
Dafür haben wir einen MCP-Server entwickelt, der SaTI mit einem Coding Assistant verbindet. Der Assistant erhält die Testfälle zusammen mit dem verwendeten Testframework und unseren projektspezifischen Standards. Anschließend kann er die Testautomatisierung weitgehend autonom implementieren und das Ergebnis zur Prüfung zurückgeben. Auch hier gilt unser Grundprinzip: Nur ein Mensch kann einen Test als implementiert markieren.
Das ist nicht nur eine Empfehlung, sondern wird technisch durchgesetzt. Versucht ein KI-Agent, diesen Status selbst zu setzen, wird die Aktion abgelehnt. KI darf arbeiten. Aber sie darf nicht selbst entscheiden, dass ihre Arbeit abgeschlossen und akzeptiert ist.
Wie viel Zeit spart das? Hier möchte ich genauso ehrlich sein, wie es unsere Plattform von uns verlangt:
Wir haben das bisher nicht unter Laborbedingungen gemessen. Was wir im täglichen Einsatz beobachten, ist jedoch deutlich.
Durch die Testgenerierung sinkt der Aufwand für die Testanalyse ungefähr um etwa 60 Prozent. Der entscheidende Unterschied besteht darin, dass sich die Arbeit verändert:
Aus Schreiben wird Prüfen. Wenn zusätzlich die Automatisierung genutzt wird, steigt die Zeitersparnis weiter. Dabei ist für mich die Zeitersparnis aber nicht einmal der wichtigste Punkt. Der eigentliche Gewinn ist, dass Tester ihre Zeit weniger mit wiederholbarer Arbeit verbringen und mehr Zeit für Analyse, Risikoabschätzung und kritisches Denken haben.
Zwei weitere Werkzeuge aus dem Alltag eines Testers
Der Bug-Reviewer
Wer schon einmal einen guten Bug-Report geschrieben hat, weiß, wie anspruchsvoll das sein kann.
Wenn man gerade tief im Kontext eines Fehlers steckt, lässt man Dinge weg, die selbstverständlich erscheinen. Genau diese Informationen fehlen dann später demjenigen, der den Fehler debuggen muss – möglicherweise Wochen später. Hier ist KI tatsächlich sehr gut.
Der Bug-Reviewer prüft Fehlerberichte, weist auf fehlende Informationen hin und bringt ihn in das projektspezifische Format.
Der Tester bleibt dabei der Autor. Die KI sorgt lediglich dafür, dass aus dem schnellen Entwurf ein brauchbarer Bug-Report wird. Unterstützung beim explorativen Testen. Das zweite Werkzeug unterstützt session-based exploratory testing. Wer diese Methode schon einmal eingesetzt hat, weiß, wie viel Disziplin dahintersteckt: ein klares Charter, strukturierte Notizen und eine saubere Nachbesprechung.
Ich halte exploratives Testen für eine extrem leistungsfähige Technik – und es ist gleichzeitig meine persönliche Lieblingsmethode. Aber genau diese notwendige Disziplin führt auch dazu, dass Teams sie manchmal gar nicht erst einsetzen. In SaTI begleitet ein KI-Assistent die Sitzung, unterstützt die Nachbesprechung und erstellt automatisch Fehlerberichte aus fehlgeschlagenen Tests.
Ich entdecke immer mehr Bereiche, in denen sich dieser Ansatz anwenden lässt. Als Nächstes möchten wir uns dem Test Reporting widmen. Einen guten Testbericht für die richtige Zielgruppe zu erstellen, ist schwieriger, als es klingt. Auch ich habe in der Vergangenheit immer wieder damit gekämpft, Testergebnisse so aufzubereiten, dass Stakeholder ihre Bedeutung wirklich verstehen. Wenn KI-Berichte auf Basis eines definierten Templates erstellen kann, verändert sich die Aufgabe. Der schwierige Teil sollte dann wieder dort liegen, wo er hingehört: Was müssen wir zeigen? Welche Daten sind relevant? Welche Aussage sollen die Ergebnisse vermitteln? Das Schreiben selbst wird zur Review-Aufgabe.
Wenn Sie bis hierher gelesen haben, werden Sie erkennen, dass dies das Muster ist, das all unseren Aktivitäten zugrunde liegt. Die KI erzeugt, der Mensch überprüft. Es zeigt sich, dass das professionelle Misstrauen eines Testers eine sehr gute Grundlage für die Zusammenarbeit mit KI ist.
Teilen Sie uns mit, in welchem Bereich Ihres QA-Prozesses die KI noch keine Unterstützung geleistet hat.
Genau diese Art von Austausch finden wir am nützlichsten.
