---

Von zwei Prototypen zur Statistik

Testdaten festlegen, ohne Code zu schreiben: Zwei Wege zur passenden Struktur

Wie lassen sich Regeln für Testdaten festlegen, wenn Nutzer:innen keine technische Schemasprache beherrschen? Im Rahmen meiner Masterarbeit habe ich zwei No-Code-Prototypen entwickelt und verglichen: eine räumliche Canvas-Ansicht und eine hierarchische Listenansicht. Die Ergebnisse zeigen keinen eindeutigen Gewinner, sondern unterschiedliche Stärken bei Überblick und Navigation.

Warum braucht es verständliche Regeln für Testdaten?

Software muss vor ihrer Veröffentlichung ausgiebig getestet werden. Dafür können synthetische Testdaten verwendet werden, also künstlich erzeugte Daten, die realistische Anwendungsfälle abbilden, ohne beispielsweise echte Personen- oder Kundendaten zu enthalten.

Damit solche Daten sinnvoll erzeugt werden können, braucht es klare Regeln. Eine Postleitzahl soll etwa aus fünf Ziffern bestehen, ein Passwort mindestens acht Zeichen enthalten und der Gesamtpreis einer Rechnung der Summe ihrer Einzelpositionen entsprechen. Solche Vorgaben werden als Constraints bezeichnet.

Technische Schemasprachen wie JSON Schema können diese Regeln präzise beschreiben. Für Personen ohne entsprechenden technischen Hintergrund stellen sie jedoch häufig eine Hürde dar. Anforderungen landen deshalb in der Praxis oft in Tabellen, allgemeinen Formularen oder Freitextdokumenten. Dadurch können Informationen verloren gehen, missverständlich formuliert sein oder müssen erst von Entwickler:innen in eine maschinenlesbare Form übertragen werden.

Von praktischen Problemen zu konkreten Anforderungen

Bevor ich mit der Entwicklung begann, hab ich Interviews mit fünf Personen aus Softwareentwicklung, Testing und weniger technischen Tätigkeitsbereichen geführt. Dabei zeigten sich mehrere wiederkehrende Herausforderungen:

• Technische Werkzeuge erfordern häufig eine längere Einarbeitung.
• Wiederkehrende Datenstrukturen müssen immer wieder neu angelegt werden.
• Bei großen und verschachtelten Strukturen geht schnell der Überblick verloren.
• Viele Tools setzen Kenntnisse voraus, die nicht bei allen beteiligten Personen vorhanden sind.

Auf dieser Grundlage entstanden zwei funktionsfähige Minimalversionen, sogenannte Minimum Viable Prototypes (MVPs). Beide verwenden im Hintergrund das JSON Schema Draft 2020-12 und bieten dieselben Möglichkeiten zum Erstellen und Bearbeiten von Feldern. Sie unterscheiden sich vor allem darin, wie sie die Gesamtstruktur darstellen: räumlich auf einer freien Arbeitsfläche oder hierarchisch in einer Liste.

Prototyp 1: Der Canvas als “Landkarte”

Der Canvas-Prototyp stellt die Felder eines Schemas als miteinander verbundene Knoten…

auf einer zweidimensionalen Arbeitsfläche dar. Verschachtelte Ebenen breiten sich von links nach rechts aus, zusammengehörige Felder werden untereinander angeordnet. So entsteht eine Darstellung, die an eine Mindmap oder eine Landkarte erinnert.

Farben erleichtern die Orientierung: Listen werden beispielsweise grün und Gruppen blau gekennzeichnet. Über Verbindungslinien lassen sich über- und untergeordnete Elemente erkennen. Eine Suchfunktion, eine Navigationsleiste sowie Zoom, Vollbildmodus und eine Minimap helfen dabei, sich auch in größeren Strukturen zu bewegen.

Die Stärke des Canvas liegt vor allem im räumlichen Überblick. Nutzer:innen können verschiedene Bereiche eines Schemas visuell voneinander unterscheiden und dessen Aufbau als zusammenhängende Struktur erfassen.

Prototyp 2: Die Liste als vertraute Baumstruktur

Der zweite Prototyp ordnet alle Felder in einer vertikal scrollbaren Liste an. Verschachtelungen werden durch Einrückungen und Führungslinien sichtbar. Das Prinzip ähnelt den Ordnerstrukturen eines Dateibrowsers und dürfte deshalb vielen Nutzer:innen bereits vertraut sein.

Kleine Markierungen zeigen direkt in der Übersicht, welchen Typ ein Feld besitzt, ob es verpflichtend ist und welche Regeln hinterlegt wurden. Über die Suche springt die Ansicht zum passenden Feld und hebt den Treffer farblich hervor. Einzelne Bereiche können ein- und ausgeklappt werden.

Darüber hinaus lassen sich Felder innerhalb einer Ebene über Pfeiltasten oder per Drag-and-drop neu anordnen. Der Schwerpunkt dieser Variante liegt damit auf schnellem Scannen, gezieltem Auffinden und effizientem Bearbeiten.

Ein gemeinsamer No-Code-Kern

Beide Ansichten sind Teil derselben Anwendung. Das war für den Vergleich wichtig: Nicht unterschiedliche Funktionen sollten untersucht werden, sondern möglichst gezielt die Art der Darstellung und die Navigation.

Das Herzstück beider Varianten ist ein gemeinsamer Assistent, der in drei Schritten durch die Konfiguration führt:

1. Name und Beschreibung des Feldes festlegen
2. Datentyp auswählen
3. Regeln definieren

Neben grundlegenden Typen wie Text, Zahl, Liste oder Gruppe stehen vordefinierte Typen zur Verfügung, etwa für deutsche Postleitzahlen, E-Mail-Adressen oder Telefonnummern. Nutzer:innen müssen die zugrunde liegenden technischen Ausdrücke nicht selbst erstellen.

Auch Regeln zwischen mehreren Feldern lassen sich konfigurieren. So kann beispielsweise festgelegt werden, dass der Preis einer Rechnungsposition aus Menge mal Einzelpreis berechnet wird. Die Oberfläche übersetzt die Eingaben automatisch in ein JSON Schema und – für Regeln, die sich mit dem Standard nicht direkt ausdrücken lassen – in ein zusätzliches Constraint-Dokument.

Eine Live-Vorschau zeigt jederzeit, welche maschinenlesbaren Dateien aus den Eingaben entstehen. Wer mit der technischen Darstellung nichts zu tun haben möchte, kann vollständig über die Oberfläche arbeiten.

Was zeigte die Studie?

An der anschließenden Studie nahmen 14 Personen teil. Da die Aufzeichnung einer Person nicht für die quantitative Analyse verwendet werden konnte, basieren die statistischen Vergleiche auf 13 vollständigen Datensätzen.

Alle Teilnehmenden arbeiteten sowohl mit dem Canvas als auch mit der Liste. Sie bearbeiteten fünf Szenarien – von einer kurzen Einführung über ein einfaches Formular bis zur Pflege eines umfangreichen, verschachtelten Schemas. Vier dieser Szenarien flossen in die Auswertung ein. Gemessen wurden Bearbeitungszeit, Anzahl der Aktionen, Fehler und erfolgreiche Abschlüsse. Zusätzlich bewerteten die Teilnehmenden Benutzerfreundlichkeit und Nutzungserlebnis.

Kein messbarer Vorsprung bei der Aufgabenbearbeitung

Bei den beobachteten Verhaltensdaten ergaben sich nach der statistischen Korrektur keine signifikanten Unterschiede. Es konnte somit kein eindeutiger Vorteil einer der beiden Ansichten bei Bearbeitungszeit, Aktionen, Fehlern oder erfolgreicher Aufgabenerledigung festgestellt werden.

In der Tendenz waren die Sitzungen mit der Liste etwas kürzer. Beim Canvas entstand zusätzlicher Navigationsaufwand durch Verschieben, Zoomen und gelegentliche Sprünge der Ansicht nach einer Suche. Ein großer Teil der eigentlichen Arbeit fand jedoch in dem gemeinsamen Konfigurationsassistenten statt. Die gewählte Übersicht beeinflusste daher vor allem, wie ein Feld gefunden wurde – nicht, wie es anschließend bearbeitet werden musste.

Wichtig ist dabei: Die nicht signifikanten Ergebnisse beweisen nicht, dass beide Ansichten in jeder Situation gleich gut funktionieren. Sie zeigen lediglich, dass unter den untersuchten Bedingungen und bei der vergleichsweise kleinen Stichprobe keine eindeutigen Unterschiede festgestellt wurden.

Canvas wirkt neuer, die Liste häufig alltagstauglicher

Auch bei den meisten subjektiven Bewertungen unterschieden sich die Prototypen statistisch nicht. Beide erreichten im System Usability Scale überdurchschnittliche Werte.

Einen bestätigten Unterschied gab es jedoch: Der Canvas wurde auf der UEQ-Skala Novelty deutlich höher bewertet. Die Teilnehmenden nahmen ihn also als innovativer und kreativer wahr. Das bedeutete allerdings nicht automatisch, dass sie ihn auch effizienter oder insgesamt benutzerfreundlicher fanden.

Bei der abschließenden Präferenzfrage wählten sieben der 14 Teilnehmenden die Liste und drei den Canvas. Vier Personen legten sich auf keine Variante fest. In den Kommentaren wurde die Liste häufig als praktisch und vertraut für die tägliche Arbeit beschrieben. Der Canvas überzeugte eher durch seine visuelle Darstellung und sein Potenzial, Zusammenhänge zwischen Feldern sichtbar zu machen.

Drei Teilnehmende schlugen deshalb vor, beide Ansichten miteinander zu kombinieren.

Fazit: Ergänzung statt Konkurrenz

Die Arbeit zeigt, dass sich technische Regeln für Testdaten durch verständliche Begriffe, vordefinierte Datentypen und geführte Interaktionen zugänglicher machen lassen. Nutzer:innen müssen JSON Schema nicht selbst schreiben, um strukturierte und maschinenlesbare Vorgaben zu erstellen.

Zwischen Canvas und Liste gibt es dabei keinen eindeutigen Gewinner. Die Liste eignet sich besonders für vertraute, strukturierte Navigation. Der Canvas bietet einen räumlichen Überblick und wird als innovativer wahrgenommen. Welche Darstellung besser passt, hängt daher von der jeweiligen Aufgabe, der Größe des Schemas und den Vorlieben der Nutzer:innen ab.

Für zukünftige Anwendungen erscheint eine hybride Oberfläche besonders vielversprechend: eine Liste für schnelles Suchen und Bearbeiten, ergänzt durch einen Canvas für den visuellen Überblick. Wenn beide Ansichten nahtlos miteinander verbunden sind, könnten sie ihre jeweiligen Stärken ausspielen, ohne dass sich Nutzer:innen dauerhaft für eine Variante entscheiden müssen.