Software-Testen an der Universität zu unterrichten heißt, praktische Laborarbeit mit genau so viel Theorie zu verbinden, dass die Praxis Sinn ergibt. Kurse rund um Testautomatisierung mit Selenium, API-Tests mit Postman und Performance-Tests packen Studierende schneller als Testkonzepte allein. Der Schwierigkeitsgrad steigt schrittweise, KI-Tools sind erlaubt, werden aber kritisch geprüft, und echte Fehlerfälle aus der Industrie geben den Studierenden einen konkreten Grund, sich um Softwarequalität zu kümmern.
Das Wichtigste in Kürze
- Testautomatisierung und Performance-Tests vor den Testkonzepten zu unterrichten hält Studierende bei der Stange, weil sie erleben, was Testen bewirkt, bevor sie lernen, wie es heißt.
- Dass Studierende KI-Tools wie ChatGPT für Automatisierungscode nutzen, ist kein Problem, das man blockieren muss, sondern eine Fähigkeit, die man ausbilden kann: Der Kurs reagiert mit komplexeren Übungen, passend zum höheren Tempo.
- Codelose Test-Tools sind nicht wirklich codelos, denn komplexe Szenarien brauchen weiterhin eigenen Code; Code schreiben und beurteilen zu können bleibt deshalb eine Kernkompetenz für Tester.
- Ein gestaffelter Schwierigkeitsgrad in den Laborübungen, bei dem die ersten Aufgaben sofort Punkte bringen, schafft die Motivation, die Studierende auch durch die schwierigeren Phasen später im Kurs trägt.
- Wenn Studierende echte Softwarefehler recherchieren und sie den Kommilitonen statt dem Dozenten präsentieren, entsteht ein gesunder Wettbewerb, und die Folgen schlechter Qualität werden greifbar.
Warum Automatisierung und Performance-Tests vor den Testkonzepten kommen
Testkonzepte ergeben wenig Sinn für jemanden, der noch nie ein System hat zusammenbrechen sehen. Aus diesem Gedanken heraus hat Dmitrij Nikolajev seinen Kurs an der Universität Vilnius umgebaut. Software-Testen unterrichten heißt für ihn: Praxis zuerst, Theorie danach.
Als Dmitrij den Kurs übernahm, drehte sich vieles um schriftliche Artefakte. Die Studierenden sollten Testfälle und Testkonzepte auf Papier erstellen. Er sah darin ein Missverhältnis. Wer Anfänger ein Testkonzept schreiben lässt, bekommt wenig Brauchbares zurück, denn ein Testkonzept lebt von einem Kontext, den die Studierenden noch gar nicht haben.
Die Lösung war, die übliche Reihenfolge umzudrehen. Statt mit Dokumenten beginnt der Kurs mit Werkzeugen und Aufgaben. Was ein Testfall ist, lernen die Studierenden, indem sie einen bekommen und ihn automatisieren sollen. Die Definition folgt dem Tun, nicht umgekehrt.
Das passt zum Publikum. Etwa ein Drittel bis die Hälfte der Studierenden im dritten Studienjahr arbeitet bereits in der IT, einige als Tester, die meisten auf dem Weg in Entwickler- oder Engineering-Rollen. Ein rein theoretischer Kurs würde sie verlieren. Praxisarbeit, die echte Situationen abbildet, hält sie bei der Stange und gibt ihnen etwas, das sie am nächsten Tag im Job nutzen können.
Drei Praxisblöcke tragen den Kurs
Der Kurs dauert fünf Monate und stützt sich auf drei Praxisblöcke: Automatisierung, Performance-Tests und API-Tests, dazu eine kleine Portion Security-Tests.
Die Automatisierung kommt zuerst. Die Studierenden schreiben Skripte zu vorgegebenen Testfällen und werden in weniger offensichtliche Situationen geschickt, etwa das Aufsetzen der Orchestrierung. Die Komplexität liegt bewusst über der Komfortzone von Anfängern, damit sie hineinwachsen, statt sich durchzumogeln.
Danach folgen die Performance-Tests mit einer klaren Botschaft: Dinge kaputt zu machen reicht nicht. Die Studierenden planen die Arbeit. Sie erstellen Betriebsprofile, richten ein Monitoring ein und suchen die schwächsten Glieder im System. Es geht nicht um Chaos, sondern um Belege dafür, wo ein System unter Last versagt.
Der dritte Block sind API-Tests, mit Fokus auf REST-APIs und die Frameworks drumherum. Security-Tests runden das Ganze in kleinerer Dosis ab, an einem absichtlich verwundbaren Übungsprojekt, damit die Studierenden Schwachstellen in einer sicheren Umgebung ausloten können.
So sieht das aus, was in den Blöcken tatsächlich entsteht:
| Block | Fokus | Was die Studierenden tun |
|---|---|---|
| Automatisierung | Testfälle in Aktion | Automatisierungsskripte schreiben, Orchestrierung aufsetzen |
| Performance | Verhalten unter Last | Betriebsprofile erstellen, überwachen, Schwachstellen finden |
| API-Tests | REST und Frameworks | REST-APIs testen, mit gängigen Frameworks arbeiten |
| Security (begrenzt) | Bekannte Schwachstellen | An einem absichtlich verwundbaren Projekt üben |
Kleine Erfolge belohnen, damit die Studierenden dranbleiben
Motivation in einem technischen Kurs lässt sich so aufbauen, wie man Verhalten trainiert: gute Aktionen früh und oft belohnen. Dmitrij nimmt das direkt aus seiner Erfahrung im Hundetraining mit, wo positive Verstärkung den Fortschritt treibt.
Im Kurs geschieht das über einen langsam steigenden Schwierigkeitsgrad. Bei den ersten Laborübungen gibt es leicht Punkte, die Studierenden sammeln schnell welche und spüren den Erfolg. Jede weitere Übung baut auf der vorigen auf und wird schwieriger. Nicht alle erreichen die Höchstpunktzahl, aber die frühen Erfolge ziehen die meisten mit.
Derselbe Gedanke prägt die Vorlesungen. Ein Raum voller 21-Jähriger verliert nach etwa einer Stunde einer 90-minütigen Einheit die Konzentration. Man sieht es in ihren Augen. Also unterbricht Dmitrij mit Rätseln, mal auf einer Folie, mal zum Anfassen, um die Aufmerksamkeit zurückzuholen, bevor es weitergeht.
Theorie hat trotzdem ihren Platz, nur immer gekoppelt an die Praxis, damit klar wird, wozu sie gut ist. Während der praktischen Arbeit werden die Konzepte im Kontext erklärt, und so bleiben sie besser hängen als nach einer reinen Vorlesung.
Software-Testen unterrichten, wenn Studierende ChatGPT nutzen
KI-Tools zu verbieten ist der falsche Weg. Besser: die Studierenden sie nutzen lassen, darauf bestehen, dass sie die Ergebnisse verstehen, und den Schwierigkeitsgrad anheben, damit die Tools helfen, statt eine Abkürzung zur guten Note zu sein.
Über drei Jahrgänge war die Veränderung deutlich zu sehen. Die erste Gruppe, kurz nach der Corona-Pandemie, hatte noch keine öffentlichen KI-Tools und kam im Suchmaschinentempo voran. Im Jahr darauf, mit breit verfügbarem ChatGPT, arbeiteten die Studierenden die Aufgaben spürbar schneller ab. Manche kopierten einfach.
Dmitrij hat nicht gegen die neue Realität angekämpft, sondern sich auf sie eingestellt. Er ermutigt die Studierenden, die Tools zu nutzen, unter einer Bedingung: nicht blind kopieren, sondern prüfen, was der Code tatsächlich tut. Zu wissen, wie man das Werkzeug einsetzt, ist schon eine Fähigkeit, die sich zu lernen lohnt.
Als die Tools die Studierenden schneller machten, wurden die Übungen schwieriger. Wenn die Komplexität mit dem wächst, was die Studierenden jetzt schaffen, bleibt das Pensum sinnvoll. Einige verzichten bewusst auf KI, und auch diese Entscheidung wird respektiert.
Generative KI verwischt die Grenze zwischen Code und codelos
Die Trennung zwischen codelosen Tools und codebasierter Automatisierung löst sich auf, und die Studierenden sehen das sehr klar. Eine Beobachtung aus dem Kurs bringt es auf den Punkt.
Viele codelose Tools sind bequem, bis ein komplexer Schritt kommt. Dann bietet das Tool einen Button an, um eigenen Code zu schreiben, mal in JavaScript, mal über einen KI-Assistenten. Das codelose Tool ist also gar nicht codelos.
Dmitrijs Studierende, die meisten davon selbst Programmierer, haben daraus eine Frage gemacht, die hängen bleibt. Dmitrij gibt sie so wieder:
“Wir haben ein codeloses Tool, das nicht wirklich codelos ist, denn für komplexe Situationen müssen wir trotzdem Code schreiben. Ist das nicht dasselbe, wie wenn ich den Code mit Selenium, Cypress oder Playwright schreibe? Ich kann ChatGPT nehmen, und es schreibt den Code für mich, also ist das auch codelos.”
(Dmitrij Nikolajev)
Generative KI hat den Spieß umgedreht. Du musst kein starker Programmierer mehr sein, um Automatisierungscode zu erzeugen, auch wenn Automatisierung auf höchstem Niveau weiterhin echte Programmierkenntnisse belohnt. Der Wert verschiebt sich dahin, zu beurteilen, was der generierte Code tut. Darum lohnt es sich weiterhin, programmieren zu lernen: Was du nicht verstehst, kannst du nicht bewerten.
Warum echte Softwarefehler das beste Argument fürs Testen sind
Geschichten über teure und gefährliche Fehler überzeugen Studierende stärker davon, dass Testen wichtig ist, als jede Liste von Grundsätzen. Der Kurs nutzt das gezielt.
Zu Beginn werden die ISTQB-Grundsätze des Testens an echten Beispielen aus fast 20 Jahren Erfahrung in IT und Softwaretest erklärt. Abstrakte Prinzipien sitzen besser, wenn sie an etwas hängen, das tatsächlich schiefgegangen ist.
Die Studierenden bauen das selbst aus. In Gruppen können sie sich einen Prüfungspunkt verdienen, indem sie Fälle recherchieren und präsentieren; die Themen sind nach Komplexität gewichtet. Beliebt sind die größten Fehler der Softwaregeschichte, Softwarefehler in Luft- und Raumfahrt und Vorfälle im Finanzsektor, darunter auch Fälle aus Litauen.
Die Recherche geht bis zur technischen Ursache, nicht nur bis zur Schlagzeile. Ein Gleitkommafehler oder eine Einheitenumrechnung zwischen amerikanischem und europäischem System kann eine Rakete vom Kurs abbringen. Wer eine Katastrophe so genau zurückverfolgt, versteht, warum Testen zählt.
Dahinter steckt auch ein sozialer Motor. Dmitrij sagt den Studierenden, dass die Präsentationen für ihre Kommilitonen gedacht sind, nicht für ihn. Das weckt einen gesunden Wettbewerb, bei dem jedes Team das vorige übertreffen will, und auch der Dozent lernt dabei etwas, etwa zu selbstheilender Automatisierung oder zu codelosen gegenüber codebasierten Ansätzen.
Welche Tools die Studierenden lernen und welche Freiheit sie behalten
Der Kurs setzt auf eine kleine Auswahl verbreiteter Tools und lässt trotzdem Raum für eigene Entscheidungen. Postman übernimmt die API-Tests, dazu kommen Google-Dienste für die übliche Umgebung.
Für die Browser-Automatisierung empfiehlt der Kurs Selenium WebDriver, bewusst ein lange etabliertes und weiterhin beliebtes Tool. Das Lehrteam kommt selbst aus diesem Stack und kann deshalb besser helfen, wenn die Studierenden auf ungewöhnliche Probleme stoßen.
Gezwungen wird niemand. Die Studierenden können mit Selenium und Java arbeiten oder zu .NET, Python oder Ruby wechseln, und einige tun das auch. Die IDE wählen sie selbst, ob Visual Studio, IntelliJ oder das kostenlose Eclipse. Die Anleitungen orientieren sich am bevorzugten Stack des Teams, weil dort die Unterstützung am besten ist, aber die Wahl bleibt bei den Studierenden.
Häufig gestellte Fragen
Warum ist das Erstellen eines Testkonzepts eine ungeeignete erste Übung für angehende Tester?
Ein Testkonzept wird durch einen Kontext geprägt, den ein Student noch nicht verinnerlicht hat. Einen Anfänger zu bitten, ein solches Konzept zu erstellen, bringt daher kaum etwas. Die Alternative ist, die Reihenfolge umzukehren: Gib dem Studenten einen fertigen Testfall und bitte ihn, diesen zu automatisieren. Die Definition ergibt sich erst, wenn die Arbeit erledigt ist, so wird das Konzept konkret statt abstrakt.
Welche praktischen Bereiche sollte ein Kurs zum Testen von Software an der Uni abdecken?
Drei Blöcke machen über fünf Monate hinweg den größten Teil des Lehrplans aus: Testautomatisierung, Performance-Tests und API-Tests für REST-Dienste, ergänzt durch einen kleineren Anteil an IT-Sicherheitstests. Die Automatisierung umfasst die Einrichtung der Orchestrierung, der Performance-Block deckt Betriebsprofile und Monitoring ab, und IT-Sicherheit wird an einem bewusst anfälligen Projekt geübt, damit die Studierenden Schwachstellen sicher ausloten können.
Wie kann ein Dozent die Motivation in einem anspruchsvollen technischen Kurs aufrechterhalten?
Der Schwierigkeitsgrad steigt schrittweise an. Die ersten Laborübungen sind einfach genug, um sofort Punkte zu sammeln, sodass die Studierenden schon früh Erfolgserlebnisse haben; jede folgende Sitzung baut auf der vorherigen auf und wird schwieriger. Manche erreichen nie die Höchstpunktzahl, aber die frühen Erfolge treiben die meisten von ihnen voran. Außerdem lässt die Aufmerksamkeit nach etwa einer Stunde einer 90-minütigen Vorlesung nach, daher sorgen kurze Rätsel für einen Neustart.
Machen KI-Assistenten wie ChatGPT Automatisierungsübungen zu einfach?
Sie machen die Studierenden schneller, und die Lösung besteht darin, die Übungen anzupassen, nicht die Tools zu verbieten. Im Vergleich zu der Gruppe, die unterrichtet wurde, bevor öffentliche KI-Tools existierten, arbeiteten die späteren Studierenden die gleichen Aufgaben spürbar schneller ab, und manche haben einfach kopiert und eingefügt. Der Kurs hat die Komplexität entsprechend erhöht, mit einer einzigen Bedingung: prüfen, was der generierte Code tatsächlich tut.
Sind codelose Tools für die Testautomatisierung wirklich codelos?
Nein. Sie bleiben benutzerfreundlich, bis ein komplexer Schritt auftaucht, und an diesem Punkt bietet das Tool eine Schaltfläche zum Schreiben von benutzerdefiniertem Code an, manchmal in JavaScript, manchmal über einen KI-Assistenten. Die Teilnehmer des Kurses trieben das Argument noch weiter: Wenn eine generative KI Selenium-, Cypress- oder Playwright-Code für dich schreibt, ist das wohl auch „codelos“.
Lohnt es sich noch für Tester, Programmieren zu lernen, wenn KI Automatisierungscode generieren kann?
Ja. Man muss kein hervorragender Programmierer mehr sein, um funktionierende Automatisierungen zu erstellen, aber der Wert verlagert sich hin zur Beurteilung dessen, was der generierte Code tut, und man kann keine Ergebnisse bewerten, die man nicht versteht. Bei der Automatisierung auf höchstem Niveau werden echte Programmierfähigkeiten nach wie vor belohnt, weshalb das Schreiben und Lesen von Code eine Kernkompetenz für Tester bleibt.
Wie kannst du den Studierenden die Qualitätskosten greifbar machen?
Echte Softwarefehler leisten das, was Listen mit Grundsätzen nicht schaffen. Die Studierenden recherchieren und präsentieren in Gruppen Fälle für eine Prüfungsnote und wählen dabei Themen wie die größten Fehler der Softwaregeschichte, Fehler in der Flugzeug- und Raumfahrtsoftware oder Vorfälle im Finanzsektor. Die Recherche zielt auf die technische Ursache ab, zum Beispiel ein Gleitkommafehler oder eine Einheitenumrechnung zwischen dem US-amerikanischen und dem europäischen System.
