Eine Umfrage ist fertig konzipiert, aber noch nicht live. Trotzdem soll bereits ein Report dafür entstehen – Trendcharts, KPI-Karten, Segmentierungen. Die Frage die sich sofort stellt: woher kommen die Daten, an denen man das alles testet?
Die ehrliche Antwort war bei mir lange Zeit: ich habe sie von Hand erzeugt. Umfrage öffnen, durchklicken, Antworten setzen, abschicken. Wieder von vorne. Zwanzig, dreißig, manchmal fünfzig Mal – je nachdem wie überzeugend die Demo aussehen sollte.
Das war mühsam, langsam, und am Ende hatte ich Daten die keiner echten Verteilung folgten. Wer setzt schon von Hand eine realistische Altersverteilung über fünfzig Klickdurchgänge um?
Und selbst wenn man sich die Mühe spart und stattdessen eine CSV-Datei von Hand zusammenbaut, fängt das eigentliche Ärgernis erst an: falsche Spaltennamen, falsche Kodierung der Antwortcodes, vergessene Subfragen bei Matrix-Fragen. Der Import schlägt fehl, man sucht den Fehler, korrigiert eine Spalte, importiert erneut – und merkt beim dritten Versuch, dass man die Sprache der Antwortcodes verwechselt hat.
Nach dem dritten Mal dieses Ärgers in unterschiedlichen Projekten war klar: das muss automatisiert gehen.
Was Faker macht
Faker erzeugt vollständige Response-Datensätze direkt in der Antworttabelle einer LimeSurvey-Umfrage – ohne dass eine einzige echte Person die Umfrage ausfüllt.
Im einfachsten Fall reicht die Survey-ID:
./faker make --survey=761537 --count=200 --seed=42 --language=de
Zweihundert Datensätze, in Sekunden, fertig zum Testen im Report.
Faker kennt die Struktur der Umfrage bereits. Es liest die Fragetypen aus und erzeugt für jeden Typ einen passenden Wert: bei einer Single-Choice-Frage einen zufälligen Antwortcode, bei einer Matrix-Frage pro Subfrage einen Wert auf der jeweiligen Skala, bei einem Freitext einen plausiblen Satz.
Reproduzierbarkeit als eigentlicher Kern
Das technisch interessanteste Detail ist nicht die Datengenerierung selbst, sondern der Seed.
gleiche Survey + gleiche YAML + gleicher Seed = identische Datensätze
Wer denselben Seed verwendet, bekommt exakt dieselben Datensätze – auch beim zehnten Lauf, auch auf einem anderen Rechner. Das klingt unspektakulär, ist aber der Unterschied zwischen einem Spielzeug und einem Werkzeug.
Ohne Reproduzierbarkeit sieht jeder Testlauf anders aus. Ein Fehler im Report der beim einen Lauf auftritt, ist beim nächsten verschwunden – nicht weil er behoben wurde, sondern weil andere Zufallsdaten erzeugt wurden. Mit einem festen Seed lässt sich ein Bug zuverlässig reproduzieren, einer anderen Person zeigen, und nach einer Korrektur erneut mit denselben Daten prüfen.
Das ist dasselbe Prinzip das in der Softwareentwicklung seit jeher als selbstverständlich gilt – ein fester Seed bei Zufallszahlengeneratoren, damit Tests deterministisch bleiben. Im LimeSurvey-Umfeld bin ich auf eine vergleichbare Lösung bislang nicht gestoßen.
Faker erzeugt keine realistischen Umfragedaten. Faker erzeugt reproduzierbare Testszenarien. Das ist ein anderer Anspruch – und ein wichtigerer.
Mehr als zufällige Werte: gezielte Szenarien
Reine Zufallsdaten reichen für einen ersten Eindruck. Für das Testen eines Reports reichen sie oft nicht.
Ein Trendchart über mehrere Jahre soll einen sichtbaren Verlauf zeigen – nicht zufälliges Rauschen das jedes Jahr anders aussieht. Genau dafür gibt es in Faker Field Overrides und Extensions.
Ein fixer Wert für ein Feld:
datasets:
- name: year_2023
count: 100
fields:
year:
fixed: AO02
Eine Auswahl aus bestimmten Werten:
fields:
GENDER:
oneOf: [M, F]
Der stärkste Fall ist die NPS-Extension. Ein Net Promoter Score lässt sich nicht einfach durch eine zufällige Zahl zwischen 0 und 10 erzeugen – er ergibt sich aus der Verteilung der einzelnen Antworten:
NPS = % Promotoren (9–10) − % Kritiker (0–6)
Faker dreht das um. Man gibt den gewünschten NPS-Zielwert vor, die Extension verteilt die einzelnen Antworten so, dass am Ende exakt dieser Wert herauskommt:
datasets:
- name: year_2022
count: 100
fields:
year: { fixed: AO01 }
extensions:
nps:
question: nps
target: 30
- name: year_2023
count: 100
fields:
year: { fixed: AO02 }
extensions:
nps:
question: nps
target: 40
Zwei Datasets, zwei Jahre, zwei klar unterschiedliche NPS-Werte. Im Report erscheint sofort ein nachvollziehbarer Trend – und ich kann prüfen ob die Trendchart-Logik, die KPI-Berechnung und die Insight-Regeln auch wirklich korrekt reagieren, wenn sich der NPS von Jahr zu Jahr ändert. Ohne auf reale Antworten warten zu müssen, die sich über Jahre ansammeln.
Was Faker bewusst nicht macht
Die erste Version deckt die Grundfälle ab, aber nicht alles. Es gibt aktuell keine Token-Unterstützung, keine Relevanzbedingungen, keine teilweise ausgefüllten oder abgebrochenen Interviews, kein Update bestehender Datensätze und keine grafische Oberfläche im LimeSurvey-Backend.
Das ist eine bewusste Reihenfolge: zuerst die Grundstruktur zuverlässig erzeugen, danach die Verfeinerungen die echtes Umfrageverhalten noch realistischer abbilden – etwa Abbrecher, die nur einen Teil der Fragen beantwortet haben, oder Relevanzbedingungen die bestimmte Fragen je nach vorheriger Antwort überspringen.
Der eigentliche Effekt
Seit ich Faker benutze, klicke ich keine Testantworten mehr von Hand durch. Ein Report lässt sich entwickeln und prüfen, bevor die erste echte Person die Umfrage überhaupt gesehen hat. Ein Bug lässt sich mit demselben Seed exakt reproduzieren, statt im Wirrwarr neuer Zufallsdaten zu verschwinden. Und ein Trend über mehrere Jahre lässt sich gezielt erzeugen, um zu prüfen ob die Auswertung darauf richtig reagiert.
Nichts davon ist kompliziert. Aber es war vorher mühsam genug, dass ich es so lange wie möglich vermieden habe.