Adaptives Testen

Bei adaptiven Tests passt das Testsystem die Schwierigkeit eines Tests während der Durchführung anhand der bisherigen Antworten der Teilnehmenden an. Im TBA II-Projekt wurde durch das IQB die Möglichkeit, adaptive Tests mit dem Testcenter durchzuführen, umgesetzt. kompetenztest.de (KT) erprobte dieses Feature 2025 und 2026 im Praxiseinsatz bei der Durchführung der Vergleichsarbeiten (VERA) in Deutsch Lesen und Mathematik an 3. Klassen in Schleswig-Holstein. Diese Tests bestehen aus jeweils einem Basismodul und zwei Ergänzungsmodulen, die unterschiedliche Schwierigkeitsgrade aufweisen. Bisher legten die Lehrkräfte im Vorfeld fest, welches Ergänzungsmodul Schüler*innen entsprechend ihrem aktuellen Leistungsstand bearbeiten sollen. Diese Entscheidung wurde nun automatisch durch das Testsystem getroffen. Als Entscheidungsgrundlage dienten dabei die automatisch auswertbaren Antworten der Schüler*innen im Basismodul.

Für diesen Einsatz in der Schulpraxis wurde das IQB Testcenter in das KT-Schulportal integriert, was im Folgenden beschrieben wird.

KT-Schulportal

Beim KT-Schulportal handelt es sich um eine Webapplikation, die die Organisation, Durchführung und Auswertung von schulischen Vergleichsarbeiten und Befragungen ermöglicht. Es umfasst Funktionen zur Vorbereitung der Testdurchführung wie z. B. die Verwaltung von Schulen, Anmeldung von Klassen zu Tests und zur Bereitstellung von Durchführungsmanualen für Lehrkräfte. Tests können sowohl digital über ein eigenes Onlinetestsystem als auch analog auf Papier durchgeführt werden. Während der digitalen Durchführung hat die Lehrkraft die Möglichkeit, den Bearbeitungszustand ihrer Schüler*innen über eine Monitoringfunktion im Schulportal zu verfolgen. Nach dem Test werden geschlossene und viele halboffene Items automatisch kodiert und die Antworten offener Items der Lehrkraft zur Bewertung vorgelegt. Wurde der Test auf Papier durchgeführt, gibt die Lehrkraft im Schulportal die kodierten Antworten ein. Nachdem alle Antworten bewertet bzw. eingegeben wurden, werden Lehrkräften, Schulleitungen und Schulaufsichtsbehörden im Schulportal Ergebnisrückmeldungen zur Verfügung gestellt.

Technisch handelt es sich beim KT-Schulportal um eine PHP-Webanwendung. Diese wird in einem Kubernetes Cluster bei einem Public Cloud Provider gehostet.

Für TBA II wurde die Testdurchführung und das Monitoring für die Lehrkräfte durch das Testcenter übernommen.

Hosting des Testcenters

Für das Hosting von Testcenter Instanzen für die VERA-Durchführungen wurden virtuelle Server des Public Cloud-Anbieters Oracle Cloud Infrastructure (OCI) verwendet. Es wurde sich für die Nutzung dieses Anbieters entschieden, da bei diesem auch die restliche Infrastruktur von KT gehostet wird.

Als Linux Distribution wurde Oracle Linux 8 verwendet.

Zur Installation und Konfiguration der Server verwendeten wir das Infrastructure-as-Code-Tool Ansible. Ansible ermöglicht die reproduzierbare Konfiguration mehrerer Server und sorgt durch die Verwendung von gut lesbaren YAML-Konfigurationen für eine automatische Dokumentation der Konfiguration. Zur Installation und Konfiguration des Testcenters erstellten wir eine Ansible-Collection, die eine Rolle zur Installation und mehrere Module zur Verwaltung von Testcenter-Usern, -Workspaces und weiteren -Einstellungen beinhaltet. Die Ansible-Rolle orientiert sich stark am offiziellen Installations-Bash-Skript des IQB. Bei Veröffentlichung neuer Testcenter Versionen überprüften wir, ob Anpassungen am Installationsprozess vorgenommen wurden oder neue Migrationsskripte hinzugefügt wurden und passten die Ansible-Rolle entsprechend an.

Abweichend von der Referenzinstallation des IQB wurde als Loggingmechanismus für Docker journald verwendet. Dafür wurde sich entschieden, um Logmeldungen nicht zu verlieren, falls ein Container neu erzeugt wird. Dafür waren Anpassungen an der Docker Compose Konfiguration nötig, die mittels einer zusätzlichen Docker Compose-Datei hinzugefügt wurden, ohne die Originalkonfigurationsdateien des IQB zu verändern.

Zusätzlich wurden durch die Ansible Rolle regelmäßige Backups der Testcenter MySQL-Datenbank in ein Storage Bucket der Oracle Cloud konfiguriert. Für die Backups wurde das Command Line Tool mysqlsh verwendet, dass in einem seperaten Docker Container ausgeführt wurde. Um die Ausführung zu steuern, wurde eine Systemd-Unit erstellt, die zweimal täglich durch einen Systemd-Timer getriggert wurde.

Um auch die Provisionierung der Testcenter Instanzen mit Testinhalten zu automatisieren, wurden drei Ansible Module entwickelt, die User und Workspaces verwalten können und Änderungen an der Testcenter Konfiguration vornehmen können. Dafür nutzen diese verschiedene Endpunkte der Testcenter API.

Die Verwendung von Ansible zur Automatisierung der Installation erwies sich als sehr nützlich, als für die Durchführung der VERA-Tests 2026 die Entscheidung getroffen wurde, die Last auf mehrere Testcenter Instanzen zu verteilen und mittels Ansible mehrere identisch konfigurierte Instanzen bereitgestellt werden konnten.

Die Ansible Collection wurde auf GitHub veröffentlicht und für eigene Implementationen des Testcenters genutzt werden.

Anbindung an das KT-System

Um das Testcenter in das oben beschriebene Schulportal von KT zu integrieren, nutzten wir dessen REST-API. Zur Nutzung der API entwickelten wir die PHP-Bibliothek testcenter-connector.

Übertragung der Anmeldedaten

Um an VERA-Tests teilzunehmen, müssen Schulen im Herbst des Vorjahres ihre teilnehmenden Klassen im Schulportal von KT anmelden. Dabei werden Klassen- und Schüler*innencodes erzeugt, über die sich die Schüler*innen während des Testzeitraums einloggen können. Es werden dabei keine personenbezogenen Daten erhoben, sondern nur pseudonyme Schüler*innencodes, deren Zuordnung zu Klarnamen ausschließlich in der Schule erfolgt.

Damit sich Schüler*innen mit den bei der Klassenanmeldung erzeugten Zugangsdaten im Testcenter anmelden können, müssen diese im Testcenter importiert werden. Zunächst werden dafür in allen Testcenter-Instanzen Workspaces für die einzelnen Tests angelegt und die entsprechenden Booklets in diese hochgeladen. Dieser Prozess wurde durch die oben beschriebene Ansible-Rolle und die zugehörigen Ansible-Module automatisiert. Anschließend erfolgte eine Zuordnung der angemeldeten Klassen auf jeweils eine Testcenter-Instanz. Diese Zuordnung musste vor Beginn des Tests festgelegt werden, da die einzelnen Instanzen vollständig unabhängig voneinander betrieben wurden, d.h. jede Instanz nutzte eine eigene Datenbank und hatte nur Zugriff auf die Antwortdaten der Schüler*innen, die den Test auf dieser Instanz durchführten. Damit Inkonsistenzen in den Daten ausgeschlossen werden können, muss deshalb sichergestellt werden, dass jede*r Schüler*in immer auf der gleichen Instanz angemeldet wird. Durch Bildung eines Hashs aus der Schul-ID wurden die Klassen möglichst gleichmäßig auf drei Testcenter-Instanzen verteilt.

Nachdem der Klassenanmeldezeitraum abgeschlossen war und die Testcenter-Instanzen mit den Testinhalten provisioniert worden sind, wurde ein Batch-Job gestartet, bei dem die Anmeldedaten aller angemeldeten Klassen in die Testcenter-Instanzen importiert wurden. Wenn später Änderungen an Klassenanmeldungen durchgeführt wurden, wurden deren geänderten Anmeldedaten automatisch erneut in das Testcenter importiert.

Es wurde dabei für jede Klasse eine separate Testtaker-Datei generiert, um deren Größe überschaubar zu halten und bei Änderungen an einer Klasse nur eine einzelne Testtaker-Datei updaten zu müssen. Für jede*n Schüler*in wurde ein Login-Element erzeugt. Dabei wurde als mode run-hot-return gesetzt, da Schüler*innen die Möglichkeit haben sollten, sich während der Testzeit erneut einzuloggen und den Test weiter bearbeiten zu können. Für diese Logins wurde ausschließlich das Attribut name gesetzt, für das als Wert eine Kombination aus Klassenpasswort und Schüler*innencode verwendet wurde. Für den Zugriff auf die Testleitungskonsole durch Lehrkräfte legten wir zusätzlich pro Klasse ein Login mit mode monitor-group an. Für dieses wurde ein langer zufallsgenerierter Username gesetzt, der zur Weiterleitung über einen Link aus dem Schulportal verwendet wurde.

Da wir die Loginseite des Testcenters zum Zeitpunkt der Durchführung der VERA-Tests als zu komplex für Drittklässler*innen einschätzten, entschieden wir uns die bestehende Loginseite von KT weiterzuverwenden. Durch diese vorgeschaltete Loginseite konnten außerdem alle Klassen den gleichen Loginlink erhalten, unabhängig davon, zu welcher Testcenter-Instanz sie zugeordnet waren. Nach erfolgreichem Login wurden die Schüler*innen direkt in die entsprechende Testcenter-Instanz in den Test weitergeleitet. Für diese Weiterleitung war das oben beschriebene Vorgehen nötig, dass nur das name-Attribut der Login-Elemente gesetzt wurde (vgl. Testcenter-Doku).

Übertragung und Konvertierung der Antwortdaten

Nach Durchführung des Onlinetests im Testcenter müssen die Antwortdaten der Schüler*innen in das System von KT importiert werden, um anschließend die automatische und manuelle Kodierung, sowie die Rückmeldung der Ergebnisse über dieses System durchzuführen.

Wenn eine Lehrkraft im Schulportal ihre persönliche Seite aufruft, auf der sie den Bearbeitungsstand ihrer Klassen sehen und die manuelle Kodierung der Antworten starten kann, wird im Hintergrund überprüft, ob im Testcenter neue Daten für eine ihrer Klassen vorliegen und diese gegebenenfalls importiert. Um dies zu überprüfen, verwenden wir den /workspace/{ws_id}/results Endpunkt der Testcenter-API. Dieser gibt einen Timestamp der letzten Änderung einer Klasse zurück, der mit einem entsprechenden Timestamp zum Zeitpunkt des letzten erfolgreichen Imports in der KT-Datenbank verglichen wird.

Da es zum Zeitpunkt der Testdurchführungen noch kein Modul zur manuellen Kodierung von offenen Items für Lehrkräfte gab, verwendeten wir die bestehende manuelle Korrektur von KT weiter, um die offenen Items dennoch kodieren zu können. Diese kann nicht mit VERONA-Items umgehen, sondern unterstützt nur das interne HTML-Itemformat von KT. Da aber in anderen Bundesländern VERA-Tests mit identischen Items von KT im eigenen System durchgeführt wurden, lagen die Items, die für TBA II kodiert werden mussten, auch im Itemformat von KT vor. Dies ermöglichte es sowohl die manuelle als auch die automatische Kodierung von KT für TBA II zu verwenden. Dazu mussten allerdings die Antwortdaten aus dem Testcenter in das von KT verwendete Antwortdatenformat konvertiert werden. Dies war nicht vollständig automatisch möglich, da sich die Datenformate von Testcenter und KT teilweise stark unterschieden und die verwendeten IDs für Subitems nicht immer konsistent waren. Es war deshalb nötig, für die einzelnen Tests jeweils eine Konfigurationsdatei zu erstellen, in der konfiguriert wurde, wie die einzelnen Items konvertiert werden sollen.

Neben der Konvertierung der Antwortdatenformate war außerdem eine Zuordnung, welche Schüler*innen welches Ergänzungsmodul bearbeitet haben, nötig. Bei anderen Tests, die bisher von KT durchgeführt wurden, wurde diese Entscheidung vorab bei der Klassenanmeldung getroffen, bei TBA II wurde sie erst während der Testdurchführung durch die adaptive Auswahl des Ergänzungsmoduls entschieden. Welches Modul bearbeitet wurde, konnte beim Import anhand der bearbeiteten Items erkannt und dann richtig in der KT-Datenbank abgelegt werden. Die Ergebnisrückmeldung erfolgte anschließend separat für die beiden Ergänzungsmodule.

Da durch die Konvertierung die Antwortdaten so vorlagen, als wäre der Test über das System von KT durchgeführt worden, mussten an den nachfolgenden Prozessen zur Kodierung und Ergebnisrückmeldung kaum Anpassungen vorgenommen werden. Außerdem konnten wir so eine spätere Einsichtnahme in die bearbeiteten Tests durch Schüler*innen, Eltern und Lehrkräfte ermöglichen. Diese ist allein mit dem Testcenter aufgrund eines fehlenden Read-Only-Modus aktuell nicht möglich.