Testtaker-XML

Tipp

Grundlagenwissen zum Aufbau einer XML ist hier zu finden.

flowchart LR
  A[Basis-Pakete für Player] --> B[Player]
  B --> C[Units]
  C --> D[Booklets]
  D --> E[Testtakers]
  style E fill:#a0e3f3

Handhabung der Logins

Die Handhabung der Testtaker-XML zur Steuerung der Logins ist ein kritischer Punkt der Testdurchführung. Bitte beachten Sie folgende Hinweise:

  • Sie können mehrere Testtaker-XML hochladen. Die Logins werden trotzdem in einer gemeinsamen Liste geführt. Die Aufteilung der Logins in verschiedene Dateien ist also aus Sicht des Testcenter ohne Bedeutung. Sie folgt nur praktischen Erwägungen der Testorganisation.
  • Sofort nach dem Hochladen einer Testtaker-XML sind die darin enthaltenen Logins freigeschaltet1.
  • Das Löschen einer Testtaker-XML verhindert sofort, dass die darin enthaltenen Logins benutzt werden können. Die Antwortdaten sind davon nicht betroffen, d. h. diese werden nicht gelöscht.
  • Die Benutzernamen der Logins müssen eindeutig sein für die gesamte Testcenter-Installation. Es kann also passieren, dass das Hochladen einer Testtaker-XML abgewiesen wird, weil in einem anderen Arbeitsbereich derselbe Benutzername definiert wurde. Nehmen Sie daher nicht zu kurze Benutzernamen oder stimmen Sie sich mit anderen Studien auf derselben Testcenter-Installation ab.
  • Wenn Sie Logins erneut hochladen, die Sie vorher gelöscht hatten und die bereits benutzt wurden, dann sind die alten Antworten ggf. wieder verfügbar2. Sollten Sie für diese Logins den Testmodus geändert haben, riskieren Sie den Verlust von Antwortdaten.

Grundstruktur

Das Beispiel zeigt eine einfache Version einer Testtaker-XML.

testtaker1.xml
<?xml version="1.0"?>
<Testtakers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1            xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/iqb-berlin/testcenter/14.14.0/definitions/vo_Testtakers.xsd">
2  <Metadata/>
3  <Group id="TestTakerGroup_d4c9t" label="Login-Gruppe A">
4    <Login mode="run-hot-return" name="t9f5y" pw="v6e5">
5      <Booklet>booklet1</Booklet>
    </Login>
    <Login mode="run-hot-return" name="y3u6u" pw="y4v5">
      <Booklet>booklet1</Booklet>
    </Login>
  </Group>
</Testtakers>
1
<Testtakers>: Verweis auf XML-Schema, das eine maschinenlesbare Liste aller möglichen Syntax-Elemente einer XML-Datei ist. Viele Text-Editoren benutzen die Angabe xsi:noNamespaceSchemaLocation zur Validierung, und auch das IQB-Testcenter prüft darüber, ob die Syntax korrekt ist. Bitte nutzen Sie die jeweils aktuelle Version.
2
<Metadata>: Ist notwendig, auch wenn es leer ist. Man kann innerhalb dieses Elementes ein Description-Element einfügen, um Erläuterungen zu hinterlegen. Diese werden jedoch an keiner Stelle verwendet – sind also nur zur Verbesserung des Lesens dieser XML gedacht.
3
<Group>: Es muss mindestens ein Group-Element geben. Logins können nicht außerhalb einer Gruppe liegen. Die id muss eindeutig innerhalb des gesamten Arbeitsbereiches sein, also über alle Testtaker-XML hinweg. Das label wird z. B. in der Anzeige des Studienfortschritts verwendet.
4
<Login>: Über das Attribut mode wird eine Vielzahl von Funktionen des Testcenters gesteuert (s. unten). Benutzername name und Kennwort pw stehen für die gängigste Anmeldemethode (s. unten).
5
<Booklet>: Es kann mehrere Booklet-Elemente geben pro Login. Das Booklet wird über seine ID referenziert und muss im Arbeitsbereich gespeichert sein.

Login-Modus

Über das Attribut mode im <Login> wird die Rolle der angemeldeten Person innerhalb einer Testung festgelegt. Es stehen hier sehr unterschiedliche Rollen zur Verfügung. Diese gehen aber nie über den Arbeitsbereich hinaus.

Vorsicht

Die folgende Dokumentation über den Login-Modus könnte veraltet sein. Eine verlässliche und genaue Darstellung finden Sie stets hier.

Testperson: run-hot-return, run-hot-restart

Dies sind die üblichen Rollen einer Person, die an einem Test oder einer Befragung teilnehmen soll. Man bekommt nach dem Ladevorgang nacheinander die vorbereiteten Seiten präsentiert, antwortet über Texteingaben, Ankreuzen, Verschieben usw., und die Antworten werden auf dem Server gesammelt für die Auswertung. Restriktionen der Testdurchführung – z. B. Zeitbeschränkungen – sind genau so wirksam, wie im Booklet-XML definiert.

  • run-hot-return: Wenn sich die Testperson zu einem späteren Zeitpunkt erneut anmeldet, sind alle Antworten wiederhergestellt und die Person setzt den Test dort fort, wo sie ihn verlassen hat. Zeitbeschränkungen haben pausiert, d. h. man kann verbliebene Bearbeitungszeit nutzen. Dieser Modus erlaubt es also z. B., bei Problemen die Testdurchführung abzubrechen und mit einem anderen Browser oder Computer fortzusetzen.
  • run-hot-restart: Eine erneute Anmeldung erzeugt auf dem Server eine komplett neue Testperson. Antworten können demnach nicht fortgesetzt werden nach einmaligen Verlassen der Testung. Dieser Modus ist gedacht für Befragungen, wenn der Kreis der Befragten vorher nicht bekannt ist. Man kann eine Einladung zur Befragung an einen großen Personenkreis verschicken und bereitet dafür nur ein Login vor. Die Personen sehen nicht die Antworten der anderen, fangen aber nach einer erneuten Anmeldung wieder beim Ausgangszustand an.

Testfortschritt beobachten und steuern: monitor-group, monitor-study

Das Testcenter bietet die Möglichkeit, alle Logins eines Group-Elementes – also einer Testgruppen, z. B. Klasse – im Fortschritt zu beobachten und zu steuern. Hierfür ist die Rolle eines Gruppenmonitors mit zahlreichen Funktionen verfügbar. Eine ausführliche Dokumentation finden Sie hier.

  • monitor-group: Diese Anmeldung ist für Lehrkräfte oder Testleitungen vor Ort gedacht. Man kann sich alle Testhefte, die den Personen der Gruppe zugewiesen sind, anschauen, und kann direkt einen Schüler ansprechen, bei dem man ein auffälliges Verhalten sieht (z. B. Verlassen des Browserfensters der Testung).
  • monitor-study: Diese Anmeldung ist zwar aus technischen Gründen ebenfalls innerhalb einer Gruppe definiert, bezieht sich aber auf alle Login-Gruppen eines Arbeitsbereiches. Die Rolle dahinter könnte man mit “Hotline” benennen: Während einer Testung mit vielen Klassen ruft jemand an, und im Support möchte man schnell nach dem Bearbeitungsstand der Gruppe schauen und ggf. eingreifen. Nach der Anmeldung erhält man zunächst alle Gruppen zur Auswahl und kann dann gezielt helfen3.

Test ausprobieren (Qualitäts-Check): run-review, run-trial, run-simulation

Ein Test bzw. eine Befragung ist das Ergebnis eines sehr aufwändigen Entwicklungsprozesses. Am IQB sind daran Lehrkräfte, Psychometriker*innen, Wissenschaftler*innen aus der Fachdidaktik und Vertreter*innen aus der Testpraxis beteiligt. Während der Arbeit ist es wiederholt erforderlich, sich die Aufgaben, Zwischenseiten, Blöcke mit ihren Restriktionen und die Tests insgesamt anzuschauen und zu diskutieren.

  • run-review: Die Antworten werden nur im Browser gespeichert (nicht auf dem Server), damit beim Zurückblättern der Bearbeitungsstand wiederhergestellt werden kann. Es kann eine Dialogbox aufgerufen werden, mit der man Kommentare abschickt, die dann im Arbeitsbereich heruntergeladen werden können. Navigationsbeschränkungen des Booklets werden als Warnung gemeldet, aber nicht angewendet. Bei Ablauf einer Zeitbeschränkung gibt es nur eine Information und keine Zwangsnavigation. Ein ggf. gesetztes Freigabewort CodeToEnter ist bereits in die Dialogbox eingetragen. Es ist eine separate Seite mit allen Aufgaben zur direkten Navigation verfügbar.
  • run-trial: Die Antworten werden auch auf dem Server gespeichert, um die nachfolgenden Prozesse der Antwortverarbeitung testen zu können. Ansonsten ist dieser Modus mit dem vorherigen identisch.
  • run-simulation: Dieser Modus ist für automatische Qualitätsprüfungen im Rahmen der Software-Entwicklung gedacht. Antworten und Logs werden nicht auf dem Server gespeichert, aber Navigationsbeschränkungen, Zeitbeschränkungen und nötige Freigabeworte CodeToEnter sind so aktiviert, wie es für die Testperson zutreffen würde.

Demo: run-demo

Oft gibt es den Wunsch, Interessierten beispielhaft einen Einblick in Testungen zu geben. Eltern, Lehrkräfte oder Verantwortliche in den Ländern möchten wissen, was auf die Schulen bzw. Schüler*innen zukommt. Auch Wissenschaftler*innen mögen Interesse an Itemformaten und dem allgemeinen Layout einer Aufgabe haben. Hierfür können Aufgabenfolgen zusammengestellt werden.

Für diese Art der Nutzung des Testcenters steht der Modus run-demo zur Verfügung. Es erfolgt serverseitig keine Speicherung, Navigations- und Zeitbeschränkungen werden ignoriert, ein ggf. gesetztes Freigabewort CodeToEnter ist bereits in die Dialogbox eingetragen.

Varianten des Anmeldeverfahrens

Richtlinien

Für die nachfolgenden <Login>-Parameter Name (name), Kennwort (pw) und Code (code) müssen geeignete Kombinationen aus Buchstaben und Ziffern gefunden werden. Beachten Sie für Testdurchführungen folgende Hinweise:

  • Die Zeichen müssen gut merkbar sein, damit bei der Übertragung vom Zettel in den Computer kein Fehler passiert.
  • Die Tasten sollen auf der Computer-Tastatur gut findbar sein.
  • Es sollte zur Eingabe nur eine Taste nötig sein. Großbuchstaben und die meisten Sonderzeichen sind also ungünstig.
  • Die Zeichen müssen gut lesbar sein: Optisch sehr ähnliche Zeichen wie n und m oder 1 und l sind zu vermeiden.
  • Die Codes müssen gut sprechbar und akustisch verständlich sein: Sollte z. B. die Testleiterin einem Schüler den Code ansagen, darf es keine Fehler geben.
  • Es sollte keine Gefahr bestehen, dass durch nicht erkannte Zeichenkodierung von Dateien Probleme mit Sonderzeichen (Umlaute!) auftreten.
  • Es sollten keine fortlaufenden oder Serien-Codes verwendet werden. Wenn Schüler*innen mitbekommen, dass die Logins nach dem Schema gxst1, gxst2 usw. vergeben wurden, probieren sie schon mal gxst9.

Das IQB verwendet folgende Zeichengruppen:

  • Buchstaben: abcdefghprqstuvxyz
  • Ziffern: 2345679

Ein Code beginnt am IQB stets mit einem Buchstaben. Danach wechseln sich Ziffern und Buchstaben ab, damit man nicht versucht ist, Worte zu bilden: affe könnte zu Irritation führen, wenn man Groß-/Kleinschreibung hinterfragt oder die Konsonantendopplung vergisst.

Tipp

Das Windows-Programm itc-ToolBox erzeugt Listen von Codes unterschiedlicher Länge nach den obigen Richtlinien. Diese sind auch eindeutig, kommen also nicht mehrfach vor.

Klassisch: Anmeldename und Kennwort

Diese Anmeldeform wird üblicherweise erwartet. Im Eingabeformular der Startseite einer Testcenter-Installation wird der Anmeldename im Klartext gezeigt, die Eingabe des Kennwortes erzeugt aber nur Punkte, d. h. man kann nicht mitlesen. Ein Klick auf das Auge-Symbol macht auch das Kennwort lesbar, was bei der Testdurchführung für die Fehlersuche hilfreich ist.

Wichtig

Ein Anmeldename darf nicht mehrfach vorkommen auf einer Testcenter-Installation. Sollte ein Anmeldename bereits in einem anderen Arbeitsbereich vergeben worden sein, scheitert das Hochladen der Testtakers-XML in das Testcenter.

Nur Anmeldename (URL)

Das Kennwort kann weggelassen werden. Diese Anmeldeform eignet sich besonders für folgende Szenarien:

  • Man möchte den Anmeldeprozess stark vereinfachen. Die Testpersonen bzw. die Befragten sehen eine komplizierte Anmeldung kritisch und man möchte die Motivation zur Teilnahme nicht gefährden.
  • Man möchte über eine URL sofort den Ladevorgang starten und den Test beginnen. Ohne ein Kennwort ist dies möglich, indem man eine URL nach folgendem Schema nutzt: https://www.iqb-testcenter.de/#/u8h5m2a4c3x2f2g8. Hinter der URL der Testcenter-Installation folgt zunächst /#/ und dann der Anmeldename. Dies erlaubt
    • Zugriff über QR-Codes: Schüler*innen scannen mit dem Tablet einen personalisierten Code und springen mit Hilfe der URL sofort in den Test
    • Zugriff über Link in E-Mail: Bei Befragungen mit unbekanntem Personenkreis lädt ein Link eher dazu ein teilzunehmen als mehrere Anmeldedaten
    • Zugriff in einem Integrationsszenario: Die Schüler*innen sind in einem Lernmanagement-System angemeldet und sollen einen Test absolvieren. Den personalisierten Link kann man automatisch erzeugen und ein Klick darauf startet den Test. Wenn dann die Testcenter-Installation eine ähnliche Gestaltung hat (Farbe, Logo), merkt die Testperson nicht, dass sie das Lernmanagementsystem verlassen hat.

Zweistufig: Personencode

Es kann sein, dass die Testleitung Zeit hat, vor Eintreffen der Schülerinnen und Schüler alle Computer zu starten, einen lokalen Standard-Benutzer anzumelden, den Browser zu starten und die richtige Internet-Adresse aufzurufen. Dann ist es auch hilfreich, wenn auf jedem Computer schon Anmeldename und Kennwort eingegeben werden kann und also ein Anmeldeprozess gestartet wird. Anmeldename und Kennwort sind dann für die Gruppe gleich. Es reicht dann anschließend die Eingabe eines kurzen Personencodes durch die Testperson, um eine eindeutige Identifizierung sicherzustellen. Man spart so Testzeit und vermeidet Fehleingaben. Dieses Szenario bietet sich z. B. an, wenn man den Test nicht in der Schule, sondern in dem eigenen oder einem angemieteten Computer-Lab durchführt.

<Login mode="run-hot-return" name="e3p2p" pw="h7u5">
  <Booklet codes="x4u t5a z9i">Booklet1</Booklet>
  <Booklet codes="r3c k6f">Booklet2</Booklet>
</Login>

Personencodes gelten spezifisch für Booklets. Mehrere Codes können in einem Booklet-Element im Attribut code zusammengefasst werden mit einem Leerzeichen dazwischen. Im obigen Beispiel wurden also Logins für fünf Personen definiert. Für den Gruppenmonitor ist dies nicht relevant, d. h. es werden normale Testsitzungen erzeugt.

Zeitbeschränkung einer Anmeldung

Es kann eine zeitliche Gültigkeit für eine Anmeldung bestimmt werden. Hierfür werden der Anmeldegruppe wahlweise die Attribute: validTo, validFrom und validFor hinzugefügt.

Nicht vorher starten
<Group id="TestakerGroup1" label="TestakerGroup1"
       validFrom="17/02/2022 10:00">
  ...
</Group>
Gültig für 20 Minuten
<Group id="TestakerGroup1" label="TestakerGroup1"
       validFor="20">
  ...
</Group>

Adaptives Testen

In der Testtaker-XML können zum Laden eines Testheftes Werte für das adaptive Testen übergeben werden. Welche Werte möglich sind und welche Bedeutung diese haben, ist dem Kapitel: Adaptives Testen zu entnehmen.

Angepasste Texte: CustomTexts

Einige Texte, die im Zusammenhang eines Tests oder einer Befragung als Titel, Eingabeaufforderung oder Warnung usw. gezeigt werden, können – spezifisch für die Logins dieser XML – geändert werden.

1  <CustomTexts>
2    <CustomText key="login_testEndButtonText">
3       Test beenden
    </CustomText>
  </CustomTexts>
1
Das CustomTexts-Element muss direkt hinter dem Metadaten-Element eingefügt werden.
2
Über das Attribut key referenziert man einen bestimmten Eintrag aus der Liste (s. u.).
3
Im Inhalt des CustomText-Elementes wird der neue zu verwendende Text platziert.

Beispiele:

  • Ansprache der Testperson ändern: “Du” oder “Sie”?
  • Bezeichnung der Studie ändern: Ist es eine “Evaluation” oder eine “Lernausgangslage”?

Eine vollständige Liste mit den verfügbaren CustomTexts finden Sie hier. Achten Sie auf den Präfix des Keys: Damit wird der Verwendungszusammenhang angezeigt.

Zurück nach oben

Fußnoten

  1. Nur wenn Sie die Attribute für Zeitrestriktionen in den Logins benutzen, wird die Freischaltung darüber gesteuert. Zeitbeschränkungen sind allerdings manchmal problematisch im praktischen Einsatz, da man schnell den Überblick verliert und die Flexibilität eingeschränkt ist (adhoc-Verschiebung eines Tests auf den nächsten Tag).↩︎

  2. Dies hängt vom Testmodus ab. Nur bei der regulären Testdurchführung run-hot-return werden Antworten wiederhergestellt.↩︎

  3. Als Admin eines Arbeitsbereiches kann man sich auch den Fortschritt aller Gruppen anzeigen lassen als Liste.↩︎