Qualitätssicherung in der Hochschullehre bedeutet, Qualitätsdenken nicht als isoliertes Pflichtfach zu vermitteln, sondern als Querschnittsthema durch alle Semester: Ressourcen messen, Testverfahren verstehen, Nachhaltigkeit in Architekturentscheidungen einbauen. Wer früh lernt, Performance zu messen und Protokolle zu hinterfragen, trägt dieses Handwerkszeug später in Unternehmen.
Das Wichtigste in Kürze
- Qualitätssicherung wird an der Hochschule Bremerhaven nicht als eigenständiges Fach vermittelt, sondern als Querschnittsthema durch alle Semester gezogen, damit es zum Alltagshandeln wird.
- Studierende erkennen den Wert von Testing und Qualitätssicherung meist erst im Praxissemester, wenn sie in Unternehmen auf konkrete Probleme stoßen und mit Testautomatisierung beauftragt werden.
- Nachhaltigkeit wird strukturell verankert: Statt alle fünf Jahre neue Laborrechner zu kaufen, setzt die Hochschule auf Refurbished-Server, minimale Docker-Ressourcen und Open-Source-Tools, damit Studierende lernen, mit begrenzten Ressourcen auszukommen.
- Das Grundwissen im Programmieren bleibt unverzichtbar, weil nur wer die Grundlagen beherrscht, KI-generierte Ergebnisse überhaupt sinnvoll einschätzen und weiterverarbeiten kann.
- Wenn zwei Lehrende mit unterschiedlichen Perspektiven, Qualitätssicherung und Programmierung, gemeinsam diskutieren und auch streiten, lernen Studierende, dass technische Entscheidungen ein Abwägen sind und kein fixes Richtig-oder-Falsch.
Qualitätssicherung gehört in die Studienkultur, nicht in eine einzelne Vorlesung
Wer Qualitätssicherung als isoliertes Fach unterrichtet, verschenkt ihren eigentlichen Hebel. Karin Vosseberg, Professorin an der Hochschule Bremerhaven, verankert Qualität stattdessen quer durch die Lehre, vom ersten Semester bis zum Abschlussprojekt.
Der Grund ist einfach. Qualität soll zum Alltagswerkzeug der Studierenden werden, nicht zu einer Pflichtübung am Ende der Entwicklung. Wenn sie nur als nachgelagerte Methode auftaucht, bleibt sie das, was viele Studierende in ihr sehen: eine lästige Zusatzaufgabe.
Im Software Engineering an Karins Hochschule arbeiten drei Lehrende eng zusammen, die das Thema gemeinsam vorantreiben wollen. Diese Bündelung ist die Voraussetzung dafür, dass Qualität nicht von der Tagesform einer einzelnen Lehrkraft abhängt. In der reinen Programmierausbildung ist sie dagegen weniger fest verdrahtet.
Warum Qualitätssicherung bei Studierenden als unsexy gilt
Studierende wollen Neues bauen, nicht prüfen. Genau hier liegt die didaktische Schwierigkeit. KI ist gerade hoch im Kurs, Qualitätssicherung wirkt im Vergleich altbacken.
Die Nachfrage steigt trotzdem, weil die Studierenden in den Unternehmen sehen, dass diese Arbeit gebraucht wird. Während des Studiums erkennt kaum jemand den Reiz. Das ändert sich oft erst später.
Der Wendepunkt ist häufig das Praxissemester. Dort landen Studierende regelmäßig in einer Rolle der Qualitätssicherung, weil man dafür Systeme analysieren und in sie hineinschauen muss. Aus dieser Erfahrung entstehen dann konkrete Abschlussthemen, viele davon zur Testautomatisierung.
Karin berichtet von Absolventen, die nach dem Studium in der Qualitätssicherung arbeiten und sich rückblickend fragen, warum sie das Thema vorher nicht spannend fanden. Die Begeisterung kommt mit der Praxis, nicht mit der Vorlesung.
Qualitätssicherungsverfahren machen die Software von Anfang an besser
Der entscheidende Perspektivwechsel: Prüfverfahren sind nicht nur dazu da, fertige Software abzunehmen. Wer sie kennt, baut von vornherein besser.
Äquivalenzklassen und Entscheidungsbäume sind dafür gute Beispiele. Sie dienen nicht allein dem Testentwurf, sondern zeigen auch typische Fehlerquellen, die sich in der Entwicklung von Anfang an vermeiden lassen.
Diese Brücke schlägt Karin gemeinsam mit einem Kollegen aus der Programmier- und DevOps-Ecke. Sein Blick liegt auf Monitoring und dem Messen von Systemen, ihrer auf den Qualitätssicherungsverfahren. Gemeinsam fragen sie: Was lernen wir aus diesen Verfahren für das Bauen von Software?
Dazu gehört auch, Werkzeuge zu verstehen, statt sie nur zu benutzen. Wer nachvollzieht, wie ein Werkzeug funktioniert und welche Sprachkonzepte es ermöglichen, kann dieses Wissen in die eigene Entwicklung zurückspielen.
Wie zwei Lehrende den Studierenden das Abwägen vorleben
Eine Wahlpflichtveranstaltung wird von zwei Lehrenden mit unterschiedlichen Ansätzen gehalten, und das ist Absicht. Die beiden diskutieren und streiten auf fachlicher Ebene vor der Gruppe.
Der Effekt für die Studierenden ist konkret. Sie sehen, dass es selten die eine richtige Entscheidung gibt, sondern ein Abwägen: Was passt zum Team, was zur Anwendung, was zur konkreten Lösung?
Genau dieses Reden über die eigene Arbeit fällt vielen Studierenden schwer. Indem die Lehrenden den fachlichen Disput vormachen, üben sie es indirekt mit. Reden über Qualität ist selbst eine Qualitätssicherungs-Kompetenz.
Skalierung ersetzt kein Nachdenken über Performance
Mehr Services hochfahren ist keine Antwort auf ein Performance-Problem. Karin beschreibt das wiederkehrende Muster: Systeme werden gelauncht, am ersten Tag gehen viele Nutzer drauf, und es kracht sofort.
Auf die Frage, warum solche Lastfälle nicht vorher geprüft wurden, kommt oft die Antwort, man fahre eben ein paar Services hoch und skaliere horizontal. Dabei ist eine hohe Zahl gleichzeitiger Zugriffe nichts Ungewöhnliches, das man nicht vorab durchspielen könnte.
Horizontale Skalierung erhöht zudem die Komplexität. Wer reflexartig skaliert, kauft sich diese Komplexität ein und löst das eigentliche Problem trotzdem nicht.
Deshalb übt Karin mit Studierenden das systematische Untersuchen statt des schnellen Reflexes. Ein Beispiel aus der eigenen Infrastruktur: Eine kleine Webanwendung in einem sparsamen Docker-Container wurde nach zehn Minuten regelmäßig abgeräumt, weil der Speicher voll lief.
Die Lernfrage lautet dann nicht, wie man mehr Speicher dranhängt, sondern wie man so ein Phänomen überhaupt untersucht. Liegt es am Speicher, an der Java Virtual Machine, am Tomcat? Studierende sollen Szenarien aufbauen und neugierig werden, statt zum Totschlag-Argument “mehr Speicher” zu greifen.
Nachhaltigkeit beginnt beim bewussten Umgang mit Ressourcen
Software-Nachhaltigkeit heißt für Karin zuerst, Ressourcen wieder zu sehen. Früher war das selbstverständlich. Wer mit 128K Speicher arbeitete, achtete in den Algorithmen automatisch auf Verbrauch.
Heute kosten Ressourcen erst einmal nichts, also schaut kaum jemand hin. CPUs in der Cloud, mehr Speicher, mehr Strom sind nur ein paar Parameter weit weg. Das macht fahrlässig.
Den Blick auf Ressourcen bringt die Lehre über ständiges Messen zurück. Studierende sollen die Laufzeit ihrer Funktionen messen, eine Implementierung in einer anderen Sprache vergleichen, den Datendurchsatz beobachten. Manche finden das nervig, weil dabei sichtbar nichts Neues entsteht.
Ein konkretes Beispiel ist die Wahl des Protokolls bei vernetzten Systemen. Wenn beide Seiten sich kennen und ein einfaches Format teilen, reicht oft eine CSV. Ein geschwätziges Format hat seine Berechtigung, aber nur dort, wo es wirklich gebraucht wird. Die Frage, wie viel Datenvolumen tatsächlich nötig ist, gehört in den Handwerkskasten.
Wie die Hochschule Nachhaltigkeit in die Infrastruktur baut
Nachhaltigkeit zeigt sich auch im Aufbau des Labors. Früher standen dort fünfzehn Rechner, alle fünf Jahre ausgetauscht und ein halbes Jahr später schon schwächer als die Laptops der Studierenden, die ihre Geräte einfach davorstellten.
Heute kommen Studierende mit einem einfachen Laptop an eine zentrale Infrastruktur, die Informatik-Cloud. Sie läuft auf Refurbished-Geräten und ist bewusst sparsam ausgelegt. Jeder Studierende bekommt einen Docker-Container mit knapp bemessenem Speicher, damit das Bauen unter realen Ressourcengrenzen stattfindet.
Diese Auslegung verbindet ökologische mit sozialer Nachhaltigkeit. Eingesetzt werden Open-Source-Werkzeuge mit einer einheitlichen Umgebung für Mac, Windows und Linux, damit alle Studierenden teilhaben können. Wer sich kein eigenes Gerät leisten kann, bekommt einen Leih-Laptop.
Getragen wird das von einer kohortenübergreifenden Gruppe aus Lehrenden, Mitarbeitenden und Studierenden. Wenn die Älteren das Studium abschließen, rücken die Jüngeren nach. So entsteht ein Kern, der die Haltung im Studiengang weiterträgt.
Programmieren bleibt Pflicht, auch im Zeitalter der KI
Ohne Programmieren ist es keine Informatik. Diese Linie zieht Karin klar, auch gegen das Argument, KI könne das ja übernehmen.
Die Basics entscheiden über die Urteilsfähigkeit. Erfahrene Entwickler können ein KI-Ergebnis einschätzen: Ist es brauchbar, ist es ein Ansatz zum Weiterarbeiten, oder ist es Schrott. Diese Einschätzung setzt eigenes Basiswissen voraus.
Daraus folgt ein Problem, das Karin offen als ungelöst bezeichnet. Wenn die einfachen Aufgaben an die KI abgegeben werden, fällt die Stufe weg, auf der man früher Erfahrung gesammelt hat. Wie wird jemand Seniorberater, wenn es die Rolle des Juniorberaters nicht mehr gibt?
Wie kann ich für komplexere Aufgaben, wo die KI nur Ansätze liefert, das Problem in den Griff kriegen, wenn ich die Erfahrung der einfachen Aufgaben nicht habe?
Karin Vosseberg
In der Bewertung von Abgaben verschiebt das den Fokus. Statt eines wohlgeschliffenen Textes wollen die Lehrenden einen authentischen Text, der zeigt, was die Studierenden tatsächlich wissen. Nachweisen lässt sich ein KI-Einsatz selten, also hilft vor allem das Gespräch.
Vom Handwerk in den Kopf: warum Wiederholung über alle Semester zählt
Programmieren lernt man durch Tun, nicht aus Büchern. An einer Hochschule für angewandte Wissenschaften passiert das in Laboren, in denen Studierende selbst kleine Übungen machen, die schrittweise größer werden.
Der typische Knick kommt verlässlich. In Java sind die ersten Wochen mit Schleifen, Abfragen und Variablen gut machbar. Dann kommen Klassen, Objekte und Polymorphie, und an dieser Stelle wird vielen erst klar, dass Programmieren schwer ist. Es braucht den Moment, in dem es Klick macht, ähnlich wie beim Lernen einer Sprache.
Das eigentliche Ziel ist, dass das Handwerkszeug verfügbar bleibt. Karin erzählt von einem Studierenden im einjährigen Abschlussprojekt, der Daten von einer Seite herunterladen sollte und feststellte, das habe er seit dem ersten Semester nicht mehr gemacht.
Deshalb greift die Lehre dieselben Techniken über alle Veranstaltungen hinweg immer wieder auf. Messen, Automatisierungsketten im Terminal, Ressourcen im Blick behalten. Nicht aus Wiederholungszwang, sondern damit sich das Wissen verinnerlicht und im späteren Projektalltag abrufbar bleibt.
Was die Studierenden mitnehmen sollen, ist diese Begeisterung für kleine, beharrliche Schritte. Wer neu in einem Unternehmen ist, kann nicht alles auf einmal ändern. Aber er kann anfangen zu hinterfragen, was passiert, und damit Nachhaltigkeit und Qualität Stück für Stück in die Projektkultur tragen.
Häufig gestellte Fragen
Wann erkennen Informatikstudierende üblicherweise den Wert von Testing?
Meist erst im Praxissemester. Dort landen Studierende regelmäßig in einer Rolle der Qualitätssicherung, weil sie Systeme analysieren und in sie hineinschauen müssen. Aus dieser Erfahrung entstehen häufig Abschlussthemen, viele davon zur Testautomatisierung. Karin Vosseberg berichtet von Absolventen, die später in der Qualitätssicherung arbeiten und sich rückblickend fragen, warum sie das Thema im Studium langweilig fanden.
Was bringen Testentwurfsverfahren für das Entwickeln selbst?
Sie verhindern Fehler, statt sie nur nachträglich zu finden. Äquivalenzklassen und Entscheidungsbäume dienen nicht allein dem Testentwurf, sie zeigen auch typische Fehlerquellen, die sich beim Bauen von Anfang an vermeiden lassen. Dazu gehört, Werkzeuge zu verstehen statt sie nur zu bedienen: Wer nachvollzieht, welche Sprachkonzepte ein Werkzeug ermöglicht, kann das in die eigene Entwicklung zurückspielen.
Löst horizontales Skalieren ein Performance-Problem?
Nein. Wer reflexartig Services hochfährt, kauft sich zusätzliche Komplexität ein und hat das eigentliche Problem trotzdem nicht gelöst. Das Muster wiederholt sich: Ein System geht live, am ersten Tag kommen viele Nutzer, und es kracht sofort. Eine hohe Zahl gleichzeitiger Zugriffe ist nichts Ungewöhnliches, das man nicht vorab als Lastfall durchspielen könnte.
Wie bringt man den Ressourcenverbrauch von Software wieder in den Blick?
Durch ständiges Messen. Studierende sollen die Laufzeit ihrer Funktionen messen, eine Implementierung in einer anderen Sprache gegenüberstellen und den Datendurchsatz beobachten. Dazu kommt die Frage nach dem Datenvolumen: Wenn beide Seiten sich kennen und ein einfaches Format teilen, reicht oft eine CSV. Ein geschwätziges Format hat seine Berechtigung, aber nur dort, wo es gebraucht wird.
Was bringt es, wenn zwei Lehrende mit unterschiedlichen Perspektiven eine Veranstaltung gemeinsam halten?
Studierende sehen das Abwägen live. In einer Wahlpflichtveranstaltung diskutieren und streiten zwei Lehrende bewusst auf fachlicher Ebene vor der Gruppe: einer mit Blick auf Monitoring und Messen, eine mit Blick auf Qualitätssicherungsverfahren. So wird deutlich, dass es selten die eine richtige Entscheidung gibt, sondern Fragen nach Team, Anwendung und konkreter Lösung.
Ist Programmieren lernen noch nötig, wenn KI Code erzeugen kann?
Ja. Ohne Programmieren ist es keine Informatik, und die Basics entscheiden über die Urteilsfähigkeit. Nur wer die Grundlagen beherrscht, kann ein KI-Ergebnis einschätzen: brauchbar, ein Ansatz zum Weiterarbeiten oder unbrauchbar. Ohne dieses eigene Basiswissen fehlt der Maßstab, um generierte Ergebnisse sinnvoll weiterzuverarbeiten.
Welches Problem entsteht, wenn KI die einfachen Programmieraufgaben übernimmt?
Die Stufe fällt weg, auf der Erfahrung entstand. Karin Vosseberg bezeichnet das offen als ungelöst: Wie wird jemand Seniorberater, wenn es die Rolle des Juniorberaters nicht mehr gibt? Bei komplexeren Aufgaben liefert die KI nur Ansätze, und dann fehlt die Routine aus den einfachen Fällen. In der Bewertung von Abgaben zählt deshalb der authentische Text und vor allem das Gespräch.
Wie lässt sich ein Informatiklabor ressourcenschonend aufbauen?
Über zentrale, bewusst knapp ausgelegte Infrastruktur statt regelmäßiger Hardwarekäufe. Früher standen fünfzehn Rechner im Labor, alle fünf Jahre ersetzt und bald schwächer als die Laptops der Studierenden. An ihre Stelle trat eine Informatik-Cloud auf Refurbished-Geräten, mit einem Docker-Container je Studierendem und knapp bemessenem Speicher. Open-Source-Werkzeuge laufen einheitlich auf Mac, Windows und Linux, Leih-Laptops gleichen fehlende eigene Geräte aus.
