Ein Release steht an, der Kalender ist voll, und ich sitze da und klicke den Chatbot durch. Manuell. Zum dritten Mal diese Woche. Immer dieselben Szenarien, immer dieselbe Hoffnung, dass diesmal alles passt.
Irgendwann hatte ich genug davon.
Ich begleite als Product Owner KI-Chatbot-Projekte von der ersten Idee bis zum laufenden Betrieb, und eine Sache hat mich dabei verlässlich gebremst: das Testing vor jedem Release. Nicht weil es unwichtig wäre – sondern weil es in dieser Form weder mir noch dem Team wirklich weiterhilft. Also hab ich das Problem selbst gelöst.
Kurze Unterbrechung – wo wir unsere Erfahrung sammeln
Mayflower Labs
Wir arbeiten nicht nur intensiv an KI-Projekten, sondern setzen auch massiv auf R&D. Unsere R&D-Projekte werden aber nicht in Schubladen verstaut. Sie lösen echte Kundenprobleme und fließen direkt in produktionsreife Lösungen ein.
Manuelles Testing skaliert nicht
Wer KI-Chatbots verantwortet, kennt das Muster: Vor jedem Release wandert ein informelles Testprotokoll durchs Team. Wer Zeit hat, klickt durch – wer keine hat, vertraut darauf, dass die anderen es tun. Bugs tauchen trotzdem auf, manchmal erst beim Kunden.
Das Problem ist strukturell. KI-Chatbots sind keine statischen Webseiten – sie haben Gesprächsflüsse, Fehlerbehandlung, Antwortzeiten, barrierefreie Bedienbarkeit und CI-konforme Darstellung, also alles Bereiche, die bei jedem Deployment wieder geprüft werden müssen. Manuell ist das nicht nur aufwendig, sondern auch nicht reproduzierbar, weil zwei Menschen dieselbe Oberfläche testen und zu unterschiedlichen Eindrücken kommen.
Für mich als PO bedeutete das, dass ich regelmäßig an Arbeit saß, die eigentlich ins Entwicklungsteam gehört – oder besser gesagt, in ein Tool.
Dazu kommt ein Punkt, den viele Produkt-Teams noch unterschätzen: Barrierefreiheit ist seit Juni 2025 keine optionale Qualitätsstufe mehr. Das EU-Barrierefreiheitsstärkungsgesetz verpflichtet Unternehmen dazu, digitale Produkte barrierefrei zugänglich zu machen, und das schließt KI-gestützte Kommunikationsoberflächen ausdrücklich ein. Wer Barrierefreiheit heute nicht systematisch prüft, hat morgen ein Compliance-Problem – und ein manueller Klick-Durchlauf reicht dafür schlicht nicht aus.
Wenn ich ehrlich bin, habe ich das lange als unvermeidlichen Teil der Arbeit akzeptiert. Irgendwann hab ich dann angefangen, die Zeit zu zählen: Pro Release etwa 45 Minuten manuelles Durchklicken, über mehrere Projekte, mehrere Sprints, ein ganzes Jahr. Das summiert sich auf Tage, die ich nicht für Roadmap-Arbeit, Stakeholder-Kommunikation oder die eigentliche Produktstrategie genutzt habe. Das ist der echte Preis von unstrukturiertem manuellen Testing – nicht die einzelne Session, sondern das Muster, das sich über Monate einschleift.
Die Frage war also: Kann man das systematisch lösen, ohne gleich ein monatelanges Testautomatisierungsprojekt aufzusetzen?
54 Tests, kein Code, kein Klick-Marathon
Ich habe ein wiederverwendbares Testing-Tool gebaut, das die technische Qualitätsprüfung von KI-Chatbot-Oberflächen automatisiert – bedienbar über den Browser, ohne eine einzige Zeile Code schreiben zu müssen.
Das Tool führt 54 automatisierte Tests in drei Kategorien durch. Was ich vorher in einer 45-Minuten-Session bestenfalls unvollständig geprüft habe, läuft jetzt reproduzierbar und dokumentiert in wenigen Minuten ab und deckt dabei deutlich mehr ab.
- 21 UI-Tests prüfen Layout, Responsive Design, Branding und Corporate Identity – also genau das, was man nach einem Styling-Update manuell durchklicken würde: Passt die Darstellung auf Mobilgeräten? Stimmen Farben und Schriften mit der CI überein?
- 18 UX-Tests decken Konversationsfluss, Fehlerbehandlung und Antwortzeiten ab. Sie prüfen, wie sich der Chatbot bei leeren Eingaben verhält, was bei langen Wartezeiten passiert und ob unerwartete Sequenzen sauber abgefangen werden.
- 15 Barrierefreiheits-Tests führen ein automatisiertes Audit auf Basis von Axe durch und prüfen unter anderem Tastaturnavigation und ARIA-Attribute. Axe deckt einen wesentlichen Teil der automatisiert prüfbaren WCAG-Kriterien ab – vollständige WCAG-Konformität lässt sich zwar nicht rein automatisiert nachweisen, aber die häufigsten und kritischsten Fehler werden zuverlässig gefunden.
Nach einem Testdurchlauf bekommt das Team eine strukturierte Checkliste, und bei Auffälligkeiten werden automatisch Jira-Tickets erstellt – keine Ampel, sondern direkt verwertbare Aufgaben, die ins Sprint-Backlog fließen.
Das Tool läuft intern bei uns, wird automatisch aktualisiert und ist für alle Teammitglieder über den Browser bedienbar. Es ist so konzipiert, dass es sich auf beliebige Chatbot-Implementierungen ausrichten lässt, unabhängig von Technologie oder Plattform.
Was das Tool abdeckt – und was nicht
Das Tool automatisiert die technische Qualitätsprüfung der Oberfläche: Es prüft, ob der Chatbot korrekt dargestellt wird, ob er zugänglich bedienbar ist und ob Gesprächsflüsse technisch funktionieren.
Was es nicht ersetzt, ist die inhaltliche Qualität der Chatbot-Antworten, die fachliche Korrektheit der Logik dahinter, Tone of Voice und Markenkonformität der generierten Texte oder mehrsprachige Edge Cases, die domänenspezifisches Urteilsvermögen erfordern.
Das ist keine Schwäche des Tools, sondern eine bewusste Abgrenzung seines Anwendungsbereichs. Was ich als PO nicht mehr tun muss, sind dieselben technischen Checks vor jedem Release. Was ich weiterhin tue, ist die inhaltliche Qualität zu beurteilen – und das ist auch die richtige Arbeitsteilung.
Drei Tage vom Problem zum produktionsreifen Tool
Der Teil, der mich selbst am meisten überrascht hat: Der initiale Sprint dauerte drei Tage – von der ersten Idee bis zum produktionsreifen, intern deployt laufenden Tool.
Möglich war das, weil ich den gesamten Code mit Claude Code entwickelt habe, dem CLI-Tool von Anthropic, das nicht nur Vorschläge macht, sondern eigenständig Dateien anlegt, Befehle ausführt und ganze Implementierungen umsetzt. Ich habe keine Zeile manuell geschrieben.
Mein Anteil lag woanders, und das ist eigentlich der springende Punkt: Was soll das Tool prüfen? Welche Tests sind für unsere Projekte relevant? Wie müssen Ergebnisse aufbereitet sein, damit das Team damit arbeiten kann? Wie integriert sich das in unsere bestehenden Jira-Workflows? Das sind PO-Fragen, und die musste ich selbst beantworten. Den Rest hat Claude Code gebaut.
Was mich an diesem Ansatz überzeugt, ist weniger die Geschwindigkeit selbst als das, was sie ermöglicht hat: Ich musste keine Entwicklungskapazität aus dem Team ziehen, kein Budget für ein externes QA-Projekt beantragen und nicht Monate auf eine Lösung warten, die ich heute brauche.
Kurze Unterbrechung – der Artikel geht gleich weiter!
Dein Thema?
Das klingt, als könnten wir dich bei deinem Thema unterstützen? Dann schreibe uns eine Nachricht und wir melden uns ganz unverbindlich bei dir!
Was sich seitdem verändert hat
Seit das Tool läuft, dauert Release-Testing bei uns Minuten statt Stunden. Ich gehe nicht mehr mit dem diffusen Gefühl in einen Release, dass ich vielleicht etwas übersehen habe – die Ergebnisse sind dokumentiert, nachvollziehbar und für alle im Team sichtbar, und zwar als Jira-Ticket mit konkreter Beschreibung statt als E-Mail oder Slack-Nachricht.
Was sich subtiler verändert hat: Ich habe wieder das Gefühl, die technische Qualität im Griff zu haben, nicht trotz des Tempos, sondern als Teil davon. Qualitätssicherung ist bei uns kein Bottleneck mehr, sondern ein Schritt im Prozess, der einfach passiert.
Das hat auch eine Wirkung aufs Team. Wenn Bugs automatisch als Tickets landen, entfällt die unbequeme Frage „Hat das eigentlich jemand geprüft?“ vor dem Release. Zuständigkeiten sind klar, der Status ist sichtbar, und niemand muss darauf vertrauen, dass der PO schon gründlich genug durchgeklickt hat.
Rückblickend hätte ich dieses Problem viel früher lösen können – und hätte es wohl auch getan, wenn die Hürde nicht so hoch gewirkt hätte. Ein eigenes Testing-Tool zu bauen klingt nach Entwicklerarbeit, nicht nach PO-Arbeit. Für mich war die entscheidende Erkenntnis, dass ich gar kein Entwickler werden musste. Ich musste nur wissen, was ich will – und genau das ist die Stärke eines POs.
Du willst sehen, wie das Tool an eurem Chatbot läuft?
Das Tool lässt sich auf beliebige Chatbot-Implementierungen ausrichten. Wenn du gerade eine KI-Lösung betreibst und dich fragst, wie strukturierte technische Qualitätssicherung ohne großen Overhead aussehen kann – schreib mir direkt. Ich zeige dir gerne, was das Tool kann und wo es an seine Grenzen stößt.
Quellen
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (2023)
- Deque Systems: Axe-Core – Open-Source-Engine für automatisierte Barrierefreiheitsprüfungen
- Bundesministerium für Arbeit und Soziales: EU-Barrierefreiheitsstärkungsgesetz (BFSG), in Kraft seit Juni 2025
Schreibe einen Kommentar