Next-Gen Software Engineering bezeichnet den Ansatz, Softwarekonstruktion und Qualitätssicherung enger zu verzahnen: Jeder Softwarespezifikation entspricht eine Testspezifikation, jedem Modell ein Testmodell. KI-gestützte Automatisierung erhöht den Grad der Testautomatisierung, ersetzt aber keine Experten. Kritische Software braucht praktisch ausgebildete Testerinnen und Tester mehr denn je.
Das Wichtigste in Kürze
- KI-generierter Code verursacht langfristig hohe Kosten, weil er oft qualitativ schlechter ist und dennoch versioniert, dokumentiert und getestet werden muss.
- Testspezifikationen sind de facto Testmodelle, auch wenn die Branche sie nicht so nennt: Sie halten die Geschäftslogik technologieübergreifend konsistent, während sich darunter liegende Technologien verändern.
- Die Tester-Rolle hat eine rosige Zukunft, weil Software in immer kritischeren Bereichen eingesetzt wird und Qualitätssicherung sich nicht vollständig automatisieren lässt.
- Weiterbildung im Software-Testing muss stärker auf praktische Erfahrung setzen, weil nur handlungsbasierte Lerneffekte echtes Expertenwissen aufbauen, das Theorie allein nicht vermittelt.
Testen kann nur feststellen, ob Software gut oder schlecht ist
Prüfen hat eine systematische Grenze: Am Ende eines Testlaufs steht nur die Aussage, ob etwas funktioniert oder nicht. Diese Grenze ist der Ausgangspunkt für ein Umdenken im Software Engineering.
Ina Schieferdecker hat über Jahrzehnte an der Qualitäts- und Prüfseite gearbeitet und dabei konsequent automatisiert. Die Testautomatisierung sei breit angekommen, die generische Testarchitektur aus dem ISTQB-Bereich Test Automation Engineer werde inzwischen auf Frameworks wie das Robot Framework angewandt. Trotzdem bleibe ein Frust: Konstatieren reicht nicht.
Der Schluss daraus ist konstruktiv gemeint. Softwarekonstruktion und Softwareanalyse müssen enger verknüpft werden, statt nachgelagert zu prüfen, was die Entwicklung produziert hat.
Warum Software und Testsoftware gegeneinander entwickelt werden sollten
Zu jedem Softwaresystem gehört ein Testsystem, zu jeder Softwarespezifikation eine Testspezifikation, zu jedem Software-Modell ein Test-Modell. Dieses Prinzip lässt sich durchdeklinieren, bis hinauf zu den Anforderungen.
Als Referenz dient das V-Modell, das im deutschsprachigen Raum verbreitet ist. Sein dokumentenbasierter Ansatz deckt nicht nur die Softwareseite ab, sondern auch die Testseite, und stimmt beide aufeinander ab. Software und Testsoftware entstehen so parallel und gegeneinander.
Der Gedanke reicht bis zu den Anforderungen selbst. Diese sollten aus der Systemperspektive und aus der Testperspektive definiert werden. Sind Anforderungen nicht testbar, lohnt sich die Entwicklung nicht.
Model-Based Testing kommt unter neuem Namen auf die Straße
Low-Code- und No-Code-Ansätze bringen Model-Based Testing in die Praxis: Der neue Begriff wird akzeptiert, wo der alte schwer vermittelbar war.
Viele Vorträge sprechen heute von Testspezifikationen, formuliert im strukturierten Test. Aus mathematischer Sicht sind das Modelle, auch wenn sie nicht so genannt werden. Es sind Testmodelle.
Der Vorteil der Spezifikationsebene zeigt sich im Vergleich zum Ausprogrammieren. Wer Keyword-Driven ausprogrammiert oder die Seitenlogik einer Web-Oberfläche abbildet, muss tief im Detail stecken, und solcher Code ist schwer zu warten. Auf Spezifikationsebene lässt sich die Logik technologieübergreifend ausformulieren. Die Technologie kann sich weiterentwickeln, die Geschäftslogik hat Bestand.
Vibe Coding holt sich ein teures Problem über die Hintertür
Schnell durchgewunkener, schlechter Code wird im Long Run sehr teuer. Genau deshalb gehört das Abfangen auf die Konstruktionsseite, also nach vorne, an die Anforderungen.
Das ist ein Shift-Left-Ansatz unter anderem Namen. Testen beginnt beim Requirements Engineering. Sind die Anforderungen nicht testbar, gibt es keine Chance, ein brauchbares System zu bauen.
Automatisch erzeugter Code bringt eigene Risiken mit. Er kann nicht nur funktional falsch sein, sondern auch performancemäßig schlecht oder als Spaghetti-Code entstehen. Sprachmodelle sind bislang nicht auf exklusiven, sehr guten Code trainiert, sondern ziehen alles herein.
Wir holen uns da ein großes Problem über die Hintertür rein, weil ein zu schnell durchgewunkener schlechterer Code im Long Run sehr, sehr teuer wird. Ina Schieferdecker
Jede zusätzliche Codezeile kostet
Der Wow-Effekt der KI-Generierung verdeckt die Folgekosten. Erzeugter Code muss überprüft, weitergezogen, versioniert, dokumentiert und getestet werden. Diese Rechnung hat bisher kaum jemand aufgemacht.
Sprachmodelle produzieren viel Text und Code, der nach Überprüfung schreit. Selbst die Aufforderung, sich knapp und prägnant zu halten, ändert wenig: Das Ergebnis bleibt eloquent und stellt sich dar.
Ina rechnet damit, dass der ernsthafte produktive Durchbruch noch fünf bis zehn Jahre braucht. Wer LLMs oder kleinere Sprachmodelle ernsthaft anwendet, sei bereits auf dem Weg der Desillusionierung und verstehe besser, was nicht geht.
Wie der ModelBus KI ins Software Engineering einbettet
Software Engineering ist Information verarbeitendes Engineering, und jede Information lässt sich modellieren. Anforderungen brauchen andere Modelle als Tests, Tests andere als Systementwürfe oder Architekturen.
Das bei Fraunhofer entwickelte Konzept ModelBus folgt der Idee eines Servicebus, verknüpft aber Modelle und Informationen. Über den Bus laufen Informationen von der Anforderung in den Systementwurf oder Testentwurf, von der Testausführung zurück in die Systemanalyse und in das Nachjustieren der Anforderungen.
Für jede Engineering-Aufgabe gibt es Frontrunner-Werkzeuge, niemals die eierlegende Wollmilchsau. Setzt man an jeder Stelle KI an, wird die Frage interessant, wie die einzelnen Chatbots voneinander erfahren, was gerade in welcher Aufgabe passiert. Ein fertiges Bild dieser Werkzeugklasse gibt es noch nicht.
KI macht Bottom-Up-Modelle möglich
Klassisches Model-Driven Software Engineering arbeitet Top-Down: Man entwirft in Modellen, doch irgendwann holt die Praxis der Entwicklung ein, die Modelle werden nicht mehr nachjustiert und geraten außer Sync.
KI bringt ein neues Element. Aus Code lassen sich Muster erkennen, und Muster sind Abstraktionen, also Modelle. Damit entsteht die Möglichkeit, nicht nur Top-Down zu modellieren, sondern auch Bottom-Up Modelle aus bestehendem Code zu ziehen.
Software ist Sprache, formalisierter als die natürliche, und damit ein gutes Anwendungsgebiet für LLMs. Dasselbe gilt für Modelle. Hier liegt offenes Forschungsterrain, an dem viele Promotionen ansetzen können.
Theorie reicht für die nächste Generation von Testern nicht
Die Ausbildung in der Tester-Profession ist heute stark theoriebasiert. Es gibt ein Glossary und ein lebendiges Syllabus-Framework mit Foundation, Advanced und Expert Level sowie Spezialisten, aber praktische Übungen sind oft nicht Teil der Prüfung.
Das wird zum Problem, weil Software in immer kritischeren Bereichen steckt. In kritischen Infrastrukturen und geschäftskritischen Anwendungen muss Software zuverlässig, sicher und performant funktionieren. Diese Qualität sichern Expertinnen und Experten, und deren Können entsteht nicht durch Theorie allein.
Hinzu kommt eine Sorge: Sprachmodelle ziehen breites Wissen ein, während wenig Zeit bleibt, die nächste Generation an Experten auszubilden. Die Weiterbildung sollte Teilnehmende deshalb konsequent in herausfordernde praktische Aufgaben schubsen, damit echte Aha- und Lerneffekte entstehen.
Praktische Übungen erzeugen den Transfer, den abstrakte Beispiele nicht schaffen
Lerneffekt entsteht an echten Aufgaben, nicht an abstrakten Schulbeispielen. Ein Geldautomat oder ein isoliertes Eingabefeld trägt durch die Prüfung, aber der Transfer gelingt erst, wenn Teilnehmende eigene Anforderungen und User Stories mitbringen und daran Testfälle entwickeln.
Ina hat den Foundation Level an mehreren Universitäten gelehrt, mit einer durchgängigen praktischen Übungsserie über ein Semester oder einen zweiwöchigen Blockkurs. Ein nicht zu einfacher Anwendungsfall wurde durchdekliniert: auf Unit-, Integrations-, System- und Abnahmeebene, mit Leistungsfragen und Model-based, heruntergezogen auf die jeweils aktuellen Werkzeuge.
KI senkt die Hürde für genau diesen Ansatz. Der Aufwand, Übungen auszuprogrammieren und zu pflegen, war lange ein Hinderungsgrund. Mit KI lässt sich das leichter in den Griff bekommen, und es gibt kaum noch eine Ausrede, Praxis aus der Ausbildung herauszuhalten.
Die Testerrolle hat eine rosige Zukunft
Je kritischer die Bereiche werden, in denen Software läuft, desto unverzichtbarer wird Qualitätssicherung, und die lässt sich nicht durch Automatismen wegrationalisieren.
KI hebt den Automatisierungsgrad eine Stufe höher, und das ist gut so. Der Gewinn liegt darin, mit begrenzten Testressourcen smarter umzugehen, gezielt auf die Pain Points zu kommen und das so früh wie möglich. Genau darauf sollte die Profession hinarbeiten.
Häufig gestellte Fragen
Warum reicht es nicht, Software erst nach der Entwicklung zu testen?
Ein Testlauf liefert am Ende nur die Aussage, ob etwas funktioniert oder nicht. Dieses Konstatieren kommt zu spät, um Qualität zu erzeugen. Next-Gen Software Engineering verzahnt deshalb Konstruktion und Prüfung: Zu jeder Softwarespezifikation gehört eine Testspezifikation, zu jedem Modell ein Testmodell, zu jedem Softwaresystem ein Testsystem.
Woran erkennt man, dass eine Anforderung nicht taugt?
An ihrer Testbarkeit. Anforderungen sollten aus der Systemperspektive und aus der Testperspektive definiert werden. Lässt sich eine Anforderung nicht testen, gibt es keine Chance, ein brauchbares System zu bauen, und die Entwicklung lohnt sich nicht. Testen beginnt damit schon im Requirements Engineering, ein Shift-Left-Ansatz unter anderem Namen.
Ist Model-Based Testing in der Praxis angekommen?
Ja, meist unter anderem Namen. Low-Code- und No-Code-Ansätze bringen die Idee auf die Straße, und was als Testspezifikation im strukturierten Test bezeichnet wird, ist mathematisch gesehen ein Testmodell. Der Vorteil gegenüber ausprogrammierten Keyword-Skripten oder abgebildeter Seitenlogik: Auf Spezifikationsebene hat die Geschäftslogik Bestand, während sich die Technologie darunter weiterentwickelt.
Warum gilt KI-generierter Code als teuer, obwohl er schnell entsteht?
Weil jede zusätzliche Codezeile Folgekosten trägt: Sie muss überprüft, weitergezogen, versioniert, dokumentiert und getestet werden. Erzeugter Code kann funktional falsch, performancemäßig schlecht oder Spaghetti-Code sein. Sprachmodelle sind bislang nicht auf exklusiven, sehr guten Code trainiert, sondern ziehen alles herein. Schnell durchgewunkener Code wird im Long Run sehr teuer.
Wie weit sind Sprachmodelle im produktiven Software Engineering?
Der ernsthafte produktive Durchbruch dürfte noch fünf bis zehn Jahre brauchen. Wer LLMs oder kleinere Sprachmodelle ernsthaft anwendet, ist bereits auf dem Weg der Desillusionierung und versteht besser, was nicht geht. Die Modelle produzieren viel Text und Code, der nach Überprüfung schreit, auch wenn man ausdrücklich um Kürze bittet.
Kann KI Modelle aus vorhandenem Code gewinnen?
Ja. Aus Code lassen sich Muster erkennen, und Muster sind Abstraktionen, also Modelle. Neben dem klassischen Top-Down-Vorgehen des Model-Driven Software Engineering wird damit auch ein Bottom-Up-Weg möglich. Das adressiert ein altes Problem: Top-Down entworfene Modelle werden im Entwicklungsalltag nicht mehr nachjustiert und geraten außer Sync.
Was fehlt einer Tester-Ausbildung, die vor allem auf Zertifikate setzt?
Die praktische Erfahrung. Glossary und ein Syllabus-Framework mit Foundation, Advanced und Expert Level bilden Wissen ab, praktische Übungen sind aber oft nicht Teil der Prüfung. Abstrakte Schulbeispiele wie ein Geldautomat oder ein isoliertes Eingabefeld tragen durch die Prüfung, der Transfer gelingt erst an eigenen Anforderungen und User Stories.
Macht KI die Rolle der Testerinnen und Tester überflüssig?
Nein. Je kritischer die Bereiche werden, in denen Software läuft, desto unverzichtbarer wird Qualitätssicherung, und die lässt sich nicht durch Automatismen wegrationalisieren. KI hebt den Automatisierungsgrad eine Stufe höher. Der Gewinn liegt darin, mit begrenzten Testressourcen smarter umzugehen, gezielt auf die Pain Points zu kommen und das so früh wie möglich.
