Testunternehmensdaten sind ein erfundenes Unternehmen, vollständig ausgeschrieben. Sie bestehen aus einem Firmennamen, einer Rechtsform, einer Handelsregisternummer, einer Steuernummer und einer Umsatzsteuernummer, einem Sitz, einer Kontakttelefonnummer und einer Handvoll kleinerer Felder – zusammengesetzt, damit Software an einem Datensatz erprobt werden kann, der wie ein gewöhnliches Handelsunternehmen aussieht, ohne eines zu beschreiben, das existiert.
Dieser Artikel erklärt, wofür ein solcher Datensatz tatsächlich gut ist, warum die Übernahme der Angaben eines echten Unternehmens sowohl rechtlich als auch technisch ein schlechtes Geschäft ist, welche Bereiche eines Produkts ihn brauchen und was ein Generator über seine Ausgabe zusichert – und was nicht.
Was Testunternehmensdaten tatsächlich sind
Zieht man das Vokabular ab, bleibt von einem Unternehmens-Testdatensatz nichts anderes übrig als ein stimmiges Bündel von Antworten auf die Fragen, die ein Geschäftsformular stellt. Jemand beantragt etwas im Namen einer Organisation. Die Organisation hat einen Namen und eine angegebene Rechtsform, sie ist irgendwo eingetragen, ihr wurden die Kennungen zugeteilt, die dieser Ort vergibt, und sie hat einen Ort der Geschäftstätigkeit.
Stimmigkeit ist es, was einen brauchbaren Datensatz von einem Haufen Zeichenketten trennt. Die Registernummer gehört zum Register des Landes, das in der Adresse steht, die Umsatzsteuernummer trägt das Präfix desselben Landes, die Rechtsform ist eine, die die Jurisdiktion tatsächlich kennt, und die Telefonnummer trägt die richtige Ländervorwahl. Ein Datensatz, der Feld für Feld zusammengesetzt wird, scheitert meist genau an dieser Stelle, weil jedes Feld für sich allein beurteilt wurde.
Die Herkunft ist es, was einen Testdatensatz von einem echten unterscheidet. Nichts darin wurde von einem Unternehmen kopiert, und nichts darin gehört einem Unternehmen. Er hat die Gestalt eines Betriebs, damit ein System ihn verarbeiten kann, und außerhalb des Tests keinen Bezugspunkt.
Wo braucht ein Team solche Geschäftsdatensätze wirklich?
Der Bedarf ist größer, als es zunächst scheint, und er bündelt sich um eine einzige Anforderung: der Software plausible Eingaben geben, während die Ausgabe irgendwo harmlos landet.
| Situation | Was ohne erzeugte Datensätze unmöglich ist |
|---|---|
| Test von Onboarding-Formularen | Pflichtfeld- und Längenregeln lassen sich nicht durchgängig prüfen |
| Probeabrechnung | Steuer- und Registerfelder lassen sich nicht an einem Dokument erproben, das niemand erhält |
| Sandbox-Integration | Die Testumgebung eines Partners braucht eine Gegenseite, die kein echter Kunde ist |
| Demo- und Vertriebsumgebungen | Das Produkt wirkt unfertig, wenn jeder Datensatz wie Platzhaltertext liest |
| Massenbefüllung | Lasttests brauchen viele Tausend Zeilen, die trotzdem plausibel aussehen |
| Regressions-Fixtures | Zusicherungen driften, wenn derselbe Test jedes Mal ein anderes Unternehmen erzeugt |
Die Liste zeigt auch, warum die Gestalt des Datensatzes wichtiger ist, als Entwickler erwarten. Eine Sandbox-Integration wird daran gemessen, ob die Prüfung des Partners die Nutzlast akzeptiert. Eine Demo wird daran gemessen, ob ein Interessent den Bildschirm lesen kann, ohne etwas Seltsames zu bemerken. Keines der beiden Ziele wird dadurch erreicht, dass man die Kennungen eines echten Unternehmens einspielt.
Warum ist die Übernahme echter Firmendaten der falsche Weg?
Weil Registernummer, Steuernummer und Organe eines echten Unternehmens persönliche und kommerzielle Tatsachen sind, die jemand anderem gehören, und weil untere Umgebungen dort liegen, wo die schwächsten Kontrollen sitzen.
Zwei Fehler folgen daraus. Der erste ist rechtlich und reputationsbezogen. Sich als anderes Unternehmen auszugeben ist eine Täuschung, und nach den Regeln des Datenschutzes können die Registrierungsangaben eines Einzelunternehmers zusammen mit einem Kontaktnamen ebenfalls personenbezogene Daten sein. Diese Tatsachen in eine Entwicklungsumgebung zu verschieben ist eine neue Verwendung, der niemand zugestimmt hat. Der zweite ist betrieblich: Die Kopie überlebt danach in Sicherungen, in Abfrageprotokollen, in Screenshots, die in Tickets eingefügt werden, und auf den Rechnern aller, die die Datenbank wiederhergestellt haben. Die Organisation hat am Ende mehr Kopien der Angaben eines Unternehmens als je zuvor, an Stellen, die niemand prüft.
Es gibt einen dritten, leisereren Preis. Ein Test, der auf einem einzigen echten Unternehmen aufbaut, sieht immer nur dessen Gestalt. Echte Portfolios enthalten kurze Namen, sehr lange Namen, kaufmännische Und-Zeichen, akzentuierte Zeichen, vom eingetragenen Namen abweichende Geschäftsnamen und Einheiten ganz ohne Umsatzsteuernummer. Ein erzeugter Satz kann diese Bandbreite bewusst abdecken, ein entlehnter Datensatz nicht.
Was enthält ein vollständiger Unternehmensdatensatz?
Der Unternehmensdaten-Generator baut die ganze Einheit in einem Schritt auf statt Feld für Feld. Ein Datensatz trägt vier Gruppen von Feldern.
- Identität – der eingetragene Name, die Rechtsform und die Beschreibung der Branche oder Tätigkeit.
- Register und Steuer – die Handelsregisternummer, die Steuerkennung und die Umsatzsteuernummer, sofern das Land eine vergibt, jeweils in der Gestalt des jeweiligen Landes.
- Sitz – Straße, Stadtteil, Stadt, Verwaltungseinheit, Postleitzahl und Land, nach den echten Adresskonventionen dieses Landes.
- Kontakt – eine Telefonnummer mit der richtigen internationalen Vorwahl sowie zugehörige Verwaltungsangaben wie die Größenklasse oder Gründungshinweise, die das Land veröffentlicht.
Zwei Eigenschaften sind zu verstehen, bevor man sich auf die Ausgabe verlässt. Die erste ist die innere Stimmigkeit, wie oben beschrieben. Die zweite ist die Reproduzierbarkeit: Die Ausgabe wird von einem Identitätsschlüssel gesteuert, und derselbe Schlüssel mit demselben Land ergibt jedes Mal exakt dasselbe Unternehmen. Reproduzierbarkeit macht einen erzeugten Datensatz in einem automatisierten Test brauchbar und nicht nur in einem manuellen Durchlauf. Die Frage der Feldstimmigkeit ist in Wahrheit eine Frage der Erzeugungsreihenfolge; der Artikel zu den Rechtsformen erklärt, warum das Land feststehen muss, bevor irgendetwas davon abhängt.
Müssen erzeugte Unternehmensdaten echt aussehen?
Sie müssen gewöhnlich aussehen, und das ist eine schwächere Anforderung – der Unterschied zählt aber.
Ein offensichtlich gefälschter Datensatz ist für einen Leser leicht zu verwerfen, für eine Prüfregel aber leicht aus dem falschen Grund abzulehnen. Ein Datensatz, der exotisch aussieht, prüft das Falsche: Wenn jeder erzeugte Firmenname eine einzige Silbe hat oder jede Straßenzeile dieselbe Platzhalterphrase ist, wird das Layout nie belastet und die Prüfung nie ausgelöst. Erzeugte Datensätze verdienen sich ihren Platz, wenn sie in derselben Gestalt landen wie die echten Einreichungen, die das System später erhält – einschließlich der unbequemen: lange Firmennamen, akzentuierte Zeichen, vom eingetragenen Namen abweichende Geschäftsnamen und Einheiten, die berechtigt keine Umsatzsteuernummer haben.
Gewöhnlich ist nicht dasselbe wie in der Welt gültig. Eine synthetische Registernummer der richtigen Gestalt ist trotzdem nirgends eingetragen. Sie besteht eine Formatprüfung und scheitert in dem Moment, in dem ein Prozess das dahinterliegende Register befragt. Das ist eine Eigenschaft und kein Mangel: Die Grenzen synthetischer Unternehmensdaten sind genau das, was verhindert, dass ein Testdatensatz für einen echten gehalten wird.
Für Entwickler: den Datensatz entwerfen
Modellieren Sie den Datensatz als Felder mit Abhängigkeiten, nicht als flache Tabelle unabhängiger Spalten. Das Land bestimmt die Adressgestalt, das Register, das Kennungsformat und die Telefonvorwahl. Die Rechtsform bestimmt den Namenszusatz und die Menge der Kennungen, die überhaupt existieren darf. Ein Schema, das diese Beziehungen verbirgt, lässt inkonsistente Zeilen zu, egal wie sorgfältig die Fixtures sind.
Drei Gewohnheiten verhindern den größten Schaden. Geben Sie dem Datensatz einen stabilen Schlüssel, damit er auf Anfrage neu erzeugt werden kann, statt zwischen Umgebungen kopiert zu werden. Behandeln Sie eine fehlende Kennung als abwesend, statt das Feld mit einer plausiblen Zeichenkette zu füllen, weil ein leeres Feld und ein falsches Feld an sehr verschiedenen Stellen scheitern. Und lassen Sie einen Testdatensatz niemals in die Produktion wandern: Halten Sie erzeugte Einheiten in einer eigenen Datenbank oder einem eigenen Schema, markieren Sie sie auf Zeilenebene, wenn eine geteilte Umgebung dazu zwingt, und kennzeichnen Sie die Fixture-Dateien selbst als synthetisch.
Der Hinweis, der mit den Fixtures ausgeliefert wird, gehört zum Entwurf. Sagen Sie deutlich in der Datei und in jedem Export, den das Werkzeug erzeugt, dass diese Unternehmen für Tests erfunden wurden, dass kein echtes Geschäft beschrieben wird und dass die Datensätze nicht dazu verwendet werden dürfen, Konten zu eröffnen, Lizenzen zu erhalten, echte Rechnungen auszustellen oder für eine tatsächliche Gegenseite einzustehen.
Nächste Schritte
Wählen Sie ein Formular in Ihrem Produkt, das Unternehmensangaben verlangt, und füllen Sie es mit einem erzeugten Datensatz statt mit dem Platzhaltertext, der heute wahrscheinlich dort steht. Senden Sie es anschließend zweimal mit demselben Identitätsschlüssel ab und prüfen Sie, ob beide Versuche identische Werte liefern. Wenn sie abweichen, sehen Sie einen Generator, der automatisierte Zusicherungen nicht tragen kann; der Artikel zur Handelsregisternummer erklärt, was Sie stattdessen verlangen sollten. Für Teams, die eine Staging-Datenbank in großem Umfang befüllen, deckt der Unternehmensdaten-Generator dasselbe Problem im Mengenbetrieb ab.