Software Testen unterrichten
Softwaretests für 120 Studierende zu unterrichten bedeutet, trockene Testkonzepte zu überspringen und stattdessen mit Automatisierung, APIs und Performanztests zu beginnen.

Software Testen an der Universität zu lehren bedeutet, praktische Laborarbeit mit gerade genug Theorie zu kombinieren, um die Praxis sinnvoll zu gestalten. Kurse, die sich mit Testautomatisierungs-Tools wie Selenium, API-Test mit Postman und Performanztest befassen, fesseln die Studierenden schneller als Testkonzepte allein. Die Komplexität nimmt allmählich zu, KI-Tools sind erlaubt, werden aber kritisch betrachtet, und echte Fehlerwirkungen aus der Industrie geben den Studierenden einen konkreten Grund, sich um die Qualität von Software zu kümmern.
Das Wichtigste in Kürze
- Die Einführung von Testautomatisierung und Performanztests vor den Testkonzepten hält die Lernenden bei der Stange, weil sie erfahren, was Testen bedeutet, bevor sie lernen, wie es genannt wird.
- Die Verwendung von KI-Tools wie ChatGPT zum Schreiben von Automatisierungscode ist kein Problem, das es zu blockieren gilt, sondern eine Fähigkeit, die es zu entwickeln gilt: Der Kurs reagiert darauf, indem er die Komplexität der Übungen erhöht, um dem schnelleren Tempo gerecht zu werden.
- Codelose Test-Tools sind nicht wirklich codelos, denn komplexe Szenarien erfordern immer noch maßgeschneiderten Code, was bedeutet, dass das Wissen, wie man Code schreibt und auswertet, eine Kernkompetenz für Tester bleibt.
- Ein abgestufter Schwierigkeitsgrad in den Laborübungen, bei dem die ersten Aufgaben leicht genug sind, um sofort Punkte zu bekommen, sorgt für die nötige Motivation, um auch die schwierigeren Phasen im späteren Verlauf des Kurses zu meistern.
- Die Aufgabe, reale Softwarefehler zu untersuchen und sie den Mitschülern und nicht dem Dozenten zu präsentieren, schafft einen gesunden Wettbewerb unter den Mitschülern und macht die Fehlerwirkung schlechter Qualität deutlich.
Warum Automatisierung und Performanztests vor Testkonzepten unterrichten?
Testkonzepte machen für jemanden, der noch nie gesehen hat, wie ein System zusammenbricht, wenig Sinn. Das ist der Grund für einen Kurs zum Testen von Software an der Universität Vilnius, bei dem Dmitrij Nikolajev den Lehrplan so umgestaltet hat, dass zuerst die praktische Arbeit und dann die Theorie im Vordergrund steht.
Als Dmitrij Nikolajev den Kurs übernahm, war er stark auf schriftliche Artefakte ausgerichtet. Die Studierenden sollten Testfälle und Testkonzepte auf Papier erstellen. Er sah darin ein Missverhältnis. Wenn man einen Schüler bittet, einen Testplan zu schreiben, bringt das wenig, denn ein Testkonzept wird von einem Kontext geprägt, den der Schüler noch nicht kennt.
Die Lösung bestand darin, die übliche Reihenfolge umzukehren. Anstatt mit Dokumenten beginnt der Kurs mit Werkzeugen und Aufgaben. Die Schüler/innen lernen das Konzept eines Testfalls kennen, indem sie einen Testfall erhalten und ihn automatisieren sollen. Die Definition folgt dem Tun, nicht umgekehrt.
Das ist wichtig für das Publikum. Etwa ein Drittel bis die Hälfte der Studierenden im dritten Studienjahr arbeitet bereits in der IT-Branche, einige als Tester, die meisten als Entwickler oder Ingenieure. Ein rein theoretischer Kurs würde sie verlieren. Praktische Arbeit, die reale Situationen widerspiegelt, hält sie bei der Stange und gibt ihnen etwas, das sie am nächsten Tag anwenden können.
Der Kurs ist in drei praktischen Blöcken aufgebaut
Der fünfmonatige Kurs besteht aus drei Praxisblöcken: Automatisierung, Performanztests und API-Tests, mit einer kleinen Prise IT-Sicherheitstests als Zugabe.
Die Automatisierung steht an erster Stelle. Die Teilnehmer/innen schreiben Skripte für vorgegebene Testfälle und werden in weniger offensichtliche Situationen gedrängt, wie z.B. die Einrichtung der Orchestrierung. Die Komplexität liegt bewusst oberhalb der Komfortzone von Anfängern, damit sie in die Materie hineinwachsen, anstatt sich zu verzetteln.
Als Nächstes folgen die Performanztests, die eine klare Botschaft enthalten: Es reicht nicht aus, Dinge kaputt zu machen. Die Schüler/innen planen die Arbeit. Sie erstellen Nutzungsprofile, richten eine Überwachung ein und suchen nach den schwächsten Gliedern in einem System. Es geht nicht um Chaos, sondern um den Nachweis, wo ein System unter Last fehlgeschlagen ist.
API-Testen bildet den dritten Block und konzentriert sich auf REST-APIs und die sie umgebenden Frameworks. IT-Sicherheitstests runden das Ganze in kleinerer Dosis ab, wobei ein absichtlich verwundbares Praxisprojekt verwendet wird, damit die Schüler/innen Schwachstellen in einer sicheren Umgebung untersuchen können.
Hier siehst du, wie sich die drei Blöcke auf das auswirken, was die Schüler/innen tatsächlich produzieren:
| Block | Fokus | Was Schüler/innen tun |
|---|---|---|
| Automatisierung | Testfälle in Aktion | Automatisierungsskripte schreiben, Orchestrierung einrichten |
| Leistung | Verhalten unter Last | Nutzungsprofile erstellen, überwachen, Schwachstellen finden |
| API-Testen | REST und Frameworks | REST-APIs testen, mit gängigen Frameworks arbeiten |
| IT-Sicherheit (eingeschränkt) | Bekannte Schwachstellen | Üben an einem absichtlich verwundbaren Projekt |
Belohne die kleinen Erfolge, damit die Schüler in Bewegung bleiben
Die Motivation in einem technischen Kurs kann auf dieselbe Art und Weise hergestellt werden, wie man Verhalten trainiert: Belohne gute Aktionen früh und oft. Dmitrij schöpft dabei aus seiner Erfahrung mit dem Gehorsamstraining von Hunden, wo positive Verstärkung den Fortschritt fördert.
Der Kurs wendet sie durch allmählich steigende Schwierigkeit an. Die ersten Laborübungen sind leicht zu bewältigen, so dass die Schüler/innen schnell Punkte sammeln und die Belohnung spüren. Jede weitere Übung baut auf der letzten auf und wird schwieriger. Einige Schüler/innen erreichen nicht die höchste Punktzahl, aber die ersten Erfolge bringen die meisten von ihnen weiter.
Derselbe Instinkt prägt auch die Vorlesungen. Ein Raum mit 21-Jährigen verliert nach etwa einer Stunde eines 90-minütigen Vortrags die Konzentration. Du kannst es in ihren Augen sehen. Also unterbricht Dmitrij den Unterricht mit Rätseln, manchmal auf einer Folie, manchmal physisch, um die Aufmerksamkeit wieder zu erlangen, bevor er weitermacht.
Die Theorie hat immer noch ihren Platz, aber sie wird mit der Praxis gepaart, damit die Schüler sehen, warum sie existiert. Während der praktischen Arbeit werden die zugrundeliegenden Konzepte im Kontext erklärt, so dass sie besser haften bleiben als bei einer reinen Vorlesung.
Wie man Testen unterrichtet, wenn Schüler sich auf ChatGPT stützen
KI-Tools zu verbieten ist der falsche Weg. Besser ist es, die Schüler/innen sie benutzen zu lassen, darauf zu bestehen, dass sie die Ergebnisse verstehen, und den Schwierigkeitsgrad zu erhöhen, damit die Tools eine Hilfe sind und nicht als Abkürzung zu einer guten Note dienen.
Die Veränderung wurde in drei Jahren Unterricht sichtbar. Die erste Gruppe, kurz nach dem COVID, hatte keine öffentlichen KI-Tools und machte Fortschritte im Suchmaschinentempo. Im nächsten Jahr, als ChatGPT allgemein verfügbar war, kamen die Schüler/innen deutlich schneller durch die Aufgaben. Einige kopierten und fügten einfach ein.
Dmitrijs Reaktion war, nicht gegen die neue Realität anzukämpfen, sondern sich ihr anzupassen. Er ermutigt die Schüler/innen, diese Tools zu nutzen, allerdings unter einer Bedingung: Kopiere nicht blindlings, sondern überprüfe, was der Code tatsächlich tut. Zu wissen, wie man das Werkzeug benutzt, ist schon eine Fähigkeit, die man lernen sollte.
Als die Werkzeuge die Schüler schneller machten, wurden die Übungen schwieriger. Durch die Erhöhung der Komplexität, die sich an den Möglichkeiten der Schüler/innen orientiert, bleibt das Arbeitspensum sinnvoll. Einige Schüler/innen entscheiden sich immer noch dafür, die KI nicht absichtlich einzusetzen, und auch diese Entscheidung wird respektiert.
Generative KI verwischt die Grenze zwischen Code und Code-los
Die Unterscheidung zwischen kodelosen Tools und kodebasierter Automatisierung verschwimmt, und die Schüler/innen sehen das deutlich. Eine Beobachtung eines Schülers aus dem Kurs bringt es auf den Punkt.
Viele codelose Tools sind benutzerfreundlich, bis ein komplexer Schritt auftaucht. In diesem Moment bietet das Tool eine Schaltfläche an, um eigenen Code zu schreiben, manchmal in JavaScript, manchmal über einen KI-Assistenten. Das codeless Tool ist also nicht wirklich codeless.
Dmitrijs Schüler/innen, die meisten von ihnen Programmierer/innen, haben daraus eine Frage gemacht, die es wert ist, behalten zu werden:
Wir haben ein kodeloses Tool, das nicht wirklich kodelos ist, denn um komplexe Situationen zu lösen, müssen wir immer noch Code schreiben. Ist es nicht dasselbe, wenn ich den Code mit Selenium, Cypress oder Playwright schreibe? Ich kann ChatGPT verwenden und es schreibt den Code für mich, also ist das auch codeless.
- Dmitrij Nikolajev
Generative KI hat den Spieß umgedreht. Du musst kein guter Programmierer mehr sein, um Automatisierungscode zu erstellen, auch wenn Automatisierungsarbeit auf höchster Ebene immer noch echte Programmierkenntnisse belohnt. Der Wert verlagert sich darauf, zu beurteilen, was der generierte Code tut. Deshalb ist es immer noch wichtig, programmieren zu lernen: Du kannst keine Ergebnisse bewerten, die du nicht verstehst.
Warum Fehlerwirkungen von Software das beste Argument für das Testen sind
Geschichten über teure und gefährliche Fehlerwirkungen überzeugen die Schüler/innen mehr davon, dass Testen wichtig ist, als jede Liste von Prinzipien. Der Kurs stützt sich direkt darauf.
Zu Beginn werden die ISTQB-Prinzipien des Testens anhand von realen Beispielen aus fast 20 Jahren Erfahrung im IT- und Softwaretesten erläutert. Abstrakte Prinzipien sind schwieriger zu verstehen, wenn sie mit etwas verbunden sind, das tatsächlich schief gelaufen ist.
Die Schüler/innen erweitern dies selbst. Sie können sich einen Prüfungspunkt verdienen, indem sie in Gruppen Berichte recherchieren und präsentieren, wobei die Themen nach ihrer Komplexität bewertet werden. Zu den beliebten Themen gehören die größten Fehlerwirkungen in der Geschichte der Software, Softwarefehler in der Luft- und Raumfahrt und Vorfälle im Finanzsektor, einschließlich Fällen aus Litauen.
Bei der Recherche geht es um die technische Ursache, nicht nur um die Schlagzeile. Eine Fließkommafehler oder eine Einheitenumrechnung zwischen amerikanischen und europäischen Systemen kann eine Rakete auf die Seite schicken. Wenn du eine Katastrophe bis ins Detail zurückverfolgst, werden die Gründe für das Testen deutlich.
Es steckt auch eine soziale Manipulation dahinter. Dmitrij sagt den Schülern, dass die Präsentationen für ihre Mitschüler bestimmt sind, nicht für ihn. So entsteht ein gesunder Wettbewerb, bei dem jedes Team versucht, das andere zu übertreffen, und auch der Dozent lernt daraus, wenn es um Themen wie selbstheilende Automatisierung und kodelose oder kodebasierte Ansätze geht.
Die Werkzeuge, die die Studierenden lernen, und die Freiheit, die sie behalten
Der Kurs standardisiert eine kleine Gruppe weit verbreiteter Tools, lässt den Studierenden aber dennoch Raum für eigene Entscheidungen. Postman ist für das API-Testen zuständig, neben den Google-Diensten für die typische Umgebung.
Für die Browser-Automatisierung empfiehlt der Kurs Selenium WebDriver, eine bewusste Entscheidung für ein seit langem etabliertes und immer noch beliebtes Tool. Das Lehrerteam verfügt selbst über Erfahrungen in diesem Bereich und kann daher besser helfen, wenn die Schüler/innen auf ungewöhnliche Probleme stoßen.
Die Schüler werden nicht dazu gezwungen. Sie können mit Selenium und Java arbeiten oder zu .NET, Python oder Ruby wechseln, was einige auch tun. Sie wählen ihre eigene IDE, ob Visual Studio, IntelliJ oder das kostenlose Eclipse. Die Anleitung orientiert sich an dem vom Team bevorzugten Stack, aber die Flexibilität bleibt bei den Auszubildenden.
Ähnliche Beiträge

Richard Seidl
•4. Juni 2026
Warum COBOL-Entwickler am liebsten Tests in Java schreiben

Richard Seidl
•28. Mai 2026