Software-Qualität im Jahr 2025 ist das Ergebnis von drei zusammenwirkenden Faktoren: einem funktionierenden Testprozess als Grundlage, dem Verständnis nicht-funktionaler Anforderungen wie Performance, Usability und Security sowie dem gezielten Einsatz von KI-Werkzeugen. Fehlt die prozessuale Basis, holt sie jeden ein, und zwar mit KI schneller als je zuvor.
Das Wichtigste in Kürze
- Unsaubere Prozesse und fehlende Grundlagenarbeit bremsen KI-Einführungen aus, weil Lücken im Setup sich mit KI schneller rächen als je zuvor mit Testautomation.
- Nicht-funktionale Qualitätsmerkmale wie Performance, Usability und Barrierefreiheit sind vom Bonus zum Pflichtprogramm geworden und ihr Gewicht steigt weiter.
- Testerinnen und Tester brauchen zukünftig ein breiteres technisches Skillset, dürfen aber ihre Fehlerintuition nicht verlieren, denn Bauchgefühl deckt einen erheblichen Teil der Defekte auf.
- Qualität muss früh ins Produkt, nicht erst am Ende: wer QA zu spät einbindet, zahlt deutlich mehr, sowohl finanziell als auch im Aufwand für Nachbesserungen.
KI beschleunigt nur, was schon sauber läuft
Künstliche Intelligenz verstärkt bestehende Schwächen, statt sie zu lösen. Wer einen lückenhaften Testprozess hat und KI darüberlegt, holt sich seine Probleme schneller zurück, nicht langsamer.
Matthias Groß beschreibt diesen Mechanismus aus der Testautomation, der sich jetzt wiederholt. Schon bei der Automatisierung galt: Ist der zugrunde liegende Prozess Müll, fällt das früher oder später auf den Tisch. Mit KI passiert genau das, nur in einem höheren Tempo. Unsaubere Setups und Lücken im Vorgehen holen das Team so schnell ein, dass die KI gar nicht im gewünschten Sinn genutzt werden kann.
Daraus folgt eine unbequeme Wahrheit für viele Projekte. KI ist oft das, was man vorschiebt, um sich nicht mit der eigentlichen Frage beschäftigen zu müssen. Die echten Themen liegen bei der Teststrategie und beim Testprozess: Wie teste ich wirklich? Was will ich überhaupt damit erreichen? Welches Problem löse ich? Wer diese Fragen mit einem KI-Werkzeug umgeht, macht nichts besser.
Vielleicht lenkt der aktuelle Hype den Blick aber genau dorthin zurück. Wenn KI nur auf einem soliden Fundament funktioniert, wird die Grundlagenarbeit wieder zum Pflichtprogramm.
Warum Grundlagenarbeit jetzt wichtiger wird, nicht unwichtiger
Ein einheitliches Verständnis und ein gelebter Prozess sind die Voraussetzung dafür, dass KI im Testen überhaupt trägt. Ohne diese Basis wird jede weitere Schicht schwerer, egal ob Automation oder KI.
Die etablierten Methoden im Testen sind teils Jahrzehnte alt, das Rahmenwerk hinter den gängigen Zertifizierungen existiert seit rund 20 Jahren. Diese Reife ist ein Vorteil. Es sind erprobte, klar definierte Konzepte mit einer gemeinsamen Sprache.
KI dagegen ist neu und ändert sich dynamisch. Selbst die Begriffe sind noch unscharf. Der eine spricht von KI-Agenten, der nächste von Prompt-Chains, und oft meint jeder etwas anderes. Bevor ein Team KI sinnvoll einsetzt, muss es klären, was die Begriffe konkret bedeuten.
Genau hier zahlt die alte Grundlagenarbeit ein. Wenn ein Unternehmen sagen kann “das ist unser Prozess und den leben wir so”, hat es die Basis, auf der KI funktioniert. Fehlt diese Basis, wird der Einstieg in Automation oder KI deutlich mühsamer.
Vibe-Coding produziert Software, die getestet werden muss
Mit KI entsteht Software in einem Tempo, das das gewohnte QA-Vorgehen überrollt. Wer testet, hängt strukturell hinterher, weil er ein Thema erst verstehen muss, bevor er es absichern kann.
Auf der anderen Seite stehen Menschen, die mit KI einfach machen. Aus einem Hackathon heraus entsteht etwas, das funktioniert, ohne dass jemand vorab über Qualität oder Sicherheit nachgedacht hat. Das Problem dabei: Was so entsteht, lässt sich später kaum noch einfangen.
Bitte, bitte nicht aus einem Hackathon heraus ein Produkt entwickeln, sondern macht euch vorher Gedanken. Baut vorher Qualitätssicherung ein, baut vorher Security ein, weil ihr es später nicht mehr eingefangen bekommt.
— Wolfgang Sperling
In den kommenden Monaten und Jahren wird viel Software entstehen, die schnell hingeworfen ist und deren Qualität fraglich bleibt. Testen muss damit umgehen. Mit 15-seitigen Excel-Testlisten kommt man da nicht weit. Solche Listen existieren weiter und funktionieren manchmal sogar, aber sie reichen für diese neue Geschwindigkeit nicht.
Die nicht-funktionalen Qualitätsmerkmale rücken in den Vordergrund
Der Fokus im Testen verschiebt sich von reiner Funktionalität hin zu nicht-funktionalen Kriterien. Funktionalität bleibt der Anfang, aber sie ist längst nicht mehr das, was gute Software ausmacht.
Christian Mercier zieht den Vergleich über die Jahre. Vor etwa 30 Jahren reichte es, wenn ein Stück Software überhaupt seine Funktion erfüllte. Heute liegt die Messlatte höher. Performance war früher nachrangig, heute erwartet jeder schnelle Antworten. Usability musste lange nur brauchbar sein, heute wird sehr gute Bedienbarkeit verlangt. Barrierefreiheit war einmal ein Alleinstellungsmerkmal, heute gehört sie zum Standard.
Auch die einschlägigen Qualitätsmodelle spiegeln diese Verschiebung. Wolfgang verweist darauf, dass dort der Funktionalität ein einzelner Satz gewidmet ist, während mehrere Kriterien auf den nicht-funktionalen Bereich entfallen.
Mit KI-Agenten verlagert sich zudem ein Teil der Qualitätssicherung in die Produktion. Wer Agenten einsetzt, muss sich fragen, was im laufenden Betrieb passiert und mit welchen Mitteln sich Risiken dort absichern lassen. Die Plattformanbieter liefern Werkzeuge zur Risiko-Mitigation. Welche du davon einsetzt, wie du sie einsetzt und konfigurierst, wird zur konkreten Testaufgabe.
Fehlersuche in der KI verlangt neue Lesefähigkeiten
Beim Testen von KI-Systemen analysierst du Traces statt klassischer Testergebnisse. Ein Trace dokumentiert die einzelnen Schritte innerhalb der KI und kann schnell mehrere Seiten umfassen.
Die Arbeit daran ist anstrengend zu lesen, aber machbar. Du musst erkennen, ob überhaupt ein Fehler vorliegt und welcher Art er ist. Ein typischer Fall: Eine Funktion wird dreimal aufgerufen, und keinmal kommt eine Antwort zurück. Dann stellt sich die Frage, ob der Prompt verbessert werden muss.
Die Mechanismen zum Fehlerfinden sind dabei genau die, die Tester ohnehin antrainiert haben. Das ist eine gute Ausgangslage. Hinzu kommt mehr Nähe zum Code und ein Gespür dafür, was beim Prompting passiert und was als Antwort zurückkommt.
Bei nicht-deterministischen Systemen geht es nicht mehr um Testen im klassischen Sinn, sondern um Validierung. Du arbeitest mit Kriterien, nicht mit fixen Sollwerten, weil dasselbe Ergebnis nicht garantiert reproduzierbar ist.
Das Skillset des Testers wird breiter und technischer
Fachliches Domänenwissen allein reicht nicht mehr. Das Profil verlangt zunehmend technische Tiefe, und gleichzeitig müssen sich Fachbereich und IT aufeinander zubewegen.
Matthias beschreibt zwei Bewegungsrichtungen. Der Fachbereich muss sich der Technik annähern und lernen, nicht nur funktional zu testen, sondern auch Aspekte wie Usability. Die IT rückt näher an den Fachbereich heran und unterstützt bei Testautomation, Performance-Tests oder Kompatibilität. Das Ziel ist ein gemeinsames Produkt statt eines Codes, der über den Zaun zum Fachbereich geworfen wird mit dem Auftrag “jetzt teste mal”.
Eines darf bei aller Technisierung nicht verloren gehen: die Intuition für den Fehler. Dieses Berufsgespür treibt die Suche an. Nach Matthias’ Einschätzung werden 40 bis 50 Prozent der Fehler nicht über einen sauberen Testfall gefunden, sondern über ein Bauchgefühl, dem man nachgeht.
Diese Intuition ist eine Form unbewusster Kompetenz, die über Jahre wächst. Sie und die methodische Ausdauer ergänzen sich. Beides zusammen deckt die Basis ab und findet zugleich das, was kein Testfall vorgesehen hat.
Qualität ist am Ende ein Gefühl
Qualität lässt sich als Gefühl beschreiben, und alle Qualitätsmerkmale zahlen darauf ein. Die funktionalen und nicht-funktionalen Kriterien sind Hilfsmittel, um dieses Gefühl messbar zu machen.
Gute Qualität merkt der Nutzer. Seine Daten sind sicher, die Software ist schnell, sie ist angenehm zu bedienen, sie tut, was er will. Die einzelnen Merkmale steigern diese innere Zufriedenheit, jedes auf seine Weise.
Daraus ergibt sich die Rolle des Testers neu. Er ist der Advokat des Nutzers, der dessen Perspektive ins Team trägt. Dieser ganzheitliche Blick deckt viele Kriterien zugleich ab und ist ein Skill, den du gezielt pflegen solltest.
Dazu gehört auch, den Status quo zu hinterfragen. Wer seit Jahren Testfallkataloge pflegt und durchführt, sollte prüfen, ob das noch passt. Stimmt die Granularität? Teste ich die richtigen Dinge? Sind die Anforderungen andere geworden? Dieses kritische Reflektieren ist keine Nebenaufgabe. Wenn es nicht ohnehin schon zum Job gehört, muss es einer werden, denn niemand sonst im Projekt geht mit diesem Blick an die Dinge heran.
Austausch schlägt Alleingang
In einer schnellen Entwicklung ist der Wissensaustausch das wirksamste Werkzeug, um mitzuhalten. Keine KI ersetzt das Netzwerk, den Blick über den Tellerrand und die kurzen Wege zu anderen.
Regionale Communities zeigen, wie schnell das tragen kann. Eine im Südwesten neu gegründete Tester-Community brachte zuvor unbekannte Leute zusammen, und nach kurzer Zeit war man stärker vernetzt, mit kürzeren Wegen, um Meinungen einzuholen. Wer so etwas anbietet, merkt schnell, dass die Leute hinströmen und sich austauschen wollen.
Der Austausch wirkt, weil dort unterschiedliche Hintergründe zusammenkommen. Systemintegratoren, reine Testprovider, Leute, die selbst IT-Lösungen umsetzen. Aus dieser Mischung entstehen Gespräche über tagtägliche Herausforderungen, aus denen jeder etwas mitnimmt.
Für die kommende Zeit zählt vor allem eines: konkrete Lösungen teilen, nicht nur Konzepte auf hohem Abstraktionsniveau. Zeig, was bei dir funktioniert hat, damit andere es in ihrem Alltag umsetzen können. Es gibt viel ungehobenes Wissen, von dem alle lernen könnten. Hab den Mut, deine Lösungen zu zeigen, sie werden dankend angenommen.
