Ein Lebenslaufdaten Generator baut eine ganze Karrieregeschichte auf – eine Person, eine Folge von Stationen mit Start- und Enddatum, eine Ausbildungshistorie, eine Skillliste, eine Menge von Zertifizierungen und eine Gehaltsvorstellung – so zusammengesetzt, dass die Teile zusammen Sinn ergeben. Einen Parser Feld für Feld zu füttern, testet fast nichts; ihn mit einer konsistenten Chronologie zu füttern, bringt die Defekte ans Licht, die Teams tatsächlich ausliefern.
Dieser Leitfaden behandelt, was ein Recruiting-System von einem Kandidatendatensatz erwartet, welche Zeitachsenregeln ein Generator einhalten muss, warum Jobtitel und Skills aus einer landesbewussten Taxonomie stammen müssen und wo die Datenschutzgrenze verläuft, wenn der Datensatz wie eine Person aussieht. Am Ende wissen Sie, welche Assertions in einen Test für Bewerbungsformulare gehören und welche Eigenschaften eines Lebenslaufs schwieriger sind, als sie aussehen.
Was macht ein Bewerbermanagement-System mit einem Kandidatendatensatz?
Ein Applicant Tracking System erhält ein Dokument, parst es in strukturierte Felder, entdoppelt es gegen bestehende Kandidaten, bewertet es, leitet es an eine prüfende Person weiter und speichert es für eine Aufbewahrungsfrist. Jeder dieser Schritte lässt sich nur dann prüfen, wenn die Eingabe einer echten Karriere ähnelt und nicht einer Stichwortliste.
Das Parsen ist der Schritt, in dem erzeugte Daten ihren Platz verdienen. Ein Parser muss den Arbeitgeber, den Titel, die Daten und den Ort im freien Text finden, und seine Fehlerarten sind spezifisch: ein Titel, der als Arbeitgeber gelesen wird; ein Monat und ein Jahr, die als Zeitraum gelesen werden; ein Ort, der in den Jobtitel hineinrutscht; ein zweiseitiges Dokument, das falsch zusammengesetzt wird. Diese Defekte zeigen sich nur, wenn die Eingabe die Form eines echten Dokuments hat.
Die Fehler ballen sich außerdem eher um die Dateiverarbeitung als um den Text: ein Dokument mit einer Tabelle statt einer Liste, eine Kopfzeile, die auf jeder Seite wiederkehrt, ein Name mit einem Akzentzeichen, der in der falschen Kodierung ankommt, oder ein zweispaltiges Layout, das quer über beide Spalten zeilenweise gelesen wird. Erzeugte Datensätze machen solche Varianten billig erzeugbar und billig als Fixture haltbar.
Das Matching ist der zweite Schritt, und es hängt davon ab, dass die Felder zueinander passen. Ein Kandidat, dessen aktuelle Station in einem Land liegt und dessen Adresse in einem anderen, ist in der Praxis nicht ungewöhnlich; ein Kandidat, dessen Ausbildungsdaten den Beschäftigungsdaten folgen, ist es. Ein Generator, der die Chronologie respektiert, liefert Ihnen Datensätze, die die Zuordnungslogik ehrlich belasten.
Die Entdopplung ist ein verwandter Test, weil sie auf Ähnlichkeiten beruht und nicht auf exakter Gleichheit: dieselbe Person zweimal mit einem zusammengesetzten Nachnamen, mit einem Geburtsnamen, mit einer anderen E-Mail-Adresse oder mit einem anders abgekürzten Firmennamen. Diese Varianten absichtlich zu erzeugen ist der einzige verlässliche Weg herauszufinden, ob der Zusammenführschritt den richtigen Datensatz behält. Der Artikel zu den Karriereprofildaten als Testdaten behandelt die weitere Feldmenge, und der Artikel zu den Fixtures für das Parsen von Lebensläufen zeigt, wie man erzeugte Datensätze in Dokumente verwandelt, gegen die ein Parser laufen kann.
Welche Zeitachsenregeln müssen gelten?
Die erste Regel lautet, dass eine Station nach ihrem Beginn endet. Das klingt trivial und wird von handgebauten Fixtures ständig verletzt, weil die beiden Daten an verschiedenen Stellen eingegeben werden und nichts die Beziehung zwischen ihnen erzwingt. Jeder Datensatz, in dem das Ende vor dem Anfang liegt, fällt durch einen Chronologie-Validator; hat die Testsuite keinen solchen Validator, wird er gespeichert und bricht später einen Bericht.
Die zweite Regel betrifft Lücken und Überschneidungen. Eine Karriere kann eine Lücke zwischen zwei Stationen enthalten, und Lücken sind legitim und häufig. Überschneidungen sind ebenfalls möglich, wenn jemand zwei Positionen gleichzeitig gehalten hat, aber sie sind selten genug, dass ein Generator sie als bewussten Fall behandeln sollte und nicht als Standard. Entscheidend ist, dass die Wahl explizit ist: Ein Datensatz, der nie Lücken erzeugt, wird nie den Pfad für Lücken prüfen, und einer, der nie Überschneidungen erzeugt, wird nie die Überschneidungswarnung prüfen.
Die dritte Regel lautet, dass die Ausbildung der frühen Beschäftigung vorausgeht oder parallel zu ihr läuft. Ein Kandidat kann während des Studiums arbeiten, die beiden dürfen sich also überschneiden; ein Abschluss, der vor dem arbeitsfähigen Alter erworben wurde, ist dagegen ein Defekt. Hier müssen ein erzeugtes Geburtsdatum und eine erzeugte Ausbildungshistorie auseinander abgeleitet werden und nicht unabhängig voneinander gezogen werden.
Die vierte Regel betrifft die Gegenwart. Genau eine Station kann aktuell sein, und sie sollte kein Enddatum haben. Ein Datensatz, in dem mehrere Stationen als aktuell markiert sind, oder in dem die letzte Station vor Jahren endete, während der Kandidat als aktiv suchend beschrieben wird, erzeugt widersprüchliche Signale, die eine echte Screening-Pipeline markieren würde.
Als fünfte Regel gehört die Plausibilität der Dauer dazu. Eine Station von zwei Wochen, gefolgt von einer Führungsrolle, ist ebenso auffällig wie eine Station, die dreißig Jahre dauert. Solche Werte sind als Negativfälle wertvoll, als Standardwerte zerstören sie die Aussagekraft des Datensatzes.
Warum brauchen Jobtitel und Branchen eine Taxonomie?
Ein Jobtitel ist kein freier Text mit einer klaren Bedeutung. Dieselbe Tätigkeit heißt in verschiedenen Unternehmen, Branchen und Ländern anders, und das Niveau, das ein Titel nahelegt, variiert mit allen drei Faktoren. Ein Generator, der ein zufälliges Senioritätswort mit einem zufälligen Substantiv verkettet, erzeugt Titel, die kein System richtig gruppiert.
Der nützliche Ansatz ist eine Taxonomie, in der jeder Titel zu einer Funktion und einer Stufe gehört und jede Funktion zu einer Menge von Branchen, in denen sie plausibel vorkommt. Ein Titel aus der falschen Branche ist ein Datensatz, den ein Matching-Algorithmus unsinnig bewertet; eine Stufe, die den Jahren an Erfahrung im Datensatz widerspricht, ist ein Datensatz, dem eine prüfende Person sofort misstraut. Der Artikel zu den Jobtiteln nach Branche erklärt, wie die Gruppierungen aufgebaut sind.
Skills folgen derselben Logik. Eine Skillliste sollte für die Rolle plausibel sein, und eine Seniorrolle sollte eine andere Mischung tragen als eine Juniorrolle. Skillstufen werden üblicherweise auf einer Skala ausgedrückt, und ein Datensatz, der für jeden Skill die höchste Stufe behauptet, ist so wenig aussagekräftig wie einer, der nichts behauptet. Der Artikel zur Skill-Taxonomie und ihren Stufen behandelt, wie die Skalen definiert werden und warum die Zahl der Stufen zählt.
Zertifizierungen und Lizenzen fügen eine dritte Dimension hinzu, weil manche Rollen sie erfordern und andere nicht und weil eine Lizenz üblicherweise an eine Jurisdiktion gebunden ist. Ein Datensatz, der eine von einem Land ausgestellte Lizenz behauptet, während die Beschäftigungshistorie in einem anderen Land liegt, ist ein Kohärenzdefekt, den man absichtlich als Negativfall erzeugen sollte. Der Artikel zu den Lizenz- und Zertifizierungsdaten beschreibt die Muster.
Wichtig ist auch die Abkürzungsdimension. Titel enthalten häufig Kurzformen, Fachkürzel oder interne Bezeichnungen, und eine Taxonomie, die nur die Langform kennt, gruppiert die Kurzform keinem Cluster zu. Ein Testdatensatz sollte beide Schreibweisen desselben Titels enthalten, damit die Normalisierung im Matching geprüft wird und nicht nur die Gruppierung.
Wie sind Gehalt und Währung zu behandeln?
Das Gehalt ist das Feld, das am wahrscheinlichsten in einer Form gespeichert wird, die später keine Fragen mehr beantworten kann. Eine Zahl ohne Währung und ohne Zeitraum ist kein Gehalt; sie ist eine Zahl. Ein Betrag bedeutet als Jahreswert in einer Währung etwas anderes als als Monatswert in einer anderen, und ein Datensatz, der beide Felder auslässt, erzeugt Berichte, die niemand mehr abgleichen kann.
Das nützliche Modell speichert einen Betrag, einen Währungscode und einen Zeitraum wie jährlich oder monatlich und behandelt alle drei gemeinsam als erforderlich. Weicht die Währung vom Land der Rolle ab, sollte der Datensatz das bewusst sagen und nicht versehentlich, weil grenzüberschreitende Vergütung ein realer Fall ist, den eine Testsuite enthalten sollte. Der Artikel zur Länderauswahl für Testdaten ordnet diese Kombinationen in die breitere Länderabdeckung ein.
Die Währungsformatierung führt eine zweite Fehlerklasse ein. Tausendertrennzeichen, Dezimaltrennzeichen, die Position des Währungssymbols und negative Beträge sind alle landesabhängig, und ein Parser, der eine Konvention annimmt, liest Werte aus einer anderen falsch. Erzeugte Datensätze geben Ihnen einen billigen Weg, mehrere Konventionen durch denselben Codepfad zu schicken, einschließlich der Umkehrung, die aus einem Dezimalkomma ein Tausendertrennzeichen macht.
Den Währungscode neben dem Betrag zu führen, statt ihn aus dem Land abzuleiten, ist das, was diese Assertions stabil hält, wenn derselbe Datensatz unter einem anderen Länderumfeld gelesen wird. Sobald der Code fehlt, hängt die Interpretation an einer Länderzuordnung, die sich ändern kann, ohne dass sich der Betrag ändert.
Spanne und Grenzwerte verdienen einen eigenen Test. Viele Formulare akzeptieren ein Minimum und ein Maximum, und die Beziehung zwischen ihnen ist dieselbe Art von Einschränkung wie bei den Beschäftigungsdaten: das Minimum darf das Maximum nicht überschreiten. Negative Werte und die Null gehören ebenfalls dazu, weil eine Pipeline, die sie klaglos speichert, irgendwann eine unsinnige Anzeige ausliefert.
Die Aufbewahrung verdient einen eigenen Test. Ein Kandidatendatensatz trägt ein Löschedatum oder einen Richtlinienhorizont, und der Ablauf, der einen Datensatz nach Ablauf dieses Horizonts anonymisiert oder entfernt, ist leicht falsch zu bauen und wird selten mit einer kontrollierten Uhr geprüft. Erzeugte Datensätze mit verschiebbaren Datumsangaben machen diesen Ablauf prüfbar, ohne dass echte Zeit vergehen muss. Warum die Fristen sich nach Jurisdiktion unterscheiden und was sie schützen, behandelt der Artikel zu den Datenschutzregeln für Testidentitäten.
Was sollten Tests für Bewerbungsformulare prüfen?
Prüfen Sie das Parsen, nicht nur die Eingabe. Senden Sie ein erzeugtes Dokument ab und vergleichen Sie die geparsten Felder mit dem Datensatz, der es erzeugt hat, Name für Name und Datum für Datum. Dieser eine Test ist der wertvollste in der Suite, weil er den gesamten Extraktionspfad abdeckt und nicht nur das Formular.
Prüfen Sie die Chronologie-Validatoren mit absichtlich kaputten Datensätzen: ein Enddatum vor einem Startdatum, zwei aktuelle Rollen, ein Ausbildungseintrag, der vor dem Geburtsdatum beginnt. Jeder sollte eine spezifische Zurückweisung auslösen und keinen pauschalen Fehler, und diese Spezifität ist selbst eine Eigenschaft, die eine Assertion verdient.
Prüfen Sie den Pfad für Aufbewahrung und Löschung. Ein Kandidatendatensatz trägt eine Aufbewahrungsfrist, und ein System, das Datensätze unbegrenzt behält, ist ein Compliance-Problem und kein Funktionstest-Problem, was es in einer funktionalen Suite leicht übersehbar macht.
Prüfen Sie die Felder an ihren Grenzen. Eine Skillliste ohne Einträge, eine Karrierehistorie mit einer einzigen Station, ein Name mit einem Apostroph oder einem diakritischen Zeichen, ein Arbeitgebername genau an der Feldlängengrenze. Der Artikel zu den Testfällen für Bewerbungsformulare sammelt diese in einer wiederverwendbaren Datei, und der Karrieredaten-Generator auf dieser Seite erzeugt Datensätze, die die Kohärenzregeln bereits erfüllen, sodass nur noch die Grenzfälle zu variieren sind.
Was ein synthetischer Lebenslauf ist und was nicht
Ein erzeugter Lebenslauf beschreibt niemanden. Der Name ist erfunden, die Arbeitgeber sind erfunden, die Daten sind erfunden und die Erfolge sind erfunden. Nichts in dem Datensatz entspricht der Geschichte einer realen Person, und kein in einem erzeugten Datensatz genannter Arbeitgeber hat je jemanden beschäftigt.
Genau deshalb ist der Datensatz in Tests unbedenklich einsetzbar. Weil kein realer Kandidat beschrieben wird, kann eine Fixture keine Kandidatendaten preisgeben, und ein Screenshot einer Staging-Umgebung kann keine Beschäftigungshistorie offenlegen. Der Artikel zu den synthetischen und anonymisierten Daten erklärt, warum erfundene Datensätze und de-identifizierte Datensätze verschiedene Dinge sind und warum nur der erste frei von Re-Identifikationsrisiko ist.
Die Grenze zählt auch für die Aufbewahrung. Ein synthetischer Datensatz hat keine Person mit Rechten daran, aber er kann im selben System wie echte Datensätze liegen, und ein Datensatzbestand, der beide mischt, ist einer, in dem Löschanfragen schwer zu erfüllen sind. Halten Sie erzeugte Datensätze als erzeugt erkennbar und halten Sie sie aus jedem Speicher heraus, der echte Kandidatendaten enthält.
Jeder so erzeugte Datensatz ist synthetischer Testdatenbestand ausschließlich für Softwaretests. Er darf nicht als Bewerbung einer Person eingereicht werden, nicht verwendet werden, um einen Kandidaten oder einen Arbeitgeber vorzutäuschen, nicht verwendet werden, um eine Stelle oder ein Zertifikat zu erlangen, und nicht verwendet werden, um ein System zu prüfen, das Sie nicht betreiben.