Testautomatisierung ohne Code: Wer schreibt die Tests?

Robert Dey 23. März 2026

In den meisten Teams liegt das Bottleneck der Testautomatisierung nicht darin, dass jemand nicht programmieren kann. Es liegt darin, dass die Menschen, die wissen, was getestet werden muss, keine Tests schreiben können, und die Menschen, die Tests schreiben können, nicht vollständig verstehen, was getestet werden muss. Codeless Test Automation verändert gerade, wer an der Qualitätssicherung teilnehmen kann und, wichtiger noch, wer es sollte.

Das Wissenstransfer-Problem, das die meisten Teams ignorieren

Jedes Mal, wenn eine Anforderung zu einem Test wird, geht Information verloren.

Ein Product Owner definiert einen User Flow in einem Ticket. Ein Entwickler liest das Ticket, baut das Feature und interpretiert, was verifiziert werden muss. Ein Tester übersetzt diese Interpretation dann in ein Testskript. Wenn der Test schließlich in der CI-Pipeline läuft, validiert er oft etwas leicht anderes als das, was der PO ursprünglich beabsichtigt hatte.

Dieser Informationsverlust akkumuliert sich über die Zeit. Teams häufen Test-Suites an, die das technische Verhalten des Codes abdecken, nicht das geschäftliche Verhalten des Produkts. Fehler schlüpfen durch, nicht weil Tests fehlen, sondern weil die Tests die falsche Frage beantworten.

Die klassische Reaktion auf dieses Problem ist mehr Kommunikation: Testfall-Reviews, Akzeptanzkriterien-Templates, Three-Amigos-Meetings, User-Story-Workshops. Diese helfen, behandeln aber das Symptom statt der Ursache. Die eigentliche Ursache ist, dass die Menschen, die Domänenwissen tragen, und die Menschen, die automatisierte Tests schreiben können, fast nie dieselbe Person sind.

Betrachten wir den typischen Ablauf in einem Sprint: Ein Product Owner schreibt eine User Story mit Akzeptanzkriterien. Der Entwickler baut das Feature. Entweder schreibt der Entwickler Unit Tests für die technische Implementierung, oder das Team bittet einen QA-Engineer, im Nachhinein E2E-Tests zu schreiben. In beiden Fällen ist die Person, die den Test schreibt, nicht die Person, die die Anforderungen am besten kennt.

Der PO weiß, dass Premium-Kunden automatisch 10% Rabatt sehen sollen, wenn ihr Warenkorb 50 Euro überschreitet, ohne einen Gutscheincode eingeben zu müssen. Der Entwickler weiß, wie man Rabattlogik implementiert. Aber der Test, der die vollständige User Experience prüft, also den Moment, in dem der Rabatt in der UI erscheint, das Verhalten bei der Warenkorb-Schwelle, das Premium-Kunden-Flag und das Fehlen eines obligatorischen Gutscheinfelds, erfordert all diesen Kontext auf einmal. Selten hat eine Person alles davon.

Wer weiß wirklich, was getestet werden muss?

Product Owner wissen, was das Produkt tun soll. Business Analysten kennen die Grenzfälle. Manuelle Tester kennen die häufigen Fehlermuster aus jahrelangem explorativem Testen. Das sind die Menschen, die am genauesten definieren können, was “korrekt” für ein gegebenes Feature bedeutet.

Das ist keine neue Erkenntnis. Die Idee, dass diejenigen, die Anforderungen definieren, die Tests besitzen sollten, hat eine klare praktische Logik: Sie tragen das Domänenwissen, das Tests brauchen, um aussagekräftig zu sein. Behavior-Driven Development (BDD), Mitte der 2000er-Jahre eingeführt, war explizit dafür gedacht, nicht-technischen Stakeholdern eine Rolle in der Testdefinition zu geben. Die Idee war, dass Product Owner und Business Analysten Testszenarien in natürlicher Sprache mithilfe der Gherkin-Syntax schreiben würden, während Entwickler die Schritt-Definitionen dahinter implementieren.

BDD hat teilweise funktioniert. Es verbesserte die Zusammenarbeit und machte Anforderungen testbarer. Aber es hat die Testerstellung nie vollständig demokratisiert, weil Gherkin immer noch eine Lernkurve hat. Es erfordert strukturiertes Denken: Szenarien, Schritte, Given-When-Then-Format. Nicht-technische Stakeholder können Gherkin-Szenarien lesen, aber sie flüssig zu schreiben ist eine andere Sache. Die kollaborative Absicht von BDD wurde in den meisten Organisationen letztlich an technische Teammitglieder delegiert.

Das Ergebnis ist, dass trotz zwanzig Jahren Bemühen, Testing zugänglicher zu machen, die grundlegende Hürde bestehen bleibt: Automatisierte Tests erfordern entweder Code oder eine strukturierte Syntax, die sich wie Code anfühlt. Für die meisten Product Owner und Business Analysten ist diese Hürde hoch genug, um eine Teilnahme vollständig zu verhindern.

Warum Entwickler nicht die richtigen Eigentümer für E2E-Tests sind

Entwickler sind gut darin, das zu testen, was sie gebaut haben. Unit Tests und Integrationstests, bei denen das Ziel ist zu überprüfen, ob eine Funktion bei einer bestimmten Eingabe die erwartete Ausgabe liefert, sind gut für Entwickler geeignet. Sie kennen die interne Struktur, wissen um die Grenzfälle in ihrer Implementierung und können Tests auf dieser Ebene schnell schreiben.

E2E-Tests sind auf eine grundlegende Weise anders. Ein End-to-End-Test prüft nicht, ob der Code funktioniert. Er prüft, ob das Produkt für einen Benutzer funktioniert. Das erfordert Kenntnis der Benutzerabsicht, der Geschäftsregeln hinter der UI, der Abfolge von Schritten, die eine echte Person unternehmen würde, und der Kriterien, nach denen eine echte Person Erfolg oder Misserfolg beurteilen würde.

Entwickler schreiben oft E2E-Tests, die immer bestehen, selbst wenn das Produkt aus Benutzerperspektive defekt ist, weil sie das testen, was der Code ihrer Kenntnis nach tut, statt was der Benutzer vom Produkt erwartet. Das Beispiel der Rabattberechnung aus einem früheren Artikel veranschaulicht dies gut: Ein Entwicklertest prüft, ob ein über die API übergebener Gutscheincode einen Rabatt anwendet. Die eigentliche Anforderung, dass der Rabatt ohne einen Gutschein automatisch für Premium-Kunden gilt, wird nie getestet.

Das ist kein Kompetenzversagen. Es ist eine strukturelle Fehlausrichtung. Entwickler schreiben gute Tests für die Schicht, die sie am besten verstehen. Sie zu bitten, auch das Domänenwissen von Product Ownern zu tragen, heißt, sie zu bitten, zwei Personen gleichzeitig zu sein.

Es gibt auch eine Wartungsdynamik, die erwähnenswert ist. E2E-Test-Suites, die Entwicklern gehören, neigen zum Drift. Wenn sich Produktlogik ändert, hören die Tests, die einst akkurat waren, schrittweise auf, das widerzuspiegeln, was das Produkt tun soll. Entwickler aktualisieren Tests, um dem neuen Code zu entsprechen, nicht unbedingt den neuen Anforderungen. Dieser Drift ist unsichtbar, bis ein Fehler die Produktion erreicht und jemand auf die Test-Suite schaut und erkennt, dass dieses Szenario nie geprüft wurde.

Die Kosten des Wissens-Round-Trips

In Teams, in denen Domänenexperten und Entwickler getrennt sind, beinhaltet jede Anforderungs-zu-Test-Reise mindestens einen vollständigen Übersetzungs-Round-Trip.

Der Product Owner erklärt die Anforderung. Der Entwickler interpretiert sie und baut das Feature. Der QA-Engineer oder Entwickler schreibt den Test, und fragt den PO oft, um Grenzfälle zu klären, die er nicht versteht. Der PO überprüft die Testbeschreibung oder Testergebnisse und identifiziert Lücken. Der Zyklus wiederholt sich. Dieses Hin-und-Her ist so tief in den Workflows der meisten Teams verankert, dass es als normal behandelt wird, als notwendiger Overhead des Entwicklungsprozesses.

Das ist nicht unvermeidlich. Der Overhead existiert, weil die Person, die den Test am genauesten definieren kann, ihn nicht erstellen kann. Wenn der PO das Testszenario in natürlicher Sprache beschreiben und einen funktionierenden automatisierten Test aus dieser Beschreibung erhalten könnte, verkürzt sich der Round-Trip auf einen einzigen Schritt.

Das ist das echte Versprechen von Codeless Test Automation im Jahr 2026: nicht nur Testing schneller zu machen, sondern die Testautorenschaft in die Hände der Menschen zu legen, die verstehen, was getestet werden muss.

Was “codeless” heute bedeutet im Vergleich zu vor fünf Jahren

Die Kategorie Codeless Testing existiert seit über einem Jahrzehnt, hat sich aber erheblich verändert. Frühe No-Code-Tools basierten auf Record-and-Playback: Ein Tester führte Aktionen im Browser aus, und das Tool zeichnete diese Aktionen als Testskript auf. Diese Tools waren einfach zu starten, aber in der Praxis fragil. Jede UI-Änderung, ein umbenannter Button, ein verschobenes Layout, ein geänderter Selektor, brach die aufgezeichneten Tests. Die Wartungskosten waren hoch genug, dass viele Teams diese Tools nach anfänglicher Begeisterung aufgaben.

Visuelle Test-Tools verbesserten dies, indem sie Bildvergleiche statt CSS-Selektoren verwendeten. Sie waren widerstandsfähiger gegenüber Layout-Änderungen, führten aber andere Probleme ein: False Positives durch unterschiedliche Font-Rendering, Screenshot-Vergleiche, die kosmetische Änderungen als Fehler markierten.

Die Kategorie hat sich erneut verschoben. Die aktuelle Generation von Codeless-Testplattformen verwendet KI-Sprachmodelle, um Absicht zu interpretieren statt Aktionen aufzuzeichnen. Statt zu erfassen, was der Benutzer klickt, verstehen sie, was der Benutzer zu erreichen versucht. Dies produziert Tests, die strukturell anders sind: Sie beschreiben ein Szenario auf der Absichtsebene, was sie widerstandsfähiger gegenüber UI-Änderungen und besser lesbar für nicht-technische Stakeholder macht.

Diese Verschiebung ist wichtig, weil sie verändert, wer einen Test schreiben kann. Klicks aufzuzeichnen erfordert Zugang zur UI und das selbständige Durchführen des Szenarios. Eine Absicht in einfachem Text zu beschreiben erfordert nur Domänenwissen. Die Hürde verschiebt sich von “Kannst du das Browser-Aufzeichnungstool bedienen” zu “Verstehst du das Szenario, das du verifizieren möchtest.” Für Product Owner und Business Analysten ist die zweite Frage viel leichter zu beantworten.

Der Markt bemerkt dies. MarketsAndMarkets prognostiziert, dass der Codeless-Testing-Markt bis 2028 55,2 Milliarden Dollar erreichen wird, ausgehend von etwa 15 Milliarden Dollar im Jahr 2023. Diese Wachstumsrate spiegelt echte Adoption wider, nicht nur Marketing-Interesse. Teams stellen fest, dass die Tools zuverlässig genug geworden sind, um in Produktionsumgebungen eingesetzt zu werden.

Könnten die Domänenexperten deines Teams jetzt deine kritischsten Testszenarien definieren?

kiteto generiert vollständige E2E-Testfälle aus einfachen Textbeschreibungen, ohne Programmierkenntnisse. Product Owner, Business Analysten und manuelle Tester können einen User Flow beschreiben und funktionierenden Playwright-Code erhalten.

Wie Plain-Text-Testgenerierung sich von früheren No-Code-Ansätzen unterscheidet

Wenn jemand “No-Code-Testing” sagt, ist das mentale Bild oft immer noch das Record-and-Playback-Tool von vor einem Jahrzehnt. Es lohnt sich, konkret zu sein, was Plain-Text-Testgenerierung ist und was nicht.

Traditionelle Record-and-Playback-Tools erfassen Aktionen: Klick auf Button mit ID checkout-btn, Eingabe in Input mit Selektor #email, Assertion, dass Text gleich Bestellung bestätigt ist. Diese Aufzeichnungen sind an den aktuellen Zustand der UI gebunden. Ändere die Button-ID und der Test bricht.

Plain-Text-Generierung funktioniert auf einer anderen Ebene. Die Eingabe ist eine Beschreibung eines Szenarios: “Ein registrierter Benutzer fügt zwei Artikel in den Warenkorb und geht zur Kasse. Das System soll E-Mail-Adresse und Zahlungsmethode verlangen, bevor die Bestellplatzierung erlaubt wird. Nach erfolgreicher Zahlung soll eine Bestätigungsseite mit der Bestellnummer erscheinen.” Aus dieser Beschreibung generiert ein Sprachmodell Testcode, der zu den Produktseiten navigiert, Artikel hinzufügt, den Checkout durchläuft, die erforderlichen Felder ausfüllt, die Zahlung einreicht und bestätigt, dass eine Bestätigungsseite mit einer Bestellnummer angezeigt wird.

Der resultierende Testcode enthält durchaus konkrete Aktionen wie bei Record-and-Playback: Selektor-Suchen, Klicks, Formular-Eingaben, Assertions. Der Unterschied liegt in der Quelle des Tests. Bei Record-and-Playback ist die aufgezeichnete Sitzung das, was gepflegt werden muss. Ändert sich die UI, muss neu aufgezeichnet werden. Bei Plain-Text-Generierung ist die Beschreibung die Quelle. Ändert sich die UI, bleibt die Beschreibung bestehen und der Test wird daraus neu generiert. Die Beschreibung ist stabil; die Implementierung kann jederzeit neu erzeugt werden, wenn sie aktualisiert werden muss.

Der praktische Unterschied für nicht-technische Benutzer: Du musst das Szenario nicht selbst ausführen, um den Test zu erstellen. Du musst keine CSS-Selektoren oder XPath-Ausdrücke kennen. Du beschreibst, was der Benutzer tut und was passieren soll, und das Tool übernimmt die Implementierung.

Ein konkretes Szenario: Von der PO-Beschreibung zum funktionierenden Test

Betrachten wir eine PO, die für einen E-Commerce-Checkout-Flow verantwortlich ist. Sie weiß, dass die drei kritischsten Pfade sind: Gast-Checkout für Erstbenutzer, Rückkehr-Benutzer-Checkout mit gespeicherter Zahlungsmethode und Premium-Kunden-Checkout mit automatischem Rabatt. Das sind die Szenarien, bei denen Fehler unmittelbaren Umsatz-Impact hätten.

Traditionell würde es Folgendes erfordern, um automatisierte Tests für alle drei Pfade zu erhalten: Detaillierte Akzeptanzkriterien schreiben, sie an einen Entwickler oder QA-Engineer übergeben, auf Implementierung warten, die Tests überprüfen und Lücken iterativ schließen. Zwei Wochen, wenn das Team es priorisiert. Oft mehr.

Mit einem Plain-Text-Testgenerierungsansatz beschreibt die PO das erste Szenario: “Ein neuer Besucher des Shops fügt ein Produkt in den Warenkorb, klickt auf Checkout, gibt seine E-Mail-Adresse und Versanddetails ein, gibt eine Test-Kreditkarte ein und schließt die Bestellung ab. Die Bestätigungsseite soll die Bestellnummer und eine Nachricht anzeigen, die den Kunden mit seinem Vornamen begrüßt.” Sie reicht das ein und der Testfall wird von kiteto direkt automatisiert.

Sie kann den Test sofort in kiteto ausführen, ohne ein Test-Framework einzurichten oder irgendeine Konfiguration anzufassen. Das Ergebnis kommt mit Bestanden oder Nicht-Bestanden zurück, einer schrittweisen Nachverfolgung und Screenshots auf jeder Stufe. Der Test tut, was er soll: den Checkout-Flow End-to-End verifizieren, aus der Perspektive der Person, die am besten weiß, was dieser Flow leisten soll.

Das ist es, was den Ansatz qualitativ von früheren Tools unterscheidet. Das Domänenwissen der PO fließt direkt in das Test-Artefakt, während das Sprachmodell die Übersetzung in ausführbaren Code übernimmt.

Wo kiteto heute steht und was als nächstes kommt

Einzelne Tests können bereits direkt in der kiteto-Oberfläche generiert und ausgeführt werden. Kein Test-Framework-Setup ist erforderlich. Beschreibe das Szenario, führe es aus und sieh die Ergebnisse mit einer vollständigen Schritt-für-Schritt-Nachverfolgung und Screenshots.

Mit Test-Suites wird man die Möglichkeit haben, einzelne Tests zu Suites zu gruppieren, die gesamte Suite in einem Durchgang auszuführen und automatische Läufe nach einem definierten Zeitplan zu planen oder über eine CI-Pipeline auszulösen. Das ermöglicht Teams, eine Bibliothek automatisierter Prüfungen aufzubauen, die um die Produktbereiche organisiert sind, die POs und BAs besitzen.

Was sich für dein Team verändert

Wenn Domänenexperten Testszenarien direkt verfassen können, verändert sich die Verteilung der Verantwortlichkeiten in der QA.

Product Owner und Business Analysten übernehmen die Eigenverantwortung für geschäftskritische Testszenarien. Sie beschreiben die Flows, die ihnen wichtig sind. Sie warten keine Test-Infrastruktur und schreiben keinen Playwright-Code. Sie definieren, was verifiziert werden muss, was genau ihre Kernkompetenz ist.

Manuelle Tester wechseln von der Ausführung zum Design. Statt bei jedem Release-Zyklus dieselbe manuelle Checkliste abzuarbeiten, dokumentieren sie ihr Test-Wissen als automatisierte Szenarien. Ihr Wissen über Fehlermuster, Edge Cases und Benutzerverhalten wird in Tests kodiert, die automatisch laufen. Das ist der Übergang vom manuellen Tester zur Automatisierung, über den die Branche seit Jahren spricht, aber zugänglich für Menschen ohne Programmier-Hintergrund.

Entwickler konzentrieren sich auf die Testschichten, die sie am besten besitzen: Unit Tests und Integrationstests für den Code, den sie schreiben. Sie überprüfen die generierten E2E-Tests bei Bedarf und können sie anpassen, sind aber kein Bottleneck für E2E-Coverage mehr.

QA-Engineers konzentrieren sich auf Test-Architektur, komplexe Szenarien, die benutzerdefinierte Logik erfordern, Performance-Testing und die Wartung der Test-Infrastruktur. Ihre Fähigkeiten werden dort eingesetzt, wo sie den größten Mehrwert bringen, nicht beim Schreiben von Testfällen für Standard-Geschäftsflows, die Product Owner ohnehin genauer definieren könnten.

Das ist keine Reduzierung von Rollen. Es ist eine Neuausrichtung, wo verschiedene Expertise angewendet wird.

Warum das jetzt wichtig ist

Die Bedingungen, die diese Verschiebung möglich machen, sind relativ neu. Sprachmodelle, die zuverlässig Code aus einfachen Textbeschreibungen generieren können, existieren in Produktionsqualität erst seit einem Jahr. Die darauf aufbauenden Tools sind noch neuer.

Das Wachstum des Codeless-Automation-Testing-Markts spiegelt das wider. Die Lücke zwischen “Record-and-Playback, das bei jeder UI-Änderung bricht” und “Intent-basierter Testgenerierung aus einfachem Text” ist erheblich, und Teams, die beides ausprobiert haben, finden letzteres auf eine Weise nutzbar, die ersteres nicht war.

Der breitere Kontext der KI-Testautomatisierung in 2026 ist, dass mehrere Schichten des Testing-Stacks gleichzeitig automatisiert werden: Testgenerierung, Testwartung durch Self-Healing, Testanalyse durch KI-gestützte Fehler-Triage. Plain-Text-E2E-Testgenerierung ist ein Teil davon, aber der Teil, der das Wissenstransfer-Problem am direktesten angeht.

Der Business Case für bessere E2E-Coverage ist gut etabliert: Produktionsfehler kosten 10-100x mehr zu beheben als Fehler, die beim Testing gefunden werden, und die meisten Teams haben kritische Pfade, die nicht durch automatisierte Tests abgedeckt sind. Die Frage war meist: Wer wird diese Tests schreiben, angesichts der Zeit- und Skill-Einschränkungen, unter denen Teams arbeiten? Domänenexperten-gesteuerte Testautorenschaft verändert diese Rechnung.

Fazit

Das Argument für Domänenexperten, die Tests schreiben, ist nicht neu. Es war das theoretische Fundament hinter BDD und Specification-by-Example-Ansätzen seit zwei Jahrzehnten. Was neu ist: Die Tools haben die Theorie eingeholt. Das Schreiben eines Tests erfordert nicht mehr das Erlernen einer Programmiersprache, eines Test-Frameworks oder einer strukturierten Syntax. Es erfordert die Beschreibung eines Szenarios in derselben Sprache, die man verwenden würde, um es einem Kollegen zu erklären.

Das verschiebt das Bottleneck von “wer kann programmieren” zu “wer versteht die Domäne.” Für Product Owner, Business Analysten und manuelle Tester ist die zweite Frage keine Hürde. Es ist ihre Kernkompetenz.

Teams, die diesen Ansatz übernehmen, finden in der Regel drei Dinge: Ihre Testabdeckung von geschäftskritischen Flows verbessert sich, der Kommunikations-Overhead rund um die Testautorenschaft nimmt ab, und die QA-Engineers und Entwickler, die sie haben, können sich auf Arbeit konzentrieren, die ihre spezifischen Fähigkeiten erfordert. Nicht jedes Team wird diesen Übergang einfach finden, aber die Richtung ist klar: Die Menschen, die Anforderungen definieren, sollten die Tests besitzen, die sie verifizieren, und in 2026 machen die Tools das möglich.