Software-Qualität ist keine Eigenschaft eines einzelnen Tests, sondern eine gemeinschaftliche Aufgabe im gesamten Entwicklungsteam. Sie entsteht, wenn Product Owner, Developer und Tester gemeinsam definieren, was Qualität für ihr Produkt konkret bedeutet. Gerade beim Testen von KI-Systemen zeigt sich: klassische Qualitätskriterien reichen nicht aus, und die Frage “Was ist eigentlich Qualität?” bleibt oft unbeantwortet.
Das Wichtigste in Kürze
- Agilität hat das Thema Softwarequalität aus der Nische geholt: Wo früher alle paar Monate regressionsgetestet wurde, erzwingen zweiwöchige Sprints kontinuierliche Qualitätsarbeit im gesamten Team.
- Qualität ist heute eine gemeinschaftliche Aufgabe, an der Product Owner, Business-Analysten, UX-Designer und Entwickler gemeinsam mitdenken, nicht mehr allein die Tester.
- KI-gestützte Testwerkzeuge helfen bei Anforderungsprüfungen und der Ableitung von Testideen, setzen aber eine organisatorische Reife voraus, die viele Teams noch nicht erreicht haben.
- KI-Systeme zu testen wirft eine Grundsatzfrage auf, die längst hätte beantwortet sein sollen: Was bedeutet Qualität konkret für unser Produkt, und wann ist genug Qualität erreicht?
Wie Qualität aus dem Kellerloch in die Projekte kam
Software-Qualität war lange ein Randthema, abgeschoben in fensterlose Testräume mit ausgemusterten Rechnern. Heute liegt sie täglich auf dem Tisch jedes Entwicklungsteams. Diese Verschiebung der letzten gut 20 Jahre hat die Profession grundlegend verändert.
Im klassischen Modell wartete der Test, bis die Entwicklung fertig war. Man schrieb vorab ein paar Testfälle, prüfte, spielte Fehler zurück und hatte dann wieder wochenlang Ruhe. Qualität war ein nachgelagerter Schritt, keine gemeinsame Aufgabe.
Diese Zeiten sind vorbei, und zwar aus einem konkreten Grund: Software steckt heute überall, auch in Business-Anwendungen, die früher als reine Werkzeuge galten. Der Anspruch an funktionierende Software gilt inzwischen flächendeckend. Wenn ein Windows-Update schlecht getestet ist, sieht man sehr schnell, wie viel daran hängt.
Warum Agilität ein Boost für das Testing war
Agiles Arbeiten hat Qualität und Testing nach vorne gezogen, weil das alte Warten plötzlich nicht mehr funktionierte. Iterationen, Sprints und ständige Regressionstests zwangen Teams, Qualität anders zu organisieren.
Was früher alle paar Monate geprüft wurde, musste auf einmal alle zwei Wochen laufen. Für Tester und Qualitätsleute war das eine harte Umstellung. Der erste Reflex waren Mini-Wasserfälle: An den letzten zwei Sprinttagen wurde schnell vor sich hingetestet, und ein Fehler machte die ganze Arbeit zunichte.
Aus diesem Schmerz entstand eine bessere Praxis. Qualität wird heute ganzheitlicher gedacht, nicht mehr nur als Profession einer einzelnen Rolle. Im Refinement und im Planning macht sich das Team gemeinsam Gedanken: Wo könnte man was testen? Auf welcher Teststufe ergibt was Sinn?
Ein zentraler Gewinn ist, nicht mehr alles doppelt zu testen. Statt jeden Fall von Unit- und Integrationstests bis hinauf in die Akzeptanztests zu wiederholen, weißt du, welche Tests auf welcher Ebene laufen. Der Fachbereich rückt näher heran und gewinnt Vertrauen in das, was passiert.
Schon 2003 lautete eine These: Agilität heißt Qualität. Die Reaktion war heftig, weil viele Agilität mit “wir müssen nichts mehr dokumentieren” verwechselten. Die Praxis hat das Gegenteil gezeigt.
Wenn ich nicht auf Qualität achte, fliegt mir nach dem dritten Sprint alles um die Ohren. Richard Seidl
Hinter dem vermeintlich locker-flockigen agilen Entwickeln steckt viel Struktur und Disziplin. Genau dadurch funktioniert Qualität überhaupt erst.
Agilität ist nicht vorbei, sie wird erst verstanden
Die These, Agilität sei am Ende, beruht auf einem Missverständnis. Agiles Arbeiten meint im Kern, sich als Team selbst einen Prozess zu gestalten, nicht ein bestimmtes Framework abzuarbeiten.
Welches Framework dabei genutzt wird, ist zweitrangig. Ein Team bedient sich aus Scrum, Kanban, Design Thinking, Working Out Loud, Retrospektiven oder auch aus großen Modellen wie SAFe und LeSS. Entscheidend ist, sich die Bausteine herauszusuchen, die zum eigenen Prozess passen.
Was bleibt, ist die Idee dahinter: als Team gemeinsame Werte und eine Vision verfolgen und daraus einen Prozess bauen, der Spaß macht, effizient ist und über die Zeit besser wird.
Der schwierige Teil ist die Selbstverantwortung. Wer aus klassischen Umgebungen kommt und sich plötzlich selbst einen Prozess gestalten soll, erlebt das als anstrengende Veränderung. Diese Anstrengung lässt sich aber nicht umgehen, wenn man komplexe Anforderungen bewältigen will. Teams verstehen gerade erst wirklich, was Agilität bedeutet.
Bessere Tools haben den Wartungs-Albtraum entschärft
Die Werkzeuglandschaft im Test hat sich spürbar verbessert und nimmt heute echte Arbeit ab. Auf Entwicklerseite unterstützen Skripte, Open-Source-Werkzeuge, Frameworks und automatisierte Sicherheitsüberprüfungen die Qualität.
Automatisierungswerkzeuge werden schlauer. Konzepte wie Keyword-Driven und Data-Driven Testing sind etabliert, und die Objekterkennung funktioniert zunehmend zuverlässig. Trotzdem braucht jede Entscheidung Hirnschmalz: Was automatisierst du überhaupt, und wo ergibt es Sinn?
Der frühere Reflex, alles über die UI zu automatisieren, führte oft in hohen Wartungsaufwand. Heute setzt das Team Tests bewusst auf der passenden Ebene an, meistens unterhalb der UI. Entwickler und andere im Team helfen, Tests dort anzusiedeln, wo sie hingehören. Ein schwerer UI-Wasserkopf, der stundenlang mitläuft, lässt sich so reduzieren.
KI ist kein Allheilmittel für Testprobleme
KI hilft im Testing nur dort, wo das eigentliche Problem auch ein KI-Problem ist. In vielen Workshops zeigt sich, dass die drängendsten Probleme woanders liegen und sich nicht mit KI lösen lassen.
Die Gefahr ist, KI zum Allerweltswerkzeug zu erklären und damit Probleme zu bearbeiten, die man gar nicht hat. Budgets sind da, die Töpfe sind voll, und genau das verleitet zu Aktionismus.
Es gibt aber sinnvolle Einsatzfelder. Dazu gehören die Prüfung von Requirements, das Ableiten von Testideen und Unterstützung bei der Automatisierung. Voraussetzung ist eine gewisse Reife im Team, sonst läuft der Einsatz ins Leere.
Die eigentliche Frage lautet: Was ist Qualität?
KI wirft das Testing auf eine Grundfrage zurück, die längst hätte beantwortet sein müssen. Die klassischen Qualitätskriterien sind deterministisch und klar: Funktionalität, Effizienz, Usability, Security. Beim Testen von KI-Systemen reichen sie nicht mehr weit.
Damit steht die Frage im Raum, was Qualität überhaupt bedeutet. Stellt man sie in einem Team, wird es still. Über diese Frage hat sich kaum jemand ernsthaft Gedanken gemacht, abgesehen von einem Absatz im Testkonzept.
Das Muster ist nicht neu. Ein Performance-Kriterium wie “das Ding muss schnell sein” zwang Tester schon immer, jemanden zu suchen, der definiert, was “schnell” konkret heißt. Oft fand sich niemand, und die Zahlen wurden aus der Nase gezogen.
Heute verschärft sich dieses Problem. Software integriert viele fachliche Sichten und bedient viele Stakeholder. Die schwierige Frage ist nicht nur, was Qualität ist, sondern auch, wer sie beantwortet und wann genug Qualität erreicht ist.
Diese Fragen bleiben offen, und das ist ehrlich so zu benennen. KI wird nicht verschwinden, auch wenn nicht alles ein LLM ist. Das ganze System muss trotzdem funktionieren. Wie der Qualitätsbegriff dafür künftig geformt wird und wie Testorganisationen sich verändern, ist noch nicht entschieden.
Häufig gestellte Fragen
Wer ist im agilen Team für Softwarequalität verantwortlich?
Qualität ist eine gemeinschaftliche Aufgabe, nicht die Zuständigkeit einer einzelnen Rolle. Product Owner, Business-Analysten, UX-Designer, Entwickler und Tester definieren gemeinsam, was Qualität für ihr Produkt konkret bedeutet. Früher wartete der Test, bis die Entwicklung fertig war, prüfte nachgelagert und spielte Fehler zurück. Dieses Modell trägt bei kurzen Iterationen nicht mehr.
Warum funktioniert nachgelagertes Testen am Ende der Entwicklung nicht mehr?
Weil aus Prüfzyklen von mehreren Monaten Zyklen von zwei Wochen geworden sind. Der erste Reflex vieler Teams waren Mini-Wasserfälle: An den letzten zwei Sprinttagen wurde schnell getestet, und ein einziger Fehler machte die Arbeit zunichte. Erst aus diesem Schmerz entstand die Praxis, Qualität über den ganzen Sprint zu organisieren.
Bedeutet agiles Arbeiten weniger Dokumentation und weniger Disziplin?
Nein. Diese Gleichsetzung war schon 2003 ein Missverständnis, als die These “Agilität heißt Qualität” heftige Reaktionen auslöste. Hinter dem vermeintlich locker-flockigen agilen Entwickeln steckt viel Struktur und Disziplin. Wer nicht laufend auf Qualität achtet, dem fliegt spätestens nach dem dritten Sprint alles um die Ohren.
Welches agile Framework sollte ein Team wählen?
Das Framework ist zweitrangig. Teams bedienen sich aus Scrum, Kanban, Design Thinking, Working Out Loud, Retrospektiven oder größeren Modellen wie SAFe und LeSS und wählen die Bausteine, die zum eigenen Prozess passen. Der Kern agilen Arbeitens ist, sich als Team aus gemeinsamen Werten selbst einen Prozess zu bauen. Der schwierige Teil daran ist die Selbstverantwortung.
Sollte man Testautomatisierung über die Benutzeroberfläche aufbauen?
Meist nicht. Der frühere Reflex, alles über die UI zu automatisieren, führte zu hohem Wartungsaufwand und zu einem schweren UI-Wasserkopf, der stundenlang mitläuft. Sinnvoller ist es, Tests bewusst auf der passenden Ebene anzusiedeln, häufig unterhalb der UI. Entwickler und andere Teammitglieder helfen bei dieser Einordnung.
Wo hilft KI beim Testen wirklich weiter?
KI hilft dort, wo das eigentliche Problem auch ein KI-Problem ist. Sinnvolle Einsatzfelder sind die Prüfung von Requirements, das Ableiten von Testideen und Unterstützung bei der Automatisierung. Voraussetzung ist eine gewisse organisatorische Reife im Team. Fehlt sie, läuft der Einsatz ins Leere. Vorhandene Budgets verleiten zu Aktionismus an Problemen, die man gar nicht hat.
Warum reichen klassische Qualitätskriterien beim Testen von KI-Systemen nicht aus?
Kriterien wie Funktionalität, Effizienz, Usability und Security sind deterministisch und klar umrissen. Bei KI-Systemen tragen sie nicht weit. Dadurch kommt eine Frage zurück, die viele Teams nie beantwortet haben: Was bedeutet Qualität konkret für dieses Produkt, wer entscheidet das, und wann ist genug Qualität erreicht? Im Testkonzept steht dazu oft nur ein Absatz.
