Daten und Prozesse

Um die Funktionen des Testcenters nutzen zu können, müssen Dateien zur Konfiguration in das Testcenter geladen werden. Diese Dateien legen fest, wie eine Studien aussehen und wie sie ablaufen soll. Außerdem werden über diese Dateien die zusätzlichen Funktionen: System-Check und Gruppenmonitor konfiguriert und es kann eine Voransicht einer Studien gestartet werden.

Daten-Input für das Testcenter

flowchart LR
  1
  style 1 fill:#ffd433
  2
  style 2 fill:#a0e3f3  
  3
  4
  style 4 fill:#ececec  
  A([Studio-Export])
  style A fill:#ffd433
  B([Studien-Definition])
  style B fill:#a0e3f3  
  C([Testheft-Definition])
  style C fill:#a0e3f3  
  D([Aufgaben-Definition])
  style D fill:#a0e3f3  
  E([Studien-XML])
  F([Testheft-XML])
  G([Aufgaben-XML])
  H([Aufgaben-VOUD])
  J([Aufgaben-VOCS])
  K([Player-HTML])
  I((Testcenter-Input))
  style I fill:#ececec
  1 --> 2
  2 --> 3
  3 --> 4
  A --> B
  A --> C
  A --> D
  B --> E
  C --> F
  D --> G
  D --> H
  D --> J
  D --> K
  E --> I
  F --> I
  G --> I
  H --> I
  J --> I
  K --> I

Um eine Studie mit dem Testcenter durchführen zu können, müssen Daten eingegeben werden. Diese Daten steuern den Zugriff auf die Studie (Zugänge), legen das Verhalten während der Durchführung fest und bestimmen Aufbau, Aufgabenreihenfolge und Aussehen der Studie. Die einzugebenen Daten bestehen aus mehreren einzelnen Dateien in unterschiedlichen Dateiformaten.

1. Die Testdateien können während des Aufgabenentwurfs vom IQB-Studio ausgegeben werden.

2. Es werden Dateien ausgegeben, die verschiedenen Funktionen zuzuordnen sind.

3. Die eigentlichen Dateien, die die in Schritt 2 genannten Funktionen erfüllen. An dieser Stelle können die Dateien auch noch einmal bearbeitet und individuell angepasst werden, bevor sie in das Testcenter geladen werden. Die Gesamtheit all dieser Dateien wird auch häufig als Testdateien bezeichnet.

4. Der Daten-Input erfolgt in den Arbeitsbereich der Studie.

Tipp

Wie diese Daten in das Testcenter geladen werden können, ist im Kapitel Daten Upload detailliert beschrieben.

Hinweis

Videos zu den Testdateien sind auch in der Videothek zu finden.

Studien-Definition

Die Zugangsdaten für die teilnehmenden Testpersonen und weitere wichtige Funktionen für den Testablauf werden in der Studien-Definition festgelegt. Hierfür wird eine XML-Datei verwendet. Diese XML wird IQB-intern auch Testtaker-XML genannt. Prinzipiell ist der Dateiname aber frei wählbar. Im weiteren Verlauf wird diese XML allgemein als Studien-XML bezeichnet.

Welche Funktionen übernimmt die Studien-XML?

  • Festlegung Zugangsdaten/ Anmeldeverfahren:
    Um eine Testdurchführung zu starten, müssen die teilnehmenden Personen zuvor mit entsprechenden Zugangsdaten angelegt werden. Die gespeicherten Antworten eines Testdurchlaufs werden dann zugeordnet zu diesen Zugangsdaten im System hinterlegt. Bei der Art der Anmeldung kann zwischen einer Vielzahl von Optionen gewählt werden. Die Anmeldung kann bspw. klassisch mittels Namen und Passwort erfolgen, mittels Code oder via Link.
  • Gruppierung von Zugangsdaten:
    Die angelegten Testpersonen werden in Gruppen angelegt. Diese Gruppen können mit zeitlichen Beschränkungen versehen werden und mit einem Gruppenmonitor überwacht werden. Bei einer finalen Testdurchführung werden die gegebenen Antworten dann auch Gruppenabhängig gespeichert.
  • Testheftzuweisung: Aufgaben können in Testheften (Booklets) zusammengefasst werden. Jedem Login kann gezielt ein Testheft zugewiesen werden. Die Zuweisung mehrerer Testhefte ist möglich. Nach Anmeldung werden die zugeordneten Testhefte der Testperson präsentiert.
  • Testablauf (bspw. heißer Test oder Review):
    Um den Ablauf der Testung festzulegen, wird zu jedem Login ein Modus hinterlegt. Dieser Modus bestimmt wie die Testung für den jeweiligen Login durchgeführt wird (finaler Durchlauf oder nur Review). Jeder Modus verfügt über spezifische Eigenschaften. Bspw. werden bei Wahl eines Modus zur finalen Testdurchführung alle Antworten zum Login gespeichert, während bei der Wahl eines Review-Modus die Antworten nicht gespeichert werden. Es sind auch spezielle Modi für die Testleitung vorgesehen. Die Testleitung wird dann in die Lage versetzt den Testverlauf steuern zu können.
  • individuelle Textersetzungen:
    Einzelne Texte der Anwendung können individuell an die eigene Bedürfnisse angepasst werden. Bspw. können Texte von Dialogfenster und Warnungen angepasst werden.

Testheft-Definition

Eine weitere XML-Datei übernimmt die Testheft-Definition. Sie trägt IQB-intern den Namen Booklet-XML. Auch hier kann der Dateiname frei gewählt werden. Im weiteren Verlauf wird diese Datei allgemein als Testheft-XML bezeichnet.

Welche Funktionen übernimmt die Testheft-XML?

  • Aufgabenreihenfolge:
    Die Reihenfolge der Aufgaben kann frei festgelegt werden. Der Aufruf erfolgt hierbei mittels eindeutiger ID der Aufgabe.
  • Aufgabensammlungen:
    Aufgaben können Testlets zugewiesen werden oder in Testlets zusammengefasst werden. Ein Testlet wird häufig auch als Block bezeichnet. Für Testlets können Beschränkungen festgelegt werden, bspw. kann ein Testlet mit einem Zugangscode versehen werden oder es ist nur für eine bestimmte Zeit zugänglich.
  • Konfiguration:
    Hinsichtlich Funktionalität und Layout der Testumgebung, können hier individuelle Festlegungen getroffen werden.

Aufgaben-Definition

Hinweis

Die Aufgaben-Definition wird auch oft als Unit-Definition bezeichnet.

Die Aufgaben-Definition besteht aus mehreren Dateien. Eine XML mit Metadaten wie bspw. ID und Label der Aufgabe. Diese wird hier allgemein als Aufgaben-XML bezeichnet. Der Dateiname ist wieder frei wählbar und trägt typischerweise den eindeutigen Namen der Aufgabe. Eine weitere Datei enthält die Aufgabeninhalte in einem JSON-Format mit der Endung .VOUD und wird hier allgemein als Aufgaben-VOUD bezeichnet. Der Name dieser Datei ist wieder frei wählbar , sollte aber günstigerweise den gleichen Namen wie die Aufgaben-XML tragen, um die Zugehörigkeit schnell erkennen zu können. Weiterhin gehört zur Aufgaben-Definition eine Datei, die die festgelegten Kodierregeln zur Aufgabe enthält. Diese Datei trägt die Endung .VOCS und wird hier als Aufgaben-VOCS bezeichnet. Auch diese Datei liegt im JSON-Format vor.

Aufgaben-XML

Diese XML enthält folgende Inhalte:

  • Metadaten:
    Die Metadaten zu einer Aufgabe. Hierzu gehören eine eindeutige ID der Aufgabe, ein Label und eine Beschreibung.
  • Angaben zur Aufgabenerstellung und Aufgabenwiedergabe:
    Angabe des zur Aufgabenerstellung verwendeten Editors und gewünschten Players zur Aufgabenwiedergabe. Deklaration der zugehörigen Aufgabenressource (Aufgaben-VOUD).
  • Angaben zur Aufgabenkodierung:
    An dieser Stelle wird die Version des verwendeten Schemers zur Aufgabenkodierung angegeben. Im Weiteren sind hier alle Variablen bzgl. Aufgabenkodierung aufgeführt.

Aufgaben-VOUD

Diese Datei enthält die eigentlichen Aufgabenelemente, wie bspw. Grafiken, Multiple Choice usw.. Sie wird oft auch als Ressource zu einer Aufgabe bezeichnet. Theoretisch sind die Aufgabeninhalte in dieser Datei manuell anpassbar, die Struktur ist aber sehr unübersichtlich und es können schnell Fehler gemacht werden. Änderungen sollten daher nur mit Hilfe des integrierten Aufgabeneditors im IQB-Studio erfolgen.

Tipp

Bei bestimmten Aufgabenelementen, wie bspw. kurzen Textpassagen in einleitenden Aufgaben, wird eventuell keine Aufgaben-VOUD erzeugt. Das Textelement befindet sich dann direkt in der Aufgabe-XML und kann auch dort verändert werden.

Aufgaben-VOCS

Zu jeder Aufgabe kann im IQB-Studio ein entsprechendes Kodierschema angelegt werden. Bei Ausgabe der Aufgabe erzeugt das Studio eine Datei mit der Endung .VOCS. In dieser Datei sind die erstellten Kodierregeln enthalten. In Verbindung mit den Kodiervariablen in der Aufgaben-XML kann das Testcenter Bedingungen für Aufgaben-Verzweigungen (adaptives Testen) schaffen.

Player-HTML

Das Testcenter enthält intern eine Komponente “Player”, die zur Aufgabenwiedergabe dient. Sinn der Teilung zwischen Testcenter und Player ist, dass das interne Format einer Aufgaben-XML, insbesondere der Aufgaben-VOUD, nicht direkt vom Testcenter selbst verarbeitet wird, sondern von einem Plug-In, welches je nach Aufgaben-Datentyp hinzugeladen wird. Der Player ist somit eine eigenständige Programmierung, die die Aufgaben-XML und Aufgaben-VOUD lesen und darstellen kann und für weitere Funktionen, wie bspw. der beschränkte Navigation (Presentation complete und Response complete), zuständig ist. Die Schnittstelle zwischen Player und Testcenter wird als Verona-Schnittstelle bezeichnet und unterliegt den Verona Spezifikationen.

Das IQB hat verschiedene Player für unterschiedliche Aufgaben-Formate programmiert. Alle Player sind bei GitHub veröffentlicht. Eine Übersicht ist zu finden auf der IQB-GitHub-Startseite. Die letzten verfügbaren Versionen der Player sind unter dem Reiter: Releases zu finden.

Tipp

Mehr Informationen zur Verona-Schnittstelle sind hier zu finden.

Im weiteren Verlauf wird die Datei mit den Programmierungen zum Player als Player-HTML bezeichnet. Typischerweise trägt die Datei den Namen des Players und der Playerversion.

Die Player-HTML wird in der Aufgaben-XML deklariert. Der so deklarierte Player muss mit in das Testcenter geladen werden. Wird eine Aufgaben-XML geladen, ohne zuvor die dort deklarierte Player-HTML zu laden, erscheint eine entsprechende Fehlermeldung.

Das IQB hat verschiedene Player für unterschiedliche Aufgaben-Formate programmiert. Alle Player sind bei GitHub veröffentlicht. Eine Übersicht ist zu finden auf der IQB-GitHub-Startseite. Die letzten verfügbaren Versionen der Player sind dann unter dem Reiter: Releases zu finden.

Es können gemischte Aufgaben mit unterschiedlichen Playern zum Einsatz kommen. Entscheidend ist, dass die in den Aufgaben deklarierten Player in das Testcenter geladen wurden. Befinden sich mehrere Player-Versionen im Testcenter, kann mit dem deklarierten Playernamen in der Aufgaben-XML bestimmt werden, welche Playerversion das Testcenter zu der entsprechenden Aufgabe lädt.

Dazu sollte zuvor Wissen über den Aufbau der Versionierung bestehen. Die Player-HTML weist immer 3 Nummern auf. Diese sind:

  • Major
  • Minor
  • Patch

Im Dateinamen der Player-HTML wird dieser Nummern noch der Name des Players vorangestellt. Der Name der Player-HTML sieht dann bspw. so aus: iqb-player-aspect@1.3.1.html

In der Aufgaben-XML kann die Player Deklaration nun auf verschiedene Weise erfolgen. Bspw. so:

 <DefinitionRef player="iqb-player-aspect@1.30" editor="iqb-editor-aspect@1.37">Aufgabe1.voud</DefinitionRef>

Es ginge aber auch:

iqb-player-aspect@1

Oder auch so:

iqb-player-aspect@1.3.1

Wie die Deklaration erfolgt, entscheidet, welcher Player zur Aufgabe geladen wird.

Nur Major angegeben:

Es wird die Player-HTML mit der angegebenen Major und der höchsten Minor, die das Testcenter findet, geladen. Wird die angegebene Major nicht gefunden, wird eine Meldung beim Laden erzeugt.

Major + Minor angegeben:

Es wird die Player-HTML mit der passenden Major, der passenden Minor und der höchsten Patch-Nummer gesucht. Wird die angegebene Minor nicht gefunden, wird eine Meldung beim Laden erzeugt.

Major + Minor + Patch angegeben:

Es wird die Player-HTML mit der passenden Major, der passenden Minor und der passenden Patch-Nummer gesucht. Ist die passende Patch-Nummer nicht zu finden, wird die höchst verfügbare Patch-Nummer gewählt. Wird die angegebene Minor nicht gefunden, wird eine Meldung beim Laden erzeugt.

Geo-Gebra

Werden in Aufgaben GeoGebra-Elemente eingesetzt, muss eine entsprechende Ressource mit der Endung .ITCR mit zur Aufgabe in das Testcenter geladen werden. Das GeoGebra-Paket kann unter https://download.geogebra.org/package/geogebra-math-apps-bundle heruntergeladen werden. Die heruntergeladene Datei muss dann in GeoGebra.itcr.zip umbenannt werden und in den Arbeitsbereich geladen werden, in dem sich auch die Aufgaben-Definitionen mit den GeoGebra-Elementen befinden.

Das Paket kann nicht mit ausgeliefert werden, da GeoGebra diese Lizenz verwendet.

System-Check

Die Konfigurationen des System-Checks erfolgt in einer XML-Datei. Der Dateiname ist frei wählbar. Diese XML muss in einen Arbeitsbereich des Testcenters geladen werden. Es wird dann auf der Anmeldeseite des Testcenter ein entsprechender Schalter für den System-Check angeboten. Nach Klick auf diesen Schalter, wird der in der XML konfigurierte System-Check gestartet.

Daten-Output des Testcenters

flowchart TB
    subgraph Testcenter
      B[System-Check]
      C[Kommentare]
      A[Test-Logs]
      subgraph Player
        D[Unit-Logs]
        E[Antworten]
      end
      style Player fill:#d0d0d0,stroke:#707070
    end
    style Testcenter fill:#ececec,stroke:#d1d1e0
    F((Kodierbox))
    A --> F
    D --> F
    E --> F
    G(Datenanalyse)
    style G fill:#eaf0f9,stroke:#4c5159
    F --> G
    H("`Studie in
    Umgebung
    durchführbar?`")
    style H fill:#eaf0f9,stroke:#4c5159
    I("`Aufgaben-
    kommentare
    während
    Review.`")
    style I fill:#eaf0f9,stroke:#4c5159
    B --> H
    C --> I

Das Testcenter stellt zur Studienauswertung und zur Studienvorbereitung Daten zur Verfügung. Diese werden sowohl vom Testcenter selbst als auch vom Player generiert. Nachfolgend wird näher beschrieben, wie und welche Daten erzeugt werden

Tipp

Wie Daten aus dem Testcenter geladen werden können, ist im Kapitel Daten Download beschrieben.

Welche Daten werden erzeugt?

Das Testcenter kann eine Reihe von Daten zur Verfügung stellen.Es können Daten bzgl. der Studienauswertung, aber auch Daten zu einem Review oder von einem System-Check heruntergeladen werden. Alle Daten bis auf System-Check Berichte werden zusammengefasst in einem Datensatz. Jeder Datensatz erhält einen spezifischen Namen. In der XML zur Studien-Definition werden die Zugangsdaten für die Teilnehmer*innen hinterlegt und einer Gruppe zugeordnet. Jede Gruppe erhält einen Namen und eine ID. Der Datensatz wird immer mit dem Namen der Gruppe gespeichert.

Folgende Daten sind je nach gesetztem Modus im Datensatz erhalten:

  • Antworten (nur im Modus: run-hot-return und run-hot-restart)
  • Logs (nur im Modus: run-hot-return und run-hot-restart)
  • Kommentare (nur im Modus run-review)

Unabhängig vom Modus wird ein System-Check Bericht erzeugt, wenn ein entsprechender System-Check durchgeführt wurde.

Antworten

Als Antworten bezeichnen wir die Daten, die durch die Interaktion der Testperson mit dem Testsystem entstehen und als Zustände zum Ende der Bearbeitung gespeichert werden. Antworten absolvieren einen Verarbeitungsprozess vom Ursprung (sog. Basis-Variable, Rohdaten-Wert) über Ableitung, Cleaning, Kodierung bis zur Bewertung. Die Daten, die nach der Aufbereitung für die Datenanalyse bereitgestellt werden (z. B. IRT-/Rasch-Analyse), nennen wir Primärdaten.

Die Antwortdaten werden als CSV-Datei aus dem Testcenter heruntergeladen. Die CSV ist wie folgt aufgebaut:

Spalte Inhalt
groupname Id der Gruppe
loginname Name des Logins
code Eindeutiger Code wird dem Login-Namen zugeordnet. Hintergrund: Bei einem bestimmten Modus (run-hot-restart) startet der Test immer wieder von vorne, obwohl immer mit dem selben Login-Namen angemeldet wird. Es werden verschiedene Testpersonen angenommen. Um die Antworten unterscheiden zu können, wird in einem solchen Fall ein anderer Code zu dem Login-Namen erzeugt.
bookletname Id des Testheftes
unitname Id der Aufgabe
responses Datenfeld mit mehreren Variablen. Hier wird die Id des bearbeiteten Aufgabenelements und die gegebene Antwort gespeichert. Außerdem wird hier ein Zeitstempel hinterlegt, der den Zeitpunkt der Bearbeitung anzeigt. Mehr dazu ist nachfolgend zu lesen.
laststate Hier wird der letzte Zustand des Players vermerkt

Das Feld responses enthält die folgenden Variablen im JSON-Format und ist spezifiziert. Mehr zu dieser Spezifikation ist auf IQB-GitHub-Startseite unter Spezifikationen: Antworten zu finden.

{
    id: string,
    status: string,
    value: null | number | string | boolean | number[] | string[] | boolean[],
    code?: number,
    score?: number
}

Logs

Wichtig

Der Modus der Studiendurchführung legt fest, ob Logs gespeichert werden oder nicht.

Aus der Interaktion mit dem Testsystem resultieren weitere Daten, die Log-Daten. Diese beschreiben nicht Zustände zum Ende der Bearbeitung, sondern beschreiben Veränderungen während der Bearbeitung. Sie können zu weiteren Variablen führen.

Dieses sog. “Logging” kann reduziert und auch ganz abgestellt werden, um die Datenmenge zu reduzieren. Welche Ereignisse genau gespeichert werden, ist auch vom Player abhängig. Folgende Erkenntnisse lassen sich beispielsweise aus den Log-Daten ablesen:

  • Version des Betriebssystems und des Browsers
  • Verweildauer auf einer Seite
  • Zeitpunkt des Beendens der Beantwortung
  • Zustand des Players

Kommentare

Hinweis

Kommentare können nur abgegeben werden, wenn der Testmodus: run-review aktiv ist.

Wird eine Studie in einem Review-Modus durchgeführt, können Kommentare zu jeder Aufgabe hinterlegt werden. Diese Kommentare können den Aufgabenentwickler*innen helfen die Aufgaben vor finaler Ansicht zu optimieren. In dem Kommentar-Formular kann folgendes angegeben werden:

  • Name der Person, die den Kommentar gibt
  • Auswahl ob der Kommentar sich auf die aktuell betrachtete Aufgabe oder auf das gesamte Testheft bezieht
  • Priorität (dringend, mittelfristig, optional)
  • Kategorie (technisches, inhaltliches, gestalterisches)
  • der eigentliche Kommentar

Diese Angaben sind auch in der heruntergeladenen CSV wiederzufinden.

System-Check Berichte

Wurde ein System-Check eingerichtet und durchgeführt, wird ein entsprechender Bericht gespeichert. Mit Hilfe der enthaltenen Informationen kann beurteilt werden, ob die Studiendurchführung in der geplanten Umgebung (Computer-Labor etc.) gesichert stattfinden kann.

Hinweis

Mehr dazu ist dem Kapitel: System-Check zu entnehmen.

Wie werden Daten erzeugt?

Alle Daten bis auf den System-Check Bericht werden zusammengefasst in einem Datensatz. In der XML zur Studien-Definition werden die Zugangsdaten für die Teilnehmer*innen hinterlegt und einer Gruppe zugeordnet. Jede Gruppe erhält einen Namen und eine ID. Der zusammengefasste Datensatz wird immer mit dem Namen der Gruppe gespeichert.

Hier ein kleines Beispiel zum besseren Verständnis:

Angenommen in der XML zur Studien-Definition sind zwei Gruppen angelegt:

<?xml version="1.0" encoding="utf-8"?>
<Testtakers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/iqb-berlin/testcenter/15.0.1/definitions/vo_Testtakers.xsd">

  <Metadata>
    <Description>
      This file contains some logins for testing and works a a sample for developers.
    </Description>
  </Metadata>

  <CustomTexts>
    <CustomText key="app_title">Hier steht ein Custom Text</CustomText>
  </CustomTexts>

  <Group id="Gruppe1" label="Erste Gruppe">
    <Login mode="run-hot-return" name="Testperson 1" pw="erds#">
        <Booklet>BOOKLET.SAMPLE-1</Booklet>
    </Login>
    <Login mode="run-hot-return" name="Testperson 2" pw="ghtz#">
        <Booklet>BOOKLET.SAMPLE-1</Booklet>
    </Login>
  </Group>
  <Group id="Gruppe2" label="Zweite Gruppe">
    <Login mode="run-hot-return" name="Testperson 4" pw="erss#">
        <Booklet>BOOKLET.SAMPLE-1</Booklet>
    </Login>
    <Login mode="run-hot-return" name="Testperson 5" pw="stdz#">
        <Booklet>BOOKLET.SAMPLE-1</Booklet>
    </Login>
  </Group>

</Testtakers>

Testperson 1 meldet sich am Testcenter an und bearbeitet Aufgaben. Dann wird ein Datensatz mit dem Namen: Erste Gruppe erzeugt. Meldet sich weiterhin Testperson 2 an, wird der vorhandene Datensatz um die gegebenen Antworten von Testperson 2 erweitert.

Melden sich Testperson 4 oder Testperson 5 am Testcenter an, wird ein weiterer Datensatz mit dem Namen: Zweite Gruppe erzeugt.

Daten-Bearbeitung

Die Testdateien für das Testcenter können manuell bearbeitet werden bevor sie in das Testcenter geladen werden. Hierfür ist ein Verständnis der Extensible Markup Language XML notwendig. Eine knappe Einleitung bietet hier der Punkt: Mehr zu XML in den Referenzen. Detaillierte Informationen dazu sind aber auch im Internet zu finden.

Der Daten-Output des Testcenters kann mit Hilfe eines weiteren IQB-Tools mit dem Namen: itc-Toolbox aufbereitet werden. Da es sich bei dem Daten-Output um CSV-Dateien handelt, kann es im Sinne der Übersichtlichkeit bspw. sinnvoll sein einzelne CSV-Dateien in Excel-Dateien zu wandeln. Mehr zur itc-Toolbox ist auf GitHub zu finden.

Zurück nach oben