Wer Stud.IP nutzt, erwartet nicht nur neue Funktionen, sondern vor allem Verlässlichkeit. Hochschulen setzen das System täglich in Lehre und Organisation ein – Ausfälle oder schlecht durchdachte Änderungen wären hier fatal. Deshalb ist Qualitätssicherung nicht ein einzelner Schritt am Ende, sondern begleitet den gesamten Entwicklungsprozess.
Bevor eine Zeile Code geschrieben wird, beginnt die Qualitätssicherung bereits bei der Art und Weise, wie Änderungen vorgeschlagen werden. Kleine Anpassungen werden als TIC (Tiny Improvement Commit) formuliert, größere Vorhaben als StEP (Stud.IP Enhancement Proposal). Während TICs relativ frei, aber dennoch präzise beschrieben werden können, müssen StEPs einer festen Struktur folgen, die Nutzen, Komplexität und Einsatzszenarien abbildet. Beide Formate werden automatisch im Forum des Developer Boards veröffentlicht, sobald ein Ticket im GitLab entsprechend gekennzeichnet wird. Dort beginnt die Diskussion – offen, gemeinschaftlich und kritisch.
Gerade StEPs werden intensiv diskutiert, denn sie greifen tief in das System ein. Über sie stimmt die Core Group ab, die sich aus langjährigen Mitgliedern der Community zusammensetzt. Nur mit einer Zweidrittelmehrheit können StEPs angenommen werden. TICs durchlaufen ein schlankeres Verfahren, können aber ebenfalls kontrovers diskutiert werden. Jedes Core Group-Mitglied hat hier die Möglichkeit, ein Veto einzulegen. Wird keine Einigung gefunden, wird der Vorschlag nicht umgesetzt. Schon in dieser frühen Phase zeigt sich, dass Qualität nicht als Checkliste verstanden wird, sondern als Gemeinschaftsaufgabe, bei der viele Perspektiven einfließen. Eine Gemeinschaftsaufgabe, die von allen getragen wird, die sich beteiligen möchten.
Nach Annahme beginnt die eigentliche Umsetzung. In dieser Phase liegt die Verantwortung zunächst stärker bei den Entwickelnden selbst, die ihre Expertise einbringen und eigenständig Entscheidungen treffen. Entwickelnde können sich jederzeit Feedback einholen und dabei auf die langjährige Erfahrung der Communitymitglieder vertrauen. Die intensive Qualitätssicherung greift erneut, sobald ein Feature oder Fix fertiggestellt ist und in die Review-Phase eintritt.
Jede größere Änderung wird vor der Integration in den Main Branch von allen relevanten Bereichen geprüft: Code, UI/UX, Barrierefreiheit und Funktionalität. Erst wenn aus allen Bereichen grünes Licht kommt, darf eingebaut werden. Für diese Reviews gibt es unterschiedliche Formen: Code wird direkt in GitLab begutachtet, die UI oft gemeinsam in virtuellen Konferenzen angeschaut. Zusätzlich entstehen automatisierte Testsysteme, die Änderungen branchweise bereitstellen. Viele Core Group-Mitglieder können sich zudem eigene Testsysteme aufsetzen, um besonders gründlich zu prüfen.
Die parallele Bearbeitung sorgt für Tempo und Effizienz. Gelegentlich können dabei Anpassungen notwendig werden, zum Beispiel wenn nach einer abgeschlossenen Code-Review neue UI-Anforderungen hinzukommen. In solchen Fällen ist die direkte und unkomplizierte Kommunikation innerhalb der Community ein wertvolles Qualitätsmerkmal. Ungereimtheiten bei Reviews lassen sich schnell klären, wodurch die Entwickelnden optimal unterstützt werden, hochwertige Software zu liefern.
Nach der Integration folgt eine Phase des Polishing. Hier werden die verschiedenen Änderungen aufeinander abgestimmt, offene Punkte wie Dokumentation, Textqualität oder Schnittstellen nachgezogen und Übersetzungen ergänzt. Parallel gibt es einen Beta-Standort, der schon früh eine Testversion zum testen oder auch produktiv einsetzt. So lassen sich Fehler, die erst im realen Einsatz sichtbar werden, noch vor dem offiziellen Release beheben. Erst wenn Integrationstests und Beta-Feedback abgeschlossen sind, wird eine neue Stud.IP-Version gepackt und veröffentlicht.
Der gesamte Prozess zeigt, dass Qualität bei Stud.IP. nicht auf schnelle Effekte setzt. Von den ersten Diskussionen über die Reviews bis hin zum Beta-Test ist jede Phase darauf ausgelegt, ein stabiles, nutzerfreundliches und barrierefreies System sicherzustellen. Diese Gründlichkeit sorgt dafür, dass Hochschulen sich seit vielen Jahren auf Stud.IP verlassen können – und das auch in Zukunft werden.
