Hintergrund des Vorfalls
In Baden-Württemberg hat eine IT-Panne im Schulbereich über zwei Jahrzehnte hinweg unbemerkt gewütet. Ein Softwarefehler sorgte dafür, dass insgesamt 1.440 Lehrerstellen unbesetzt blieben, obwohl sie im System als besetzt galten . Seit 2005 wurden frei werdende Stellen nicht neu besetzt, weil die Verwaltungssoftware die Positionen fälschlich weiterhin als belegt führte . Die Panne geht auf den Wechsel des Lehrer-Personalverwaltungssystems im Jahr 2005 zurück – nach dem Umstieg auf das System DIPSY-Lehrer wurden offenbar Daten fehlerhaft übertragen. „Derzeit gehen wir davon aus, dass bereits bei der Datenübertragung ein Fehler passiert sein muss“, zitiert das Kultusministerium Baden-Württemberg .
Erst im Sommer 2025, nach Jahren vager Hinweise und einzelner Unstimmigkeiten, kam das ganze Ausmaß ans Licht. Eine vollständige Neuberechnung der Stellenbesetzung mithilfe eines speziellen Prüfprogramms zeigte plötzlich, dass 1.440 rechnerisch besetzte Lehrerstellen in Wirklichkeit frei waren . Anders gesagt: Über Jahre hinweg standen diese Stellen zwar im System, doch in Klassenräumen fehlten die entsprechenden Lehrerinnen und Lehrer. Steuermittel gingen dabei nicht verloren – allerdings wurden jedes Jahr geschätzte 110 bis 120 Millionen Euro an Personalkosten gar nicht ausgegeben, was in einem Milliarden-Haushalt lange Zeit nicht weiter auffiel . Die Konsequenz für die Schulen war gravierend: Woche für Woche fehlten zehntausende Unterrichtsstunden, weil reguläre Lehrkräfte gar nicht eingestellt wurden und stattdessen Vertretungen einspringen oder Stunden ausfallen mussten .
Dieser Vorfall sorgt nun für Empörung in der Bildungsgemeinde und wird politisch aufgearbeitet. Doch für Fachleute aus Software-Test und Qualitätssicherung stellt sich vor allem die Frage: Wie konnte ein solcher Fehler so lange unentdeckt bleiben? Im Folgenden beleuchten wir die technischen Hintergründe des Fehlers, die Gründe für das späte Auffallen und – besonders wichtig – welche Lehren Testmanager und QA-Verantwortliche aus diesem „Super-GAU“ ziehen können.
Der technische Fehler im Detail
Die baden-württembergische Kultusverwaltung verwaltet Lehrkräfte über einen zentralen Stellenpool von rund 95.000 Vollzeitstellen . Zwei IT-Systeme spielen dabei zusammen: DAISY – das Dialogisierte Abrechnungs- und Informationssystem des Landesamts für Besoldung – kümmert sich um Gehaltsabrechnungen. DIPSY-Lehrer – das Dialogisierte Integrierte Personalverwaltungssystem – verwaltet die Verteilung der Lehrerstellen an den Schulen . Schulleitungen können nur dann neue Lehrkräfte anfordern, wenn in DIPSY eine Stelle als frei verfügbar markiert ist; sobald eine Lehrkraft zugewiesen wird, gilt die Stelle als besetzt und wird über DAISY bezahlt . Genau an dieser Schnittstelle trat der Fehler auf: Bestimmte Stellen wurden nie als frei gemeldet, obwohl die bisherigen Stelleninhaber längst nicht mehr da waren.
Der Ursprung liegt offenbar im Jahr 2005, als das alte Personalprogramm durch DIPSY ersetzt wurde. Bei der Migration der Daten kam es zu einem Fehler, sodass damals offene Lehrerstellen im neuen System falsch übernommen wurden . Anstatt als unbesetzt gekennzeichnet zu sein, galten sie weiterhin als „belegt“. In den folgenden Jahren wurde die Stellenstatistik zwar fortgeschrieben, aber nie von Grund auf überprüft . Mit jeder Pensionierung, jedem Todesfall oder längerer Krankheit eines Lehrers hätte eigentlich eine Stelle freigegeben werden müssen – doch wegen Programmierfehlern im automatischen Poolstellen-Management passierte dies in vielen Fällen nicht . Die Software versäumte es, solche Stellen wieder als frei zu markieren, insbesondere bei gewissen Sonderfällen wie langfristiger Erkrankung oder Ruhestand . Diese “virtuell besetzten” Stellen blieben also im System blockiert, obwohl die zugehörigen Lehrer faktisch nicht mehr unterrichteten .
Im Laufe von 20 Jahren führte dieser schleichende Bug zu einer stetigen Aufsummierung der Geisterstellen. Jedes Jahr kamen schätzungsweise 80 bis 100 falsche „Besetzungen“ hinzu . Das erklärt, warum im Jahr 2025 schließlich 1.440 solcher Stellen zusammenkamen. Kurz gesagt: Ein Logikfehler in der Stellenverwaltung – verursacht durch fehlerhafte Datenübernahme und vermutlich weitere Programmiermängel – sorgte dafür, dass Stellen trotz Weggang der Lehrkraft nicht als vakant registriert wurden. Die genaue technische Ursache (etwa welche Berechnungslogik oder Bedingung im Code versagte) ist noch Gegenstand einer Untersuchung durch eine eingesetzte Projektgruppe . Fest steht aber, dass fehlende Abgleiche und inkorrekte Zählweisen im System dazu führten, dass etliche Planstellen als vergeben galten, obwohl niemand darauf arbeitete .
Für die IT-gestützte Schulverwaltung hatte dieser unscheinbare Bug sehr konkrete Auswirkungen: Da die Stellen im System besetzt schienen, konnten Schulen gar nicht erst zusätzliche Lehrer anfordern . Die Stellen blieben einfach ungenutzt. Dieser Vorfall macht deutlich, welch enorme Wirkung ein unsauber programmiertes Verwaltungsverfahren haben kann. Ein einzelnes, zunächst unauffälliges Dateninkonsistenz-Problem entwickelte sich – über zwei Jahrzehnte unbemerkt – zu einer massiven personellen Schieflage im Schulsystem.
Warum fiel der Fehler so lange nicht auf?
Dass ein solch gravierender Fehler über zwanzig Jahre unentdeckt blieb, erscheint auf den ersten Blick unfassbar. Wie konnte niemand merken, dass Hunderte Lehrerstellen faktisch fehlten? Die Gründe dafür liegen in einer Mischung aus systemischer Komplexität, organisatorischen Silos und mangelnder Kontrolle.
1. Große Zahlen, kleiner relativer Effekt: Im Verhältnis zur Gesamtzahl von 95.000 Lehrerstellen fiel die schleichende Lücke lange nicht deutlich ins Auge. Beide zuständigen Ministerien – Kultus und Finanzen – sahen im jährlichen Hin und Her der Personalzuweisungen zunächst kein klares Alarmzeichen. Bei zehntausenden Lehrkräften, die zudem oft ihre Deputatsstunden ändern, wirken 50 oder 100 fehlende Stellen pro Jahr statistisch nicht sofort auffällig . Aus ihrer Sicht blieb der Vorgang „unauffällig“ . Anders ausgedrückt: Die Fehlerquote im System wuchs pro Jahr nur im Promillebereich, was im Alltagsgeschäft unterging.
2. Fehlendes Controlling und Datenabgleich: Entscheidend war, dass nie eine vollständige Neuberechnung oder Gegenprüfung der Daten erfolgte . Man verließ sich blind auf die fortgeschriebenen Zahlen aus DIPSY. Offensichtlich gab es keinen Automatismus, der beispielsweise jährlich prüfte: Wie viele Lehrer bezahlen wir tatsächlich (DAISY) vs. wie viele Stellen gelten als besetzt (DIPSY)? Ein solcher Soll-Ist-Abgleich hätte die Diskrepanz vermutlich früher ans Licht gebracht. Doch ein umfassendes Controlling über die Jahre fand nicht statt . Diese Lücke wird inzwischen selbst von der Verwaltung eingeräumt – nicht umsonst wurde nun eine Arbeitsgruppe eingesetzt, um das Controlling deutlich zu verbessern und solche Fehler künftig auszuschließen .
3. Haushaltsmittel wurden nicht hinterfragt: Normalerweise hätte auffallen können, dass jährlich hohe Summen im Bildungsetat gar nicht abgerufen wurden – schließlich waren 1.440 Stellen etatisiert, deren Gehälter aber nie gezahlt wurden. Das entspricht über 100 Millionen Euro pro Jahr, die übrig blieben . Allerdings ging dieser Budgetüberschuss im Milliardenhaushalt des Landes unter und wurde offenbar stillschweigend für andere Zwecke verwendet . Tatsächlich konnte das Kultusministerium in Sparrunden sogar davon profitieren, indem die nicht verbrauchten Gelder als Puffer dienten . Da keiner explizit nachfragte, warum dieses Geld übrig war, blieb der ursächliche Fehler im Personalbestand verborgen. Ein Kommentator bemerkte spöttisch, es sei erstaunlich, dass „die Haushälter nicht merken, dass jedes Jahr Geld übrig bleibt“ – genau das ist jedoch passiert.
4. Organisatorische Trennung und Vertrauensproblem: Die Zuständigkeiten waren aufgeteilt – die Kultusverwaltung führte das Personal, das Landesamt (LBV) programmierte die Poolstellen-Software, das Finanzministerium überwachte den Etat. Jeder Teilbereich vertraute offenbar darauf, dass die anderen schon richtig rechnen. So fehlte ein ganzheitlicher Blick auf das System. Zudem ist DIPSY-Lehrer ein einzigartiges Konstrukt in Baden-Württemberg; andere Bundesländer nutzen dieses spezielle Verfahren nicht . Das bedeutete, es gab keinen externen Vergleichsmaßstab und wenig Aufmerksamkeit von außen für mögliche Probleme in diesem Nischensystem.
5. Warnsignale wurden ignoriert: Es gab Anzeichen, die auf Ungereimtheiten hindeuteten – doch sie drangen nicht durch. Beispielsweise soll der Landesschülerbeirat bereits im August 2024 auf Unstimmigkeiten hingewiesen haben, als ihm Diskrepanzen bei Lehrerzahlen auffielen . Eine entsprechende Anfrage blieb jedoch unbeantwortet . Hier zeigt sich ein klassisches Problem: Wenn Meldungen von der „Basis“ nicht ernst genommen oder nicht an die richtige Stelle weitergeleitet werden, kann ein Fehler weiter schlummern. Erst ein neuer Impuls aus dem Finanzministerium führte schließlich zur genaueren Prüfung, in deren Folge das Update 2025 die 1.440 Geisterstellen offensichtlich machte .
Zusammengefasst blieb der Bug so lange unentdeckt, weil er sich gut versteckte: im Dickicht einer komplexen Verwaltungs-IT mit riesigen Datenmengen, wo kleine Abweichungen leicht übersehen werden. Keine automatischen Prüfmechanismen oder regelmäßigen Reviews griffen, um den schwelenden Fehler aufzudecken. Zudem fehlte offenbar lange das Bewusstsein, dass überhaupt ein Fehler vorliegen könnte – man vertraute dem System über Jahre blind. Dieser Vertrauensvorschuss in Kombination mit unzureichender Qualitätssicherung im laufenden Betrieb ebnete dem Fehler den Weg, zwei Jahrzehnte zu überdauern.
Lehren für das Testmanagement
Für Testmanager und Qualitätssicherungs-Profis ist dieser Vorfall ein drastisches Lehrstück. Er zeigt, dass Softwarefehler in komplexen Verwaltungsstrukturen mitunter jahrelang unentdeckt bleiben können – mit erheblichen realweltlichen Folgen – wenn Test- und Kontrollmechanismen lückenhaft sind. Was kann die QA-Community daraus lernen? Hier einige zentrale Punkte:
Testmanagement hört nicht nach dem Go-Live auf: Allzu oft liegt der Fokus von Tests auf der Einführungsphase neuer Software. Doch insbesondere bei langlebigen Verwaltungssystemen muss Qualitätssicherung als kontinuierlicher Prozess verstanden werden. In Baden-Württemberg wurde nach 2005 offenbar nie wieder eine vollständige Validierung der DIPSY-Daten vorgenommen . Lehre: Planen Sie regelmäßige Audits und Health-Checks ein. Ein Testmanager sollte z.B. alle paar Jahre (oder bei wichtigen Änderungen) eine Neu-Abstimmung von kritischen Kennzahlen anstoßen – notfalls mit einem separaten Prüftool, so wie 2025 geschehen . Solche Re-Validierungstests können schleichende Abweichungen frühzeitig entdecken.
Sorgfältige Tests bei Datenmigrationen: Der Ursprung lag hier in einer fehlerhaften Migration von Altdaten . Migrationstests müssen daher mit höchster Sorgfalt erfolgen. Empfehlung: Bei Ablösung eines Altsystems parallel fahren und Ergebnisse abgleichen, wo immer möglich. Testmanager sollten für kritische Daten (wie Anzahl freier Stellen) Abstimmungslisten erstellen: Stimmen die Zahlen im neuen System 1:1 mit dem alten System überein? Falls nicht, muss die Ursache ergründet werden, bevor produktiv geschaltet wird. Es reicht nicht, nur Funktionstests der Software durchzuführen – Datenintegritätstests sind ebenso essenziell.
Edge Cases und Fach-Logik abdecken: In diesem Fall trat der Fehler vor allem bei bestimmten Sonderfällen auf (z.B. Dauerkrankenstand, vorzeitiger Ruhestand) . Solche Randfälle müssen in Testfällen explizit berücksichtigt werden. Testmanager sollten gemeinsam mit Fachexperten alle Geschäftsregeln durchgehen: Was passiert, wenn… ein Lehrer längere Zeit krank ist? Wenn jemand kurz vor Schuljahresbeginn pensioniert wird? – und sicherstellen, dass für jede Regel Konstellationen im Test simuliert werden. Tipp: Erstellen Sie eine Matrix der Sonderfälle und prüfen Sie, ob das System in jedem dieser Fälle das gewünschte Verhalten zeigt (hier: Freigabe der Stelle). Gerade in komplexen Verwaltungssoftwares schlummern Fehler oft in den „Wenn X und Y, dann Z“-Logiken, die selten eintreten.
Integrationstests über Systemgrenzen hinweg: Ein weiteres Lernfeld ist die Bedeutung von integrierten Tests in einer verzahnten Systemlandschaft. DIPSY und DAISY wirkten hier zusammen – der eine Teil verwaltet Stellen, der andere zahlt Gehälter. Offensichtlich fand kein Abgleich statt, ob Anzahl besetzter Stellen = Anzahl ausbezahlter Gehälter. Ein Testmanager sollte solche bereichsübergreifenden Konsistenzprüfungen konzipieren. Empfehlung: Definieren Sie Testcases für System-übergreifende Konsistenz (z.B. Datenabgleich zwischen Personalverwaltung und Gehaltszahlung). Führen Sie End-to-End-Tests durch, die den kompletten Prozess abbilden (von der Stellenausschreibung bis zur Besoldung), um sicherzustellen, dass keine Diskrepanz zwischen den Systemen entsteht. In hochgradig arbeitsteiligen IT-Verfahren muss QA die Gesamtsicht wahren, nicht nur einzelne Module isoliert testen.
Monitoring und Kontrollen etablieren: Qualitätsmanagement in laufenden Systemen bedeutet auch, auffällige Muster zu überwachen. Hier wäre ein anhaltender Personalüberhang (Budgetreste, unbesetzte Stunden) ein solches Muster gewesen. Lehre: Implementieren Sie (ggf. gemeinsam mit dem Controlling) automatisierte Reports oder Alerts für Kennzahlen, die vom Erwartungswert abweichen. Beispiele: “Zeige alle Organisationseinheiten, in denen seit X Monaten keine Stelle frei wurde” oder “Melde, wenn budgetierte Stellen zu mehr als 5% unbesetzt bleiben” etc. Solche Mechanismen gehören zwar eher zur Betriebssteuerung als zum klassischen Test – ein moderner Testmanager sollte jedoch darauf hinwirken, dass präventive Qualitätskontrollen im Betrieb verankert werden. Eine enge Kooperation zwischen QA und Fach-Controlling kann helfen, Datenqualität kontinuierlich zu prüfen und früh zu alarmieren, bevor ein Problem eskaliert.
Dokumentation und Wissenstransfer: Ein subtiler Aspekt langerlaufender Systeme ist der Wissensverlust. Möglicherweise wusste nach 10–15 Jahren niemand mehr genau, wie die Poolstellen-Logik ursprünglich gedacht war und wo mögliche Stolpersteine liegen. Testmanager sollten daher darauf drängen, dass geschäftskritische Regeln dokumentiert werden. Wenn Personal wechselt, muss das Wissen um komplexe Funktionen (wie die automatisierte Stellenfreigabe) erhalten bleiben. In diesem Kontext kann auch Exploratives Testen durch neue Teammitglieder hilfreich sein – frische Augen entdecken bisweilen Unstimmigkeiten, die alteingesessene Nutzer übersehen. Allgemein gilt: Kenntnis der Fachdomäne ist für Tester in Verwaltungssystemen Gold wert. Nur wer versteht, was die Software eigentlich zählen oder steuern soll, kann Hinterfragen, ob die gelieferten Zahlen plausibel sind.
Konkrete Empfehlungen für Testmanager
Abschließend fassen wir die wichtigsten Lessons Learned als Handlungsempfehlungen zusammen:
- Umfassende Migrationstests: Bei Systemwechseln alle übernommenen Daten gründlich abgleichen. Datenfehler bei der Migration können jahrelange Folgewirkungen haben – daher jede Abweichung ernst nehmen und aufklären .
- Regelmäßige Daten-Reviews: Auch Jahre nach Produktivstart periodisch Integritätsprüfungen durchführen. Planen Sie z.B. jährlich oder anlassbezogen einen Full Scan kritischer Daten (wie Stellenpläne) und vergleichen Sie sie mit den Ist-Zuständen .
- Automatisierte Konsistenzchecks: Etablieren Sie Scripts/Reports, die verschiedene Datenquellen gegeneinander prüfen (z.B. Personalstand vs. Gehaltsabrechnung). Stille Diskrepanzen dürfen nicht ungesehen bleiben – Monitoring kann hier als verlängerter Arm der QA dienen.
- Testfälle für Sonderfälle: Schließen Sie fachliche Ausnahmefälle explizit in die Tests ein. Simulieren Sie Ereignisse wie Ruhestand, Todesfall, Langzeiterkrankung oder Teilzeitänderungen und prüfen Sie, ob das System in jedem Fall korrekt reagiert (z.B. die Stelle freigibt).
- Fachabteilungen einbeziehen: Arbeiten Sie eng mit den Domain-Experten zusammen. Lassen Sie sich Geschäftsregeln erklären und überprüfen Sie mit ihnen gemeinsam die Testergebnisse. Eine offene Kommunikation hätte im vorliegenden Fall vielleicht früher Misstrauen geweckt, warum trotz Lehrermangel angeblich alle Stellen besetzt seien.
- Qualitätssicherung im Betrieb verankern: Verstehen Sie QA als dauerhafte Aufgabe. Richten Sie in Abstimmung mit dem Management Kontrollpunkte ein: z.B. halbjährliche Meetings, in denen ungewöhnliche Trends (unbesetzte Stellen, Budgetreste) thematisiert werden. Testmanager können hier mit Zahlen und Fakten aus dem Systemfeed in die Diskussion gehen und so Qualitätsbewusstsein fördern.
Diese Empfehlungen sollen Testmanager dabei unterstützen, systematische Fehler frühzeitig zu erkennen oder ganz zu vermeiden. Gerade in komplexen Verwaltungsstrukturen reicht es nicht, nur bei der Softwareentwicklung zu testen – man muss den lebenden Systemen im Betrieb über die Schulter schauen und kontinuierlich validieren, ob Realität und Soll übereinstimmen.
Fazit
Der Baden-württembergische „Geisterstellen“-Vorfall ist ein eindrückliches Beispiel dafür, wie ein unscheinbarer Programmierfehler ohne ausreichende QA-Maßnahmen zum jahrelangen Schattenproblem werden kann. 1.440 fehlende Lehrerstellen über 20 Jahre – diese Zahl steht sinnbildlich für die Bedeutung von gründlichem Testmanagement und kontinuierlicher Qualitätssicherung. Technisch betrachtet handelte es sich um einen Daten- und Logikfehler in einer speziellen Personalsoftware. Aus Test- und QS-Sicht jedoch offenbart sich vor allem ein Versäumnis in Sachen Kontrollprozesse und ganzheitliche Tests.
Für Testmanager gilt es, daraus mitzunehmen, dass Vertrauen gut, Kontrolle besser ist: Kritische Verwaltungs-IT sollte regelmäßig auf den Prüfstand – durch automatisierte Checks, durchdachte Testfälle und interdisziplinäre Reviews. Die Abstraktionsebene mag hoch sein, doch letztlich müssen die Zahlen in solchen Systemen der Wirklichkeit standhalten. Wenn an irgendeiner Stelle plötzlich 1.400 „Phantom“-Entitäten auftauchen, darf das weder als Zufall abgetan noch aufgrund organisatorischer Zersplitterung übersehen werden.
Positiv lässt sich verbuchen, dass der Fehler nun endlich erkannt wurde und Korrekturmaßnahmen eingeleitet sind. Die Behörden haben eine Arbeitsgruppe ins Leben gerufen, um die genaue Fehlerursache zu ermitteln und für die Zukunft auszuschließen . Für die Schulen bedeutet dies hoffentlich bald zusätzliche Lehrer und Entlastung im Unterricht. Für uns in der Softwaretest-Community bedeutet es einen Weckruf: Wir müssen bei komplexen, langlebigen Systemen noch wachsamer sein, Querprüfungen institutionalieren und auch unbequeme Fragen stellen („Können diese Zahlen wirklich stimmen?“).
Am Ende zeigt der Vorfall, dass Softwarequalität nicht nur ein technisches, sondern immer auch ein organisatorisches Thema ist. Robustere Teststrategien, ein besseres bereichsübergreifendes Controlling und die enge Einbindung von Fachexperten sind der Schlüssel, damit systematische Fehler wie dieser gar nicht erst Jahrzehnte unerkannt bleiben. Testmanager sollten sich ermutigt fühlen, aus solchen Fällen die richtigen Schlüsse zu ziehen – im Sinne einer proaktiven Qualitätssicherung, die langfristig sowohl die Technik als auch die Fachprozesse im Blick behält. Denn die beste Zeit, einen derartigen Fehler zu finden, ist bevor er produktiv geht – die zweitbeste ist jetzt sofort.
Quellen: Die Informationen in diesem Beitrag beruhen auf aktuellen Presseberichten und offiziellen Mitteilungen zum Vorfall in Baden-Württemberg, u.a. von Heise Online , Golem , ZDFheute, Spiegel, sowie einer Pressemitteilung des Kultusministeriums Baden-Württemberg . Diese Quellen wurden herangezogen, um die technischen Details des Fehlers und die Hintergründe präzise darzustellen, und sie sind im Text verlinkt.
