TL;DR: KI verändert, wie Software gebaut wird – und schafft dabei Kapazitäten für Dinge, die schon immer wichtig waren, aber selten Aufmerksamkeit bekommen haben. Qualitätssicherung ist eine davon. Automatisierte Akzeptanztests, auch E2E-Tests genannt, stehen am Ende der QA-Kette – und sind das Erste, das wegfällt, wenn die Zeit knapp wird. Warum das ein Problem ist, warum das Vier-Augen-Prinzip wichtiger denn je ist – und warum KI-gestützte Entwicklung automatisierte E2E-Tests nicht optional macht, sondern zwingend notwendig.

KI verändert die Regeln – auch für Qualität

KI verändert, wie wir Software entwickeln. Nicht als Selbstzweck – sondern weil sie verschiebt, wo menschliche Kapazität wirklich gebraucht wird. Und diese neu gewonnene Kapazität fließt fast reflexartig in das, was sichtbar ist: neue Features, schnellere Lieferung, mehr Funktionalität.

Was dabei weiterhin zu kurz kommt, ist das, was schon vor der KI zu kurz kam:

  • Code-Qualität und technische Sauberkeit
  • Wartbarkeit und Erweiterbarkeit
  • Skalierbarkeit und langfristige Stabilität

Software nicht nur effizienter, sondern besser bauen.

Das sind die Dinge, die niemand vorführt – für die aber alle irgendwann zahlen. Wer KI nutzt, um Software effizienter zu entwickeln, braucht einen Qualitätssicherungsprozess, der diesem Anspruch gerecht wird.

Qualitätssicherung – ein kurzer Überblick

Qualitätssicherung beginnt früher, als die meisten denken. In einem früheren Artikel haben wir beschrieben, wie KI bereits bei der Anforderungsanalyse eine Rolle spielt. Qualität wird nicht am Ende eingebaut; sie ist durchgängig verankert:

  • Anforderungsanalyse – Spezifikationen, die präzise genug sind, um testbar zu sein
  • Code-Reviews & statische Analyse – Qualität direkt im Code adressiert
  • Unit-Tests – einzelne Komponenten isoliert getestet
  • Integrations- & API-Tests – wie die Schichten zusammenspielen
  • Automatisierte Akzeptanztests (E2E) – die gesamte Anwendung aus Nutzerperspektive

Jede Schicht fängt andere Fehler ab. Automatisierte Akzeptanztests kommen zuletzt – die letzte unabhängige Prüfung, bevor Software echte Nutzer erreicht. Und weil sie zuletzt kommen, fallen sie als Erstes weg, wenn der Druck steigt.

QA-Ebenen im Softwareentwicklungsprozess bei PLATIS

QA ist in jedem Schritt des Softwareentwicklungsprozesses wichtig. E2E-Tests markieren den letzten Schritt vor dem Release – und damit die letzte Chance, abzufangen, was Ihre Kunden nicht erreichen sollte.

Was E2E-Tests tatsächlich tun

E2E-Tests simulieren, was ein Mensch tun würde: die Anwendung öffnen, Workflows durchklicken, Formulare ausfüllen, Ergebnisse prüfen. Frontend und Backend gemeinsam getestet, nicht isoliert. Genau hier tauchen Fehler auf, die Unit-Tests konstruktionsbedingt nicht erkennen können: Brüche zwischen Schichten, Timing-Probleme, Zustände, die nur durch echte Nutzerinteraktion entstehen.

Vier Argumente stechen heraus:

Regressionssicherheit – Jedes neue Feature birgt das Risiko, etwas zu brechen, das vorher funktioniert hat. E2E-Tests machen dieses Risiko beherrschbar – nicht durch Optimismus, sondern durch systematische Prüfung nach jeder Änderung.

Refactoring als echte Option – Ohne automatisierte Sicherheitsnetze weiß niemand, was eine strukturelle Änderung auslöst – also passiert sie nicht. Mit E2E-Tests wird Refactoring planbar, weil Regressionen sofort sichtbar werden. Das ist ein Argument für die Langlebigkeit von Software.

Edge Cases in der Breite – Manuelles Testen unter Zeitdruck deckt die Hauptszenarien ab, selten mehr. E2E-Tests prüfen den 50. Edge Case mit derselben Gründlichkeit wie den ersten. Menschen schaffen das nicht – wir werden müde, priorisieren, lassen Dinge durch.

Frontend-Testbarkeit – Unit-Tests sehen den Browser nie. Ist ein Element sichtbar? Ist ein Button deaktiviert? Erscheint eine Fehlermeldung an der richtigen Stelle? Das sind Fragen, die nur E2E-Tests beantworten können.

Das Vier-Augen-Prinzip

Wer den Code schreibt, schreibt auch seine eigenen Annahmen hinein. Tests, die von derselben Hand stammen, validieren diese Annahmen – nicht ob sie richtig sind. Das ist keine Kritik; es ist eine kognitive Eigenschaft, die sich nicht wegdisziplinieren lässt.

Qualitätssicherung funktioniert, weil sie aus einer unabhängigen Perspektive kommt:

  • Andere Erwartungen an das Verhalten der Software
  • Andere mentale Modelle davon, was „korrekt" bedeutet
  • Andere Instinkte dafür, wo etwas schiefgehen könnte

Was das für KI-gestützte Entwicklung bedeutet: KI, die Code schreibt und dann Tests für diesen Code generiert, liefert keine unabhängige Qualitätssicherung – sie verlängert dieselbe Perspektive. Das Vier-Augen-Prinzip läuft mit KI nicht ab. Es wird wichtiger.

Warum man auf automatisierte E2E-Tests nicht verzichten sollte

Was passiert konkret, wenn E2E-Tests fehlen?

  • Bugs erreichen die Produktion, die manuelles Testen unter Zeitdruck schlicht übersehen hat
  • Release-Angst entsteht – ohne automatisierte Sicherheitsnetze wird jedes Deployment zum Bauchgefühl. Teams deployen seltener, weil Zuversicht Zeit kostet, die niemand hat
  • Grüne Unit-Tests erzeugen falsche Sicherheit – „alle Tests bestehen" sagt nichts darüber aus, ob die Anwendung als Ganzes funktioniert. Das ist möglicherweise die gefährlichste Folge von allen
  • Refactoring wird aufgeschoben, weil niemand weiß, was eine tiefere Änderung auslöst – und eine Codebasis, die nicht gepflegt wird, wird zur Last: neue Features werden schwerer, Sicherheitsupdates riskanter, die Kosten steigen still, lange bevor es sichtbar wird

Jetzt mal ehrlich: Gibt es irgendjemanden, der es genießt, zum zehnten Mal eine ganze Anwendung durchzuklicken, nur um sicherzustellen, dass nichts kaputt gegangen ist?

Automatisierte E2E-Tests sind die Antwort: Hunderte von Szenarien, die nach jeder Änderung erneut durchlaufen – zu vernachlässigbaren Kosten im Vergleich zum manuellen Testen.

Drei Fragen, über die es sich lohnt nachzudenken:

  • Wie lange dauert ein manueller Regressionstest vor einem Release?
  • Wann wurde zuletzt ein Refactoring aufgeschoben, weil das Risiko nicht einschätzbar war?
  • Wer schreibt die Tests – und ist es dieselbe Person, die den Code geschrieben hat?

Wie wir E2E-Tests bei PLATIS einsetzen – und wie wir KI dabei einbeziehen, um gute Qualität und Abdeckung zu erreichen, ohne das Vier-Augen-Prinzip zu untergraben – das ist Thema des nächsten Artikels.