Testen in der Hochschullehre zu vermitteln ist schwierig, weil Studierenden der Praxisbezug fehlt: Kleine, überschaubare Übungsbeispiele machen den Nutzen von Tests kaum spürbar. Komplexere Projekte mit echter Infrastruktur, Techniken wie Test-Driven Development und Behavior Driven Development sowie der bewusste Umgang mit KI-generiertem Code schaffen das nötige Verständnis für Tests und Codequalität.
Das Wichtigste in Kürze
- Studierende verstehen den Sinn von Tests erst dann, wenn die Aufgaben komplex genug sind: Einfache Übungsbeispiele erzeugen keine echte Motivation, weil der Nutzen nicht spürbar wird.
- Test-Driven Development eignet sich besonders gut für die Lehre, weil das Rot-Grün-Schema eine klar überprüfbare Struktur vorgibt, die Anfänger direkt anwenden können.
- Schlechte Softwarearchitektur macht gutes Testen strukturell unmöglich: Wer Domain-Logik und Datenbanklogik vermischt, kann Businesslogik nicht ohne laufende Datenbank testen.
- Code-Coverage-Metriken wie das 75%-Quality-Gate in SonarQube verführen Studierende dazu, Tests nur zum Erfüllen der Zahl zu schreiben, statt zur Qualitätssicherung.
- Wer KI-generierten Code einsetzt, ohne ihn zu verstehen, verliert die Kontrolle darüber, was im System läuft, was in sicherheitskritischen Domänen wie Banking oder Flugsicherung direkt zum Problem wird.
Warum Testen in der Lehre so schwer zu vermitteln ist
Studierenden das Testen beizubringen, scheitert oft an einem simplen Problem: Der Sinn ist nicht spürbar, solange die Aufgaben trivial bleiben. Wer eine einfache Funktion schreibt, über die er lange nachgedacht hat und von der er weiß, dass sie funktioniert, sieht keinen Grund, sie auch noch zu testen.
Kai Renz, seit acht Jahren Professor für Software Engineering an der Hochschule Darmstadt, beschreibt diese Hürde als doppelt. Am Anfang können viele noch gar nicht richtig programmieren. Tests zu schreiben wirkt dann doppelt abstrakt, weil das Fundament fehlt. Ist diese erste Hürde genommen, kommt die nächste: kleine, überschaubare Beispiele liefern keinen glaubwürdigen Anlass für Tests.
Das klassische Argument zieht in dieser Phase nicht. Der Hinweis, dass Tests später in der echten Softwareindustrie vor Regressionen und Unsicherheit bei der Weiterentwicklung schützen, bleibt anekdotisch. Es ist eine erzählte Geschichte über eine Zukunft, die für Lernende noch nicht existiert.
Verschärft wird das durch generative KI. Wenn ChatGPT die korrekte Lösung ohnehin ausspuckt, stellt sich die Frage nach dem Sinn eines Tests umso dringlicher.
Komplexe Projekte schaffen den Anlass, den triviale Beispiele nicht liefern
Der Hebel gegen die fehlende Motivation ist Komplexität. Sobald ein Projekt realistisch genug wird, entsteht der Bedarf für Tests von selbst.
In Darmstadt simuliert ein Software-Engineering-Praktikum dafür einen Pizza-Shop. Jede Gruppe betreibt ein eigenes Kubernetes-Cluster mit echter Infrastruktur, bei dem auch Integrationstests notwendig werden. Die Studierenden werden bewusst ins kalte Wasser geworfen.
Das Ergebnis ist gespalten. Bei einem Teil zündet das Prinzip, sie verstehen, warum sie testen. Andere fragen vor allem, was sie tun müssen, um das Testat zu bekommen. Bei ihnen bleibt der Funke aus. Diese Spaltung ist kein Versagen der Methode, sondern Realität in einer heterogenen Studierendenschaft.
Konzeptionelles Verständnis schlägt Tool-Wissen
Der wichtigste Lernertrag liegt nicht in der Beherrschung eines konkreten Tools, sondern im konzeptionellen Verständnis. Die Industrie ist so schnelllebig, dass jedes spezifische Werkzeug schnell veraltet.
Konkrete Techniken und Tools werden trotzdem vermittelt, von Unit-Tests über Integrations- und End-to-End-Tests bis zu UI-Tests. Der Aufbau eines Tests steht dabei im Zentrum: das AAA-Pattern konsequent anwenden, klar entscheiden, was das System under Test überhaupt ist. Eine einzelne Klasse? Eine komplette Funktionalität? Auf welcher Ebene bewege ich mich gerade?
Genau diese Entscheidungen treffen erfahrene Entwickler fast automatisch. Brauche ich eine Testdatenbank? Mocke ich ein Framework oder nicht? Wer das Zusammenspiel der Komponenten kennt, entscheidet bewusst. Wer es nicht kennt, braucht klare Anleitung als Einstieg.
Test-Driven Development eignet sich besonders gut für die Lehre
Test-Driven Development hat ein einfaches, klar verständliches Schema, das sich im Hörsaal gut nachvollziehen lässt. Zuerst der Test, dann die Funktionalität. Der Test ist erst rot, vielleicht kompiliert anfangs nicht einmal alles, danach folgt der Code.
Die häufigste Rückfrage der Studierenden lautet: Woher weiß ich, was ich teste, wenn die Funktion noch gar nicht existiert? Daraus entstehen halb-philosophische Diskussionen darüber, was man wissen muss, um etwas zu tun.
Die Antwort ist pragmatisch: Wenn du weißt, was du als Nächstes programmieren würdest, weißt du auch, was rauskommen soll. Und damit weißt du, wie der Test aussieht. TDD hilft hier, weil es den Fokus auf einen einzigen kleinen Schritt in Richtung der Funktionalität verengt.
Verstärkt wird das durch Pair-Programming mit Driver und Navigator sowie durch Coding-Sessions im Hörsaal nach dem Prinzip des Mob-Programmings. Einer programmiert, alle schauen zu. Das funktioniert, bleibt aber anspruchsvoll, weil sehr gute und sehr unerfahrene Studierende im selben Raum sitzen.
Behavior Driven Development bringt die Nutzerperspektive in den Test
Behavior Driven Development verschiebt den Blick weg von der Umsetzung hin zur Anwendungs- und Nutzerseite. Statt zu fragen, wie etwas implementiert ist, fragt BDD, was getestet werden soll und wie sich ein Testfall beschreiben lässt.
Diese Technik kommt in einem Wahlpflichtfach namens “Professionelles Testen” zum Einsatz. Über vierzehn Wochen werden die Teilnehmenden mit dem gesamten Spektrum konfrontiert, von Backend-Tests über verschiedene Programmiersprachen und Tools bis zu UI-Tests mit Playwright. Die Lernkurve ist steil, das mitgenommene Wissen breit.
Der Effekt zeigt sich im Beruf. Ehemalige berichten, dass sie Gelerntes direkt einsetzen konnten. Manche bringen in Firmen, in denen Testen noch nicht selbstverständlich gelebt wird, mehr Wissen mit als die Kollegen vor Ort. Frische Leute sind oft der einzige Weg, Qualitätsdenken in ein Unternehmen zu tragen, das zwanzig Jahre ohne ausgekommen ist.
Architektur entscheidet darüber, ob ein System testbar ist
Gute Testbarkeit hängt maßgeblich von der Softwarearchitektur ab. Systeme, die schwer zu testen sind, vermengen in der Regel Dinge, die getrennt gehören.
Das klarste Beispiel ist die Trennung von Domain-Logik und Controller-Logik. Ansätze wie hexagonale oder funktionale Architektur zeigen ihre Stärke erst, wenn man sie konsequent durchzieht. Der Preis ist sichtbarer Overhead: viele Hilfsklassen, die Objekte aus der Datenbanklogik in die Businesslogik kopieren.
Genau an dieser Stelle steigen Studierende oft aus. Sie haben bereits eine Klasse, die mit der Datenbank gekoppelt ist, und fragen, warum das ein Problem sein soll. Die Antwort wird greifbar, sobald man die Businesslogik testen will: Musst du erst eine Datenbank erzeugen, um die Businesslogik zu prüfen, ist sie nicht sauber getrennt.
Was tun, wenn ein bestehendes System sich nicht testen lässt
Die typische Falle ist eine Schockstarre. Das Team steht vor einem System, das schlecht testbar ist, und sieht keinen Ansatzpunkt. Es bräuchte Refactoring, aber das geht ohne absichernde Tests kaum, und die Tests gehen wegen der Architektur kaum. Ein echter Teufelskreis.
Der pragmatische Einstieg führt über das Neue. Neue Funktionalität wird konsequent sauber gebaut und getestet. Daran erlebt das Team, was eine gute Architektur bringt: leichteres Refactoring, Tests auf allen Ebenen, statische Analyse ohne offene Befunde.
Dieses Verständnis sickert mit der Zeit in den Altbestand ein. Bei sehr großen, alten Systemen lässt sich das nie vollständig umsetzen. Und selbst in der Neuentwicklung droht die Gefahr, dieselben Fehler zu wiederholen. Deshalb braucht es ein gemeinschaftliches Denken über Qualität im Team.
Codequalität messen: Metriken sind Mittel, nicht Ziel
Eine Code-Coverage von 75 Prozent ist kein Selbstzweck. Genau das verkennen Teams, die nur deshalb Tests schreiben, weil ein rotes Quality Gate grün werden soll.
Im Praktikum wird SonarQube als Tool für statische Code-Analyse eingesetzt, mit einem Quality Gate, das eine Coverage über 75 Prozent verlangt. Schaffen Teams das zunächst nicht, schreiben manche einfach irgendwelche Tests, bis die Zahl stimmt. Damit kippt das Mindset in die falsche Richtung.
Der Grundsatz lautet: Du schreibst einen Test nicht, damit eine Zahl grün wird, sondern damit die Qualität steigt. Spannender als die reine Coverage sind ohnehin die Aussagen zur Codequalität, etwa zur Komplexität.
Nicht-funktionale Tests werden bewusst ausgelagert
Security, Usability und Performance lassen sich im Software-Engineering-Teil kaum unterbringen, weil der Themenkanon dort bereits randvoll ist. Darmstadt löst das über spezialisierte Veranstaltungen.
IT-Security hat eine eigene Lehrveranstaltung und eine starke Forschergruppe im Rücken, sowohl auf technischer als auch auf Usability-Ebene. Für Usability gibt es zusätzlich eine eigene Veranstaltung zu Human-Computer-Interaction, die fragt, wie sich Funktionalität überhaupt sinnvoll umsetzen lässt.
Eine engere Verzahnung dieser Module wäre wünschenswert, scheitert aber an zwei Hürden. Lehrende arbeiten gerne autonom, eine Abstimmung ist mühsam. Und Studierende stünden vor einer deutlich größeren Workload, wenn ein Modul ein weiteres voraussetzt.
Performance-Tests werden über die Quadranten des agilen Testens eingeordnet, mehr nicht. Ein Lasttest mit 500 Pizzabestellungen hat nichts mit einem realen System zu tun und bliebe fake. Übungen sollen Real-World-Impact haben, statt Aufgaben zu simulieren, die im Bildungskontext leer bleiben.
KI im Studium: Verantwortung bleibt beim Menschen
Generative KI ist für die aktuelle Generation Studierender selbstverständlich. Die Lehre reagiert darauf mit klaren Grenzen dort, wo es zählt, und mit Offenheit überall sonst.
In der Grundlagen-Veranstaltung Programmieren steht am Ende eine praktische Prüfung am Rechner ohne Internetzugang. Wer sich die Lösungen vorher nur generieren ließ, kann die grundlegenden Programmiertechniken in der Prüfung nicht. In den Praktika gilt dagegen: KI darf genutzt werden, aber die Verantwortung für das Abgegebene bleibt bei den Studierenden. Sie müssen erklären können, was sie getan haben.
Ein Vorfall zeigt das Risiko konkret. Beim Entwickeln eines neuen Features für das Pizza-Projekt war die gesuchte Funktionalität bereits im Code vorhanden. In der Commit History fand sich ein Commit, der fast das komplette Projekt austauschte. Ein Student hatte den Code unter Abgabestress an ChatGPT gegeben mit der Bitte, Fehler zu finden. Die KI fügte dabei ungefragt die Funktionalität hinzu.
Wenn du bei einer Bank arbeiten würdest oder in der Flugsicherung oder bei einem Bremsenhersteller: Könntest du gut schlafen, wenn du Code committed hättest, von dem du gar nicht weißt, dass er da ist?
Kai Renz
Der Student gab den Vorgang ehrlich zu. Genau das machte das Gespräch lehrreich. Der Lerneffekt: KI hilft, aber man muss selbst wissen, was man tut.
Worin der bleibende Skill liegt
Wer nur ChatGPT bedienen kann, hat keine Kompetenz, die einen Arbeitgeber überzeugt. Diese Botschaft bekommen Studierende deutlich, die ihre Abgaben offen rein über KI lösen.
Ein Abschluss lässt sich theoretisch mit KI erreichen, ohne viel zu verstehen, solange man die Klausuren irgendwie übersteht. Aber Prompting allein ist ein kurzfristiger Skill, der sich vermutlich wieder vereinfacht, je natürlicher man mit KI sprechen kann.
Zwei Fähigkeiten tragen langfristig. Die erste ist Kommunikation mit Menschen: wirklich zu erfassen, was das Gegenüber will. Das lässt sich schlecht delegieren. Die zweite ist Kontrolle über das Ausgespuckte. Ist das plausibel? Verstehe ich es? Behalte ich den Überblick?
Den Überblick hast du allerdings erst mit Erfahrung. Wer noch keine Erfahrung hat, hat keinen Überblick. Darin liegt das eigentliche Dilemma einer Generation, die mit KI startet, bevor sie das Urteilsvermögen aufgebaut hat, deren Ergebnisse zu prüfen.
KI versteht den Kontext nicht von selbst
Manche Rahmenbedingungen muss man der KI explizit mitgeben, weil sie sie nicht von allein berücksichtigt. Logging ist ein gutes Beispiel.
Logging-Frameworks samt gutem Aufbau von Messages lassen sich schnell vermitteln, und der Nutzen leuchtet ein. Dann kommt die Gegenfrage: Darfst du überhaupt alles loggen? Verlangt jemand die Löschung seiner Daten, das System hat aber protokolliert, welche Seiten diese Person angesehen hat, bekommst du das jemals wieder aus dem Log heraus?
Solche Grenzen ergeben sich aus Datenschutz, Copyright und Urheberrecht. Auch die Frage, wohin Quellcode aus einer Firma überhaupt geschickt wird und welcher Server mitliest, gehört dazu. Eine KI versteht diese Implikationen nicht automatisch. Du musst sie ihr vorgeben.
Häufig gestellte Fragen
Reicht es aus, das Testen an kleinen Programmieraufgaben zu üben?
Nein. Bei trivialen Aufgaben bleibt der Nutzen unspürbar: Wer eine kurze Funktion schreibt, lange über sie nachgedacht hat und weiß, dass sie läuft, sieht keinen Grund für einen Test. Der Verweis auf spätere Regressionen in der Industrie bleibt eine erzählte Geschichte über eine Zukunft, die für Lernende noch nicht existiert. Erst realistische Komplexität erzeugt den Bedarf von selbst.
Was bringt es, in Lehrprojekten mit echter Infrastruktur zu arbeiten?
Sie schafft den Anlass für Testarten, die sich sonst nicht begründen lassen. In einem Software-Engineering-Praktikum simulieren Gruppen einen Pizza-Shop und betreiben dafür jeweils ein eigenes Kubernetes-Cluster, wodurch Integrationstests notwendig werden. Das Ergebnis ist gespalten: Bei einem Teil zündet das Prinzip, andere fragen vor allem, was für das Testat nötig ist.
Wie begegnet man dem Einwand, man könne nichts testen, was noch nicht programmiert ist?
Pragmatisch: Wenn du weißt, was du als Nächstes programmieren würdest, weißt du auch, was herauskommen soll, und damit, wie der Test aussieht. Genau das ist die häufigste Rückfrage von Einsteigern beim Test-Driven Development. Die Technik hilft, weil sie den Fokus auf einen einzigen kleinen Schritt in Richtung der Funktionalität verengt.
Woran erkennt man, dass eine Architektur das Testen behindert?
Ein klares Signal: Du musst erst eine Datenbank erzeugen, um Businesslogik zu prüfen. Dann sind Domain-Logik und Datenbanklogik nicht sauber getrennt. Ansätze wie hexagonale oder funktionale Architektur zeigen ihre Stärke erst, wenn man sie konsequent durchzieht, und kosten sichtbaren Overhead: viele Hilfsklassen, die Objekte aus der Datenbankschicht in die Businesslogik kopieren.
Ist eine Testabdeckung von 75 Prozent ein sinnvolles Ziel?
Als Zahl allein nicht. Ein Quality Gate, das eine Coverage über 75 Prozent verlangt, verführt dazu, irgendwelche Tests zu schreiben, bis der Wert stimmt. Damit kippt das Mindset: Ein Test wird geschrieben, damit die Qualität steigt, nicht damit eine Zahl grün wird. Aussagekräftiger als die reine Abdeckung sind Angaben zur Codequalität, etwa zur Komplexität.
Wie riskant ist es, KI-generierten Code zu übernehmen, ohne ihn zu verstehen?
Man verliert die Kontrolle darüber, was im System läuft. In einem Studienprojekt fand sich in der Commit History ein Commit, der fast das komplette Projekt austauschte: Ein Student hatte den Code unter Abgabestress zur Fehlersuche an ChatGPT gegeben, die KI fügte ungefragt Funktionalität hinzu. In Domänen wie Banking, Flugsicherung oder Bremsenbau wird so etwas unmittelbar zum Problem.
Welche Fähigkeiten bleiben wertvoll, wenn KI einen großen Teil des Codes schreibt?
Zwei. Erstens Kommunikation mit Menschen, also wirklich zu erfassen, was das Gegenüber will. Das lässt sich schlecht delegieren. Zweitens Kontrolle über das Ausgespuckte: Ist es plausibel, verstehe ich es, behalte ich den Überblick? Prompting allein ist ein kurzfristiger Skill, der sich vermutlich wieder vereinfacht, je natürlicher sich mit KI sprechen lässt.
Muss man einer KI rechtliche Rahmenbedingungen ausdrücklich mitgeben?
Ja, sie berücksichtigt solche Implikationen nicht von allein. Logging zeigt das gut: Der technische Aufbau guter Log-Messages ist schnell erklärt, die eigentliche Frage lautet aber, ob alles geloggt werden darf. Verlangt jemand die Löschung seiner Daten, während protokolliert ist, welche Seiten er angesehen hat, wird das schwierig. Dazu gehört auch, wohin Quellcode einer Firma geschickt wird.
